Geen van de antwoorden hier heeft me geholpen, maar uiteindelijk kreeg ik MySQL 5.6 aan het werk.
DRIE opties om MySQL 5.6 te repareren:
-
(bevestigd) Bewerk
/etc/my.cnf(maak aan indien niet bestaat) en voeg toe:[mysqld] innodb_file_per_table = OFF
en start MySQL opnieuw. Om dit te laten werken, moet u uw databases in een SQL-bestand (mysqldump) dumpen, vervolgens de databases neerzetten en opnieuw maken, en vervolgens de gegevens opnieuw laden.
-
Wijzig de standaard ulimit-waarde van OSX (aanbevolen door Github-gebruiker sodabrew ):https://superuser.com/questions/261023/how-to-change-default-ulimit-values-in-mac-os-x-10-6
-
Voeg de volgende optie toe aan het [mysqld]-gedeelte van my.cnf:
table_open_cache = 250. Standaard is deze ingesteld op 2000, wat ver boven de standaard ulimit van OSX ligt. Deze oplossing wordt ook niet aanbevolen, omdat het de prestaties van uw MySQL schaadt - het dwingt MySQL om tabellen vaak opnieuw te openen, als u meer dan 250 tabellen heeft:https://mariadb.com/kb/en/optimizing-table_open_cache/
Waarom gebeurt deze fout?
Aangezien MySQL 5.6 innodb_file_per_table optie standaard AAN is, wat betekent dat de gegevens van elke tabel in zijn eigen bestand worden opgeslagen. De standaardlimiet van OSX voor het aantal geopende bestanden is 256 per proces. Normaal gesproken is dit geen probleem, maar in mijn geval voer ik unit-tests parallel uit, waardoor 8 databases met elk 405 tabellen worden gemaakt. OSX heeft een limiet voor het aantal geopende bestandshandles per proces. Dit StackOverflow-antwoord suggereert dat deze limiet 256 is, wat mijn probleem perfect verklaart:vóór MySQL 5.6 stonden alle gegevens van al deze 8 databases in EEN bestand.
Met dank aan mijn collega Thomas L. die een MySQL-bugrapport heeft gevonden die deze oplossing liet doorschemeren!