Analyse von drei Parametern des MySQL-Replikationsproblems

Analyse von drei Parametern des MySQL-Replikationsproblems

Heute ist Dienstag. Ich bin morgens spät aufgewacht und zu spät zur Arbeit gekommen. Es war wirklich... . . Kurzerhand haben wir im gestrigen Artikel drei Parameter erwähnt, nämlich:

  • Slave_exec_mode-Parameter;
  • sql_slave_skip_counter=N-Parameter;
  • Slave-Skip-Errors=N-Parameter.

Diese drei Parameter können bestimmte Fehler bei der parallelen Replikation beheben, z. B. den Fehler „Duplicate Key 1062“. Heute werden wir kurz die Unterschiede zwischen diesen drei Parametern testen:

01 sql_slave_skip_counter-Parameter

Dieser Parameter wird hauptsächlich verwendet, um bestimmte fehlerhafte „Ereignisse“ zu überspringen. Beachten Sie, dass das hier verwendete Wort „Ereignis“ und nicht „Transaktion“ ist, da es im Wesentlichen darum geht, Ereignisse einzeln zu überspringen. Es ist zu beachten, dass dieser Parameter im Offset-Replikationsmodus verwendet werden muss. Wenn der GTID-Replikationsmodus verwendet wird, kann dieser Parameter nicht verwendet werden. Schauen wir uns ein Beispiel an. Zuerst erstellen wir eine Replikationsbeziehung:

Meister 10.30.124.68

Sklave 10.30.124.128

Diese beiden Instanzen sind Master und Slave zueinander. Wir erstellen eine Testtabelle test.yeyz und fügen einige Daten ein, wobei id der Primärschlüssel ist und wie folgt eindeutig ist:

Auf Master

mysql:(keine) 22:25:56>>Wählen Sie * aus test.yeyz;
+----+------+
| ID | Alter |
+----+------+
| 1 | 1 |
| 2 | 2 |
| 3 | 3 |
| 4 | 4 |
+----+------+
4 Zeilen im Satz (0,00 Sek.)

Auf Sklave

mysql:(keine) 22:25:38>>Wählen Sie * aus test.yeyz;
+----+------+
| ID | Alter |
+----+------+
| 1 | 1 |
| 2 | 2 |
| 3 | 3 |
| 4 | 4 |
| 5 | 5 |
+----+------+
5 Zeilen im Satz (0,00 Sek.)

Wir können feststellen, dass der Slave-Knoten einen Datensatz mehr hat als der Master-Knoten, mit einem zusätzlichen Datensatz mit der ID=5. Dann fügen wir Daten auf dem Master-Knoten ein:

mysql:(keine) 22:26:06>>in test.yeyz Werte (5,5),(6,6) einfügen;
Abfrage OK, 2 Zeilen betroffen (0,00 Sek.)
Datensätze: 2 Duplikate: 0 Warnungen: 0

Beobachten Sie zu diesem Zeitpunkt den Slave-Knoten:

mysql:(keine) 22:26:34>>Slave-Status anzeigen\G
                  Master_Host: 10.30.124.68
                  Master_Benutzer: dba_repl
                  Master_Port: 4306
                Verbindungswiederholung: 60
              Master_Log_File:mysqlbin.000002
          Read_Master_Log_Pos: 523
               Relay_Log_Datei: slave-relay-bin.000002
                Relay_Log_Pos: 319
        Relay_Master_Log_File: mysqlbin.000002
             Slave_IO_Running: Ja
            Slave_SQL_Running: Nein
                   Letzte_Fehlernummer: 1062
                   Last_Error: Der Koordinator wurde angehalten, da Fehler auftraten.
 im/in den Arbeiter(n). Der letzte Fehler war:
 Worker 0 konnte die Transaktion 'ANONYMOUS' nicht ausführen bei
 Hauptprotokoll mysqlbin.000002, end_log_pos 492.
 Siehe Fehlerprotokoll und/oder performance_schema.replication_applier_status_by_worker
 Weitere Einzelheiten zu diesem oder anderen Fehlern (sofern vorhanden) finden Sie in der Tabelle.
                 Skip_Counter: 0

Es kann festgestellt werden, dass der SQL-Thread des Slave-Knotens getrennt wurde. Fragen Sie zu diesem Zeitpunkt das Binlog an Position 492 dieses Fehlers auf dem Master-Knoten ab und Sie können Folgendes sehen:

