Lösung für MySQL-Replikationsfehler aufgrund voller Festplatte

Lösung für MySQL-Replikationsfehler aufgrund voller Festplatte

Fallbeispiel

Heute wurde online ein Problem entdeckt. Aufgrund mangelnder Überwachungsabdeckung war die Festplatte einer bestimmten Maschine voll, was zu Problemen bei der Online-MySQL-Master-Slave-Replikation führte. Das Problem ist folgendes:

localhost.(keine)>Slave-Status anzeigen\G
*************************** 1. Reihe ***************************
               Slave_IO_State:
                  Master_Host: 10.xx.xx.xx
                  Master_User: Replikat
                  Master_Port: 5511
                Verbindungswiederholung: 60
              Master_Log_Datei:
          Read_Master_Log_Pos: 4
               Relay_Log_File: relay-bin.001605
                Relay_Log_Pos: 9489761
        Relay_Master_Log_File:
             Slave_IO_Running: Nein
            Slave_SQL_Running: Nein
                   Letzte_Fehlernummer: 13121
                   Last_Error: Fehler beim Lesen des Relay-Protokolls: Der Ereigniseintrag des Relay-Protokolls 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' im Binärlog), ist das Relay-Log des Slaves beschädigt (Sie können dies überprüfen, indem Sie
 Ausführen von 'mysqlbinlog' im Relay-Log), ein Netzwerkproblem, der Server konnte keinen
 Schlüsselbundschlüssel zum Öffnen einer verschlüsselten Relay-Logdatei oder ein Fehler im Master- oder
 MySQL-Code des Slaves. Wenn Sie das Binärlog des Masters oder das Relay-Log des Slaves überprüfen möchten,
 Sie können ihre Namen erfahren, indem Sie auf diesem Slave „SHOW SLAVE STATUS“ eingeben.

Also habe ich das Fehlerprotokoll überprüft und darin den folgenden Inhalt gefunden:

2021-03-31T11:34:39.367173+08:00 11 [Warnung] [MY-010897] [Repl] Speichern von MySQL-Benutzernamen oder
 Die Kennwortinformationen im Master-Info-Repository sind nicht sicher und werden daher nicht
 empfohlen. Bitte erwägen Sie die Verwendung der Verbindungsoptionen USER und PASSWORD für START SLAVE.
 Weitere Informationen finden Sie in der „START SLAVE-Syntax“ im MySQL-Handbuch.

2021-03-31T11:34:39.368161+08:00 12 [FEHLER] [MY-010596] [Repl] Fehler beim Lesen des Relay-Protokolls
 Ereignis für Kanal '': Binärprotokoll mitten im Ereignis abgeschnitten; Speicherplatz auf der Festplatte erschöpft

2021-03-31T11:34:39.368191+08:00 12 [FEHLER] [MY-013121] [Repl] Slave SQL für Kanal '': Relay
 Fehler beim Lesen des Protokolls: Der Ereigniseintrag im Relay-Protokoll konnte nicht analysiert werden. Mögliche Gründe sind:
 Das Binärprotokoll ist beschädigt (Sie können dies überprüfen, indem Sie „mysqlbinlog“ im Binärprotokoll ausführen).
 Das Relay-Log des Slaves ist beschädigt (Sie können dies überprüfen, indem Sie „mysqlbinlog“ im Relay-Log ausführen).
 Aufgrund eines Netzwerkproblems konnte der Server den zum Öffnen einer verschlüsselten
 Relay-Logdatei oder ein Fehler im MySQL-Code des Masters oder Slaves. Wenn Sie die
 Das Binärlog des Masters oder das Relaylog des Slaves, deren Namen Sie erfahren, indem Sie 'SHOW
 SLAVE STATUS‘ auf diesem Slave. Fehlercode: MY-013121

