Keine der Antworten hier hat mir geholfen, aber schließlich habe ich MySQL 5.6 zum Laufen gebracht.
DREI Optionen, um MySQL 5.6 zu reparieren:
-
(bestätigt) Bearbeiten Sie
/etc/my.cnf
(erstellen falls nicht vorhanden) und hinzufügen:[mysqld] innodb_file_per_table = OFF
und starten Sie MySQL neu. Damit dies funktioniert, müssen Sie Ihre Datenbanken in eine SQL-Datei (mysqldump) kopieren, dann die Datenbanken löschen und neu erstellen und dann die Daten zurückladen.
-
Ändern Sie den standardmäßigen ulimit-Wert von OSX (vorgeschlagen vom Github-Benutzer sodabrew ). ):https://superuser.com/questions/261023/how-to-change-default-ulimit-values-in-mac-os-x-10-6
-
Fügen Sie die folgende Option zum Abschnitt [mysqld] von my.cnf hinzu:
table_open_cache = 250
. Standardmäßig ist es auf 2000 eingestellt, was weit über dem Standard-ulimit von OSX liegt. Diese Lösung wird auch nicht empfohlen, da sie die Leistung Ihres MySQL beeinträchtigt - sie zwingt MySQL, Tabellen häufig neu zu öffnen, wenn Sie mehr als 250 Tabellen haben:https://mariadb.com/kb/en/optimizing-table_open_cache/
Warum tritt dieser Fehler auf?
Seit MySQL 5.6 ist die Option innodb_file_per_table standardmäßig aktiviert, was bedeutet, dass die Daten jeder Tabelle in einer eigenen Datei gespeichert werden. Das OSX-Standardlimit für die Anzahl der geöffneten Dateien beträgt 256 pro Prozess. Normalerweise ist dies kein Problem, aber in meinem Fall führe ich Unit-Tests parallel aus, wodurch 8 Datenbanken mit jeweils 405 Tabellen erstellt werden. OSX hat eine Begrenzung der Anzahl offener Datei-Handles pro Prozess. Diese StackOverflow-Antwort schlägt vor, dass dieses Limit 256 ist, was mein Problem perfekt erklärt:Vor MySQL 5.6 befanden sich alle Daten aus all diesen 8 Datenbanken in EINER Datei.
Danke an meinen Kollegen Thomas L., der einen MySQL-Fehlerbericht gefunden hat was auf diese Lösung hinwies!