Multi-Master-Replikation - Multi-master replication

Multi-Master-Replikation ist eine Methode der Datenbankreplikation , die es ermöglicht, Daten von einer Gruppe von Computern zu speichern und von jedem Mitglied der Gruppe zu aktualisieren. Alle Mitglieder reagieren auf Kundendatenabfragen. Das Multi-Master-Replikationssystem ist dafür verantwortlich, die von jedem Mitglied vorgenommenen Datenänderungen an den Rest der Gruppe weiterzugeben und alle Konflikte aufzulösen, die zwischen gleichzeitig von verschiedenen Mitgliedern vorgenommenen Änderungen auftreten könnten.

Die Multi-Master-Replikation kann der Primär-Replikat- Replikation gegenübergestellt werden, bei der ein einzelnes Mitglied der Gruppe als "Master" für ein bestimmtes Datenelement bezeichnet wird und der einzige Knoten ist, der dieses Datenelement ändern darf. Andere Mitglieder, die das Datenelement modifizieren möchten, müssen zuerst den Masterknoten kontaktieren. Das Zulassen nur eines einzigen Masters macht es einfacher, Konsistenz zwischen den Mitgliedern der Gruppe zu erreichen, ist jedoch weniger flexibel als die Multi-Master-Replikation.

Multi-Master-Replikation kann auch mit Failover-Clustering verglichen werden, bei dem passive Replikatserver die Stammdaten replizieren, um die Übernahme vorzubereiten, falls der Master nicht mehr funktioniert. Der Master ist der einzige Server, der für die Client-Interaktion aktiv ist.

Kommunikation und Replikation in Multi-Master-Systemen werden häufig über eine Art Konsensalgorithmus abgewickelt , können aber auch über benutzerdefinierte oder proprietäre Algorithmen speziell für die Software implementiert werden.

Die Hauptzwecke der Multi-Master-Replikation sind erhöhte Verfügbarkeit und schnellere Server-Reaktionszeiten.

Vorteile

  • Zugänglichkeit : Wenn ein Master ausfällt, aktualisieren andere Master die Datenbank weiter .
  • Verteilter Zugriff: Master können sich an mehreren physischen Standorten befinden, dh über das Netzwerk verteilt sein.

Nachteile

  • Konsistenz : Die meisten Multi-Master-Replikationssysteme sind nur lose konsistent, dh träge und asynchron und verletzen ACID- Eigenschaften.
  • Leistung : Eager Replikationssysteme sind komplex und erhöhen Kommunikation Latenz .
  • Integrität : Probleme wie die Konfliktlösung können unlösbar werden, wenn die Anzahl der beteiligten Knoten steigt und die Latenz zunimmt.

Implementierungen

Verzeichnisdienste

Viele Verzeichnisserver basieren auf dem Lightweight Directory Access Protocol (LDAP) und implementieren eine Multi-Master-Replikation.

Active Directory

Eine des häufigen Multi-Master - Replikation Implementierungen in Verzeichnisserver ist Microsoft ‚s Active Directory . Innerhalb von Active Directory werden Objekte, die auf einem Domänencontroller aktualisiert werden, dann durch Multimasterreplikation auf andere Domänencontroller repliziert. Es ist nicht erforderlich, dass alle Domänencontroller miteinander replizieren, da dies in großen Active Directory-Bereitstellungen zu übermäßigem Netzwerkverkehr führen würde. Stattdessen verfügen Domänencontroller über ein komplexes Aktualisierungsmuster, das sicherstellt, dass alle Server rechtzeitig ohne übermäßigen Replikationsverkehr aktualisiert werden. Einige Active Directory-Anforderungen werden jedoch durch den flexiblen Single-Master-Betrieb besser erfüllt .

CA-Verzeichnis

CA Directory unterstützt die Multi-Master-Replikation.

OpenDS/OpenDJ

OpenDS (und sein Nachfolgeprodukt OpenDJ ) implementierten Multimaster seit Version 1.0. Die OpenDS/OpenDJ-Multi-Master-Replikation ist asynchron, sie verwendet ein Protokoll mit einem Publish-Subscribe-Mechanismus, der eine Skalierung auf eine große Anzahl von Knoten ermöglicht. Die OpenDS/OpenDJ-Replikation führt eine Konfliktlösung auf Eintrags- und Attributebene durch. Die OpenDS/OpenDJ-Replikation kann über ein Wide Area Network verwendet werden .

OpenLDAP

Der weit verbreitete Open-Source- LDAP-Server OpenLDAP implementiert seit Version 2.4 (Oktober 2007) die Multi-Master-Replikation [1] .

Datenbankmanagementsystem

Amazon Aurora

