So vermeiden Sie Datenschleifenkonflikte, wenn MySQL mit Dual-Master konfiguriert ist

Ich frage mich, ob Sie jemals über diese Frage nachgedacht haben? Wie lassen sich Datenschleifenkonflikte vermeiden, wenn Dual-Active konfiguriert ist? Dies ist eine der zentralen Designideen des Active-Active-Datendesigns.

Wenn die Hauptdatenbank eine SQL-Anweisung auslöst:

in test_data(Name) Werte('aa') einfügen;

Anschließend generiert Master1 ein Binärprotokoll, überträgt Datenänderungen an Master2, generiert ein Relay-Protokoll auf Master2 und übergibt es dann an den SQL-Thread zur Wiedergabe der Änderungen. Der umgekehrte Vorgang ist ähnlich. Der gesamte Vorgang kann wie folgt beschrieben werden.

Wenn Master2 die Daten vom Relay verbraucht, wird ein Binärprotokoll generiert (log_slave_updates ist standardmäßig aktiviert). Das zu diesem Zeitpunkt generierte Binärprotokoll wird weiterhin zum Verbrauch an Master1 gesendet und dann hin und her geschoben. Eine Reihe von Einfügeanweisungen wäre endlos. Offensichtlich ist dieses Design unvernünftig, und MySQL wird dies sicherlich nicht tun.

Der entscheidende Teil der Frage ist also: Hat Master2 das vorherige Binärprotokoll an Master1 gesendet?

a) Wenn es gepusht wird, wie filtert Master1 es, um eine Endlosschleife zu vermeiden?

b) Wenn kein Push vorhanden ist, wie filtert Master2

Wenn wir diesen Prozess verstehen möchten, müssen wir den Test simulieren und den Binlog-Status während des Datenflusses überprüfen. Sie können sich auf diesen Prozess beziehen.

1) Binärlog von Master1

2) Master2s Relay-Log

3) Binlog des Masters

Es wurde schnell eine Master-Slave-Umgebung bereitgestellt und dann durch Hinzufügen von Change Master schnell eine Dual-Master-Umgebung zum Testen erstellt.

Um möglichst vollständige Binlog-Ereignisinformationen anzuzeigen, aktivieren wir den Parameter binlog_rows_query_log_events

Trigger-Anweisung auf Master1:

in test_data(Name) Werte('gg') einfügen;

Die erhaltenen Binlog-Ereignisse sind wie folgt und die relevanten SQL-Anweisungen sind deutlich zu erkennen.

Auf der Master2-Seite überprüfen wir den Binlog-Status. Wenn binlog_rows_query_log_events aktiviert ist, können wir sehen, dass es deutlich weniger Ereignisse gibt: Rows_query.

An dieser Stelle muss berücksichtigt werden, ob sich der Offset während dieses Vorgangs geändert hat. Vom von Master1 generierten Binlog bis zum Relay-Log des Masters sind die erhaltenen Offsets beim Parsen über mysqlbinlog genau gleich. Nach dem Verbrauch durch Master2 werden relevante Binlog-Informationen generiert.

Hier liegt der Schlüssel zum Problem. In Maser2 wird die Datenquelle durch die Server-ID gekennzeichnet, sodass sie hier als Endpunkt des gesamten Datenflusses bezeichnet wird. Dies bedeutet, dass die Daten beim Kopieren gemäß der Server-ID gefiltert werden und jedes Master-Ende nur seine eigenen zugehörigen Binlog-Informationen überträgt.

Aus dieser Perspektive betrachtet, liegt hierin einer der Gründe, warum MySQL bei der Replikation hinsichtlich der Server-ID so wichtig ist.

Wenn wir die offsetbasierte asynchrone Replikation aus einer anderen Perspektive betrachten, können wir tatsächlich ähnliche Informationen erhalten.

Dies sind die Binärprotokolldetails, nachdem Master1 die Einfügeanweisung ausgelöst hat.

Dies sind die Binlog-Details, nachdem Master2 Echtzeitdaten empfängt.

Tatsächlich besteht hier immer noch ein Problem. Wenn im Offset-Modus ein Datenänderungsvorgang in Master2 verloren geht, gibt es keine Möglichkeit zum Zurückverfolgen.

Der GTID-Modus kann globale Transaktionen eindeutig identifizieren, sodass selbst wenn die Operation wiederholt angewendet wird, selbst wenn es sich um eine DDL-Anweisung handelt, die Anzahl der von der Operation betroffenen Zeilen 0 ist.

Wir führen eine bereits ausgeführte Operation erneut aus, um zu sehen, ob MySQL solche Operationen automatisch verwirft.

mysql> SET @@SESSION.GTID_NEXT= '6fb744dd-05dd-11ea-ada7-52540043a8b5:6';

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

mysql> verwende „Test“; erstelle Tabelle „Testdaten“ (ID Int Primärschlüssel Auto_Increment, Name varchar(30));

Datenbank geändert

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

Beim Überprüfen show binlog events dass dieser Prozess keine zusätzlichen Binärprotokolle generiert.

Auf dieser Grundlage haben wir im Wesentlichen eine Designidee für die Datenschleifenlösung geklärt, nämlich wie MySQL die angewendeten Transaktionsdaten identifizieren kann. Ich denke, GTID ist eine Antwort, und eine verteilte ID ist nicht erforderlich. Dies ist der interne Verarbeitungsmechanismus von MySQL und eine Methode, die MySQL erkennen kann.

Oben finden Sie Einzelheiten dazu, wie Sie Datenschleifenkonflikte vermeiden können, wenn MySQL mit Dual-Master konfiguriert ist. Weitere Informationen dazu, wie Sie Datenschleifenkonflikte in MySQL vermeiden können, finden Sie in den anderen verwandten Artikeln auf 123WORDPRESS.COM!