Mysql si è bloccato e non si avvia

Il nostro server mysql di produzione si è appena arrestato e non verrà ripristinato. Sta dando un errore segfault. Ho provato un riavvio e non so cos'altro provare. Ecco lo stacktrace:

140502 14:13:05 [Nota] Il plug-in 'FEDERATED' è disabilitato.
InnoDB: la scansione del registro è passata oltre il checkpoint lsn 108 1057948207
140502 14:13:06 InnoDB: il database non è stato chiuso normalmente!
InnoDB: avvio del ripristino di emergenza.
InnoDB: Lettura delle informazioni sul tablespace dai file .ibd ...
InnoDB: ripristino di possibili pagine di dati scritte a metà dalla scrittura doppia
InnoDB: buffer ...
InnoDB: In fase di ripristino: scansionato per registrare il numero progressivo 108 1058059648
InnoDB: 1 transazioni che devono essere ripristinate o ripulite
InnoDB: in totale 15 operazioni di riga da annullare
InnoDB: il contatore ID Trx è 0 562485504
140502 14:13:06 InnoDB: avvio di un batch di applicazione dei record di registro nel database ...
InnoDB: Progressi in percentuale: 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 69 71 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: applica batch completato
InnoDB: avvio in background del rollback delle transazioni senza commit
140502 14:13:06 InnoDB: rollback di trx con ID 0 562485192, 15 righe da annullare
140502 14:13:06 InnoDB: avviato; numero sequenza log 108 1058059648
140502 14:13:06 InnoDB: errore di asserzione nel thread 1873206128 nel file ../../../storage/innobase/fsp/fsp0fsp.c riga 1593
InnoDB: asserzione non riuscita: fram_n_used> 0
InnoDB: generiamo intenzionalmente una trappola di memoria.
InnoDB: invia una segnalazione dettagliata dei bug a http://bugs.mysql.com.
InnoDB: anche se si verificano ripetuti fallimenti o arresti anomali delle asserzioni
InnoDB: subito dopo l'avvio di mysqld, potrebbero esserci
InnoDB: corruzione nel tablespace InnoDB. Per favore riferisci a
InnoDB: http://dev.mysql.com/doc/refman/5.1/en/forcing-recovery.html
InnoDB: forzare il recupero.
140502 14:13:06 - mysqld ha ricevuto il segnale 6;
Questo può essere perché hai trovato un bug di sistema. È anche possibile che questo binario
o una delle biblioteche a cui era collegata è corrotta, costruita in modo errato,
o configurato male. Questo errore può anche essere causato da un malfunzionamento dell'hardware.
Faremo del nostro meglio per raccogliere alcune informazioni che speriamo possano aiutare a diagnosticare
il problema, ma dal momento che ci siamo già schiantati, qualcosa è decisamente sbagliato
e questo potrebbe fallire.

key_buffer_size = 16777216
read_buffer_size = 131072
max_used_connections = 0
max_threads = 151
threads_connected = 0
È possibile che mysqld possa utilizzare fino a 
key_buffer_size + (read_buffer_size + sort_buffer_size) * max_threads = 345919 K
byte di memoria
Spero sia ok; in caso contrario, ridurre alcune variabili nell'equazione.

