Was sind die häufigsten Ursachen und Lösungen für MySQL-Datenbankabstürze?

Überprüfen Sie die Startzeit der MySQL-Datenbank

systemd und mysqld_safe im Linux-System starten den MySQL-Dienst automatisch neu, nachdem der mysqld-Prozess abstürzt. Beachten Sie, dass die Verwendung von kill -9 zum Beenden des mysqld-Prozesses automatisch erfolgt Starten Sie das System neu, und nur die Verwendung des Kill-Befehls führt nicht zu einem Neustart, da das System beim Ausführen des Kill-Befehls ein SIGTERM-Signal an MySQL sendet, die MySQL-Datenbank normal heruntergefahren wird und ein Datensatz ähnlich dem folgenden erstellt wird erscheinen im Protokoll:

2020-10-26T09: 06:48.435181Z 0 [System] [MY-010910] [Server] /usr/sbin/mysqld: Herunterfahren abgeschlossen (mysqld 8.0.19) MySQL Community Server – GPL .

MySQL-Datenbank wird nach dem Absturz neu gestartet, sodass wir manchmal nicht wissen, dass die MySQL-Datenbank abgestürzt ist, aber wir können Hinweise aus der Startzeit der MySQL-Datenbank finden. Hier sind vier Möglichkeiten, die Startzeit der MySQL-Datenbank zu überprüfen.

Die Überprüfung des MySQL-Dienststatus

scutech@scutech:~$ service mysql status
● mysql.service - MySQL Community Server
   Loaded: loaded (/lib/systemd/system/mysql.service; enabled; vendor preset: enabled)
   Active: active (running) since Wed 2020-10-21 05:54:18 NDT; 4 days ago
  Process: 774 ExecStart=/usr/sbin/mysqld --daemonize --pid-file=/var/run/mysqld/mysqld.pid (code=exited, status=0/SUCCESS)
  Process: 708 ExecStartPre=/usr/share/mysql/mysql-systemd-start pre (code=exited, status=0/SUCCESS)
 Main PID: 791 (mysqld)
    Tasks: 27 (limit: 2328)
   CGroup: /system.slice/mysql.service
           └─791 /usr/sbin/mysqld --daemonize --pid-file=/var/run/mysqld/mysqld.pid

zeigt, dass die MySQL-Datenbank seit mehr als 4 Tagen läuft.

Überprüfen Sie den Betriebszeitstatus in MySQL

mysql> show global status like 'uptime';
+---------------+--------+
| Variable_name | Value  |
+---------------+--------+
| Uptime        | 428334 |
+---------------+--------+
1 row in set (0.32 sec)

Dieser Wert ist in Sekunden angegeben. Die folgende Umrechnung in Tage beträgt mehr als 4 Tage.

mysql> select 428334/60/60/24;
+-----------------+
| 428334/60/60/24 |
+-----------------+
|  4.957569444444 |
+-----------------+
1 row in set (0.01 sec)

Eine andere Möglichkeit, den Betriebszeitstatus abzufragen, besteht darin, die MySQL-Admin-Version zu verwenden oder „s“ im MySQL-Client zur Abfrage zu verwenden.

Verwenden Sie ps, um die Startzeit des Prozesses zu überprüfen.

Verwenden Sie den ps-Befehl, um eine Abfrage durchzuführen und festzustellen, dass mysqld seit 4 Tagen, 23 Stunden, 3 Minuten und 54 Sekunden gestartet ist „Bereit für Verbindungen“, um die Startinformationen zu finden.

2020-10-21T08:24:18.986765Z 0 [Hinweis] /usr/sbin/mysqld: bereit für Verbindungen.

Version: '5.7.28-log' Socket: '/var/run/mysqld/mysqld. sock'-Port: 3306 MySQL Community Server (GPL)

Häufige Gründe für den Absturz der MySQL-Datenbank

Es gibt zwei häufigste Gründe für den Absturz der MySQL-Datenbank: einer ist ein MySQL-Fehler, der andere ist MySQL-Fehler bei der Beantragung von Systemressourcen oder Speicherlecks.

MySQL-Fehler

Einer der häufigsten Gründe für einen Absturz der MySQL-Datenbank ist natürlich der MySQL-Fehler. 95 % der Fehler hängen mit einer bestimmten SQL zusammen. Normalerweise liegt ein Problem mit der letzten SQL vor, die vor dem Absturz von MySQL ausgeführt wurde. Daher sollten Sie beim Auffinden des Fehlers das allgemeine Abfrageprotokoll öffnen und nach Hinweisen suchen, die auf der letzten SQL basieren.

