Detaillierte Erklärung der MySQL-Halbsynchronisierung

Vorwort

Als ich nach Neujahr mein zweites Vorstellungsgespräch bei Tencent hatte, war die erste Frage, die mir nach dem Schreiben des Algorithmus gestellt wurde: „Was ist MySQL-Halbsynchronisation?“ Ich war damals völlig verwirrt. Ich dachte, es ginge um das Zwei-Phasen-Commit-Problem von MySQL? Nach der Bestätigung stellte sich heraus, dass es sich nicht um eine zweistufige Bewerbung handelte. Dann sah der Interviewer, dass ich nicht einmal wusste, worum es bei der Frage ging, also übersprang er diese Frage und ging direkt zur nächsten über. Daher werde ich dieses Mal den Wissensinhalt dieses Teils zusammenfassen. Es gibt viel Textinhalt, der vielleicht etwas langweilig ist, aber dennoch für diejenigen interessant ist, die sich für diesen Bereich interessieren.

MySQL Master-Slave-Replikation

In großen Projekten verwenden wir normalerweise die MySQL-Replikation, um einen MySQL-Master-Slave-Cluster zu erstellen. Die Datensynchronisierung kann hauptsächlich durch die Konfiguration einer oder mehrerer Sicherungsdatenbanken für den Server durchgeführt werden. Die Replikationsfunktion unterstützt nicht nur die Erstellung leistungsstarker Anwendungen, sondern bildet auch die Grundlage für hohe Verfügbarkeit, Skalierbarkeit, Notfallwiederherstellung, Sicherung und Data Warehouse.

Einfach ausgedrückt wird die Master-Slave-Replikation von MySQL verwendet, um eine Lese- und Schreibtrennung zu erreichen. Im Vergleich zu einer Single-Point-Datenbank, die lesen und schreiben kann, verbessert sie die Leistung des Geschäftssystems und optimiert die Benutzererfahrung. Darüber hinaus wird die hohe Verfügbarkeit der Datenbank durch Master-Slave-Replikation erreicht. Wenn MySQL auf dem Masterknoten hängt, kann die Slave-Datenbank zur Übernahme verwendet werden.

Von MySQL unterstützte Replikationsmethoden

MySQL unterstützt drei Replikationsmodi:

• Anweisungsbasierte Replikation (auch logische Replikation genannt) bedeutet im Wesentlichen, dass die auf der Masterdatenbank ausgeführten SQL-Anweisungen auf der Slavedatenbank wiederholt werden. Dies ist der Replikationstyp, den MySQL standardmäßig verwendet, da er effizienter ist. Es gibt jedoch bestimmte Probleme. Wenn in SQL Funktionen wie uuid() und rand() verwendet werden, sind die in die Slave-Datenbank kopierten Daten verzerrt.
• Bei der zeilenbasierten Replikation werden aktualisierte Daten in die Slave-Datenbank kopiert, anstatt Nebenanweisungen auszuführen. Es wird nur ab MySQL 5.1 unterstützt.
• Bei der Hybridreplikation wird standardmäßig die Anweisungsreplikation verwendet. Wenn festgestellt wird, dass die Anweisung die Daten nicht genau replizieren kann (z. B. wenn die Anweisung Funktionen wie uuid() und rand() enthält), wird die zeilenbasierte Replikation verwendet.
  

Master-Slave-Replikationsprinzip

Das MySQL-Replikationsprinzip lässt sich grob in drei Schritte unterteilen:

1. Protokollieren Sie Datenänderungen in der Masterdatenbank im Binärprotokoll.
2. Die Slave-Datenbank kopiert die Protokolle der Master-Datenbank in ihr eigenes Relay-Protokoll.
3. Die Slave-Datenbank liest die Ereignisse im Relay-Protokoll und spielt sie über den Daten der Slave-Datenbank erneut ab.
   

Der Hauptprozess ist wie folgt:

Schauen wir uns die drei Schritte des Kopierens genauer an:

Der erste Schritt besteht darin, Binärprotokolle in der Masterdatenbank aufzuzeichnen. Zunächst muss die Masterdatenbank die Binärprotokollierungsfunktion aktivieren und der Slavedatenbank den Zugriff darauf gestatten. Hierbei ist zu beachten, dass die Reihenfolge im Binärprotokoll in der Reihenfolge aufgezeichnet wird, in der die Transaktionen übermittelt wurden, und nicht in der Reihenfolge, in der die einzelnen Anweisungen ausgeführt wurden.

