VorwortVor ein paar Tagen kontaktierte mich ein Freund über WeChat und erzählte mir, dass eine Produktionsdatenbankinstanz nach einer Wiederherstellung der Maschine nach einem Ausfall nicht gestartet werden konnte und dass die Instanz keine Hochverfügbarkeits-, Notfallwiederherstellungs- oder Backup-Funktionen hatte, was enorme Auswirkungen auf das Geschäft hatte. Er hoffte, dass ich bei der Untersuchung helfen könnte, und ich beteiligte mich sofort an der Untersuchung. Szenarioanalyse(1) Überprüfen Sie zunächst das Fehlerprotokoll. Die Fehlermeldung ist sehr eindeutig: „Protokolldatei konnte nicht geöffnet werden“. Die Protokolldatei kann nicht geöffnet werden. 2021-01-06 13:23:51 20464 [FEHLER] Das Öffnen des Protokolls ist fehlgeschlagen (Datei „Da stimmt definitiv etwas nicht und dies kann fehlschlagen.“, Fehlernummer 2) 2021-01-06 13:23:51 20464 [FEHLER] Die Protokolldatei konnte nicht geöffnet werden 2021-01-06 13:23:51 20464 [FEHLER] TC-Protokoll kann nicht initialisiert werden 2021-01-06 13:23:51 20464 [FEHLER] Abbruch (2) Nachdem Sie den obigen Fehler gesehen haben, sollten Sie natürlich überprüfen, ob die my.cnf-Konfiguration korrekt ist und das Protokollverzeichnis und die Berechtigungen korrekt sind. Es wurden jedoch keine Probleme gefunden. # weniger my.cnf Datenverzeichnis=/var/lib/mysql log-bin=mysql-bin Relay-Log = Relay-Bin # ls -lrt -rw-rw---- 1 mysql mysql 1073761373 4. Januar 06:18 mysql-bin.007351 -rw-rw---- 1 mysql mysql 1073755587 4. Januar 09:26 mysql-bin.007352 -rw-rw---- 1 mysql mysql 1073777045 4. Januar 12:07 mysql-bin.007353 -rw-rw---- 1 mysql mysql 1073742801 4. Januar 15:12 mysql-bin.007354 -rw-rw---- 1 mysql mysql 1074087344 4. Januar 18:13 mysql-bin.007355 -rw-rw---- 1 mysql mysql 1073869414 4. Januar 21:32 mysql-bin.007356 -rw-rw---- 1 mysql mysql 1073771900 5. Januar 00:16 mysql-bin.007357 -rw-rw---- 1 mysql mysql 213063247 5. Januar 01:00 mysql-bin.007358 -rw-rw---- 1 mysql mysql 1073753668 5. Januar 02:11 mysql-bin.007359 -rw-rw---- 1 mysql mysql 671219722 5. Januar 03:31 mysql-bin.007360 -rw-rw---- 1 mysql mysql 1073774928 5. Januar 07:34 mysql-bin.007361 -rw-rw---- 1 mysql mysql 1073845285 5. Januar 11:33 mysql-bin.007362 -rw-rw---- 1 mysql mysql 1073756444 5. Januar 15:37 mysql-bin.007363 -rw-rw---- 1 mysql mysql 1073790555 5. Januar 19:37 mysql-bin.007364 -rw-rw---- 1 mysql mysql 1073768027 5. Januar 23:59 mysql-bin.007365 -rw-rw---- 1 mysql mysql 311398643 6. Januar 01:00 mysql-bin.007366 -rw-rw---- 1 mysql mysql 1071242043 6. Januar 03:31 mysql-bin.007367 -rw-rw---- 1 mysql mysql 1010516229 6. Januar 07:27 mysql-bin.007368 -rw-rw---- 1 mysql mysql 1651 6. Januar 07:27 mysql-bin.index -rw-rw---- 1 mysql mysql 1073741824 6. Januar 12:08 ib_logfile1 -rw-r--r-- 1 mysql mysql 183 6. Januar 13:23 VM_58_10_centos-slow.log -rw-rw---- 1 mysql mysql 1073741824 6. Januar 13:23 ib_logfile0 -rw-rw---- 1 mysql mysql 7492941 6. Januar 13:23 VM_58_10_centos.err (3) Es gibt einen sehr merkwürdigen Punkt in der Fehlermeldung: Datei „Etwas ist definitiv falsch und dies kann fehlschlagen.“ Warum ist der Name der Protokolldatei so merkwürdig? Was Sie hier wissen müssen, ist, dass mysql-bin.index binlog-bezogene Informationen aufzeichnet. Wenn die MySQL-Instanz gestartet wird, müssen Sie diese Datei lesen, um Informationen zu erhalten. Überprüfen Sie dann die Datei und stellen Sie fest, dass tatsächlich ein Problem vorliegt. Die zweite Hälfte von mysql-bin.index schreibt fälschlicherweise den Inhalt des Fehlerprotokolls, was dazu führt, dass die Instanz beim Start den Fehlerinhalt (der als Binlog-Protokolldatei behandelt wird) liest und einen Fehlerfehler meldet. # cat mysql-bin.index ./mysql-bin.007351 ./mysql-bin.007352 ./mysql-bin.007353 ./mysql-bin.007354 ./mysql-bin.007355 ./mysql-bin.007356 ./mysql-bin.007357 ./mysql-bin.007358 ./mysql-bin.007359 ./mysql-bin.007360 ./mysql-bin.007361 ./mysql-bin.007362 ./mysql-bin.007363 ./mysql-bin.007364 ./mysql-bin.007365 ./mysql-bin.007366 ./mysql-bin.007367 ./mysql-bin.007368 23:27:31 UTC – mysqld hat Signal 6 erhalten; Dies könnte daran liegen, dass Sie auf einen Fehler gestoßen sind. Es ist auch möglich, dass diese Binärdatei oder eine der Bibliotheken, mit denen es verknüpft war, ist beschädigt, falsch erstellt, oder falsch konfiguriert. Dieser Fehler kann auch durch eine Fehlfunktion der Hardware verursacht werden. Wir werden unser Bestes tun, um einige Informationen zusammenzukratzen, die hoffentlich helfen werden das Problem zu diagnostizieren, aber da wir bereits abgestürzt sind, irgendetwas stimmt definitiv nicht und dies kann fehlschlagen. Schlüsselpuffergröße = 16777216 Puffergröße lesen=3145728 max_used_connections=523 max_threads=800 Threadanzahl = 522 Verbindungsanzahl = 522 Es ist möglich, dass mysqld bis zu Schlüsselpuffergröße + (Lesepuffergröße + Sortierpuffergröße)*max_threads = 9037821 KB Speicher Hoffe, das ist ok. Wenn nicht, verringern Sie einige Variablen in der Gleichung. Threadzeiger: 0x0 Backtrace wird versucht. Mit den folgenden Informationen können Sie herausfinden, wo mysqld abgestürzt ist. Wenn Sie danach keine Nachrichten mehr sehen, ist etwas schiefgegangen furchtbar falsch... Stapel_unten = 0 Thread_Stapel 0x40000 Die Manualpage unter http://dev.mysql.com/doc/mysql/en/crashing.html enthält Informationen, die Ihnen dabei helfen sollen, die Absturzursache herauszufinden. (4) Nachdem Sie die Ursache gefunden haben, besteht die Lösung darin, die Datei mysql-bin.index zu sichern, sie manuell zu reparieren und die Instanz dann erfolgreich zu starten. # ./mysql start MySQL wird gestartet.... ERFOLGREICH! MySQL-Verbindung wird geprüft: Verbindung ok! # ps -ef | grep mysqld root 22955 1 0 13:30 pts/5 00:00:00 /bin/sh /usr/bin/mysqld_safe --datadir=/var/lib/mysql --pid-file=/var/lib/mysql/VM_58_10_centos.pid mysql 23733 22955 24 13:30 pts/5 00:00:05 /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql --plugin-dir=/usr/lib64/mysql/plugin --user=mysql --log-error=/var/lib/mysql/VM_58_10_centos.err --open-files-limit=20000 --pid-file=/var/lib/mysql/VM_58_10_centos.pid --socket=/var/lib/mysql/mysql.sock --port=3306 root 32075 14929 0 13:30 Punkte/5 00:00:00 grep mysqld ZusammenfassenAn diesem Punkt ist das Problem gelöst. Was den Grund angeht, warum der Inhalt des Fehlerprotokolls in mysql-bin.index geschrieben wird, vermute ich persönlich, dass die Datei aufgrund eines Absturzes ungeordnet ist (das Dateisystem anderer virtueller Maschinen auf dem Hostcomputer ist beschädigt). Abschließend muss betont werden, dass das Produktionssystem ernst genommen werden muss und Backup, hohe Verfügbarkeit und Notfallwiederherstellung unverzichtbar sind. Oben finden Sie eine detaillierte Analyse und Lösung für das Problem, dass die MySQL-Instanz nicht gestartet werden kann. Weitere Informationen zum Thema „MySQL-Instanz kann nicht gestartet werden“ finden Sie in den anderen verwandten Artikeln auf 123WORDPRESS.COM! Das könnte Sie auch interessieren:
|
<<: Implementierung einer coolen 3D-Würfeltransformationsanimation in CSS3
>>: Lösung für den Docker-Container, der nicht gestoppt und gelöscht werden kann
In MySQL können in der Datenbank fehlerhafte Zeic...
Beim Erstellen einer Tabellenseite ist die für td ...
Inhaltsverzeichnis 1. Hintergrund 2. Was ist ein ...
Vorwort Linux verfügt über entsprechende Open-Sou...
Elasticsearch erfreut sich derzeit großer Beliebt...
Ich lerne derzeit etwas über MySQL-Optimierung. D...
Auf Mobilgeräten sehe ich häufig kreisförmige Wel...
1. Konventionelles Schreiben in vue2 // Die überg...
Wirkung Die Bilder im Code können selbst geändert...
In diesem Artikel wird der spezifische Code zur z...
brauchen: In der Hintergrundverwaltung gibt es hä...
Inhaltsverzeichnis 1. Fehlerbehebung und Lokalisi...
Inhaltsverzeichnis schließen Fallstudie: Vertiefe...
Inhaltsverzeichnis Vorwort Konfigurieren Sie die ...
1. Einleitung Die Anforderung besteht darin, die ...