2021-03-31T11:34:39.368205+08:00 12 [FEHLER] [MY-010586] [Repl] Fehler beim Ausführen der Abfrage, Slave-SQL
 Thread abgebrochen. Beheben Sie das Problem und starten Sie den Slave-SQL-Thread mit "SLAVE START" neu. Wir
 angehalten bei Protokoll 'mysql-bin.000446' Position 9489626

Wie Sie der Beschreibung entnehmen können, ist das Fehlerprotokoll recht intelligent. Es hat das Festplattenproblem gefunden und uns aufgefordert, „nicht genügend Speicherplatz zu berücksichtigen“.

Lösung des Problems

Nachdem ich mich beim Server angemeldet hatte, stellte ich schnell fest, dass die Festplattennutzung des Servers, auf dem sich MySQL befindet, 100 % erreicht hatte. Die Ursache des Problems stimmte mit dem Inhalt des Fehlerprotokolls überein.

Lösen Sie dieses Problem jetzt. Die Grundidee besteht darin, die Datenträgerdateien zu bereinigen und dann die Replikationsbeziehung neu aufzubauen. Dieser Vorgang scheint relativ einfach zu sein, aber im tatsächlichen Betrieb tritt beim Aufbau der Replikationsbeziehung der folgende Fehler auf:

### Basierend auf der GTID-Replikation möchte ich die Replikationsbeziehung localhost.(none)>reset slave; neu erstellen.
FEHLER 1371 (HY000): Löschen alter Relay-Protokolle fehlgeschlagen: Beim Zurücksetzen des Protokolls ist ein Fehler aufgetreten.

localhost.(keine)>alle Slaves zurücksetzen;
FEHLER 1371 (HY000): Löschen alter Relay-Protokolle fehlgeschlagen: Beim Zurücksetzen des Protokolls ist ein Fehler aufgetreten.

Schritt 1: Da die Replikation auf GTID basiert, können Sie nach dem direkten Aufzeichnen des Status von „Show Slave Status“ den Slave zurücksetzen und die Anweisung „Change Master“ verwenden, um die Replikationsbeziehung neu zu erstellen.

Es wird jedoch die obige Fehlermeldung angezeigt. Aus der Fehlermeldung geht hervor, dass MySQL den Löschvorgang des Relay-Protokolls nicht abschließen kann, was nicht wissenschaftlich erscheint. Da Sie den Vorgang zum Löschen der Relay-Protokolle nicht alleine durchführen können, möchte ich Ihnen helfen.

Schritt 2: Löschen Sie alle Relay-Protokolle manuell mit rm -f. Sie sehen, dass die Fehlermeldung wie folgt lautet:

localhost.(keine)>alle Slaves zurücksetzen;
FEHLER 1374 (HY000): E/A-Fehler beim Lesen der Protokollindexdatei

Na gut, das Problem wurde nicht gelöst.

Dann habe ich darüber nachgedacht. Da ich das Relay-Protokoll nicht durch manuelles Zurücksetzen des Slaves bereinigen konnte, habe ich es einfach gestoppt.

Ist ein Wechsel vom Slave zum Master möglich?

Schritt 3: Stoppen Sie den Slave direkt und wechseln Sie dann den Master, ohne die Anweisung „reset slave all“ auszuführen. Das Ergebnis ist wie folgt:

localhost.(none)>Ändern Sie den Master in master_host='10.13.224.31',
    -> master_user='Replik',
    -> Master-Passwort = 'eHnNCaQE3ND',
    -> Master-Port = 5510,
    -> master_auto_position=1;
FEHLER 1371 (HY000): Löschen alter Relay-Protokolle fehlgeschlagen: Beim Zurücksetzen des Protokolls ist ein Fehler aufgetreten.

Nun, das Problem bleibt bestehen.

Schritt 4: Die Replikation wurde jedenfalls mit einem Fehler unterbrochen. Führen Sie also „start slave“ aus, um zu sehen, was passiert. Als Ergebnis bietet sich eine dramatische Szene:

localhost.(keine)>Slave starten;
FEHLER 2006 (HY000): MySQL-Server ist weg
Keine Verbindung. Versuch, die Verbindung wiederherzustellen …
Verbindungs-ID: 262
Aktuelle Datenbank: *** KEINE ***