Schritt 2: Kopieren Sie binLog aus der Bibliothek in das lokale RelayLog. Zuerst startet die Slave-Datenbank einen Arbeitsthread, einen sogenannten I/O-Thread. Der I/O-Thread stellt eine normale Client-Verbindung mit der Master-Datenbank her. Dann wird ein spezieller Binärdump-Thread (Binlog-Dump) auf der Master-Datenbank gestartet. Dieser Dump-Thread liest Ereignisse im Binlog. Nachdem es mit der Hauptdatenbank gleichgezogen hat, wird es in den Ruhezustand versetzt, bis die Hauptdatenbank es über eine neue Aktualisierungsanweisung benachrichtigt. Auf diese Weise werden die Binärprotokolldaten über den E/A-Thread in der Slave-Bibliothek und den Binärprotokoll-Dump-Thread in der Master-Bibliothek an das Relaylog in der Slave-Bibliothek übertragen.

Schritt 3: Starten Sie einen SQL-Thread in der Slave-Datenbank, lesen Sie Ereignisse aus dem Relaylog und führen Sie sie in der Slave-Datenbank aus, um die Daten der Slave-Datenbank zu aktualisieren.

==Diese Replikationsarchitektur erreicht die Entkopplung von Ereigniserfassung und Ereigniswiedergabe, und der laufende E/A-Thread kann unabhängig vom SQL-Thread arbeiten. Diese Architektur schränkt jedoch auch den Replikationsprozess ein. Der wichtigste Punkt ist, dass Abfragen, die gleichzeitig auf der primären Datenbank ausgeführt werden, nur seriell auf der Standby-Datenbank ausgeführt werden können, da nur ein SQL-Thread vorhanden ist, um die Ereignisse im Relay-Protokoll wiederzugeben. ==

Beim Problem der seriellen Ausführung der Master-Slave-Replikation fiel mir ein Problem ein, das ich zuvor bei der Arbeit hatte. Es gab ein Geschäftsszenario, in dem wir einen Vorgang zum Initialisieren eines Datenstapels hatten. Die Daten wurden von der Schnittstelle eines externen Systems abgerufen. Dann verwendete ich mehrere Threads im Threadpool, um parallel Daten von der Schnittstelle des externen Systems abzurufen. Nachdem jeder Thread die Daten abgerufen hatte, wurden sie direkt in die Datenbank eingefügt. Nachdem alle Daten in die Datenbank eingegeben wurden, wird eine Batchabfrage ausgeführt, um die gerade in die Datenbank eingefügten Daten abzufragen und in ElasticSearch einzufügen. Infolgedessen waren die in ES eingegebenen Daten immer unvollständig. Nach längerem Studium funktionierte es immer noch nicht. Schließlich wurde das Problem gelöst, indem die Abfrage an die Hauptdatenbank gesendet wurde. Damals wusste ich nicht, dass dieses Problem durch die Serialisierung der MySQL-Master-Slave-Replikation verursacht wurde.

MySQL Master-Slave-Replikationsmodus

Die Master-Slave-Replikation von MySQL unterstützt tatsächlich mehrere Replikationsmodi, darunter asynchrone Replikation, halbsynchrone Replikation und GTID-Replikation.

Asynchroner Modus

Der Standardreplikationsmodus von MySQL ist der asynchrone Modus, der sich hauptsächlich auf den E / A-Thread auf dem MySQL-Masterserver bezieht. Nach dem Schreiben der Daten in Binlong gibt es die erfolgreiche Datenaktualisierung direkt an den Client zurück, unabhängig davon, ob die Daten an den Slave-Server übertragen und in das Relaylog geschrieben wurden. In diesem Modus ist das Kopieren von Daten tatsächlich riskant. Sobald die Daten nur in das Binlog der Master-Datenbank geschrieben und nicht rechtzeitig mit der Slave-Datenbank synchronisiert wurden, kommt es zu Datenverlust.

Dieser Modus ist jedoch tatsächlich der effizienteste, da die Funktion zum Ändern von Daten nur in der Hauptdatenbank abgeschlossen werden muss und das Kopieren von Daten aus der Datenbank den Datenschreibvorgang der Hauptdatenbank nicht beeinträchtigt.

Wie ich oben sagte, ist dieser asynchrone Replikationsmodus zwar hocheffizient, das Risiko eines Datenverlusts ist jedoch sehr hoch. Daher wird später ein halbsynchroner Replikationsmodus eingeführt.

