Beenden Sie eine Reihe von MySQL-Datenbanken mit nur einem Shell-Skript wie diesem (empfohlen)

Ich wurde am frühen Morgen durch einen Anruf geweckt. Die Datenbank eines bestimmten Projekts war ausgefallen und konnte nicht gestartet werden (ich hatte zu tief geschlafen und die Alarm-SMS nicht gehört). Ich hatte große Angst!

Die Person am Telefon sagte, dass alle MySQL-Datenbank-Masterdatenbanken nicht gestartet werden konnten, die Slave-Datenbanken jedoch normal waren. Es wurde vermutet, dass die Masterdatenbank eine Verbindung zu anderen Alibaba Cloud-Masterdatenbanken herstellte. Diese Datenbanken wurden zuvor von Alibaba Cloud in den IDC-Computerraum migriert, daher traf er diese Beurteilung.

Schalten Sie den Computer schnell ein, stellen Sie eine Verbindung zu *** her, melden Sie sich bei einem der Datenbankserver an und versuchen Sie, den folgenden Befehl auszuführen, um den MySQL-Dienst zu starten

[root@bbsmysql121 Backup]#mysqld_safe –user=mysql &

Der Start schlug fehl und ich habe es mit einem anderen Datenbankserver versucht, aber auch dieser schlug fehl. Da nicht alle Datenbanken gestartet werden können, kann vorläufig festgestellt werden, dass das Problem möglicherweise durch ein Problem mit dem Datenbankhost verursacht wird.

Das zugrunde liegende Design der Datenbank besteht aus zwei virtualisierten physischen Knoten plus einer physischen Maschine für die Sicherung. Alle virtuellen Maschinen auf einer physischen Maschine werden als MySQL-Masterdatenbanken verwendet, und virtuelle Maschinen auf einer anderen physischen Maschine werden als MySQL-Slavedatenbanken verwendet.

Geben Sie die Fehlersuche in der virtuellen Maschine auf und melden Sie sich schnell beim Hostsystem an. Als Nächstes werden wir das Problem aus zwei Blickwinkeln beheben.

ü Virtualisiertes Backend-Managementsystem

Es stellte sich heraus, dass der Speicher voll war und ein schwerwiegendes Problem bestand.

ü SSH-Login zum Hostsystem Debian

[6885005.756183] Puffer-E/A-Fehler bei dev dm-16, logischer Block 34667776, asynchrones Schreiben der Seite verloren
[6885005.757292] Puffer-E/A-Fehler bei dev dm-16, logischer Block 34667792, asynchrones Schreiben der Seite verloren
[6885005.758210] Puffer-E/A-Fehler bei dev dm-16, logischer Block 34667808, asynchrones Schreiben der Seite verloren
[6885005.759079] Puffer-E/A-Fehler bei dev dm-16, logischer Block 34667824, asynchrones Schreiben der Seite verloren
[6885005.759922] Puffer-E/A-Fehler bei dev dm-16, logischer Block 34667840, asynchrones Schreiben der Seite verloren
[6885005.760723] Puffer-E/A-Fehler bei dev dm-16, logischer Block 34667856, asynchrones Schreiben der Seite verloren

Das Systemprotokoll /var/log/messages hat eine große Anzahl von Festplatten-E/A-Fehlern gefunden.

Aus den oben genannten Erkenntnissen lässt sich grundsätzlich schließen, dass ein Problem mit der Festplatte vorliegt: Ein Problem besteht darin, dass der von Proxmox zugewiesene Speicherplatz voll ist, und das andere ist ein Festplatten-E/A-Fehler. Nachdem Sie das Problem kennen, gibt es zwei Lösungen: Beheben Sie den Fehler oder stufen Sie die Slave-Datenbank zur Master-Datenbank hoch. Angesichts des Standby-Problems sollten wir unser Bestes geben, um die Master-Datenbank zu reparieren. Wenn dies nicht möglich ist, können wir die zweite Lösung verwenden (die Slave-Datenbank hochstufen).

Geben Sie Speicherplatz frei

Warum ist der Speicherplatz voll? Jemand muss etwas auf der virtuellen Maschine getan haben, und es kann sein, dass jede virtuelle Maschine denselben Vorgang ausgeführt hat, wodurch der Speicherplatz der Hostmaschine schnell voll war. Melden Sie sich bei einer virtuellen Maschine mit MySQL-Datenbank an und führen Sie den Befehl aus