thd: 0x0
Tentativo di backtrace. È possibile utilizzare le seguenti informazioni per scoprirlo
dove è morto mysqld. Se non vedi più messaggi dopo questo, qualcosa è andato
terribilmente sbagliato ...
stack_bottom = (zero) thread_stack 0x30000
140502 14:13:06 [Nota] Utilità di pianificazione eventi: caricati 0 eventi
140502 14:13:06 [Nota] / usr / sbin / mysqld: pronto per le connessioni.
Versione: socket '5.1.41-3ubuntu12.10': porta '/var/run/mysqld/mysqld.sock': 3306 (Ubuntu)
/ usr / sbin / mysqld (my_print_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 (btr_discard_page + 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 (que_run_threads + 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]
La pagina di manuale all'indirizzo http://dev.mysql.com/doc/mysql/en/crashing.html contiene
informazioni che dovrebbero aiutarti a scoprire cosa sta causando l'incidente.

Qualche consiglio?

Ahia.

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.

Controlla la pagina web suggerita: http://dev.mysql.com/doc/refman/5.1/en/forcing-recovery.html .

Fondamentalmente, prova ad avviare il server MySQL in una modalità di ripristino ed esegui un backup delle tue tabelle bloccate .

Modifica il tuo /etc/my.cnfe aggiungi:

 innodb_force_recovery = 1

... per vedere se riesci ad accedere al tuo database e ottenere i tuoi dati / trovare la tabella danneggiata.

Di solito, quando ciò accade, si tratta di una ricostruzione (almeno di una o due tabelle danneggiate).

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

1. Stop mysqld( service mysql stop).
2. di riserva /var/lib/mysql/ib*

3. Aggiungi la seguente riga in /etc/my.cnf:

   innodb_force_recovery = 1
   

   (suggeriscono 4, ma è meglio iniziare con 1 e aumentare se non si avvia)

4. Riavvia mysqld( service mysql start).

5. Scarica tutti i tavoli: mysqldump -A > dump.sql
6. Eliminare tutti i database che richiedono il ripristino.
7. Stop mysqld( service mysql stop).
8. Rimuovere /var/lib/mysql/ib*
9. Commenta innodb_force_recoverydentro/etc/my.cnf
10. Riavvia mysqld. Guarda il registro degli errori di mysql. Di default dovrebbe essere /var/lib/mysql/server/hostname.com.errvedere come crea nuovi ib*file.
11. Ripristina database dal dump: mysql < dump.sql

Stavo affrontando questo stesso errore durante l'utilizzo di mysql: 5.7 docker image. L'errore principale è stato il tentativo di creare l'utente root esistente per impostazione predefinita. Ulteriori informazioni: https://github.com/docker-library/mysql/issues/129

Come indicato nel link precedente, la soluzione era NON impostare MYSQL_USER e MYSQL_PASSWORD nelle variabili di ambiente durante l'avvio dell'immagine docker.

Questo è successo a me in Laravel Homestead (Vagrant dopo un panico del kernel con 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

Ecco alcune risorse che puoi provare, anche se nessuna delle opzioni di riparazione ha funzionato per me :

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

Ho provato ad aggiungere il recupero forzato alla configurazione di mysql (iniziare da 1 e andare progressivamente più in alto poiché numeri presumibilmente più alti possono causare corruzione permanente):

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

In un'altra finestra, esegui:

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

Quindi prova a riavviare mysqld con le varie opzioni abilitate:

sudo /etc/init.d/mysql restart

In caso di timeout, puoi forzare il riavvio dei processi mysql con:

# 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

Se funziona, il registro mostrerà qualcosa del tipo:

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

Se fallisce, il registro mostrerà qualcosa del tipo:

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

Quando il peggio è peggiorato, ho provato a rimuovere i database che potrebbero essere corrotti:

sudo ls -alt /var/lib/mysql

Si è scoperto che il database su cui stavo lavorando era l'ultimo modificato in cima all'elenco. Fortunatamente da quel giorno ho avuto un dump SQL per esso, quindi sono stato in grado di rimuoverlo:

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

Ho lasciato tutti gli altri file e mysql è stato comunque in grado di avviarsi.

AGGIORNAMENTO: assicurati di disabilitare innodb_force_recovery = 1una volta che mysql funziona di nuovo, altrimenti otterrai errori quando tenti di modificare database e tabelle.

Quindi ho ricreato il database con Sequel Pro, ho reimportato i miei dati e sono stato in grado di andare avanti senza dover eliminare tutti i database dagli altri miei progetti.

In futuro, devo presumere che qualsiasi database mysql possa essere danneggiato e provare a mantenere i backup giornalieri e avere lo script di ricreazione del database documentato o codificato nei miei strumenti di integrazione continua.