it-swarm.com.de

MySQL ist abgestürzt und startet nicht

Unser Produktions-MySQL-Server ist gerade abgestürzt und wird nicht wieder hochgefahren. Es gibt einen Segfault-Fehler. Ich habe einen Neustart versucht und weiß nur nicht, was ich sonst noch versuchen soll. Hier ist die Stapelverfolgung:

 140502 14:13:05 [Hinweis] Das Plugin 'FEDERATED' ist deaktiviert. 
 InnoDB: Der Protokollscan wurde am Checkpoint lsn 108 1057948207 
 140502 14:13:06 InnoDB: Datenbank wurde nicht normal heruntergefahren! 
 InnoDB: Starten der Absturzwiederherstellung. 
 InnoDB: Lesen von Tabellenbereichsinformationen aus den .ibd-Dateien ... 
 InnoDB: Wiederherstellen möglicher halbgeschriebener Datenseiten aus dem Doublewrite 
 InnoDB: Puffer ... 
 InnoDB: Wiederherstellung: Gescannt bis zur Protokollsequenznummer 108 1058059648 
 InnoDB: 1 Transaktion (en), die zurückgesetzt werden müssen oder bereinigt 
 InnoDB: Insgesamt 15 Zeilenoperationen zum Rückgängigmachen 
 InnoDB: Trx-ID-Zähler ist 0 562485504 
 140502 14:13:06 InnoDB: Starten eines Stapels von Protokolldatensätzen auf die Datenbank ... 
 InnoDB: Fortschritte in Prozent: 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: Charge abgeschlossen anwenden 
 InnoDB: Beginnend im Hintergrund das Rollback nicht festgeschriebener Transaktionen 
 140502 14:13:06 InnoDB: Zurücksetzen von trx mit der ID 0 562485192, 15 Zeilen zum Rückgängigmachen 
 140502 14:13:06 InnoDB: Gestartet; Protokollsequenznummer 108 1058059648 
 140502 14:13:06 InnoDB: Assertionsfehler im Thread 1873206128 in Datei ../../../storage/innobase/fsp/fsp0fsp.c Zeile 1593 
 InnoDB: Fehlerhafte Behauptung: frag_n_used> 0 
 InnoDB: Wir generieren absichtlich eine Speicherfalle. 
 InnoDB: Senden Sie einen detaillierten Fehlerbericht an http://bugs.mysql.com. 
 InnoDB: Wenn Sie wiederholt Assertionsfehler oder Abstürze erhalten, sogar 
 InnoDB: Unmittelbar nach dem Start von mysqld kann 
 InnoDB: Beschädigung im InnoDB-Tabellenbereich vorliegen. Weitere Informationen finden Sie in 
 InnoDB: http://dev.mysql.com/doc/refman/5.1/en/forcing-recovery.html[.____.‹InnoDB: Informationen zum Erzwingen der Wiederherstellung. 
 140502 14:13:06 - mysqld hat Signal 6 erhalten; 
 Dies könnte daran liegen, dass Sie einen Fehler gefunden haben. Es ist auch möglich, dass diese Binärdatei 
 Oder eine der Bibliotheken, mit denen sie verknüpft wurde, beschädigt, nicht ordnungsgemäß erstellt, 
 Oder falsch konfiguriert ist. Dieser Fehler kann auch durch eine fehlerhafte Hardware verursacht werden. 
 Wir werden unser Bestes geben, um einige Informationen zu sammeln, die hoffentlich bei der Diagnose des Problems helfen. 
, Aber da wir bereits abgestürzt sind, stimmt definitiv etwas nicht 
 und dies kann fehlschlagen. 
 
 key_buffer_size = 16777216 
 read_buffer_size = 131072 
 max_used_connections = 0 
 max_threads = 151 
 threads_connected = 0 
 Es ist möglich, dass mysqld bis zu 
 key_buffer_size + (read_buffer_size + sort_buffer_size) * max_threads = 345919 K 
 Bytes Speicher 
 verwendet OK; Wenn nicht, verringern Sie einige Variablen in der Gleichung. 
 
 thd: 0x0 
 Versuch einer Rückverfolgung. Mithilfe der folgenden Informationen können Sie 
 Herausfinden, wo mysqld gestorben ist. Wenn Sie danach keine Nachrichten mehr sehen, ist etwas 
 Schrecklich schief gelaufen ... 
 Stack_bottom = (nil) thread_stack 0x30000 
 140502 14:13:06 [Hinweis] Ereignisplaner: Geladen 0 Ereignisse 
 140502 14:13:06 [Hinweis]/usr/sbin/mysqld: Bereit für Verbindungen. 
 Version: '5.1.41-3ubuntu12.10' Socket: '/ var/run /mysqld/mysqld.sock 'Port: 3306 (Ubuntu) 
/usr/sbin/mysqld (my_print_stacktrace + 0x2d) [0xb7579cbd] 
/usr/sbin/mysqld (handle_segfault + 0x494) [0x ] 
 [0xb6fc0400] 
