Ein praktischer Bericht über die Wiederherstellung einer MySQL Slave-Bibliothek

Beschreibung der Situation:

Heute habe ich mich bei einem MySQL-Datenbank-Slave-Knotenhost angemeldet und eine große Anzahl von mysql-relay-bin-Dateien gefunden, die in /var/lib/mysql gespeichert sind. Das früheste Dateierstellungsdatum war sogar 2018. Ich erinnere mich, dass diese Dateien gelöscht wurden, nachdem die Slave-Bibliothek die Protokolloperationsaufzeichnungen des Masters synchronisiert hatte (die Standardeinstellung löschte sie nicht, ich erinnerte mich falsch), also überprüfte ich den Status der Slave-Bibliothek und fand den folgenden Fehler:

mysql> Slave-Status anzeigen\G;
*************************** 1. Reihe ***************************
        Slave_IO_State: Wartet darauf, dass der Master ein Ereignis sendet
         Master_Host: *.*.*.*
         Master_Benutzer: dbsync
         Master_Port: 3306
        Verbindungswiederholung: 60
       Master_Log_File:mysql-bin.000095
     Read_Master_Log_Pos: 869242147
        Relay-Log-Datei:mysqld-relay-bin.000146
        Relay_Log_Pos: 871280529
    Relay_Master_Log_File: mysql-bin.000075
       Slave_IO_Running: Ja
      Slave_SQL_Running: Nein
       Replikations-Do_DB: cdb,cdb_admin
     Replicate_Ignore_DB: mysql
      Tabelle_replizieren: 
    Tabelle_Ignorieren_replizieren: 
   Wild_Do_Tabelle replizieren: 
 Tabelle_Wild_Ignore_replizieren: 
          Letzte_Fehlernummer: 1594
          Last_Error: Fehler beim Lesen des Relay-Logs: Ereigniseintrag des Relay-Logs konnte nicht analysiert werden. Mögliche Gründe sind: Das Binärlog des Masters ist beschädigt (Sie können dies überprüfen, indem Sie „mysqlbinlog“ auf dem Binärlog ausführen), das Relay-Log des Slaves ist beschädigt (Sie können dies überprüfen, indem Sie „mysqlbinlog“ auf dem Relay-Log ausführen), ein Netzwerkproblem oder ein Fehler im MySQL-Code des Masters oder Slaves. Wenn Sie das Binärlog des Masters oder das Relay-Log des Slaves überprüfen möchten, können Sie deren Namen erfahren, indem Sie „SHOW SLAVE STATUS“ auf diesem Slave ausführen.
         Skip_Counter: 0
     Exec_Master_Log_Pos: 871280384
       Relay_Log_Space: 19994786573
       Until_Condition: Keine
        Bis_Log_Datei: 
        Bis_Log_Pos: 0
      Master_SSL_Allowed: Nein
      Master_SSL_CA_Datei: 
      Master_SSL_CA_Pfad: 
       Master_SSL_Zertifikat: 
      Master_SSL_Chiffre: 
        Master_SSL_Schlüssel: 
    Seconds_Behind_Master: NULL
Master_SSL_Verify_Server_Cert: Nein
        Last_IO_Errno: 0
        Letzter_E/A-Fehler: 
        Last_SQL_Errno: 1594
        Last_SQL_Error: Fehler beim Lesen des Relay-Protokolls: Ereigniseintrag des Relay-Protokolls konnte nicht analysiert werden. Mögliche Gründe sind: Das Binärprotokoll des Masters ist beschädigt (Sie können dies überprüfen, indem Sie „mysqlbinlog“ auf dem Binärprotokoll ausführen), das Relay-Protokoll des Slaves ist beschädigt (Sie können dies überprüfen, indem Sie „mysqlbinlog“ auf dem Relay-Protokoll ausführen), ein Netzwerkproblem oder ein Fehler im MySQL-Code des Masters oder Slaves. Wenn Sie das Binärprotokoll des Masters oder das Relay-Protokoll des Slaves überprüfen möchten, können Sie deren Namen erfahren, indem Sie „SHOW SLAVE STATUS“ auf diesem Slave ausführen.
1 Zeile im Satz (0,00 Sek.)

FEHLER: 
Keine Abfrage angegeben

Grund:

Ich habe die Datei im Format mysql-bin.00007 auf dem Masterknoten gelöscht, einschließlich mysql-bin.000075. Infolgedessen konnte die Slave-Bibliothek die Datei nicht finden und konnte nicht synchronisiert werden.

Lösung:

1. Geben Sie die Synchronisierungsposition in der Slave-Bibliothek erneut an. (Nicht machbar)

Sklavenstopp;
CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000095',MASTER_LOG_POS=869242147; //Die bestehende Position von mysql-bin.000095 auf dem MySQL-Masterknoten-Slave-Start;

