Są chwile, kiedy jesteśmy wyczerpani długim dniem i popełniamy błędy, które kosztują cały zespół dużo czasu.
Wczoraj testowałem różne metody tworzenia kopii zapasowych i odzyskiwania obsługiwane przez ZRM, usługa tworzenia kopii zapasowych MySQL w nadchodzącej wersji. ZRM dla MySQL wymaga włączenia rejestrowania binarnego na serwerze MySQL. Podczas testów zabrakło miejsca na dysku i usunąłem dzienniki binarne.
Przypadkowo usunąłem ostatni dziennik binarny używany przez serwer MySQL, a serwer MySQL używa najnowszego dziennika binarnego do uruchomienia swojego demona.
Krótka wersja - w ogóle nie mogłem uruchomić serwera MySQL.
Odzyskaj dzienniki binarne MySQL: Śledzenie stosu podczas próby uruchomienia serwera
$ service mysqld start
061031 17:38:48 mysqld uruchomiony
061031 17:38:48 InnoDB: Rozpoczęto; numer kolejny dziennika 14 1645228884
/ usr / libexec / mysqld: Nie znaleziono pliku '/var/lib/mysql/mysql-bin.000017' (kod błędu: 2)
061031 17:38:48 [BŁĄD] Nie można otworzyć dziennika (plik „/var/lib/mysql/mysql-bin.000017”, errno 2)
061031 17:38:48 [BŁĄD] Nie można otworzyć pliku dziennika
061031 17:38:48 [BŁĄD] Nie można zainicjować dziennika tc
061031 17:38:48 [BŁĄD] Przerwanie
061031 17:38:48 InnoDB: Rozpoczynanie wyłączania ...
061031 17:38:51 InnoDB: Wyłączenie zakończone; numer kolejny dziennika 14 1645228884
061031 17:38:51 [Uwaga] / usr / libexec / mysqld: Zamykanie zakończone
061031 17:38:51 mysqld zakończył się
Dziękuję Aishwaryi za przekazanie mi pomysłów na rozwiązanie problemu. Plik indeksu dziennika binarnego (/var/lib/mysql/mysql-bin.index) przechowuje informacje o najnowszym pliku dziennika binarnego. Usunięcie pliku indeksu rozwiązuje problem. Oczywiście miałem kopie zapasowe bazy danych przy użyciu ZRM dla MySQL i mogłem odzyskać dane do dowolnego punktu w czasie przed usunięciem dziennika binarnego.
Podsumowując: nie usuwaj najnowszego pliku dziennika binarnego, aby zaoszczędzić miejsce na dysku i regularnie wykonuj kopie zapasowe. Preferowany jest ZRM, a oto plik link więcej informacji
