Żadna z odpowiedzi mi nie pomogła, ale w końcu udało mi się uruchomić MySQL 5.6.
TRZY opcje naprawy MySQL 5.6:
-
(potwierdzone) Edytuj
/etc/my.cnf(utwórz, jeśli nie istnieje) i dodaj:[mysqld] innodb_file_per_table = OFF
i uruchom ponownie MySQL. Następnie, aby to zadziałało, musisz zrzucić swoje bazy danych do pliku SQL (mysqldump), a następnie upuścić i ponownie utworzyć bazy danych, a następnie załadować dane z powrotem.
-
Zmień domyślną wartość ulimit OSX (sugerowana przez użytkownika Github sodabrew ):https://superuser.com/questions/261023/jak-zmienić-domyślne-ulimit-wartości-w-mac-os-x-10-6
-
Dodaj następującą opcję do sekcji [mysqld] my.cnf:
table_open_cache = 250. Domyślnie jest ustawiony na 2000, czyli znacznie powyżej domyślnego ulimitu OSX. To rozwiązanie również nie jest zalecane, ponieważ zmniejsza wydajność MySQL - zmusza MySQL do częstego otwierania tabel, jeśli masz więcej niż 250 tabel:https://mariadb.com/kb/en/optimizing-table_open_cache/
Dlaczego ten błąd występuje?
Od MySQL 5.6 opcja innodb_file_per_table jest domyślnie WŁĄCZONA, co oznacza, że dane każdej tabeli są przechowywane w osobnym pliku. Domyślny limit OSX liczby otwartych plików to 256 na proces. Zwykle nie stanowi to problemu, ale w moim przypadku równolegle przeprowadzam testy jednostkowe, które tworzą 8 baz danych po 405 tabel każda. OSX ma limit liczby otwartych uchwytów plików na proces. Ta odpowiedź StackOverflow sugeruje, że ten limit wynosi 256, co doskonale wyjaśnia mój problem:przed MySQL 5.6 wszystkie dane ze wszystkich tych 8 baz danych znajdowały się w JEDNYM pliku.
Dziękuję mojemu koledze Thomasowi L., który znalazł zgłoszenie błędu MySQL co zasugerowało to rozwiązanie!