Amazon Aurora besteht aus Writer-Knoten, die Redo-Datensätze replizieren, und 6 Speicherknoten. Der Writer-Knoten sendet Änderungen an jeden Speicherknoten, von denen jeder auf Konflikte prüft und dann die Bestätigung oder Ablehnung der Änderung meldet.

Apache CouchDB

Apache CouchDB verwendet ein einfaches, HTTP-basiertes Multi-Master-Replikationssystem, das auf der Verwendung eines reinen Append-Datenspeichers und der Verwendung von Multiversion Concurrency Control (MVCC) basiert .

Jedes Dokument enthält eine Revisions-ID, so dass jeder Datensatz die evolutionäre Zeitleiste aller vorherigen Revisions-IDs speichert, die zu sich selbst führen – was die Grundlage des MVCC- Systems von CouchDB bildet. Darüber hinaus führt es einen sequenziellen Index für die gesamte Datenbank. "Der Replikationsprozess kopiert nur die letzte Revision eines Dokuments, daher werden alle vorherigen Revisionen, die sich nur in der Quelldatenbank befanden, nicht in die Zieldatenbank kopiert."

Der CouchDB-Replikator fungiert als einfacher HTTP-Client, der sowohl auf eine Quell- als auch auf eine Zieldatenbank wirkt . Es vergleicht aktuelle Sequenz-IDs für die Datenbank, berechnet Revisionsunterschiede und nimmt die erforderlichen Änderungen am Ziel basierend auf den Ergebnissen in der Historie der Quelldatenbank vor . Die bidirektionale Replikation ist das Ergebnis einer weiteren Replikation mit vertauschten Quell- und Zielwerten .

ArangoDB

ArangoDB ist ein natives Multi-Model-Datenbanksystem mit Multi-Master-Replikation. Cluster in ArangoDB verwenden das CP-Master/Master-Modell ohne Single Point of Failure. Wenn ein Cluster auf eine Netzwerkpartition stößt, zieht ArangoDB es vor, seine interne Konsistenz der Verfügbarkeit beizubehalten. Clients erhalten dieselbe Ansicht der Datenbank, unabhängig davon, mit welchem ​​Knoten sie eine Verbindung herstellen. Und der Cluster bedient weiterhin Anfragen, selbst wenn eine Maschine ausfällt.

Cloudant

Cloudant , ein verteiltes Datenbanksystem, verwendet weitgehend die gleiche HTTP-API wie Apache CouchDB und bietet die gleiche Fähigkeit zur Replikation mit Multiversion Concurrency Control (MVCC) . Cloudant-Datenbanken können untereinander replizieren, aber intern verwenden Knoten in Cloudant-Clustern die Multi-Master-Replikation, um miteinander synchron zu bleiben und API-Nutzern eine hohe Verfügbarkeit zu bieten.

eXtremeDB-Cluster

eXtremeDB Cluster ist das Clustering-Subsystem für die eingebettete Datenbankproduktfamilie eXtremeDB von McObject . Durch die synchrone Replikation von Transaktionen (Zweiphasen-Commit) wird die Datenbankkonsistenz über mehrere Hardwareknoten hinweg aufrechterhalten. Ein wichtiges Merkmal von eXtremeDB Cluster ist die Transaktionsreplikation im Gegensatz zu protokolldateibasierten, SQL-Anweisungsbasierten oder anderen Replikationsschemata, die den Erfolg oder Misserfolg ganzer Transaktionen garantieren können oder nicht. Dementsprechend ist eXtremeDB Cluster ein ACID- kompatibles System (nicht BASE oder eventuelle Konsistenz ); eine auf einem beliebigen Cluster-Knoten ausgeführte Abfrage gibt das gleiche Ergebnis zurück, als ob sie auf einem anderen Cluster-Knoten ausgeführt würde.

Orakel

Datenbank - Cluster implementieren Multi-Master - Replikation eines von zwei Methoden. Bei der asynchronen Multi-Master-Replikation werden Datenänderungen an eine verzögerte Transaktionswarteschlange übergeben, die regelmäßig auf allen Datenbanken im Cluster verarbeitet wird. Die synchrone Multi-Master-Replikation verwendet die Zweiphasen-Commit-Funktion von Oracle, um sicherzustellen, dass alle Datenbanken mit dem Cluster über einen konsistenten Datensatz verfügen .

Microsoft SQL

Microsoft SQL bietet Multi-Master-Replikation durch Peer-to-Peer-Replikation. Es bietet eine Scale-out- und Hochverfügbarkeitslösung, indem Kopien von Daten über mehrere Knoten hinweg verwaltet werden. Basierend auf der Transaktionsreplikation propagiert die Peer-to-Peer-Replikation transaktionskonsistente Änderungen nahezu in Echtzeit.

