Detaillierte Erläuterung von vier Lösungen für die MySQL Active-Active-Synchronreplikation

Der Kern der Echtzeit-Datensynchronisierung besteht in der Implementierung auf Basis von Protokollen, wodurch eine quasi-Echtzeit-Datensynchronisierung erreicht werden kann. Die protokollbasierte Implementierung erfordert keine zusätzlichen Einschränkungen bei Entwurf und Implementierung durch die Datenbank selbst.

Master-Master-Synchronisierungslösung basierend auf MySQL Native Replication

Dies ist eine gängige Lösung. Im Allgemeinen ist diese Architektur für kleine und mittelgroße Projekte am praktischsten.

Die beiden Knoten können einen einfachen Dual-Master-Modus annehmen und eine dedizierte Leitungsverbindung verwenden. Nachdem der Knoten Master_A ausfällt, wird die Anwendungsverbindung schnell auf den Knoten Master_B umgeschaltet und umgekehrt. Dabei sind mehrere Dinge zu beachten. Beim Split Brain schreiben zwei Knoten dieselben Daten und verursachen einen Konflikt. Gleichzeitig werden auto_increment_increment (Auto-Inkrement-Schritt) und auto_increment_offset (Auto-Inkrement-Startwert) der beiden Knoten auf unterschiedliche Werte gesetzt. Der Zweck besteht darin, zu vermeiden, dass bei einem unerwarteten Absturz des Masterknotens einige Binärprotokolle möglicherweise nicht rechtzeitig zur Anwendung auf den Slave kopiert werden, was dazu führt, dass die neu geschriebene Auto-Increment-ID des Slaves mit dem ursprünglichen Master in Konflikt gerät. Daher werden sie von Anfang an gestaffelt; natürlich kann dies auch vermieden werden, wenn es einen geeigneten fehlertoleranten Mechanismus zur Lösung des Konflikts der Auto-Increment-ID zwischen Master und Slave gibt. Mit der neueren Datenversion 5.7+ kann die Multithread-Replikation verwendet werden, um Replikationsverzögerungen erheblich zu reduzieren. Gleichzeitig gibt es eine andere alternative Lösung, die besonders empfindlich auf Replikationsverzögerungen reagiert, nämlich die halbsynchrone halbsynchrone Replikation, die grundsätzlich keine Verzögerung aufweist, aber einen erheblichen Verlust an Transaktions-Parallelitätsleistung mit sich bringt, insbesondere bei bidirektionalen Schreibvorgängen, was vor der Entscheidung eine umfassende Bewertung erfordert.

Basierend auf der Galera-Replikationslösung

Galera ist ein von Codership bereitgestellter Multimaster-Datensynchronisations- und Replikationsmechanismus. Er kann Datensynchronisationsreplikation sowie Lesen und Schreiben zwischen mehreren Knoten realisieren und eine hohe Verfügbarkeit von Datenbankdiensten und Datenkonsistenz gewährleisten. Zu den auf Galera basierenden Hochverfügbarkeitslösungen gehören hauptsächlich MariaDB Galera Cluster und Percona XtraDB Cluster (kurz PXC).

Derzeit wird PXC häufiger verwendet. Es weist eine strikte Datenkonsistenz auf und eignet sich besonders für E-Commerce-Anwendungen. Allerdings hat PXC auch seine Grenzen. Wenn das gleichzeitige Transaktionsvolumen groß ist, wird empfohlen, ein InfiniBand-Netzwerk zu verwenden, um die Netzwerklatenz zu verringern. Da PXC Schreiberweiterungs- und Shortboard-Effekte aufweist, wird die gleichzeitige Effizienz stark reduziert. Ähnlich wie bei der halbsynchronen halbsynchronen Replikation kann Gelera in der Praxis nur drei Knoten verwenden, und die durch Netzwerkjitter verursachten Leistungs- und Stabilitätsprobleme sind üblich.

Basierend auf der Gruppenreplikationslösung

