Aucune des réponses ici ne m'a aidé, mais j'ai finalement réussi à faire fonctionner MySQL 5.6.
TROIS options pour corriger MySQL 5.6 :
-
(confirmé) Modifier
/etc/my.cnf(créer s'il n'existe pas) et ajouter :[mysqld] innodb_file_per_table = OFF
et redémarrez MySQL. Ensuite, pour que cela fonctionne, vous devrez vider vos bases de données dans un fichier SQL (mysqldump), puis supprimer et recréer les bases de données, puis recharger les données.
-
Modifier la valeur ulimit par défaut d'OSX (suggéré par l'utilisateur Github sodabrew ):https://superuser.com/questions/261023/how-to-change-default-ulimit-values-in-mac-os-x-10-6
-
Ajoutez l'option suivante à la section [mysqld] de my.cnf :
table_open_cache = 250. Par défaut, il est défini sur 2000, ce qui est bien au-dessus de l'ulimit par défaut d'OSX. Cette solution est également déconseillée, car elle nuit aux performances de votre MySQL - elle oblige MySQL à rouvrir souvent les tables, si vous avez plus de 250 tables :https://mariadb.com/kb/en/optimizing-table_open_cache/
Pourquoi cette erreur se produit ?
Depuis MySQL 5.6, l'option innodb_file_per_table est activée par défaut, ce qui signifie que les données de chaque table sont stockées dans son propre fichier. La limite par défaut d'OSX du nombre de fichiers ouverts est de 256 par processus. Normalement, ce n'est pas un problème, mais dans mon cas, j'exécute des tests unitaires en parallèle, ce qui crée 8 bases de données avec 405 tables chacune. OSX a une limite du nombre de descripteurs de fichiers ouverts par processus. Cette réponse StackOverflow suggère que cette limite est de 256, ce qui explique parfaitement mon problème :avant MySQL 5.6, toutes les données de ces 8 bases de données étaient dans UN SEUL fichier.
Merci à mon collègue Thomas L. qui a trouvé un rapport de bogue MySQL qui a suggéré cette solution !
