MariaDB
 sql >> Datenbank >  >> RDS >> MariaDB

Zu ergreifende Schritte bei einem MySQL-Ausfall

Ein MySQL-Ausfall bedeutet einfach, dass Ihr MySQL-Dienst aus der Perspektive des anderen nicht zugänglich ist oder nicht reagiert. Ausfälle können durch eine Reihe möglicher Ursachen verursacht werden..

  • Netzwerkproblem – Konnektivitätsproblem, Switch, Routing, Resolver, Load-Balancer-Ebene.
  • Ressourcenproblem – Ob Sie das Ressourcenlimit oder einen Engpass erreicht haben.
  • Fehlkonfiguration - Falsche Berechtigung oder Besitz, unbekannte Variable, falsches Passwort, Berechtigung geändert.
  • Sperren - Globale oder Tabellensperre verhindert, dass andere auf die Daten zugreifen.

In diesem Blogbeitrag sehen wir uns einige Schritte an, die Sie unternehmen können, wenn Sie einen MySQL-Ausfall haben (Linux-Umgebung).

Schritt Eins:Fehlercode abrufen

Bei einem Ausfall gibt Ihre Anwendung einige Fehler und Ausnahmen aus. Diese Fehler werden normalerweise mit einem Fehlercode geliefert, der Ihnen eine ungefähre Vorstellung davon gibt, womit Sie konfrontiert sind und was als nächstes zu tun ist, um das Problem zu beheben und den Ausfall wiederherzustellen.

Um weitere Details zu dem Fehler zu erhalten, überprüfen Sie die Seiten MySQL-Fehlercode bzw. MariaDB-Fehlercode, um herauszufinden, was der Fehler bedeutet.

Schritt Zwei:Läuft der MySQL-Server?

Melden Sie sich über das Terminal beim Server an und prüfen Sie, ob der MySQL-Daemon läuft und auf den richtigen Port hört. Unter Linux würde man folgendermaßen vorgehen:

Überprüfen Sie zuerst den MySQL-Prozess:

$ ps -ef | grep -i mysql

Du solltest etwas zurückbekommen. Andernfalls wird MySQL nicht ausgeführt. Wenn MySQL nicht läuft, versuchen Sie es zu starten:

$ systemctl start mysql # systemd

$ service mysql start # sysvinit/upstart

$ mysqld_safe # manual

Wenn Sie beim obigen Schritt einen Fehler sehen, sollten Sie sich das MySQL-Fehlerprotokoll ansehen, das je nach Betriebssystem und MySQL-Variablenkonfiguration für log_error in der MySQL-Konfigurationsdatei unterschiedlich ist. Bei RedHat-basierten Servern befindet sich die Datei üblicherweise unter:

$ cat /var/log/mysqld.log

Achten Sie auf die neusten Zeilen mit Loglevel "[Error]". Einige mit „[Warnung]“ gekennzeichnete Zeilen könnten auf Probleme hinweisen, aber diese sind ziemlich ungewöhnlich. In den meisten Fällen können hier Fehlkonfigurationen und Ressourcenprobleme erkannt werden.

Falls MySQL läuft, überprüfen Sie, ob es den richtigen Port abhört:

$ netstat -tulpn | grep -i mysql

tcp6       0 0 :::3306                 :::* LISTEN   1089/mysqld

Sie würden den Prozessnamen "mysqld" erhalten, der auf allen Schnittstellen (:::3306 oder 0.0.0.0:3306) auf Port 3306 mit PID 1089 lauscht und der Status "LISTEN" ist. Wenn Sie sehen, dass die obige Zeile 127.0.0.1:3306 anzeigt, lauscht MySQL nur lokal. Möglicherweise müssen Sie den bind_address-Wert in der MySQL-Konfigurationsdatei ändern, um auf alle IP-Adressen zu hören, oder einfach die Zeile kommentieren.

Schritt Drei:Auf Verbindungsprobleme prüfen

Wenn der MySQL-Server ohne Fehler im MySQL-Fehlerprotokoll läuft, ist die Wahrscheinlichkeit, dass Verbindungsprobleme auftreten, ziemlich hoch. Prüfen Sie zunächst die Konnektivität zum Host per Ping (falls ICMP aktiviert ist) und telnet Sie vom Anwendungsserver zum MySQL-Server:

(application-server)$ ping db1.mydomain.com

(application-server)$ telnet db1.mydomain.com 3306

Trying db1.mydomain.com...

Connected to 192.168.0.16.

Escape character is '^]'.

O

5.6.46-86.2sN&nz9NZ�32?&>H,EV`_;mysql_native_password

Du solltest einige Zeilen in der Telnet-Ausgabe sehen, wenn du dich mit dem MySQL-Port verbinden kannst. Versuchen Sie es jetzt noch einmal, indem Sie den MySQL-Client vom Anwendungsserver verwenden:

(application-server)$ mysql -u db_user -p -h db1.mydomain.com -P3306

ERROR 1045 (28000): Access denied for user 'db_user'@'db1.mydomain.com' (using password: YES)

Im obigen Beispiel gibt uns der Fehler ein paar Informationen darüber, was als nächstes zu tun ist. Das obige wahrscheinlich, weil jemand das Passwort für "db_user" geändert hat oder das Passwort für diesen Benutzer abgelaufen ist. Dies ist ein ziemlich normales Verhalten von MySQL 5.7. 4 und höher, wo die Richtlinie für den automatischen Kennwortablauf standardmäßig mit einem Schwellenwert von 360 Tagen aktiviert ist – was bedeutet, dass alle Kennwörter einmal im Jahr ablaufen.

Schritt Vier:Überprüfen Sie die MySQL-Prozessliste

Wenn MySQL ohne Verbindungsprobleme gut läuft, überprüfen Sie die MySQL-Prozessliste, um zu sehen, welche Prozesse gerade laufen:

mysql> SHOW FULL PROCESSLIST;

+-----+------+-----------+------+---------+------+-------+-----------------------+-----------+---------------+

| Id  | User | Host      | db | Command | Time | State | Info                  | Rows_sent | Rows_examined |

+-----+------+-----------+------+---------+------+-------+-----------------------+-----------+---------------+

| 117 | root | localhost | NULL | Query   | 0 | init | SHOW FULL PROCESSLIST |       0 | 0 |

+-----+------+-----------+------+---------+------+-------+-----------------------+-----------+---------------+

1 row in set (0.01 sec)

Achten Sie auf die Spalte Info und Zeit. Einige MySQL-Operationen könnten destruktiv genug sein, um die Datenbank zum Stillstand zu bringen und nicht mehr zu reagieren. Die folgenden SQL-Anweisungen könnten, wenn sie ausgeführt werden, andere am Zugriff auf die Datenbank oder Tabelle hindern (was aus Sicht der Anwendung zu einem kurzen Ausfall des MySQL-Dienstes führen könnte):

  • FLUSH TABLES WITH READ LOCK
  • SPERRTABELLE ...
  • TABELLE ÄNDERN ...

Einige lang laufende Transaktionen könnten auch andere anhalten, was schließlich zu Zeitüberschreitungen bei anderen Transaktionen führen würde, die darauf warten, auf dieselben Ressourcen zuzugreifen. Sie können entweder die anstößige Transaktion beenden, damit andere auf dieselben Zeilen zugreifen können, oder die Enqueue-Transaktionen erneut versuchen, nachdem die lange Transaktion beendet ist.

Fazit

Proaktive Überwachung ist wirklich wichtig, um das Risiko eines MySQL-Ausfalls zu minimieren. Wenn Ihre Datenbank von ClusterControl verwaltet wird, werden alle genannten Aspekte automatisch ohne zusätzliche Konfiguration durch den Benutzer überwacht. Sie erhalten Alarme in Ihrem Posteingang für Anomalieerkennungen wie lang andauernde Abfragen, Server-Fehlkonfiguration, Ressourcenüberschreitung und vieles mehr. Außerdem versucht ClusterControl automatisch, Ihren Datenbankdienst wiederherzustellen, wenn etwas mit dem Host oder Netzwerk schief geht.

Sie können auch mehr über MySQL &MariaDB Disaster Recovery erfahren, indem Sie unser Whitepaper lesen.