mysql:(keine) 22:30:28>>Binlog-Ereignisse in „mysqlbin.000002“ von 194 anzeigen;
  +-----------------+-----+----------------+--------------+-------------+-----------------------------------------+
| Logname | Pos | Ereignistyp | Server-ID | End_log_pos | Info |
+-----------------+-----+----------------+--------------+-------------+-----------------------------------------+
| mysqlbin.000002 | 194 | Anonymous_Gtid | 192 | 259 | SET @@SESSION.GTID_NEXT= 'ANONYMOUS' |
| mysqlbin.000002 | 259 | Abfrage | 192 | 327 | BEGIN |
| mysqlbin.000002 | 327 | Rows_query | 192 | 391 | # in test.yeyz Werte (5,5),(6,6) einfügen |
| mysqlbin.000002 | 391 | Table_map | 192 | 439 | table_id: 108 (test.yeyz) |
| mysqlbin.000002 | 439 | Zeilen schreiben | 192 | 492 | Tabellen-ID: 108 Flags: STMT_END_F |
| mysqlbin.000002 | 492 | Xid | 192 | 523 | COMMIT /* xid=38 */ |
+-----------------+-----+----------------+--------------+-------------+-----------------------------------------+
6 Zeilen im Satz (0,00 Sek.)

Aus dem obigen Binärprotokoll können wir ersehen, dass einer unserer Einfügevorgänge tatsächlich fünf Ereignisse mit entsprechenden Positionen von 259 bis 492 generiert hat. Über Ereignisse werden wir später sprechen.

Da der Datensatz mit der ID=5 auf dem Masterknoten eingefügt wurde, steht er im Konflikt mit dem Datensatz auf dem Slaveknoten. Beim Überprüfen des Fehlerprotokolls finden wir Folgendes:

Doppelter Eintrag '5' für Schlüssel 'PRIMARY',
 Fehlercode: 1062; Handler-Fehler HA_ERR_FOUND_DUPP_KEY;
 ZUERST das Hauptprotokoll der Veranstaltung,
 end_log_pos 492 | 16.07.2019 22:26:25

Wir lösen dieses Problem, indem wir den Parameter sql_slave_skip_counter festlegen. Die Schritte sind wie folgt:

mysql:(keine) 22:29:32>>Slave stoppen;
Abfrage OK, 0 Zeilen betroffen, 1 Warnung (0,00 Sek.)

mysql:(keine) 22:32:45>>globalen sql_slave_skip_counter=1 festlegen;
Abfrage OK, 0 Zeilen betroffen (0,00 Sek.)

mysql:(keine) 22:33:06>>Slave starten;

Im gestrigen Artikel haben wir gesagt, dass der Wert nach sql_slave_skip_counter die Anzahl der Ereignisse ist, daher entspricht dies dem Überspringen eines Ereignisses. MySQL legt fest, dass die Transaktion weiterhin übersprungen wird, wenn Sie ein Ereignis überspringen und sich noch in einer Transaktion befinden.

Nachdem wir diesen Parameter zum Überspringen eines Ereignisses verwendet haben, sehen wir uns die Daten und den Replikationsstatus in der Datenbanktabelle an und sehen:

Slave-Tabelle:

mysql:(keine) 22:33:10>>Slave-Status anzeigen\G
*************************** 1. Reihe ***************************
               Slave_IO_State: Wartet darauf, dass der Master ein Ereignis sendet
                  Master_Host: 10.30.124.68
                  Master_Benutzer: dba_repl
                  Master_Port: 4306
                Verbindungswiederholung: 60
              Master_Log_File:mysqlbin.000002
          Read_Master_Log_Pos: 523
               Relay_Log_Datei: slave-relay-bin.000003
                Relay_Log_Pos: 319
        Relay_Master_Log_File: mysqlbin.000002
             Slave_IO_Running: Ja
            Slave_SQL_Running: Ja


mysql:(keine) 22:33:16>>Wählen Sie * aus test.yeyz;
+----+------+
| ID | Alter |
+----+------+
| 1 | 1 |
| 2 | 2 |
| 3 | 3 |
| 4 | 4 |
| 5 | 5 |
+----+------+
5 Zeilen im Satz (0,00 Sek.)

Schauen Sie sich die Haupttabelle an:

