Taa, problem był podejrzewam spowodowany przez awarię serwera w SLDC, na której stał nasz VPS.
Wyłączenie spowodowało dataloss.
Przez awaryjne wyłączenie, logi transakcyjne były wybrakowane. Generalnie daemon mysql próbował robić rollbacka na pozycji w logu, która nie istniała (w wyniku wyłączenia awaryjnego dane zostały utracone)
W poniższym wpisie widzimy, że linijek wczytanych z loga jest 1108141056, a checkpoint z którego miał być robiony rollback jest ustawiony na 1108141186:
Kod: Zaznacz cały
[ERROR] InnoDB: We scanned the log up to 1108141056. A checkpoint was at 1108141186 and the maximum LSN on a database page was 0. It is possible that the database is now corrupt!
Takie info są niestety na sztywno wpisane (ibdata0, ibdata1), zatem zmiana byłaby upierdliwa.
Daemon ruszał bezproblemowo po ustawieniu parametru innodb_force_recovery=3 (pomijanie rollbacków transakcji).
Problemem jednak był fakt, że nie dało się go zamknąć - daemon oczekiwał na zakończenie transakcji cały czas.
Polecenie kill -9 <pid> powodowało, że owszem - proces znikał, jednakże w jego miejsce pojawiały się następne, co summa summarum wieszało nasz serwer w chwili, gdy go restartowałem. xD
Odwinąłem backup z 24.11.2016 roku i wszystko śmiga.
Kroki które poczyniłem w celu rozwiązania usterki:
1. Backup katalogu /var/lib/mysql,
2. Stworzyłem nowy katalog, który jest teraz głównym katalogiem mysqla. Skopiowałem ze starego katalogu bazę główną mysqla (do tego chown, odpowiedni chmod) i puściłem mysql_upgrade (zauważyłem, że performance.schema dostała porażenia mózgowego) - nie chciało mi się bawić w tworzenie userów od nowa, a w niej wszystkie informacje były zawarte.
Po drodze też odbudowałem tabele:
Kod: Zaznacz cały
+----------------------+
| table_name |
+----------------------+
| innodb_index_stats |
| innodb_table_stats |
| slave_master_info |
| slave_relay_log_info |
| slave_worker_info |
+----------------------+
3. Zrestartowałem daemona,
4. Odwinąłem backupy forum i bloga,
5. Póki co wszystko bangla.
Cóż, zaczynam coraz mocniej zastanawiać się nad zmianą providera, SLDC z czego zauważyłem ma dość mierne SLA.
Poza tym, parawirtualizacja ssie. Cholernie ogranicza nam pole manewru.