Abfrage OK, 0 Zeilen betroffen (0,01 Sek.)


localhost.(keine)>
[Wurzel@ ~]

Nach der Ausführung von „Start Slave“ bleibt die Instanz direkt hängen.

Zu diesem Zeitpunkt ist die Replikation vollständig getrennt und die Slave-Instanz ist abgestürzt.

Schritt 5: Überprüfen Sie, ob die Instanz neu gestartet werden kann. Versuchen Sie, die Instanz neu zu starten, und stellen Sie fest, dass die Instanz erneut gestartet werden kann. Nachdem die Instanz neu gestartet wurde, überprüfen Sie die Replikationsbeziehung. Die Ergebnisse sind wie folgt:

localhost.(keine)>Slave-Status anzeigen\G
*************************** 1. Reihe ***************************
               Slave_IO_State: Master-Ereignis in die Relay-Log-Warteschlange einreihen
                  Master_Host: 10.xx.xx.xx
                  Master_User: Replikat
                  Master_Port: 5511
                Verbindungswiederholung: 60
              Master_Log_Datei:
           Read_Master_Log_Pos: 4
               Relay_Log_File: relay-bin.001605
                Relay_Log_Pos: 9489761
        Relay_Master_Log_File:
             Slave_IO_Running: Ja
            Slave_SQL_Running: Nein
                   Letzte_Fehlernummer: 13121
                   Last_Error: Fehler beim Lesen des Relay-Protokolls: Der Ereigniseintrag des Relay-Protokolls 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' im Binärlog), ist das Relay-Log des Slaves beschädigt (Sie können dies überprüfen, indem Sie
 Ausführen von 'mysqlbinlog' im Relay-Log), ein Netzwerkproblem, der Server konnte keinen
 Schlüsselbundschlüssel, der zum Öffnen einer verschlüsselten Relay-Logdatei erforderlich ist, oder ein Fehler im Master- oder Slave-
 MySQL-Code. Wenn Sie das Binärlog des Masters oder das Relaylog des Slaves überprüfen möchten, können Sie
 um ihre Namen zu erfahren, indem Sie auf diesem Slave die Ausgabe „SHOW SLAVE STATUS“ ausführen.
                 Skip_Counter: 0

Beim Kopieren der Beziehung tritt dennoch ein Fehler auf.

Schritt 6: Setzen Sie alle Slaves zurück und prüfen Sie, ob es erfolgreich ist.

localhost.(keine)>Slave stoppen;
Abfrage OK, 0 Zeilen betroffen (0,00 Sek.)


localhost.(keine)>alle Slaves zurücksetzen;
Abfrage OK, 0 Zeilen betroffen (0,03 Sek.)

Schritt 7: Wiederherstellen der Replikationsbeziehung und Starten der Replikation

localhost.(none)>Ändere Master in master_host='10.xx.xx.xx',
    -> master_user='Replik',
    -> Master-Passwort = 'xxxxx',
    -> Master-Port = 5511,
    -> master_auto_position=1;
Abfrage OK, 0 Zeilen betroffen, 2 Warnungen (0,01 Sek.)


localhost.(keine)>Slave starten;
Abfrage OK, 0 Zeilen betroffen (0,00 Sek.)


localhost.(keine)>Slave-Status anzeigen\G
*************************** 1. Reihe ***************************
               Slave_IO_State: Wartet darauf, dass der Master ein Ereignis sendet
                  Master_Host: 10.xx.xx.xx
                  Master_User: Replikat
                  Master_Port: 5511
                Verbindungswiederholung: 60
                          ...
             Slave_IO_Running: Ja
            Slave_SQL_Running: Ja

Es wurde festgestellt, dass die Replikationsbeziehung der Instanz hergestellt werden kann.

Zusammenfassung