mysql:(keine) 22:33:36>>Wählen Sie * aus test.yeyz;
+----+------+
| ID | Alter |
+----+------+
| 1 | 1 |
| 2 | 2 |
| 3 | 3 |
| 4 | 4 |
| 5 | 5 |
| 6 | 6 |
+----+------+
6 Zeilen im Satz (0,00 Sek.)

Es kann festgestellt werden, dass das Einfügen der Daten in den Master erfolgreich ist, das Einfügen der Daten in den Slave jedoch fehlschlägt, das heißt:

Wenn dieser Parameter fälschlicherweise weggelassen wird, sind die Master- und Slave-Daten inkonsistent.

02 Slave_Skip_Errors-Parameter

Dieser Parameter dient zum Überspringen des angegebenen Fehlers, d. h. wir müssen den entsprechenden Fehlercode festlegen. Aus dem Inhalt des folgenden Protokolls können wir ersehen, dass der Wert von Fehlercode 1062 beträgt

Doppelter Eintrag '5' für Schlüssel 'PRIMARY',
 Fehlercode: 1062; Handler-Fehler HA_ERR_FOUND_DUPP_KEY;
 ZUERST das Hauptprotokoll der Veranstaltung,
 end_log_pos 492 | 16.07.2019 22:26:25

Wir müssen den Wert dieses Parameters manuell auf 1062 ändern. Es ist zu beachten, dass die Änderung dieses Parameters einen Neustart des MySQL-Dienstes erfordert, da dieser Parameter ein schreibgeschützter Parameter ist.

Die geänderte Situation ist wie folgt:

[email protected]:(keine) 22:38:55>>Variablen wie „%errors%“ anzeigen;
+--------------------+---------+
| Variablenname | Wert |
+--------------------+---------+
| max_Verbindungsfehler | 1000000 |
| Fehler beim Überspringen von Slave-Objekten | 1062 |
+--------------------+---------+
2 Zeilen im Satz (0,01 Sek.)

An diesem Punkt aktualisieren wir die Daten in der Master-Tabelle und der Slave-Tabelle. Die aktualisierte Situation ist wie folgt:

Master:

mysql:(keine) 22:39:15>>Wählen Sie * aus test.yeyz;
+----+------+
| ID | Alter |
+----+------+
| 1 | 1 || 2 | 2 |
| 3 | 3 || 4 | 4 |
| 5 | 5 || 6 | 6 |
+----+------+
6 Zeilen im Satz (0,00 Sek.)

Auf dem Slave:

mysql:(keine) 22:40:15>>Wählen Sie * aus test.yeyz;
+----+------+
| ID | Alter |
+----+------+
| 1 | 1 |
| 2 | 2 |
| 3 | 3 |
| 4 | 4 |
| 5 | 5 |
| 6 | 6 |
| 7 | 7 |
+----+------+
7 Zeilen im Satz (0,00 Sek.)

Wir haben festgestellt, dass die Slave-Tabelle einen Datensatz mehr enthält als die Master-Tabelle, nämlich den Datensatz mit der ID = 7. Zu diesem Zeitpunkt führen wir auf dem Master Folgendes aus:

mysql:(keine) 22:34:15>>in test.yeyz Werte (7,7),(8,8) einfügen;
Abfrage OK, 2 Zeilen betroffen (0,00 Sek.)
Datensätze: 2 Duplikate: 0 Warnungen: 0

Überprüfen Sie den Replikations- und Datenstatus auf dem Slave wie folgt:

mysql:(keine) 22:39:05>>Slave-Status anzeigen\G
*************************** 1. Reihe ***************************
               Slave_IO_State: Wartet darauf, dass der Master ein Ereignis sendet
                  Master_Host: 10.30.124.68
                  Master_Benutzer: dba_repl
                  Master_Port: 4306
                Verbindungswiederholung: 60
              Master_Log_File:mysqlbin.000002
          Read_Master_Log_Pos: 852
               Relay_Log_Datei: slave-relay-bin.000005
                Relay_Log_Pos: 648
        Relay_Master_Log_File: mysqlbin.000002
             Slave_IO_Running: Ja
            Slave_SQL_Running: Ja
              Replicate_Do_DB:
           Replikat_Ignorieren_DB:
            Tabelle_replizieren:
        Tabelle_Ignorieren_replizieren:
       Wild_Do_Tabelle replizieren:


 mysql:(keine) 22:40:15>>Wählen Sie * aus test.yeyz;