df-h

Beim Anmelden bei anderen Servern ist die Partition /dev/sdb1 ebenfalls zu über 90 % belegt. Geben Sie das Verzeichnis /data ein und führen Sie den folgenden Befehl aus, um die Verzeichnisspeicherplatznutzung anzuzeigen:

[root@cumysql121 data]# du -hs *
4,0K-Sicherung
59G db_pkg
59G mysql_db
[root@cumysql121 Daten]# CD-Backup
[root@cumysql121 backup]# du -hs *

Wow, es gibt mehrere Verzeichnisse mit mehr als 50 GB (ich habe sie beim Schreiben dieses Artikels gelöscht und habe keine Datensätze mehr). Den Verzeichnisnamen nach zu urteilen, sollten diese Dateien automatisch von der Sicherungsdatenbank generiert werden. Ignorieren Sie es und löschen Sie es zuerst.

Irgendjemand muss eine automatische Aufgabe im System ausgeführt haben. Ich habe dies mit dem Befehl crontab –l überprüft und Folgendes festgestellt:

#!/bin/bash
/usr/local/xtrabackup/bin/innobackupex --defaults-file=/etc/my.cnf --user=root --passwor='+N4dohask+MsLhG' /data/backup/
finde /daten/backup/* -mtime +1 -exec rm -fr {} \;
~

Auf den ersten Blick ist an diesem Skript nichts auszusetzen. Aber wenn Sie genau hinsehen, werden Sie feststellen, dass in der letzten Zeile ein „~“-Symbol steht. Da stimmt etwas nicht! Die Absicht des Autors des Skripts bestand darin, einmal täglich eine Sicherungskopie der Datenbank zu erstellen und anschließend die historischen Sicherungsdaten vom Vortag zu löschen, um die Festplatte nicht zu füllen.

Es gibt jedoch zwei schwerwiegende Probleme, die hier beschrieben werden.

Fehler bei der Sicherungsstrategie

Es gibt ein dediziertes Sicherungssystem, und die Daten sollten auf diesem System und nicht auf einer lokalen Sicherung gesichert werden.

Falsche Mittel

Nachdem das Sicherungsskript geschrieben wurde, sollte es manuell ausgeführt werden, um seine Richtigkeit zu überprüfen. Anstatt es nach dem Schreiben einfach dorthin zu werfen.

Reparieren von Festplattenfehlern

Kontaktieren Sie dringend den Computerraum und bitten Sie die Techniker, KVM an den Hostcomputer anzuschließen. Falls das System nicht gestartet werden kann, können Sie es aus der Ferne anzeigen oder im Einzelbenutzermodus Reparaturvorgänge wie fsck durchführen.

Stellen Sie über SSH eine Verbindung zum Hostsystem Debian her, bestätigen Sie, dass der gesamte Speicherplatz freigegeben ist, und führen Sie dann einen Neustart aus, um das System neu zu starten. Nach einigen Minuten startet das System normal.

Nachfolgende Operationen

Beim Überprüfen des Systemprotokolls ist kein Festplatten-E/A-Fehler aufgetreten und die Erstellung von Verzeichnissen und Dateien verläuft normal. Auch das Starten jeder virtuellen Maschine und der darauf befindlichen Datenbank verläuft normal.

Benachrichtigen Sie alle Beteiligten und prüfen Sie, ob aus geschäftlicher Sicht alles im Lot ist. Nach einer Weile erhielt ich eine Reihe von Genesungsnachrichten per SMS und fühlte mich viel wohler. Es erübrigt sich zu sagen, dass dies vom SA des Projekts durchgeführt wurde und niemanden darüber informiert wurde.

Sagen Sie es ihm unter vier Augen und bitten Sie ihn, die Sache auch anderen Leuten zu erklären. Wenn Sie in Zukunft etwas Riskantes tun, informieren Sie sich am besten gegenseitig.

Das Obige habe ich Ihnen vorgestellt. Wie man mit genau so einem Shell-Skript eine ganze Reihe von MySQL-Datenbanken beendet. Ich hoffe, es wird Ihnen helfen. Wenn Sie Fragen haben, hinterlassen Sie mir bitte eine Nachricht und ich werde Ihnen rechtzeitig antworten. Ich möchte auch allen für ihre Unterstützung der Website 123WORDPRESS.COM danken!