Was sind die drei Replikationsmodi von MySQL-Master und -Slave?

Asynchrone MySQL-Replikation

Die asynchrone MySQL-Replikation ist der Standard-Replikationsmodus während des Master-Slave-Replikationsprozesses. Die Replikation umfasst drei Threads, darunter den Master-E/A-Thread, den Slave-E/A-Thread und den Slave-SQL-Thread. Da es sich um eine asynchrone Replikation handelt, muss die Übermittlung der Master-Transaktion nicht vom Slave bestätigt werden. Das heißt, nachdem der Master-E/A-Thread die Transaktion übermittelt hat, muss er nicht auf die Antwortbestätigung vom Slave I warten /O-Thread. Der Master garantiert nicht, dass das Binlog in das Relay-Protokoll geschrieben wird. Es wird vom Slave-SQL-Thread asynchron ausgeführt und auf das Slave-MySQL angewendet . Slave-E/A erfordert keine Antwortbestätigung von Slave-SQL und garantiert nicht, dass das Relay-Protokoll vollständig in MySQL geschrieben wird.

Halbsynchrone Replikation

Um die Mängel der herkömmlichen asynchronen Replikation auszugleichen, hat MySQL in Version 5.5 die halbsynchrone Replikation eingeführt, die eine Verbesserung gegenüber der herkömmlichen asynchronen Replikation darstellt. Bevor die Master-Transaktion festgeschrieben wird, muss sichergestellt werden, dass das Binlog-Protokoll in das Relay-Protokoll des Slaves geschrieben wurde. Erst nach Erhalt der Antwort vom Slave an den Master kann die Transaktion festgeschrieben werden. Trotzdem wird die zweite Hälfte des Relay-Protokolls weiterhin zur asynchronen Ausführung an den SQL-Thread übergeben.

Gruppenreplikation

Aufgrund der Mängel der herkömmlichen asynchronen Replikation und der halbsynchronen Replikation – Datenkonsistenz kann nicht garantiert werden – hat MySQL die Gruppenreplikation (MGR) in Version 5.7.17 offiziell eingeführt.

Eine Replikationsgruppe besteht aus mehreren Knoten. Die Übermittlung einer Transaktion muss von der Mehrheit der Knoten in der Gruppe (N / 2 + 1) gelöst und genehmigt werden, bevor sie übermittelt werden kann. Wie in der Abbildung oben gezeigt, besteht eine Replikationsgruppe aus 3 Knoten. Die Konsensschicht ist die Konsistenzprotokollschicht. Während des Transaktionsübermittlungsprozesses findet die Kommunikation zwischen den Gruppen statt endlich gelöst werden. Senden und antworten.

Der Hauptzweck der Einführung der Gruppenreplikation besteht darin, das Problem der Dateninkonsistenz zu lösen, das durch die herkömmliche asynchrone Replikation oder halbsynchrone Replikation verursacht wird. Die Gruppenreplikation basiert auf dem Distributed-Consistency-Protokoll (einer Variante des Paxos-Protokolls), um die ultimative Konsistenz verteilter Daten zu erreichen und eine echte Datenhochverfügbarkeitslösung bereitzustellen (ob sie wirklich hochverfügbar ist, muss noch diskutiert werden). Die bereitgestellte Multi-Write-Lösung gibt uns Hoffnung, eine multiaktive Lösung zu erreichen.

In der MGR-Umgebung muss die Anzahl der Server mehr als 3 und eine ungerade Zahl betragen, um den 2/n+1-Algorithmus zu implementieren.

Eine Replikationsgruppe besteht aus mehreren Knoten (Datenbankinstanzen). Jeder Knoten in der Gruppe verwaltet seine eigene Datenkopie (Share Nothing) und implementiert atomare Nachrichten und global geordnete Nachrichten über das Konsistenzprotokoll, um Instanzen innerhalb der Gruppe zu implementieren Gruppe. Datenkonsistenz.

Funktionen, über die die MGR-Lösung jetzt verfügt

Datenkonsistenzgarantie: Stellen Sie sicher, dass die meisten Knoten im Cluster Protokolle empfangen

Multi-Knoten-Schreibunterstützung: Alle Knoten im Cluster werden im Multi-Schreibmodus unterstützt. Schreiben (aber Unter Berücksichtigung von Szenarios mit 1 bis hoher Parallelität, um eine hohe Datenkonsistenz sicherzustellen, wählt die Produktion kein Multi-Master-Schreiben und verwendet einen Single-Master-Cluster)

Fehlertoleranz: Stellen Sie sicher, dass das System im Falle eines Ausfalls (einschließlich Split Brain), doppeltes Schreiben hat keine Auswirkungen auf das System

Die aktuellen Auswirkungen der MGR-Lösung

• unterstützen nur InnoDB-Tabellen, und jede Tabelle muss einen Primärschlüssel für die Konflikterkennung des Schreibsatzes haben

• Wenn die GTID-Funktion aktiviert ist, muss das Binärprotokollformat auf ROW eingestellt sein und für die Masterauswahl und den Schreibsatz verwendet werden. COMMIT kann zu Fehlern führen, ähnlich dem Fehlerszenario der Snapshot-Transaktionsisolationsstufe. Derzeit ein MGR Cluster unterstützt bis zu 9 Knoten

• Unterstützt keine Fremdschlüssel- und Speicherpunktfunktionen, kann keine globale Einschränkungserkennung und teilweises Rollback durchführen

• Binärprotokoll unterstützt keine Binlog-Ereignisprüfsumme

Das obige ist der detaillierte Inhalt vonWas sind die drei Replikationsmodi von MySQL-Master und -Slave?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!