+----+------+
| ID | Alter |
+----+------+
| 1 | 1 |
| 2 | 2 |
| 3 | 3 |
| 4 | 4 |
| 5 | 5 |
| 6 | 6 |
| 7 | 7 |
+----+------+
7 Zeilen im Satz (0,00 Sek.)

Wie Sie sehen, liegt bei der Replikation kein Fehler vor, obwohl auf dem Slave bereits ein Datensatz mit der ID=7 vorhanden ist. Außerdem wurde festgestellt, dass die Daten in der Slave-Datenbank mit denen der vorherigen übereinstimmten, d. h. der in die Master-Datenbank eingefügte Datensatz mit der ID=8 wurde nicht synchronisiert.

Zusammenfassend: Wenn dieser Parameter Replikationsfehler überspringt, muss der MySQL-Dienst neu gestartet werden, was zu Inkonsistenzen zwischen Master- und Slave-Daten führen kann.

03 Slave-Skip-Errors = N-Parameter

Schauen wir uns den letzten Parameter an. Dieser Parameter gibt den Slave-Replikationsmodus bei paralleler Replikation an. Der Standardwert ist der strikte Modus. Schauen wir uns wie oben zuerst die Daten der Master- und Slave-Bibliotheken an:

Stammdaten:

mysql:(keine) 22:39:20>>Wählen Sie * aus test.yeyz;
                 +----+------+
| ID | Alter |
+----+------+
| 1 | 1 |
| 2 | 2 |
| 3 | 3 |
| 4 | 4 |
| 5 | 5 |
| 6 | 6 |
| 7 | 7 |
| 8 | 8 |
+----+------+
8 Zeilen im Satz (0,00 Sek.)

Slave-Daten:

mysql:(keine) 22:42:46>>Wählen Sie * aus test.yeyz;
+----+------+
| ID | Alter |
+----+------+
| 1 | 1 |
| 2 | 2 |
| 3 | 3 |
| 4 | 4 |
| 5 | 5 |
| 6 | 6 |
| 7 | 7 |
| 8 | 8 |
| 9 | 9 |
+----+------+
9 Zeilen im Satz (0,00 Sek.)

An diesem Punkt ändern wir die Parameter der Slave-Bibliothek wie folgt:

mysql:(keine) 22:42:59>>Variablen wie „%exec%“ anzeigen;
+----------------------------------+--------+
| Variablenname | Wert |
+----------------------------------+--------+
| gtid_executed_compression_perioden | 1000 |
| maximale Ausführungszeit | 0 |
| rbr_exec_mode | STRENG |
| Slave-Exec-Modus | STRENG |
+----------------------------------+--------+
4 Zeilen im Satz (0,00 Sek.)

mysql:(keine) 22:44:05>>globalen Slave_exec_mode='IDEMPOTENT' festlegen;
Abfrage OK, 0 Zeilen betroffen (0,00 Sek.)

mysql:(keine) 22:44:10>>Variablen wie „%exec%“ anzeigen;
           +----------------------------------+------------+
| Variablenname | Wert |
+----------------------------------+------------+
| gtid_executed_compression_perioden | 1000 |
| maximale Ausführungszeit | 0 |
| rbr_exec_mode | STRENG |
| Slave-Exec-Modus | IDEMPOTENT |
+----------------------------------+------------+
4 Zeilen im Satz (0,00 Sek.)

Nachdem wir die Parameter geändert haben, führen wir den Einfügevorgang in der Hauptdatenbank aus:

in test.yeyz Werte (9,9),(10,10) einfügen;

Überprüfen Sie den Replikationsstatus und den Datenstatus der Slave-Bibliothek wie folgt:

mysql:(keine) 22:44:14>>Slave-Status anzeigen\G
*************************** 1. Reihe ***************************
               Slave_IO_State: Wartet darauf, dass der Master ein Ereignis sendet
                  Master_Host: 10.30.124.68
                  Master_Benutzer: dba_repl
                  Master_Port: 4306
                Verbindungswiederholung: 60
              Master_Log_File:mysqlbin.000002
          Read_Master_Log_Pos: 1183
               Relay-Log-Datei: slave-relay-bin.000007
                Relay_Log_Pos: 650
        Relay_Master_Log_File: mysqlbin.000002
             Slave_IO_Running: Ja
            Slave_SQL_Running: Ja

1 Zeile im Satz (0,00 Sek.)