Halbsynchroner Modus

MySQL unterstützt den halbsynchronen Master-Slave-Replikationsmodus seit Version 5.5 in Form eines Plug-Ins. Was ist der halbsynchrone Master-Slave-Replikationsmodus? Hier eine Erklärung zum Vergleich:

• Asynchroner Replikationsmodus: Wie oben erläutert, kehrt die Masterdatenbank im asynchronen Replikationsmodus, nachdem sie die vom Client übermittelte Transaktion ausgeführt hat, sofort zum Client zurück, solange die Ausführungslogik in das Binlog geschrieben ist, und kümmert sich nicht darum, ob die Slavedatenbank erfolgreich ausgeführt wurde. Dies birgt eine versteckte Gefahr, nämlich dass die Masterdatenbank hängt, wenn das von der Masterdatenbank ausgeführte Binlog nicht mit der Slavedatenbank synchronisiert wurde. Zu diesem Zeitpunkt wird die Slavedatenbank zwangsweise zur Masterdatenbank hochgestuft, was zu Datenverlust führen kann.
• Synchroner Replikationsmodus: Nachdem die Masterdatenbank die vom Client übermittelte Transaktion ausgeführt hat, muss sie warten, bis alle Slavedatenbanken die Transaktion ebenfalls ausgeführt haben, bevor sie dem Client eine erfolgreiche Ausführung zurückgibt. Da gewartet werden muss, bis alle Slave-Bibliotheken ausgeführt wurden, wird der Ausführungsprozess blockiert und auf die Rückgabe der Ergebnisse gewartet, wodurch die Leistung erheblich beeinträchtigt wird.
• Halbsynchroner Replikationsmodus: Der halbsynchrone Replikationsmodus kann als Replikationsmodus zwischen asynchron und synchron bezeichnet werden. Nachdem die Masterdatenbank die vom Client übermittelte Transaktion ausgeführt hat, muss sie warten, bis mindestens eine Slavedatenbank das Binlog empfängt und die Daten in das Relay-Protokoll schreibt, bevor sie ein erfolgreiches Ergebnis an den Client zurückgibt. Der halbsynchrone Replikationsmodus verbessert die Datenverfügbarkeit im Vergleich zum asynchronen Modus, erzeugt jedoch auch eine gewisse Leistungsverzögerung, die mindestens der Roundtrip-Zeit einer TCP/IP-Verbindung entspricht.
  

Im halbsynchronen Replikationsmodus ist es klar, dass nach dem erfolgreichen Commiten einer Transaktion die Transaktion an mindestens zwei Stellen vorhanden ist: in der Masterdatenbank und in einer der Slavedatenbanken. Das Hauptprinzip besteht darin, dass, wenn der Dump-Thread des Masters den Slave benachrichtigt, ein ACK-Mechanismus hinzugefügt wird, der bestätigt, ob der Slave den Transaktionsflagcode erhalten hat. Der Dump-Thread des Masters sendet nicht nur Binlog an den Slave, sondern ist auch für den Empfang der ACK des Slaves verantwortlich. Wenn eine Ausnahme auftritt und der Slave die Transaktion nicht bestätigt, wird automatisch auf die asynchrone Replikation zurückgestuft, bis die Ausnahme behoben ist, und dann automatisch auf die halbsynchrone Replikation umgestellt.

Der Prozess der halbsynchronen MySQL-Replikation läuft wie folgt ab:

Versteckte Gefahren der halbsynchronen Replikation Der halbsynchrone Replikationsmodus birgt auch bestimmte Datenrisiken: Wenn eine Transaktion an die Masterdatenbank gesendet wird und auf die ACK der Slavedatenbank wartet, treten zu diesem Zeitpunkt zwei Probleme auf, wenn der Master ausfällt.

• Die Transaktion wurde nicht an den Slave gesendet: Wenn die Transaktion nicht an den Slave gesendet wurde, sendet der Client die Transaktion erneut, nachdem er das Fehlerergebnis erhalten hat. Da die erneut gesendete Transaktion auf dem neuen Master ausgeführt wird, wird sie erfolgreich ausgeführt. Wenn der vorherige Master später wiederhergestellt wird, tritt er dem Cluster als Slave bei. Zu diesem Zeitpunkt wird die vorherige Transaktion zweimal ausgeführt. Das erste Mal, wenn diese Maschine zuvor der Master war, und das zweite Mal wird sie von der Hauptdatenbank synchronisiert, nachdem sie ein Slave geworden ist.
• Die Transaktion wurde mit dem Slave synchronisiert: Da die Transaktion mit dem Slave synchronisiert wurde, wird die Transaktion auf dem aktuellen Slave-Computer zweimal ausgeführt, wenn der Client das Fehlerergebnis erhält und die Transaktion erneut übermittelt.
  

