Mysql rozbił się i nie chce się uruchomić

Nasz produkcyjny serwer mysql właśnie się zawiesił i nie chce wrócić. Daje błąd segfault. Próbowałem zrestartować komputer i po prostu nie wiem, co jeszcze spróbować. Oto stacktrace:

140502 14:13:05 [Uwaga] Wtyczka „FEDERATED” jest wyłączona.
InnoDB: skanowanie dziennika przebiegło poza punkt kontrolny lsn 108 1057948207
140502 14:13:06 InnoDB: Baza danych nie została zamknięta normalnie!
InnoDB: Rozpoczęcie odzyskiwania po awarii.
InnoDB: odczyt informacji o obszarze tabel z plików .ibd ...
InnoDB: Przywracanie możliwych częściowo zapisanych stron danych z podwójnego zapisu
InnoDB: bufor ...
InnoDB: Trwa odzyskiwanie: skanowano do numeru sekwencji dziennika 108 1058059648
InnoDB: 1 transakcje, które należy wycofać lub wyczyścić
InnoDB: w sumie 15 operacji wiersza do cofnięcia
InnoDB: Licznik identyfikatora Trx to 0 562485504
140502 14:13:06 InnoDB: Rozpoczęcie stosowania partii rekordów dziennika do bazy danych ...
InnoDB: Postęp w procentach: 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 
InnoDB: Zastosuj partię zakończoną
InnoDB: Rozpoczęcie w tle wycofywania niezaangażowanych transakcji
140502 14:13:06 InnoDB: Cofanie trx z identyfikatorem 0 562485192, 15 rzędów do cofnięcia
140502 14:13:06 InnoDB: Rozpoczęty; numer kolejny dziennika 108 1058059648
140502 14:13:06 InnoDB: Błąd potwierdzenia w wątku 1873206128 w pliku ../../../storage/innobase/fsp/fsp0fsp.c linia 1593
InnoDB: Niepowodzenie asercji: frag_n_used> 0
InnoDB: Celowo generujemy pułapkę pamięci.
InnoDB: Prześlij szczegółowy raport o błędzie na stronie http://bugs.mysql.com.
InnoDB: Nawet jeśli powtarzają się awarie lub awarie asercji
InnoDB: może być natychmiast po uruchomieniu mysqld
InnoDB: uszkodzenie w obszarze tabel InnoDB. Należy zapoznać się
InnoDB: http://dev.mysql.com/doc/refman/5.1/en/forcing-recovery.html
InnoDB: o wymuszaniu odzyskiwania.
140502 14:13:06 - mysqld dostał sygnał 6;
Przyczyną może być błąd. Możliwe jest również, że ten plik binarny
lub jedna z bibliotek, z którymi była połączona, jest uszkodzona, niepoprawnie zbudowana,
lub źle skonfigurowane. Ten błąd może być również spowodowany nieprawidłowym działaniem sprzętu.
Postaramy się jak najlepiej zebrać trochę informacji, które, mam nadzieję, pomogą zdiagnozować
problem, ale skoro już się rozbiliśmy, coś jest zdecydowanie nie tak
i to może się nie powieść.

key_buffer_size = 16777216
read_buffer_size = 131072
max_used_connections = 0
max_threads = 151
Thread_connected = 0
Możliwe, że mysqld może użyć do 
key_buffer_size + (read_buffer_size + sort_buffer_size) * max_threads = 345919 K
bajty pamięci
Mam nadzieję, że w porządku; jeśli nie, zmniejsz niektóre zmienne w równaniu.

