MAMP PRO ulega awarii; MySQL nie uruchamia się po ponownym uruchomieniu

PRZEDMOWA: Brzmi to źle, ale przed podjęciem działania przeczytaj wszystko w tej odpowiedzi. Nie możesz zepsuć rzeczy gorszych, nie spiesząc się. Przeczytaj każdy krok i miejmy nadzieję, że będzie to wystarczająco jasne, abyś mógł śledzić i ponownie uruchomić serwer bazy danych MySQL w MAMP Pro.

Wygląda więc na to, że Twoje bazy danych InnoDB uległy awarii. Nie sama aplikacja. Klucz znajduje się tutaj w dzienniku:

140527 15:06:58 InnoDB: highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 791075520
140527 15:06:58  InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
InnoDB: Doing recovery: scanned up to log sequence number 791076717
InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 8402.
InnoDB: You may have to recover from a backup.

Wygląda na to, że używasz tutaj MAMP PRO:

/Library/Application Support/appsolute/MAMP PRO/db/mysql

Pytanie brzmi, czy masz kopię zapasową baz danych MAMP Pro? Albo przez mysqldump albo coś innego? Czy masz inne bazy danych InnoDB w swojej instalacji MAMP?

Mówisz też, że udało Ci się uruchomić mysqldump , ale naprawdę nie jest możliwe, aby baza danych uległa awarii. Tak więc zakładam, że uruchomiłeś mysqldump to była kolejna, osobna instalacja MySQL w twoim systemie. Pliki binarne MySQL, takie jak mysqldump w MAMP lub MAMP Pro nie są takie same jak ogólnosystemowe mysqldump . Są to dwie w 100% różne instalacje. Możesz sprawdzić, który mysqldump jest używany przez wpisanie tego polecenia:

which mysqldump

Aby zobaczyć pełną ścieżkę tego, z czego, jak sądzisz, korzystałeś. Instalacja MAMP mysqldump —i inne powiązane pliki binarne—znajdują się tutaj:

/Applications/MAMP/Library/bin/

I uruchomić go bezpośrednio bez modyfikowania $PATH value (cała inna rzecz) polega na uruchomieniu go w ten sposób:

/Applications/MAMP/Library/bin/mysqldump

PROSZĘ UWAŻNIE PRZECZYTAĆ: Proszę zwrócić uwagę, że rada, którą udzielam poniżej, przedstawiam wszystkie sposoby, w jakie poradziłbym sobie w takiej sytuacji. Jeśli baza danych InnoDB nie jest ważna, po prostu zrób moją pierwszą sugestię, aby usunąć pliki DB specyficzne dla InnoDB. Jeśli masz mysqldump wykonaj kopię zapasową, zrób to samo, ale odzyskaj mysqldump kopia zapasowa.

Ponadto InnoDB nie domyślny silnik pamięci masowej. Musisz zrobić wszystko, aby to ustawić. Wartość domyślna to MyISAM. Każda nowa baza danych utworzona w MySQL będzie MyISAM. Więc to ci pomoże. Musisz założyć limit myślenia, aby dowiedzieć się, które bazy danych mają ustawione silniki przechowywania InnoDB. Jeśli powiesz, że masz 25, ale tylko 1 ma InnoDB, proste rozwiązanie. Ale także, jeśli masz 25 baz danych, powinieneś przyzwyczaić się do regularnego tworzenia mysqldump kopie zapasowe. Gdybyś miał kopie zapasowe, byłby to ból głowy, ale prosta sprawa do rozwiązania.

JEDNA OPCJA:Usuń uszkodzone elementy InnoDB i odzyskaj z mysqldump kopia zapasowa.

Pierwszą rzeczą, którą bym zrobił, gdybym był Ty, to wykonać kopię zapasową mysql katalog w /Library/Application Support/appsolute/MAMP PRO/db/ więc możesz mieć przynajmniej kopię zapasową uszkodzonych plików na wszelki wypadek.

Następnie usunę następujące pliki:

/Library/Application Support/appsolute/MAMP PRO/db/mysql/ib_logfile0
/Library/Application Support/appsolute/MAMP PRO/db/mysql/ib_logfile1
/Library/Application Support/appsolute/MAMP PRO/db/mysql/ibdata1

Są to pliki specyficzne dla InnoDB. Usuń je, a następnie spróbuj ponownie uruchomić MAMP. Powinno się pojawić. Ale każda baza danych InnoDB w MAMP będzie w stanie „zombie”. Powinieneś usunąć te bazy danych i odtworzyć je z kopii zapasowej. Lub od zera, jeśli możesz.

INNA OPCJA:spróbuj ponownie uruchomić serwer MySQL za pomocą innodb_force_recovery .

Teraz, jeśli potrzebujesz odzyskać tę bazę danych, możesz uruchomić próbę ustawienia innodb_force_recovery jak opisano tutaj.

W przypadku MAMP Pro wygląda na to, że możesz edytować plik konfiguracyjny MySQL zgodnie z tymi instrukcjami:

1. Uruchom MAMP Pro.
2. Zatrzymaj serwer MAMP Pro, jeśli jest uruchomiony.
3. Wybierz plik -> Edytuj szablon -> MySQL my.cnf
4. Pojawi się okno edytora.
5. Jeśli pojawi się komunikat ostrzegawczy, potwierdź przyciskiem OK.
6. Znajdź sekcję „[mysqld]”
7. Pod ostatnim wierszem tej sekcji dodaj ten wiersz:innodb_force_recovery = 1

Oraz jak wyjaśnia dokumentacja MySQL , służy to wyłącznie uruchomieniu i uruchomieniu bazy danych, dzięki czemu można wykonać kopię zapasową za pomocą mysqldump :

Teraz istnieje około 6 różnych wartości dla innodb_force_recovery ale tak naprawdę powinieneś próbować tylko z 1 Na razie. Jeśli chcesz spróbować każdego z 6, oto podział:

Jeśli zdarzy ci się uruchomić bazę danych i wykonać mysqldump to gratulacje! Jesteś czysty! Najlepsze następne kroki to

1. Zatrzymaj serwer bazy danych MySQL
2. Usuń innodb_force_recovery opcja z konfiguracji MySQL, aby serwer bazy danych mógł działać normalnie.
3. Uruchom ponownie serwer bazy danych MySQL.
4. Usuń uszkodzoną bazę danych MySQL z serwera (nie usuwaj pliku zrzutu! To jest twoja kopia zapasowa!)
5. Utwórz nową bazę danych, którą chcesz odzyskać.
6. Zaimportuj mysqldump kopia zapasowa do nowej bazy danych.

I powinieneś skończyć.