Um die oben genannten versteckten Gefahren zu beseitigen, hat MySQL seit Version 5.7 einen neuen halbsynchronen Modus hinzugefügt. Der Ausführungsprozess der neuen halbsynchronen Methode besteht darin, den Schritt „Storage Commit“ nach dem Schritt „Write Slave Dump“ zu verschieben. Dadurch wird sichergestellt, dass die Transaktion in der Master-Datenbank erst ausgeführt wird, nachdem die Slave-Transaktion bestätigt wurde. MySQL 5.7.2 fügt einen neuen Parameter zur Konfiguration hinzu: rpl_semi_sync_master_wait_point. Dieser Parameter hat zwei konfigurierbare Werte:

• AFTER_SYNC: Wenn der Parameterwert AFTER_SYNC ist, bedeutet dies, dass die neue halbsynchrone Replikationsmethode verwendet wird.
• AFTER_COMMIT: Zeigt an, dass der alte halbsynchrone Replikationsmodus verwendet wird.

Ab MySQL Version 5.7.2 ist der standardmäßige halbsynchrone Replikationsmodus der AFTER_SYNC-Modus, aber diese Lösung ist kein Allheilmittel, da der AFTER_SYNC-Modus die Transaktion der Master-Datenbank erst festschreibt, nachdem die Transaktion mit dem Slave synchronisiert wurde. Wenn der Master hängt, während die Master-Datenbank darauf wartet, dass die Slave-Datenbank erfolgreich synchronisiert wird, schlägt die Übermittlung der Master-Transaktion fehl und der Client erhält auch das Ergebnis des Transaktionsausführungsfehlers. Der Inhalt von binLog wurde jedoch in das Relay-Protokoll auf dem Slave geschrieben. Zu diesem Zeitpunkt gibt es mehr Slave-Daten, aber das Problem mit mehr Daten ist im Allgemeinen nicht schwerwiegend. Mehr Daten sind immer besser als weniger. Wenn MySQL das Problem der verteilten Datenkonsistenz nicht lösen kann, kann es garantieren, dass keine Daten verloren gehen. Mehr Daten sind immer besser als Datenverlust.

Hier sind einige Parameter des halbsynchronen Replikationsmodus:

mysql> Variablen wie „%Rpl%“ anzeigen;
+----------------------------------------------+------------+
| Variablenname | Wert |
+----------------------------------------------+------------+
| rpl_semi_sync_master_enabled | EIN |
| rpl_semi_sync_master_timeout | 10000 |
| rpl_semi_sync_master_trace_level | 32 |
| rpl_semi_sync_master_wait_for_slave_count | 1 |
| rpl_semi_sync_master_wait_no_slave | EIN |
| rpl_semi_sync_master_wait_point | NACH_SYNC |
| rpl_stop_slave_timeout | 31536000 |
+----------------------------------------------+------------+

-- Schalter für den halbsynchronen Replikationsmodus rpl_semi_sync_master_enabled
-- Halbsynchrone Replikation, Timeout in Millisekunden. Wenn diese Zeit überschritten wird, wird automatisch in den asynchronen Replikationsmodus gewechselt rpl_semi_sync_master_timeout
-- Diese Variable wurde in MySQL 5.7.3 eingeführt und legt fest, auf wie viele Slave-Antworten der Master warten muss, bevor er zum Client zurückkehrt. Der Standardwert ist 1.
rpl_semi_sync_master_wartet_auf_Slave_Anzahl
- Dieser Wert gibt an, ob die Anzahl der Slaves im aktuellen Cluster den aktuell konfigurierten halbsynchronen Replikationsmodus noch erfüllen kann. Der Standardwert ist EIN. Wenn der halbsynchrone Replikationsmodus nicht erfüllt ist, wechseln alle Slaves zur asynchronen Replikation und dieser Wert wird ebenfalls AUS.
rpl_semi_sync_master_wait_no_slave
-- Stellt die Art und Weise dar, wie bei der halbsynchronen Replikation Transaktionen festgeschrieben werden. Nach 5.7.2 ist der Standardwert AFTER_SYNC
rpl_semi_sync_master_wait_point 