MGR ist eine offiziell von MySQL eingeführte Hochverfügbarkeitslösung, die über das Paxos-Protokoll eine starke Konsistenzgarantie für Datenbankclusterknotendaten bietet. Es basiert auf nativer Replikationstechnologie und wird als Plug-In bereitgestellt. Alle Knoten zwischen Clustern können geschrieben werden, wodurch die Schreibleistung eines einzelnen Clusters gelöst wird. Alle Knoten können lesen und schreiben, das durch Netzwerkpartitionen verursachte Brain-Split-Problem lösen und die Zuverlässigkeit replizierter Daten verbessern. Die Realität ist jedoch immer noch ein bisschen grausam. Derzeit haben es nicht viele Leute ausprobiert. Gleichzeitig unterstützt es nur InnoDB-Tabellen und jede Tabelle muss einen Primärschlüssel für die Erkennung von Schreibsatzkonflikten haben. Die GTID-Funktion muss aktiviert sein und das Binärprotokollformat muss für die Primärauswahl und den Schreibsatz auf ROW eingestellt sein.

COMMIT kann zu Fehlern führen, ähnlich dem Fehlerszenario der Isolationsebene für Snapshot-Transaktionen. Derzeit unterstützt ein MGR-Cluster bis zu 9 Knoten, unterstützt keine Fremdschlüssel und Speicherpunktfunktionen, kann keine globale Einschränkungserkennung und kein teilweises Rollback durchführen und Binärprotokolle unterstützen keine Binlog-Ereignisprüfsumme

Basierend auf Kanallösung

Für die Echtzeitsynchronisierung von Datenbanken verfügt Alibaba über ein spezielles Open-Source-Projekt namens Otter, um die synchrone Replikation verteilter Datenbanken zu implementieren. Die Kernidee besteht weiterhin darin, eine quasi-Echtzeit-synchrone Replikation durch Abrufen inkrementeller Datenprotokolle der Datenbank durchzuführen. Daher basiert Otter selbst auf einem anderen Open-Source-Projekt, Canal, dessen Schwerpunkt auf dem Abrufen inkrementeller Protokollinformationen zur Datenbanksynchronisierung liegt.

Derzeit konzentriert sich Otter auf die Datenbanksynchronisierung und -replikation zwischen MySQL. Dabei werden grundsätzlich ähnliche Technologien verwendet, um eine bidirektionale synchrone Datenbankreplikation zwischen zwei MySQL-Datenbanken zu erreichen. Es ist zu beachten, dass diese Bidirektionalität selbst bedeutet, dass es von A->B oder von B->A gehen kann und zu einem bestimmten Zeitpunkt unidirektional ist.

Die Master-Slave-Replikation gliedert sich in drei Schritte:

Der Master zeichnet die Änderungen im Binärprotokoll auf (diese Aufzeichnungen werden als Binärprotokollereignisse bezeichnet und können mit „show binlog events“ angezeigt werden).

Der Slave kopiert die Binärprotokollereignisse des Masters in sein Relay-Protokoll.

Der Slave wiederholt die Ereignisse im Relay-Protokoll und ändert die Daten, sodass sie seine eigenen widerspiegeln.

Das Kanalprinzip ist relativ einfach:

Canal simuliert das interaktive Protokoll des MySQL-Slaves, gibt sich als MySQL-Slave aus und sendet das Dump-Protokoll an den MySQL-Master

Der MySQL-Master empfängt die Dump-Anforderung und beginnt mit dem Weiterleiten des Binärprotokolls an den Slave (Kanal).
Canal analysiert binäre Log-Objekte (ursprünglich Byte-Streams)

Weitere Informationen finden Sie unter https://github.com/alibaba/canal

Zusammenfassen

Oben sind die vier Lösungen für die MySQL Active-Active-Synchronreplikation, die der Herausgeber vorgestellt hat. Ich hoffe, sie sind für alle hilfreich. Wenn Sie Fragen haben, hinterlassen Sie mir bitte eine Nachricht und der Herausgeber wird Ihnen rechtzeitig antworten. Ich möchte auch allen für ihre Unterstützung der Website 123WORDPRESS.COM danken!