Gängige Reparaturmethoden für die Trennung der MySQL Master-Slave-Replikation

01 Problembeschreibung

In einer Produktionsumgebung treten häufig Situationen auf, in denen die MySQL-Master-Slave-Replikation unterbrochen wird. Wenn die Master-Slave-Replikation unterbrochen wird, werden in der Regel folgende Schritte zur Lösung des Problems durchgeführt:

1. Verwenden Sie „Slave-Status anzeigen“ in der Datenbank, um den intuitiven Grund für die Replikationstrennung anzuzeigen und den aktuellen Replikationsstandort aufzuzeichnen

2. Überprüfen Sie das Fehlerprotokoll, um die Gründe für die Unterbrechung der Replikation genauer zu analysieren

3. Reparieren Sie die Master-Slave-Replikationsbeziehung

4. Wenn die Replikationsbeziehung nicht repariert werden kann, müssen Sie die Slave-Datenbank neu erstellen

02 Lösung

Es gibt verschiedene Gründe, warum die Master-Slave-Replikationsbeziehung unterbrochen wird. Manchmal haben wir keine Zeit, die Ursache objektiv zu analysieren, weil die Anwendung unbrauchbar ist und sofort wiederhergestellt werden muss. In diesem Fall müssen wir einen Kompromiss zwischen dem Replikationsunterbrechungsproblem und der Dienstverfügbarkeit finden und dann entsprechend damit umgehen.

Gängige Methoden zum Beheben von Master-Slave-Replikationsunterbrechungen sind die folgenden:

1. Finden Sie andere Slave-Bibliotheken und ersetzen Sie sie schnell

Diese Methode erfordert, dass Ihre Anwendung eine Architektur mit mindestens einem Master und zwei Slaves hat. Wenn in einer der Slave-Bibliotheken ein Problem auftritt, kann die andere Slave-Bibliothek schnell online geschaltet werden, um den Anwendungszugriff wiederherzustellen. Die spezifische Ursache des Problems in der ausgefallenen Slave-Bibliothek kann später untersucht werden.

2. Überspringen Sie den Fehler des fehlgeschlagenen Kopierens

In einigen Fällen können wir den Grund für die Unterbrechung der Master-Slave-Replikation ermitteln. Wenn beispielsweise auf dem Master eine Datenbank db_1 mehr vorhanden ist als auf dem Slave, wird die Replikation des Slaves definitiv unterbrochen, wenn wir auf dem Master „drop database db_1“ ausführen. In diesem Fall können wir das Problem lösen, indem wir eine Transaktion überspringen.

Methode 1: (die aktuelle Transaktion direkt überspringen)

Im GTID-Modus kann dies durch den folgenden Befehl gelöst werden:

mysql> SLAVE STOPPEN;
mysql> SET GTID_NEXT='xxxxxx:yyy'; ----- Legen Sie das zu überspringende GTID-Ereignis fest
mysql> BEGINNEN;COMMIT;
mysql> SET GTID_NEXT='AUTOMATISCH';
mysql> START SLAVE;

Im Nicht-GTID-Modus kann dies durch den folgenden Befehl gelöst werden:

Sklave stoppen;
setze sql_slave_skip_counter=1;
Slave starten;

Methode 2: (Neuen Standort angeben)

Wenn wir den spezifischen Speicherort der nächsten Transaktion durch die Binlog-Analyse kennen, können wir das Problem auch lösen, indem wir den spezifischen Speicherort der nächsten Transaktion angeben:

Im GTID-Modus:

mysql> SLAVE STOPPEN;
mysql> MASTER ZURÜCKSETZEN;
mysql> SET @@GLOBAL.GTID_PURGED ='xxxxxxx:yyyyyy' ----- zeigt an, dass diese GTID-Ereignisse ausgeführt wurden mysql> START SLAVE;

Beachten Sie, dass GTID_PURGED GLOBAL sein muss. Der obige Befehl kann auch als set global gtid_purged='xxx:yyy' geschrieben werden.

Im Nicht-GTID-Modus:

Sklave stoppen;
Ändern Sie Master in master_log_file='mysql-bin.001360',master_log_pos=676383371;
Slave starten;

Methode 3: pt-slave-restart-Tool

Wenn wir eine Transaktion überspringen und trotzdem eine Trennung vorliegt (z. B. haben wir 100 Daten in der Slave-Datenbank gelöscht, aber die Master-Datenbank möchte diese 100 Daten aktualisieren), können wir das Tool pt-slave-restart verwenden, mit dem die getrennte Position kontinuierlich übersprungen werden kann.

So verwenden Sie es:

pt-slave-restart -h 10.xxx.xxx.xxx -P Port -u Benutzer -p Passwort

Wenn wir parallele Replikation verwenden, meldet pt-slave-restart möglicherweise einen Fehler. Zu diesem Zeitpunkt können wir die parallele Replikation in eine Single-Thread-Replikation ändern und dann das Tool pt-slave-restart verwenden. Sie können diesen Artikel lesen:

Werkzeug „pt-slave-restart“

Methode 4: Setzen Sie den Parameter slave_exec_mode

Dieser Parameter kann den Ausführungsmodus der Slave-Bibliothek während des Master-Slave-Replikationsprozesses ändern. Wenn er auf den strikten Modus eingestellt ist, wird die gesamte Replikation gestoppt, sobald ein Fehler gemeldet wird. Wenn er auf den idempotenten Modus eingestellt ist, werden Fehler mit bestimmten Fehlernummern übersprungen. Der Befehl lautet wie folgt:

Setzen Sie den globalen Slave_Exec_Mode auf idempotent.

Einzelheiten entnehmen Sie bitte dem vorherigen Artikel:

Einführung in drei Parameter des MySQL-Replikationsproblems

In diesem Artikel gibt es zwei weitere Parameter zum Überspringen von Replikationsfehlern, nämlich slave_skip_errors und sql_slave_skip_counter.

3. Verwenden Sie ein Backup, um die Slave-Bibliothek neu zu erstellen

Diese Methode wird in vielen Szenarien nicht verwendet. Normalerweise wird diese Methode nur dann in Betracht gezogen, wenn die Slave-Bibliothek nicht verfügbar ist oder nicht mit der Master-Bibliothek synchronisiert werden kann. Beispielsweise wird der Vorgang „Master zurücksetzen“ für die Master-Bibliothek ausgeführt, wodurch alle Binärprotokolle gelöscht werden. In diesem Fall kann die Slave-Bibliothek das richtige Binärprotokoll nicht abrufen und lesen und die Replikation wird unterbrochen. In diesem Fall ist das Neuaufbauen der Slave-Bibliothek möglicherweise die einzige Möglichkeit.

Oben finden Sie Einzelheiten zu den häufig verwendeten Reparaturmethoden für die Trennung der MySQL-Master-Slave-Replikation. Weitere Informationen zur Reparatur der Trennung der MySQL-Master-Slave-Replikation finden Sie in den anderen verwandten Artikeln auf 123WORDPRESS.COM!