GTID-Modus

MySQL hat seit Version 5.6 den GTID-Replikationsmodus eingeführt. GTID ist die Abkürzung für Global Transaction Identifier. GTID setzt sich aus UUID+TransactionId zusammen. UUID ist die eindeutige Kennung einer einzelnen MySQL-Instanz. Wenn die MySQL-Instanz zum ersten Mal gestartet wird, wird automatisch eine Server-UUID generiert und standardmäßig in die Datei auto.cnf (mysql/data/auto.cnf) im Datenverzeichnis geschrieben. TransactionId ist die Anzahl der auf dem MySQL-Server ausgeführten Transaktionen und steigt mit der Anzahl der Transaktionen. Dadurch wird sichergestellt, dass die GTID innerhalb einer Gruppe von Replikaten global eindeutig ist.

Auf diese Weise können Sie anhand der GTID deutlich erkennen, von welcher Instanz die aktuelle Transaktion übermittelt wurde und wie viele Transaktionen übermittelt wurden.

Schauen wir uns die spezifische Form einer GTID an:

mysql> Masterstatus anzeigen;
+-----------+----------+--------------+------------------+-------------------------------------------+
| Datei | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+-----------+----------+--------------+------------------+-------------------------------------------+
| am.000003 | 187 | | | 76147e28-8086-4f8c-9f98-1cf33d92978d:1-322|
+-----------+----------+--------------+------------------+-------------------------------------------+
1 Zeile im Satz (0,00 Sek.)

So funktionieren GTIDs

Aufgrund der Eindeutigkeit von GTID in einer Reihe von Master-Slave-Replikationsclustern ist garantiert, dass jede GTID-Transaktion nur einmal auf einem MySQL ausgeführt wird. Wie wird dieser Mechanismus implementiert? Was ist das Prinzip von GTID?

Wenn der Slave-Server eine Verbindung zum Master-Server herstellt, übergibt er die von ihm ausgeführte GTID (Executed_Gtid_Set: der ausgeführte Transaktionscode) und die erhaltene GTID (Retrieved_Gtid_Set: die Transaktionsnummer, die der Slave vom Master erhalten hat) an den Master-Server. Der Master-Server sendet die fehlende GTID und die entsprechende Transaktions-ID vom Slave-Server an den Slave-Server, sodass der Slave-Server die Daten vervollständigen kann. Wenn der primäre Server ausfällt, wird der Konferenzserver, der die Daten am erfolgreichsten synchronisiert, gefunden und direkt zum primären Server befördert. Wenn ein anderer als der erfolgreichste Slave-Server gezwungen wird, Master zu werden, wird ein Änderungsbefehl an den erfolgreichsten Server gesendet, um die GTID zu vervollständigen. Anschließend wird der erzwungene Server zum Master befördert.

Der Hauptmechanismus zur Datensynchronisierung kann in die folgenden Schritte unterteilt werden:

• ==Wenn der Master Daten aktualisiert, generiert er vor der Transaktion eine GTID und zeichnet sie im Binärprotokoll auf. ==
• ==Der Slave-E/A-Thread schreibt das geänderte Binärprotokoll in das Relay-Protokoll. ==
• ==Der SQL-Thread erhält die GTID aus dem Relay-Protokoll und vergleicht dann, ob im Binärprotokoll auf der Slave-Seite ein Datensatz vorhanden ist. ==
• ==Wenn ein Datensatz vorhanden ist, bedeutet dies, dass die Transaktion dieser GTID ausgeführt wurde und der Slave diese GTID ignoriert. ==
• ==Wenn kein Datensatz vorhanden ist, führt der Slave die GTID-Transaktion aus dem Relay-Protokoll aus und zeichnet sie im Binärprotokoll auf. ==
• ==Bestimmen Sie während des Analysevorgangs, ob ein Primärschlüssel vorhanden ist. Wenn kein Primärschlüssel vorhanden ist, verwenden Sie den Sekundärindex. Wenn kein Sekundärindex vorhanden ist, scannen Sie die gesamte Tabelle. ==

Die anfängliche Struktur ist wie folgt