MySQL / MariaDB

Grundsätzlich ist es möglich, ein Multi-Master-Replikationsschema ab MySQL-Version 3.23 mit zirkulärer Replikation zu erreichen. Abweichend davon werden MariaDB und MySQL mit einer gewissen Replikationsunterstützung ausgeliefert, die jeweils unterschiedliche Nuancen aufweisen.

In Bezug auf die direkte Unterstützung haben wir:

MariaDB: unterstützt nativ Multi-Master-Replikation seit Version 10.0, aber Konfliktlösung wird nicht unterstützt, daher muss jeder Master unterschiedliche Datenbanken enthalten. Bei MySQL wird dies als Multi-Source bezeichnet und ist seit Version 5.7.6 verfügbar .

MySQL: MySQL Group Replication, ein Plugin für virtuelle synchrone Multimaster mit Konfliktbehandlung und verteilter Wiederherstellung wurde mit 5.7.17 veröffentlicht .

Clusterprojekte:

MySQL Cluster unterstützt seit Version 6.3 die Konflikterkennung und -lösung zwischen mehreren Mastern, um eine echte Multi-Master-Fähigkeit für den MySQL Server zu gewährleisten.

Es gibt auch ein externes Projekt, Galera Cluster, das von codership erstellt wurde und echte Multi-Master-Fähigkeit bietet, basierend auf einem Fork der InnoDB-Speicher-Engine und benutzerdefinierten Replikations-Plug-Ins. Die Replikation ist synchron, daher ist kein Konflikt möglich.

Percona XtraDB Cluster ist auch eine Kombination aus der Galera-Replikationsbibliothek und MySQL, das Multi-Master unterstützt.

PostgreSQL

Es gibt verschiedene Optionen für die synchrone Multi-Master-Replikation. Postgres-XL, das unter der Mozilla Public License verfügbar ist, und PostgresXC (jetzt bekannt als Postgres-X2 ), das unter derselben Lizenz wie PostgreSQL selbst verfügbar ist, sind Beispiele. Beachten Sie, dass das Projekt PgCluster ( Archived 2017-07-05 at the Wayback Machine ) 2007 aufgegeben wurde.

Die Replikationsdokumentation für PostgreSQL kategorisiert die verschiedenen verfügbaren Replikationstypen. Es gibt verschiedene Optionen für verteilte Multimaster , einschließlich Bucardo , Rubyrep und BDR Bi-Directional Replication .

PostgreSQL-BDR

BDR zielt auf eine eventuelle Aufnahme in den PostgreSQL-Kern ab und wurde im Vergleich zu früheren Optionen als eine deutlich verbesserte Leistung eingestuft. BDR umfasst die Replikation von Datenschreibvorgängen (DML) sowie Änderungen an der Datendefinition (DDL) und globalen Sequenzen. BDR-Knoten können ab Version 0.9 online aktualisiert werden. 2ndQuadrant hat BDR seit 2012 kontinuierlich weiterentwickelt, wobei das System seit 2014 in Produktion ist. Die neueste Version BDR 3.6 bietet Konflikterkennung auf Spaltenebene, CRDTs, Eager Replication, Multi-Node-Abfragekonsistenz und viele andere Funktionen.

Ingres

Innerhalb von Ingres Replicator können Objekte, die auf einem Ingres-Server aktualisiert werden, dann durch Multi-Master-Replikation auf andere Server repliziert werden, egal ob lokal oder remote. Wenn ein Server ausfällt, können Clientverbindungen auf einen anderen Server umgeleitet werden. Es ist nicht erforderlich, dass alle Ingres-Server in einer Umgebung miteinander replizieren, da dies bei großen Implementierungen zu übermäßigem Netzwerkverkehr führen kann. Stattdessen ermöglicht Ingres Replicator die Replikation der entsprechenden Daten auf die entsprechenden Server ohne übermäßigen Replikationsverkehr. Dies bedeutet, dass einige Server in der Umgebung als Failover-Kandidaten dienen können, während andere Server andere Anforderungen erfüllen können, z. B. die Verwaltung einer Teilmenge von Spalten oder Tabellen für eine Abteilungslösung, eine Teilmenge von Zeilen für eine geografische Region oder eine unidirektionale Replikation für ein Reporting Server. Im Falle eines Quellen-, Ziel- oder Netzwerkfehlers wird die Datenintegrität durch dieses zweiphasige Commit-Protokoll erzwungen , indem sichergestellt wird, dass entweder die gesamte Transaktion repliziert wird oder keine davon. Darüber hinaus kann Ingres Replicator über RDBMS von mehreren Anbietern betrieben werden, um diese zu verbinden.

Siehe auch

Verweise

Externe Links