Nachdem Sie die Ursache des Absturzes ermittelt haben, sollten Sie die MySQL-Fehlerbibliothek (https://bugs.mysql.com) überprüfen, normalerweise mithilfe der erweiterten Suche, um festzustellen, ob ähnliche Probleme vorliegen. Wenn Sie einen Fehler finden, der für Sie relevant sein könnte, bestätigen Sie, dass er behoben wurde. Wenn der Fehler behoben wurde, aktualisieren Sie MySQL auf eine Version, in der der Fehler behoben wurde.

In den Versionshinweisen jeder Version gibt es einen Abschnitt „Behobene Fehler“, in dem Sie die behobenen Fehler überprüfen können.

MySQL beantragt keine Systemressourcen oder Speicherlecks

Unzureichender Speicher oder MySQL kann keine Systemressourcen beantragen, führt zum Absturz von MySQL, z. B. weil der Speicherplatz voll ist, die Dateien auf der Festplatte beschädigt sind usw. Derzeit gibt es mehrere Methoden, um die Ursache des Absturzes zu lokalisieren:

Lesen Sie das MySQL-Fehlerprotokoll sorgfältig durch. Einige der Programm-Debugging-Informationen in diesem Protokoll können verwirrend erscheinen, aber wenn Sie sich beruhigen und genau hinsehen, werden Sie feststellen, dass dies der Fall ist. Das werden Sie oft finden Finden Sie Hinweise;

• Öffnen Sie das allgemeine Abfrageprotokoll, suchen Sie die Tabelle oder den Index, auf den die letzte SQL zugegriffen hat, überprüfen Sie die Tabelle oder den Index und erstellen Sie sie neu, wenn ein Problem vorliegt, wodurch das Problem normalerweise behoben wird.

• Verwenden Sie strace, pstack, pmap, gdb, um den Code von mysqld zu analysieren. Möglicherweise müssen Sie den Core-Dump öffnen.

• Verwenden Sie die CMake-Option -DWITH_DEBUG=1, um mysqld neu zu kompilieren, führen Sie dann das neu kompilierte mysqld aus und sehen Sie sich das an Trace-Datei, Fehlerprotokoll zur Fehlerbehebung.

• MySQL-Speichernutzungsberechnung

globaler Speicher

innodb_buffer_pool_size innodb_log_buffer_size thread_cache_size table_open_cache table_definition_cache key_buffer_size

thread-Speicher

binlog_cache_size thread_stack

einzelne Operation ffer _size read_buffer_size read_rnd_buffer_size tmp_table_size sort_buffer_size

Berechnungsformel
Maximaler Referenzwert für die Speichernutzung in der MySQL 8-Berechnung Formel:

scutech@scutech:~$ ps -eo pid,user,args,etime|grep mysqld
  791 mysql    /usr/sbin/mysqld --daemoniz  4-23:03:54

innodb_buffer_pool_size

key_buffer_size

• max_connections*(sort_buffer_size+read_buffer_size+binlog_cache_size)

• max_connections*2MB

• Als vorübergehende Lösung können Sie den folgenden Befehl verwenden, um den Cache freizugeben :

  rrree

  0 : 0 ist der Systemstandardwert. Standardmäßig bedeutet dies, dass der Speicher nicht freigegeben wird und automatisch vom Betriebssystem verwaltet wird. 2: Einträge und Inodes freigeben Auf lange Sicht müssen Sie die entsprechenden Parameter noch ändern.

MySQL-Client-Speicherlecks

MySQL-Client-Speicherlecks haben normalerweise die folgenden Aufforderungen

MySQL: Nicht genügend Speicher in Zeile 42, 'malloc.c'
MySQL: 8136 Byte (8 KB) benötigt, verwendeter Speicher: 12481367 Byte (12189 KB)
FEHLER 2008: Der MySQL-Client hat nicht mehr genügend Speicher

Das ist Normalerweise liegt es daran, dass die vom Client empfangene zurückgegebene Ergebnismenge zu groß ist. Es gibt zwei Lösungen:

Überprüfen Sie die laufende SQL, um zu sehen, ob Sie wirklich eine so große zurückgegebene Ergebnismenge benötigen.
Erlauben Sie MySQL mit der Option --quick, wodurch der jeweils vom Client empfangene Rückgabesatz reduziert, aber die Auslastung von MySQL erhöht wird.

Das obige ist der detaillierte Inhalt vonWas sind die häufigsten Ursachen und Lösungen für MySQL-Datenbankabstürze?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!