Aus der obigen Abbildung können wir ersehen, dass Slave-1 die Transaktionen des Masters abgeschlossen hat, wenn der Master auflegt, Slave-2 jedoch etwas verzögert ist und die Transaktionen des Masters daher nicht abgeschlossen hat. Zu diesem Zeitpunkt wird Slave-1 zum Master befördert. Nachdem Slave-2 eine Verbindung zum neuen Master (Slave-1) hergestellt hat, überträgt er die neueste GTID an den neuen Master, und dann beginnt Slave-1, Transaktionen von der nächsten GTID dieser GTID an Slave-2 zu senden. Dieses selbstfindende Replikationsmodell verringert die Möglichkeit eines Transaktionsverlusts und die zur Wiederherstellung nach Fehlern erforderliche Zeit.

Vor- und Nachteile von GTID

Aus der obigen Analyse können wir schließen, dass die Vorteile von GTID folgende sind:

• ==Jede Transaktion entspricht einer Ausführungs-ID und eine GTID wird auf einem Server nur einmal ausgeführt;==
• ==GTID wird verwendet, um die traditionelle Replikationsmethode zu ersetzen. Der größte Unterschied zwischen GTID-Replikation und normalem Replikationsmodus besteht darin, dass keine Angabe des Binärdateinamens und -speicherorts erforderlich ist. ==
• ==Reduzieren Sie manuelle Eingriffe und Service-Ausfallzeiten. Wenn die Hauptmaschine ausfällt, kann die Software verwendet werden, um eine Backup-Maschine aus vielen Backup-Maschinen zur Hauptmaschine zu machen;==

Auch die Nachteile von GTID liegen auf der Hand:

• ==Erstens werden nicht-transaktionale Speicher-Engines nicht unterstützt; ==
• ==Unterstützt keine Replikation von Anweisungen zum Erstellen einer Tabelle ... Auswählen (die Masterdatenbank meldet einen Fehler direkt); (Prinzip: Es werden zwei SQL-Anweisungen generiert, eine ist die DDL-SQL-Anweisung zum Erstellen einer Tabelle und die andere ist die SQL-Anweisung zum Einfügen von Daten. Da DDL ein automatisches Commit verursacht, erfordert diese SQL-Anweisung mindestens zwei GTIDs, aber im GTID-Modus kann für diese SQL-Anweisung nur eine GTID generiert werden)==
• ==Eine SQL-Anweisung darf nicht gleichzeitig eine Transaktions-Engine-Tabelle und eine Nicht-Transaktions-Engine-Tabelle aktualisieren;==
• ==In einer MySQL-Replikationsgruppe müssen alle GTIDs aktiviert oder deaktiviert werden. ==
• ==Zum Aktivieren von GTID ist ein Neustart erforderlich (außer mysql5.7);==
• ==Nachdem GTID aktiviert wurde, wird die ursprüngliche traditionelle Replikationsmethode nicht mehr verwendet (im Gegensatz zur halbsynchronen Replikation, die nach einem Fehler auf eine asynchrone Replikation herabgestuft werden kann);==
• ==Anweisungen zum Erstellen und Löschen temporärer Tabellen werden nicht unterstützt;==
• ==sql_slave_skip_counter wird nicht unterstützt;==
  

Tatsächlich gibt es viel Inhalt zu GTID. Wenn Sie sich eingehender damit befassen möchten, können Sie diesen Artikel lesen. Lassen Sie uns abschließend über einige notwendige Voraussetzungen zum Aktivieren von GTID sprechen:

• MySQL-Version 5.6, fügen Sie in der Datei my.cnf Folgendes hinzu:

gtid_mode=on (erforderlich) # Aktiviere die gtid-Funktion log_bin=log-bin=mysql-bin (erforderlich) # Aktiviere die binäre Protokollfunktion binlog log-slave-updates=1 (erforderlich) # Du kannst auch 1 als on schreiben.
enforce-gtid-consistency=1 (erforderlich) #Sie können auch 1 als on schreiben

• Für MySQL 5.7 oder höher fügen Sie der Datei my.cnf Folgendes hinzu:

gtid_mode=on (erforderlich)
enforce-gtid-consistency=1 (erforderlich)
log_bin = mysql-bin (optional) #Hochverfügbarkeits-Switching, am besten aktivieren Sie diese Funktion log-slave-updates = 1 (optional) #Hochverfügbarkeits-Switching, am besten aktivieren Sie diese Funktion

Oben finden Sie eine ausführliche Erläuterung der MySQL-Halbsynchronisierung. Weitere Informationen zur MySQL-Halbsynchronisierung finden Sie in den anderen verwandten Artikeln auf 123WORDPRESS.COM!