4 Lösungen für MySQL Active-Active Synchronreplikation

MySQL ist ein weit verbreiteter Open-Source-Relationen-Datenbanksystem zur Verwaltung und Speicherung strukturierter Daten. Es zeichnet sich durch seine Einfachheit, Benutzerfreundlichkeit und Skalierbarkeit aus, wodurch es für verschiedene Anwendungen von kleineren Webseiten bis hin zu großen Unternehmen eine beliebte Wahl ist.

Für die Echtzeitdatensynchronisation ist das Kernziel, dies auf Basis von Logs umzusetzen, was eine nahezu Echtzeitdatensynchronisation ermöglicht. Dies legt keine zusätzlichen Einschränkungen für die Gestaltung und Implementierung der Datenbank selbst auf. Das Ziel der MySQL Active-Active-synchronen Replikation ist es, eine kontinuierliche Verfügbarkeit und Fehlertoleranz zu gewährleisten. Hier sind 4 Methoden zur Erreichung einer MySQL Active-Active-synchronen Replikation.

Master-Master-Replikation basierend auf der eingebauten Replikationsfunktion der MySQL-Datenbank

Sie ist in der Regel für kleinere bis mittlere Bereitstellungen geeignet.

In dieser Architektur können zwei Knoten einen einfachen Dual-Master-Modus verwenden und eine dedizierte Verbindung nutzen. Im Falle eines Ausfalls des Knotens master_A können die Anwendungskonnektivitäten schnell zu master_B wechseln und umgekehrt.

Um Szenarien mit geteiltem Gehirn zu vermeiden, bei denen beide Knoten widersprüchliche Daten schreiben, ist es wichtig, verschiedene Werte für auto-increment-increment und auto-increment-offset auf den beiden Knoten zu setzen. Dies liegt daran, dass wenn der Masterknoten unerwartet abstürzt oder nicht verfügbar ist, die Möglichkeit besteht, dass einige Binlog-Ereignisse nicht an den Slaveknoten repliziert werden. In solchen Fällen können Konflikte zwischen dem generierten Auto-Increment-Wert auf dem Slave und dem ursprünglichen Wert auf dem Master auftreten.

Allerdings, wenn es ein geeignetes fehlertolerantes Mechanismus gibt, um Konflikte bei automatisch inkrementellen IDs zwischen Master und Slave zu lösen, ist es möglich, dieses Verfahren zu vermeiden. In den aktualisierten Versionen 5.7+ von MySQL kann die Nutzung der Multi-Thread-Replikation die Replikationsverzögerung erheblich reduzieren. Darüber hinaus bietet als Alternative, die besonders empfindlich auf Replikationsverzögerungen reagiert, die halbsynchronen Replikation, die praktisch keine Verzögerung verursacht. Allerdings kann dies zu einer Verringerung der Transaktionskonkurrenzleistung führen, insbesondere bei bidirektionalen Schreibvorgängen. Eine umfassende Bewertung ist erforderlich, um eine Entscheidung zu treffen.

Lösung basierend auf der Galera-Replikation

Galera ist ein von Codership bereitgestellter Multi-Master-Datensynchronisierungsreplikationsmechanismus. Er ermöglicht die Datensynchronreplikation sowie Lese- und Schreibvorgänge auf mehreren Knoten, um hohe Verfügbarkeit und Datenkonsistenz in der Datenbank sicherzustellen. Die wichtigsten Hochverfügbarkeitslösungen basierend auf Galera sind MariaDB Galera Cluster und Percona XtraDB Cluster (PXC).

Aktuell wird PXC häufiger verwendet und bietet eine strenge Datensicherheit, wodurch es besonders für den E-Commerce geeignet ist. Allerdings hat PXC auch seine Einschränkungen. In Szenarien mit hohen gleichzeitigen Transaktionsvolumen wird empfohlen, ein InfiniBand-Netzwerk zu verwenden, um die Netzwerklatenz zu reduzieren. Dies liegt daran, dass PXC unter Schreibverstärkung und Flaschenhals-Effekt leiden kann, was zu einem erheblichen Verlust der Parallelitätseffizienz führt. Ähnlich wie bei der halbsynchronen Replikation wird die Galera-Replikation in der Regel auf drei Knoten beschränkt. Zudem können Netzwerkstörungen Leistungs- und Stabilitätsprobleme verursachen.

Lösung auf Basis der Gruppenreplikation

MGR (MySQL Group Replication) ist eine Hochverfügbarkeitslösung, die von MySQL offiziell eingeführt wurde. Es bietet starke Konsistenzgarantien für die Daten zwischen den Knoten in einem Datenbankcluster durch das Paxos-Protokoll. MGR basiert auf der nativen Replikationstechnologie und wird als Plugin angeboten. Es ermöglicht, dass alle Knoten im Cluster beschreibbar sind, was die Leistungseinschränkungen eines einzelnen Clusters behebt, das Problem der durch Netzwerkpartitionierung verursachten Split-Brain-Situation löst und die Zuverlässigkeit der replizierten Daten verbessert.

Allerdings ist die Realität etwas härter. Derzeit gibt es nicht viele Frühverwender von MGR. Zudem unterstützt es nur InnoDB-Tabellen und erfordert, dass jede Tabelle einen Primärschlüssel für die Konfliktprüfung von Schreibsätzen hat. Die GTID-Funktion muss aktiviert sein, und das Binärlog-Format muss auf ROW gesetzt sein, um die Führerwahl und die Schreibsätze zu ermöglichen. 