thd: 0x0
Próba śledzenia wstecznego. Aby to sprawdzić, możesz użyć następujących informacji
gdzie zmarł mysqld. Jeśli po tym nie widzisz żadnych wiadomości, coś poszło
strasznie źle ...
stack_bottom = (zero) thread_stack 0x30000
140502 14:13:06 [Uwaga] Harmonogram zdarzeń: Załadowano 0 zdarzeń
140502 14:13:06 [Uwaga] / usr / sbin / mysqld: gotowy na połączenia.
Wersja: Gniazdo „5.1.41-3ubuntu12.10”: Port „/var/run/mysqld/mysqld.sock”: 3306 (Ubuntu)
/ usr / sbin / mysqld (mój_druk_stacktrace + 0x2d) [0xb7579cbd]
/ usr / sbin / mysqld (handle_segfault + 0x494) [0xb7245854]
[0xb6fc0400]
/lib/tls/i686/cmov/libc.so.6(abort+0x182) [0xb6cc5a82]
/ usr / sbin / mysqld (+ 0x4867e9) [0xb74647e9]
/ usr / sbin / mysqld (btr_page_free_low + 0x122) [0xb74f1622]
/ usr / sbin / mysqld (btr_compress + 0x684) [0xb74f4ca4]
/ usr / sbin / mysqld (btr_cur_compress_if_useful + 0xe7) [0xb74284e7]
/ usr / sbin / mysqld (btr_cur_pessimistic_delete + 0x332) [0xb7429e72]
/ usr / sbin / mysqld (btr_node_ptr_delete + 0x82) [0xb74f4012]
/ usr / sbin / mysqld (strona btr_discard + 0x175) [0xb74f41e5]
/ usr / sbin / mysqld (btr_cur_pessimistic_delete + 0x3e8) [0xb7429f28]
/ usr / sbin / mysqld (+ 0x526197) [0xb7504197]
/ usr / sbin / mysqld (row_undo_ins + 0x1b1) [0xb7504771]
/ usr / sbin / mysqld (row_undo_step + 0x25f) [0xb74c210f]
/ usr / sbin / mysqld (wątki_ruchu_pole + 0x58a) [0xb74a31da]
/ usr / sbin / mysqld (trx_rollback_or_clean_all_without_sess + 0x3e3) [0xb74ded43]
/lib/tls/i686/cmov/libpthread.so.0(+0x596e) [0xb6f9f96e]
/lib/tls/i686/cmov/libc.so.6(clone+0x5e) [0xb6d65a4e]
Strona podręcznika pod adresem http://dev.mysql.com/doc/mysql/en/crashing.html zawiera
informacje, które powinny pomóc Ci dowiedzieć się, co powoduje awarię.

Jakieś rekomendacje?

Auć.

InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.1/en/forcing-recovery.html
InnoDB: about forcing recovery.

Sprawdź sugerowaną stronę internetową: http://dev.mysql.com/doc/refman/5.1/en/forcing-recovery.html .

Zasadniczo spróbuj uruchomić serwer MySQL w trybie odzyskiwania i zrób kopię zapasową uszkodzonych tabel .

Edytuj swój /etc/my.cnfi dodaj:

 innodb_force_recovery = 1

... aby sprawdzić, czy możesz dostać się do bazy danych i uzyskać dane / znaleźć uszkodzoną tabelę.

Zwykle, gdy tak się dzieje, jest to przebudowa (przynajmniej zepsuty stół lub dwa).

Od http://chepri.com/mysql-innodb-corruption-and-recovery/ :

1. Stop mysqld( service mysql stop).
2. Utworzyć kopię zapasową /var/lib/mysql/ib*

3. Dodaj następujący wiersz do /etc/my.cnf:

   innodb_force_recovery = 1
   

   (sugerują 4, ale najlepiej zacząć od 1 i zwiększyć, jeśli się nie uruchomi)

4. Restart mysqld( service mysql start).

5. Zrzuć wszystkie tabele: mysqldump -A > dump.sql
6. Usuń wszystkie bazy danych, które wymagają odzyskania.
7. Stop mysqld( service mysql stop).
8. Usunąć /var/lib/mysql/ib*
9. Skomentuj innodb_force_recoveryw/etc/my.cnf
10. Restart mysqld. Spójrz na dziennik błędów mysql. Domyślnie powinno być /var/lib/mysql/server/hostname.com.errwidać, jak tworzy nowe ib*pliki.
11. Przywróć bazy danych ze zrzutu: mysql < dump.sql