Wenn die Festplatte voll ist, kann der MySQL-Dienst keine Daten in die Metainformationstabelle schreiben und das Relay-Protokoll ist möglicherweise unvollständig. Wenn Sie die Festplattendaten auf dem Server direkt bereinigen und dann den Master erneut ändern, um die Master-Slave-Replikationsbeziehung zu ändern, kann ein Fehler auftreten, der nicht direkt behoben werden kann, da dies kein normales Szenario für eine Unterbrechung der Master-Slave-Replikationsbeziehung ist.

Der richtige Ansatz sollte also sein:

1. Bereinigen Sie die Festplatte des Servers

2. Starten Sie die Slave-Bibliothek neu, deren Replikationsbeziehung getrennt ist

3. Setzen Sie alle Slaves zurück und ändern Sie den Master, um eine Master-Slave-Replikationsbeziehung aufzubauen

Wenn es einen besseren Weg gibt, lassen Sie es mich bitte wissen.

Oben finden Sie ausführliche Informationen zur Lösung des Problems, dass die MySQL-Replikation aufgrund einer vollen Festplatte fehlschlägt. Weitere Informationen zur Lösung des Problems, dass die MySQL-Replikation fehlschlägt, finden Sie in den anderen verwandten Artikeln auf 123WORDPRESS.COM!

Das könnte Sie auch interessieren:
  • Umfassende Analyse des MySql-Master-Slave-Replikationsmechanismus
  • Detaillierte Erläuterung der MySQL Master-Slave-Replikation und der Lese-/Schreibtrennung
  • So kopieren Sie eine MySQL-Tabelle
  • Automatisches Failover von Slave-Knoten in der Replikationsarchitektur in MySQL 8.0.23
  • MySQL-Datenbank GTID realisiert Master-Slave-Replikation (super praktisch)
  • Implementierungsprinzip und Konfiguration der MySql Master-Slave-Replikation
  • Eine kurze Analyse der parallelen WriteSet-Replikation von MySQL
  • MySQL Master-Slave-Replikationsprinzip und zu beachtende Punkte
  • So ändern Sie den Replikationsfilter in MySQL dynamisch
  • Eine kurze Analyse der parallelen MySQL-Replikation
  • Analyse von drei Parametern des MySQL-Replikationsproblems

<<:  CSS -webkit-box-orient: vertikale Eigenschaft nach der Kompilierung verloren

>>:  Lösen Sie das Problem, dass Docker Sudo-Operationen verwenden muss

Artikel empfehlen

Verwendung von „align-content“ im Zeilenumbruchbereich des Flex-Layouts

1. Das in diesem Artikel implementierte Effektdia...

So implementieren Sie die Anpassung des Echats-Diagramms an große Bildschirme

Inhaltsverzeichnis beschreiben erreichen Die Proj...

Javascript-Countdown-Eingabeaufforderungsfeld

In diesem Artikelbeispiel wird der spezifische Ja...

Lösung für die Nginx-Installation ohne Generierung des sbin-Verzeichnisses

Fehlerbeschreibung: 1. Nach der Installation von ...

Verwenden Sie Elasticsearch, um Indexdaten regelmäßig zu löschen

1. Manchmal verwenden wir ES Aufgrund begrenzter ...

Unterschiede zwischen FLOW CHART und UI FLOW

Viele Konzepte im UI-Design mögen in der Formulie...

Installieren Sie JDK1.8 in einer Linux-Umgebung

Inhaltsverzeichnis 1. Installationsumgebung 2. In...

jQuery-Plugin zum Erzielen eines Code-Rain-Effekts

In diesem Artikel wird der spezifische Code des j...

Erfahrungsaustausch durch einen Frontend-Supervisor mit 7 Jahren Praxiserfahrung

Heute teile ich die wertvollen Erfahrungen eines ...

So verwenden Sie den Linux-Befehl „basename“

01. Befehlsübersicht Basisname - entfernt Verzeic...

Lösung für Ubuntu, das keine Verbindung zum Internet herstellen kann

Problembeschreibung: Ich habe einen Desktop-Compu...