COMMIT kann potenziell fehlschlagen, ähnlich wie bei Ausfall­szenarien im Snapshot-Isolation-Level. Derzeit unterstützt ein MGR-Cluster (MySQL Group Replication) maximal 9 Knoten. Er unterstützt keine Fremdschlüssel und Savepoint-Funktionen, was globale Integritätsprüfung und partielle Rollbacks verhindert. Das Binärprotokoll unterstützt kein binäres Ereignis-Prüfsummen.

Lösung basierend auf Canal

Für die Echtzeit-Datenbanksynchronisierung hat Alibaba ein eigenes Open-Source-Projekt namens Otter, das eine verteilte Datenbankreplikation ermöglicht. Das Kernkonzept von Otter basiert immer noch auf der Erfassung inkrementeller Datenbank-Logs, um eine nahezu Echtzeit-Synchronisation zu erreichen. Otter selbst stützt sich auf ein weiteres Open-Source-Projekt namens Canal, das sich auf die Erfassung von inkrementellen Datenbanksynchronisations-Logs konzentriert.

Aktuell konzentriert sich Otter darauf, eine synchrone Replikation zwischen MySQL-Datenbanken zu erreichen. Es nutzt ähnliche Technologien, um eine bidirektionale synchrone Replikation zwischen zwei MySQL-Datenbanken zu realisieren. Es ist wichtig zu beachten, dass bidirektional bedeutet, dass Daten von A nach B oder von B nach A synchronisiert werden können, jedoch zu einem bestimmten Zeitpunkt einseitig sein können.

Der Prozess der Master-Slave-Replikation kann in drei Schritte unterteilt werden:

1. Der Master protokolliert die Änderungen im Binärlog, die als Binärlogevents bekannt sind. Diese Ereignisse können mit dem Befehl "show binlog events" angezeigt werden.

2. Der Sklave kopiert die Binärprotokollereignisse vom Master in sein eigenes Relay-Log.

3. Der Sklave wird die in dem Relay-Log aufgezeichneten Ereignisse nacheinander erneut ausführen, um die Änderungen vom Master auf seine eigenen Daten anzuwenden.

Was das Prinzip des Canals betrifft, ist es relativ einfach:

1. Canal simuliert das Interaktionsprotokoll eines MySQL-Sklaven indem es sich als MySQL-Sklave tarnt und einen Dump-Anfrage an den MySQL-Master sendet.

2. Nach dem Erhalt der Dump-Anforderung beginnt der MySQL-Master mit dem Senden der Binärprotokolle an den Slave (der in diesem Fall Canal ist).

3. Canal analysiert dann die Binärprotokoll-Objekte (ursprünglich im Bytestream-Format) um die relevanten Informationen zu extrahieren.

Sichern von MySQL-Datenbanken mit Vinchin Backup & Recovery

Um Daten besser zu schützen, wird empfohlen, Ihre Datenbanken zu sichern. Vinchin Backup & Recovery bietet leistungsstarke Funktionen zum Schutz Ihrer Datenbanken sowohl in virtuellen Maschinen als auch in physischen Servern. Durch die gute Zusammenarbeit mit Sicherungen auf VM-Ebene erhalten Benutzer virtueller Umgebungen doppelte Sicherheit für ihre wichtigen Geschäftsdaten und Informationssysteme.

Vinchin Backup & Recovery unterstützt den Schutz von Oracle DB, MySQL, SQL Server, PostgreSQL, Postgres Pro und MariaDB, die sowohl auf physischen als auch auf virtuellen Maschinen installiert sind, mit leistungsstarken Datenbank-Backup- und -Wiederherstellungsfunktionen. Es bietet auch vollständige Backups, differentielle Backups, inkrementelle Backups und Transaktionsprotokoll-Backups, damit Sie Ihren eigenen Backup-Plan nach Bedarf erstellen können.

Vinchin Backup & Recovery unterstützt eine effiziente Heißsicherung ohne die normale Datenbankoperation zu beeinträchtigen und es ist einfach ein angepasster Datenbanksicherungsjob zu erstellen.

1 Wählen Sie die Ziel-Datenbank aus

2 Wählen Sie das Backup-Speichermedium aus

3 Wählen Sie die Sicherungstrategien aus

4 Die Arbeit einreichen

Sie können mit einer 60-tägigen voll ausgestatteten Testversion dieses leistungsstarken Systems beginnen. Klicken Sie einfach auf die Schaltfläche, um das Installationspaket zu erhalten. Klicken Sie hier, um mehr über das Sicherstellen von MySQL mit Vinchin Backup & Recovery zu erfahren.

Zusammenfassung

Die MySQL aktive-aktive synchrone Replikation ist darauf ausgelegt, hohe Verfügbarkeit und Flexibilität zu bieten. Sie ermöglicht es, mehrere MySQL-Instanzen gleichzeitig aktiv zu halten und die Daten zwischen ihnen zu synchronisieren, was bidirektionale Lese- und Schreibvorgänge ermöglicht. Sie gewährleistet eine kontinuierliche Verfügbarkeit, Lastverteilung, Datensicherheit und Flexibilität. Allerdings sind eine richtige Konfiguration und Verwaltung entscheidend, und die Wahl der Implementierungslösungen und Werkzeuge hängt von den spezifischen Anforderungen ab.

Um Datenbankdaten effizient zu schützen, können Sie Vinchin Backup & Recovery wählen, um einfach Datensicherungen und -wiederherstellungen durchzuführen. Nutzen Sie das kostenlose Testangebot nicht aus.