Napotkałem ten sam błąd podczas korzystania z obrazu dokowanego mysql: 5.7. Głównym błędem była próba utworzenia użytkownika root, który istnieje domyślnie. Więcej informacji: https://github.com/docker-library/mysql/issues/129

Jak podano w powyższym linku, rozwiązaniem było NIE ustawianie MYSQL_USER i MYSQL_PASSWORD w zmiennych środowiskowych podczas uruchamiania obrazu dokera.

Zdarzyło mi się to w Laravel Homestead (Vagrant po panice jądra z systemem Mac OS Sierra 10.12.4 (16E195):

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 14.04.3 LTS
Release:    14.04
Codename:   trusty

$ mysql -V
mysql  Ver 14.14 Distrib 5.7.9, for Linux (x86_64) using  EditLine 
wrapper

Oto niektóre zasoby, które możesz wypróbować, chociaż żadna z opcji naprawy nie działała dla mnie :

https://dev.mysql.com/doc/refman/5.7/en/forcing-innodb-recovery.html

https://forums.mysql.com/read.php?22,603093,604631#msg-604631

https://support.plesk.com/hc/en-us/articles/213939865-How-to-fix-InnoDB-corruption-cases-for-the-MySQL-database

Próbowałem dodać wymuszone odzyskiwanie do konfiguracji mysql (zacznij od 1 i zwiększaj stopniowo, ponieważ rzekomo wyższe liczby mogą spowodować trwałe uszkodzenie):

sudo nano /etc/mysql/my.cnf

[mysqld]
innodb_force_recovery = 1
#innodb-read-only=1
#innodb_purge_threads=0
#key_buffer_size=16M
#event-scheduler=disabled

W innym oknie uruchom:

tail -f /var/log/mysql/error.log

Następnie spróbuj ponownie uruchomić mysqld z włączonymi różnymi opcjami:

sudo /etc/init.d/mysql restart

Jeśli upłynie limit czasu, możesz wymusić ponowne uruchomienie procesów mysql za pomocą:

# process id is first column with number, just ignore lines with grep because they list the process running 'grep mysql'
ps aux | grep mysql
sudo kill -9 <process-id>
sudo /etc/init.d/mysql restart

Jeśli to działa, dziennik wyświetli coś takiego:

Version: '5.7.9' socket: '/var/run/mysqld/mysqld.sock' port: 3306 MySQL Community Server (GPL)

Jeśli się nie powiedzie, dziennik wyświetli coś takiego:

InnoDB: Assertion failure in thread 140049488692992 in file log0recv.cc line 1420

Gdy pogorszyło się, próbowałem usunąć bazy danych, które mogą być uszkodzone:

sudo ls -alt /var/lib/mysql

Okazało się, że baza danych, nad którą pracowałem, była ostatnio zmodyfikowana na górze listy. Na szczęście miałem zrzut SQL dla tego dnia, więc mogłem go usunąć:

sudo rm -rf /var/lib/mysql/<database_name>

Zostawiłem wszystkie pozostałe pliki, a mysql i tak mógł się uruchomić.

AKTUALIZACJA: pamiętaj, aby wyłączyć, innodb_force_recovery = 1gdy mysql znów zacznie działać, w przeciwnym razie wystąpią błędy podczas próby modyfikacji baz danych i tabel.

Następnie odtworzyłem bazę danych za pomocą Sequel Pro, ponownie zaimportowałem swoje dane i mogłem przejść dalej bez konieczności wyrzucania wszystkich baz danych z moich innych projektów.

Idąc dalej, muszę założyć, że każda baza danych mysql może ulec uszkodzeniu i starać się zachować codzienne kopie zapasowe, a skrypt odtwarzania bazy danych powinien być udokumentowany lub zakodowany w moich narzędziach do ciągłej integracji.