Ninguna de las respuestas aquí me ayudó, pero finalmente conseguí que MySQL 5.6 funcionara.
TRES opciones para arreglar MySQL 5.6:
-
(confirmado) Edite
/etc/my.cnf(crear si no existe) y agregar:[mysqld] innodb_file_per_table = OFF
y reinicie MySQL. Luego, para que esto funcione, deberá volcar sus bases de datos en un archivo SQL (mysqldump), luego soltar y volver a crear las bases de datos, luego volver a cargar los datos.
-
Cambie el valor ulimit predeterminado de OSX (sugerido por el usuario de Github sodabrew ):https://superuser.com/questions/261023/how-to-change-default-ulimit-values-in-mac-os-x-10-6
-
Agregue la siguiente opción a la sección [mysqld] de my.cnf:
table_open_cache = 250. De forma predeterminada, está configurado en 2000, que está muy por encima del ulimit predeterminado de OSX. Esta solución tampoco se recomienda, porque perjudica el rendimiento de su MySQL:obliga a MySQL a volver a abrir las tablas con frecuencia, si tiene más de 250 tablas:https://mariadb.com/kb/en/optimizing-table_open_cache/
¿Por qué ocurre este error?
Desde MySQL 5.6, la opción innodb_file_per_table está activada de forma predeterminada, lo que significa que los datos de cada tabla se almacenan en su propio archivo. El límite predeterminado de OSX para el número de archivos abiertos es de 256 por proceso. Normalmente esto no es un problema, pero en mi caso estoy ejecutando pruebas unitarias en paralelo, lo que crea 8 bases de datos con 405 tablas cada una. OSX tiene un límite en la cantidad de identificadores de archivos abiertos por proceso. Esta respuesta de StackOverflow sugiere que este límite es 256, lo que explica perfectamente mi problema:antes de MySQL 5.6, todos los datos de estas 8 bases de datos estaban en UN archivo.
Gracias a mi colega Thomas L. que encontró un informe de errores de MySQL que insinuó esta solución!