Wenn ich „show slave status“ auf dem Slave-Knoten ausführe, wird immer noch eine Fehlermeldung ausgegeben. Ich habe die spezifische Fehlermeldung nicht notiert, aber ich erinnere mich, dass errno 1236 ist, der Prozess Slave_IO_Running nicht läuft und der Prozess Slave_SQL_Running läuft. Die allgemeine Beschreibung ist, dass es ein Problem mit einer Tabelle in einer bestimmten Bibliothek gibt.

Nach mehreren Versuchen, verschiedene Synchronisierungsorte anzugeben (den Ort, an dem der Fehler gemeldet wurde, den Ort, an dem mysql-bin-000095 auf dem Master gerade geschrieben wurde), trat der Fehler weiterhin auf.

Tatsächlich gibt es bereits Probleme mit den Tabellendatensätzen. Nehmen wir als Beispiel die in der Beschreibung erwähnte Tabelle. Die Slave-Datenbank speichert etwa 1.200 Datensätze, während die Master-Datenbank über mehr als 1.900 Datensätze verfügt. Sofern ich diese Daten nicht manuell hinzufüge, kann ich den aktuellsten Speicherort für die Ausführung eines konsistenten Protokollvorgangs nicht finden, da die Protokolle, die die Vorgangsdaten aufzeichnen, verloren gegangen sind (von mir gelöscht).

2. Erstellen Sie die Slave-Bibliothek neu.

Da der Datenunterschied zu groß ist und ich denke, dass das Problem nicht auf eine Tabelle beschränkt ist, sollten Sie aufräumen und die Slave-Datenbank neu erstellen.
1) Vergleichen Sie die Konfigurationsinformationen der Master- und Slave-Knotenbibliothek, um Konsistenz sicherzustellen. (Ich weiß nicht, warum der Dual-Master-Modus eingestellt ist, aber ich habe tatsächlich nur eine Instanz auf dem Masterknoten laufen?)

2) Überprüfen Sie den Verkehrsstatus auf den Master- und Slave-Knoten (Prozessliste anzeigen), um sicherzustellen, dass kein Geschäftsverkehr mit der Slave-Datenbank verbunden ist, der erneut ausgeführt werden muss.

3) Stoppen Sie den Slave-Prozess auf dem Master-Knoten. (Ich habe es nicht geöffnet, seit es aufgehört hat, also weiß ich nicht, ob es irgendwelche Probleme gibt. Ich werde abwarten und sehen)

4) Notieren Sie den Speicherort der Protokolldatensätze der Bibliothek auf dem Masterknoten und sichern Sie anschließend die Datenbank:

mysql> Masterstatus anzeigen;
+------------------+----------+------------------------------+------------------+
| Datei | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+------------------------------+------------------+
| mysql-bin.000095 | 871760173 | cdb,cdb_admin | mysql |
+------------------+----------+------------------------------+------------------+
1 Zeile im Satz (0,01 Sek.)
 mysqldump -u root -p --databases cdb,cdb_admin > bak.master.sql

5) Um auf Nummer sicher zu gehen, sichern Sie die Slave-Knotenbibliothek:

mysqldump -u root -p --databases cdb,cdb_admin > bak.slave.sql

6) Neustart: Kopieren Sie die Sicherungsdatei der Master-Datenbank auf den Slave-Knoten und importieren Sie die Sicherungsdatei

mysql -u root -p < bak.master.sql

7) Geben Sie auf dem Slave-Knoten den Speicherort zum Lesen des Master-Protokolls erneut an:

Sklavenstopp;
CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000095',MASTER_LOG_POS=871760173; //POS ist die Position des Protokolldatensatzes des Masterknotens, der gerade beim Start des Slaves aufgezeichnet wurde;

8) Zeigen Sie den Slave-Status auf dem Slave-Knoten an. Zu diesem Zeitpunkt werden Slave_IO_Running und Slave_SQL_Running beide ausgeführt. Aktualisieren Sie den Slave-Status, und der Wert von Read_Master_Log_Pos beginnt ebenfalls zu steigen, und die Synchronisierung wird erneut gestartet.

Zusammenfassen:

Achten Sie beim Bereinigen von Dateien auf den Speicherort der MySQL-Bin-Datei beim Lesen und Schreiben im Protokoll des Master- und Slave-Knotens! Vor dem Löschen müssen Sie bestätigen, dass die Protokollposition sowohl auf dem Master- als auch auf dem Slave-Knoten gelesen wurde. Löschen Sie nicht wahllos, da sonst die Slave-Datenbank nicht synchronisiert werden kann. Selbst wenn Sie die Master-Protokollleseposition auf dem Slave-Knoten zwangsweise angeben oder den Fehler überspringen, kann die Möglichkeit eines Datenverlusts auf der Slave-Datenbank nicht ausgeschlossen werden.

Das Obige ist der vollständige Inhalt dieses Artikels. Ich hoffe, er wird für jedermanns Studium hilfreich sein. Ich hoffe auch, dass jeder 123WORDPRESS.COM unterstützen wird.