/Lib/tls/i686/cmov/libc.so.6 (Abbruch + 0x182) [0xb6cc5a82] 
/Usr/sbin/mysqld (+ 0x4867e9 ) [0xb74647e9] 
/Usr/sbin/mysqld (btr_page_free_low + 0x122) [0xb74f1622] 
/Usr/sbin/mysqld (btr_compress + 0x684) [0xb74f4ca4] [.____]. sbin/mysqld (btr_cur_compress_if_useful + 0xe7) [0xb74284e7] 
/usr/sbin/mysqld (btr_cur_pessimistic_delete + 0x332) [0xb7429e72] 
/usr/sbx .____.]/usr/sbin/mysqld (btr_discard_page + 0x175) [0xb74f41e5] 
/usr/sbin/mysqld (btr_cur_pessimistic_delete + 0x3e8) [0xb7429f28] 
/usr/sbin/mysqld (+ 0x526197) [0xb7504197] 
/usr/sbin/myb1 0xb7504771] 
/Usr/sbin/mysqld (row_undo_step + 0x25f) [0xb74c210f] 
/Usr/sbin/mysqld (que_run_threads + 0x58a) [0xb74a31da]/.b. mysqld (trx_rollback_or_clean_all_without_sess + 0x3e3) [0xb74ded43] 
/lib/tls/i686/cmov/libpthread.so.0 (+ 0x596e) [0xb6f9f96e] 
/lib/tls/i6/.so.6 (Klon + 0x5e) [0xb6d65a4e] 
 Die Handbuchseite unter http://dev.mysql.com/doc/mysql/en/crashing.html enthält 
 Informationen, die helfen sollten Sie finden heraus, was den Absturz verursacht. 

Irgendwelche Empfehlungen?

20
tilleryj

Autsch.

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.

Überprüfen Sie die vorgeschlagene Webseite: http://dev.mysql.com/doc/refman/5.1/en/forcing-recovery.html .

Versuchen Sie grundsätzlich , den MySQL-Server in einem Wiederherstellungsmodus zu starten und eine Sicherungskopie Ihrer abgestürzten Tabellen zu erstellen .

Bearbeiten Sie Ihren /etc/my.cnf Und fügen Sie hinzu:

 innodb_force_recovery = 1

... um zu sehen, ob Sie in Ihre Datenbank gelangen und Ihre Daten abrufen/die beschädigte Tabelle finden können.

In diesem Fall handelt es sich normalerweise um eine Neuerstellung (mindestens eine oder zwei beschädigte Tabellen).

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

  1. Stoppen Sie mysqld (service mysql stop).
  2. Backup /var/lib/mysql/ib*
  3. Fügen Sie die folgende Zeile in /etc/my.cnf Ein:

    innodb_force_recovery = 1
    

    (Sie schlagen 4 vor, aber es ist am besten, mit 1 zu beginnen und zu erhöhen, wenn es nicht startet)

  4. Starten Sie mysqld (service mysql start) Neu.

  5. Alle Tabellen sichern: mysqldump -A > dump.sql
  6. Löschen Sie alle Datenbanken, die wiederhergestellt werden müssen.
  7. Stoppen Sie mysqld (service mysql stop).
  8. Entfernen Sie /var/lib/mysql/ib*
  9. Kommentar aus innodb_force_recovery In /etc/my.cnf
  10. Starten Sie mysqld neu. Schauen Sie sich das MySQL-Fehlerprotokoll an. Standardmäßig sollte es /var/lib/mysql/server/hostname.com.err Sein, um zu sehen, wie neue ib* - Dateien erstellt werden.
  11. Stellen Sie Datenbanken aus dem Speicherauszug wieder her: mysql < dump.sql
27
Jonathan

Bei der Verwendung des Docker-Images mysql: 5.7 trat derselbe Fehler auf. Der Hauptfehler bestand darin, einen Standardbenutzer zu erstellen, der standardmäßig vorhanden ist. Weitere Informationen: https://github.com/docker-library/mysql/issues/129

Wie im obigen Link angegeben, bestand die Lösung darin, MYSQL_USER und MYSQL_PASSWORD beim Starten des Docker-Images NICHT in den Umgebungsvariablen festzulegen.

2
rahuljain1311

Dies geschah mir in Laravel Homestead (Vagrant nach einer Kernel-Panik unter 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

Hier sind einige Ressourcen, die Sie ausprobieren können, obwohl keine der Reparaturoptionen für mich funktioniert hat :

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

Ich habe versucht, der MySQL-Konfiguration eine Force-Wiederherstellung hinzuzufügen (beginnen Sie bei 1 und steigen Sie zunehmend an, da angeblich höhere Zahlen zu dauerhafter Beschädigung führen können):

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

Führen Sie in einem anderen Fenster Folgendes aus:

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

Versuchen Sie dann, mysqld mit den verschiedenen aktivierten Optionen neu zu starten:

Sudo /etc/init.d/mysql restart

Wenn das Zeitlimit überschritten wird, können Sie einen Neustart von MySQL-Prozessen erzwingen mit:

# 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

Wenn es funktioniert, zeigt das Protokoll Folgendes an:

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

Wenn dies fehlschlägt, wird im Protokoll Folgendes angezeigt:

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


Als es immer schlimmer wurde, habe ich versucht, Datenbanken zu entfernen, die wahrscheinlich beschädigt sind:

Sudo ls -alt /var/lib/mysql

Es stellte sich heraus, dass die Datenbank, an der ich gearbeitet hatte, die zuletzt geänderte Datenbank ganz oben auf der Liste war. Zum Glück hatte ich von diesem Tag an einen SQL-Dump dafür und konnte ihn entfernen:

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

Ich habe alle anderen Dateien verlassen und MySQL konnte trotzdem starten.

UPDATE: Deaktivieren Sie unbedingt innodb_force_recovery = 1, Sobald MySQL wieder funktioniert. Andernfalls werden Fehler angezeigt, wenn Sie versuchen, Datenbanken und Tabellen zu ändern.

Dann habe ich die Datenbank mit Sequel Pro neu erstellt, meine Daten erneut importiert und konnte fortfahren, ohne alle Datenbanken aus meinen anderen Projekten wegwerfen zu müssen.

In Zukunft muss ich davon ausgehen, dass jede MySQL-Datenbank beschädigt werden kann, und versuchen, tägliche Sicherungen zu führen und das Datenbankwiederherstellungsskript in meinen Tools für die kontinuierliche Integration zu dokumentieren oder zu codieren.

1
Zack Morris