mysql:(keine) 22:44:38>>Wählen Sie * aus test.yeyz;
+----+------+
| ID | Alter |
+----+------+
| 1 | 1 |
| 2 | 2 |
| 3 | 3 |
| 4 | 4 |
| 5 | 5 |
| 6 | 6 |
| 7 | 7 |
| 8 | 8 |
| 9 | 9 |
| 10 | 10 |
+----+------+
10 Zeilen im Satz (0,00 Sek.)

Es zeigt sich, dass kein Replikationsfehler vorliegt und die in die primäre Datenbank eingefügten Daten ebenfalls synchronisiert werden.

Um es zusammenzufassen:

  • Slave_exec_mode-Parameter;
  • sql_slave_skip_counter=N-Parameter;
  • Slave-Skip-Errors=N-Parameter.

Diese drei Parameter können die Inkonsistenz während des Replikationsprozesses beheben. Die Unterschiede sind wie folgt:

Der Parameter slave_exec_mode kann die Konsistenz der Master-Slave-Daten sicherstellen, die anderen beiden können dies jedoch nicht.

Der Parameter „slave-skip-errors“ kann angegebene Fehler überspringen, erfordert jedoch einen Neustart der Instanz und kann keine Datenkonsistenz garantieren.

Der Parameter sql_slave_skip_counter muss im Offset-Replikationsmodus verwendet werden und kann keine Datenkonsistenz garantieren.

Oben finden Sie den detaillierten Inhalt der Drei-Parameter-Analyse des MySQL-Replikationsproblems. Weitere Informationen zum MySQL-Replikationsproblem finden Sie in den anderen verwandten Artikeln auf 123WORDPRESS.COM!

Das könnte Sie auch interessieren:
  • Prinzip und Implementierung der parallelen Replikation von MySQL5.7
  • Detaillierte Erläuterung der MySQL Master-Slave-Replikation und der Lese-/Schreibtrennung
  • Gängige Reparaturmethoden für die Trennung der MySQL Master-Slave-Replikation
  • Umfassende Analyse des MySql-Master-Slave-Replikationsmechanismus
  • MySQL Serie 13 MySQL-Replikation

<<:  Neue Ideen zur Zeitformatierung in JavaScript toLocaleString()

>>:  Verwenden von CSS zum Implementieren einer Ladeanimation des Android-Systems

Artikel empfehlen

Informationen zur Nginx-GZIP-Konfiguration

Das Prinzip von nginx zur Erzielung einer Ressour...

Installieren des Ping-Tools in einem von Docker erstellten Container

Denn die von Docker abgerufenen Basisimages wie C...

Ladeanimation mit CSS3 implementiert

Ergebnisse erzielen Implementierungscode <h1&g...

Eine kurze Analyse der Unterschiede zwischen den häufig verwendeten Anweisungen v-if und v-show von Vue

Inhaltsverzeichnis Vorwort 1.v-show 2.v-wenn 3. D...

Verwenden von Zabbix zum Überwachen des Betriebsvorgangs des Oracle-Tabellenbereichs

0. Übersicht Zabbix ist ein extrem leistungsfähig...

So installieren Sie Graphviz und beginnen mit dem Tutorial unter Windows

Herunterladen und installierenUmgebungsvariablen ...

So aktivieren Sie Fernzugriffsberechtigungen in MySQL

1. Melden Sie sich bei der MySQL-Datenbank an mys...

Detailliertes Tutorial zur Installation von VirtualBox 6.0 auf CentOS 8 / RHEL 8

VirtualBox ist ein kostenloses Open Source-Virtua...

Tutorial zur Installation von Ubuntu 1804 in VMware Workstation 15 Pro (mit Bildern und Text)

Dieser Hinweis ist ein Installationstutorial. Er ...

Einführung in die Verwendung von CSS3-Filterattributen

1. Einleitung Beim Schreiben von Animationseffekt...

So optimieren Sie Bilder, um die Website-Leistung zu verbessern

Inhaltsverzeichnis Überblick Was ist Bildkomprimi...

Pessimistisches Sperren und optimistisches Sperren in MySQL

In relationalen Datenbanken sind pessimistisches ...

Detaillierte Einführung in TABLE-Tags (TAGS)

Grundlegende Syntax der Tabelle <table>...&l...

Verwendung des Linux-Befehls ipcs

1. Befehlseinführung Der Befehl ipcs wird verwend...

Grafisches Tutorial zur Installation und Konfiguration komprimierter Pakete in MySQL 8.0.16

In diesem Artikel wird die Installations- und Kon...