Apache HBase Replication ist eine Möglichkeit, Daten von einem HBase-Cluster in einen anderen und möglicherweise entfernten HBase-Cluster zu kopieren. Es funktioniert nach dem Prinzip, dass die Transaktionen vom Ursprungscluster zu einem anderen Cluster gepusht werden. Im HBase-Jargon wird der Cluster, der den Push durchführt, Master genannt, und derjenige, der die Transaktionen empfängt, wird Slave genannt. Dieses Pushen von Transaktionen erfolgt asynchron und diese Transaktionen werden in einer konfigurierbaren Größe gestapelt (Standard ist 64 MB). Der asynchrone Modus verursacht minimalen Overhead auf dem Master und das Versenden von Bearbeitungen in einem Stapel erhöht den Gesamtdurchsatz.
In diesem Blogpost werden die möglichen Anwendungsfälle, die zugrunde liegende Architektur und die Modi der HBase-Replikation erörtert, wie sie in CDH4 (das auf 0.92 basiert) unterstützt werden. Wir werden die Replikationskonfiguration, das Bootstrapping und die Fehlertoleranz in einem Folge-Blogpost besprechen.
Anwendungsfälle
Die HBase-Replikation unterstützt die Replikation von Daten über Rechenzentren hinweg. Dies kann für Disaster-Recovery-Szenarien verwendet werden, in denen wir den Slave-Cluster für Echtzeitverkehr sorgen können, falls der Master-Standort ausfällt. Da die HBase-Replikation nicht für automatisches Failover vorgesehen ist, erfolgt der Wechsel vom Master- zum Slave-Cluster, um mit der Bereitstellung des Datenverkehrs zu beginnen, durch den Benutzer. Anschließend, sobald der Master-Cluster wieder aktiv ist, kann man einen CopyTable-Job ausführen, um die Deltas in den Master-Cluster zu kopieren (indem man die Start-/Stopp-Zeitstempel bereitstellt), wie im CopyTable-Blogpost beschrieben.
Ein weiterer Anwendungsfall für die Replikation ist, wenn ein Benutzer lastintensive MapReduce-Jobs auf seinem HBase-Cluster ausführen möchte; man kann dies auf dem Slave-Cluster tun, während man auf dem Master-Cluster einen leichten Leistungsabfall hinnehmen muss.
Architektur
Das zugrunde liegende Prinzip der HBase-Replikation besteht darin, alle Transaktionen vom Master zum Slave zu wiederholen. Dies erfolgt durch erneutes Abspielen der WALEdits (Write Ahead Log-Einträge) in den WALs (Write Ahead Log) aus dem Master-Cluster, wie im nächsten Abschnitt beschrieben. Diese WALEdits werden nach dem Filtern (unabhängig davon, ob eine bestimmte Bearbeitung für die Replikation vorgesehen ist oder nicht) und dem Versand in einer benutzerdefinierten Stapelgröße (Standard ist 64 MB) an die Server der Slave-Clusterregion gesendet. Falls der WAL-Reader das Ende der aktuellen WAL erreicht, versendet er alle bis dahin gelesenen WALEdits. Da es sich um einen asynchronen Replikationsmodus handelt, kann der Slave-Cluster in einer schreibintensiven Anwendung um Minuten hinter dem Master zurückbleiben.
WAL/WALEdits/Memstore
In HBase werden alle Mutationsoperationen (Puts/Deletes) in einen Speicher geschrieben, der zu einer bestimmten Region gehört, und auch an eine Write-Ahead-Log-Datei (WAL) in Form eines WALEdit angehängt. Ein WALEdit ist ein Objekt, das eine Transaktion darstellt und mehr als eine Mutationsoperation haben kann. Da HBase Transaktionen auf Einzelzeilenebene unterstützt, kann ein WALEdit Einträge für nur eine Zeile haben. Die WALs werden nach einem konfigurierten Zeitraum wiederholt (Standard ist 60 Minuten), sodass es zu jedem Zeitpunkt nur eine aktive WAL pro Regionsserver gibt.
IncrementColumnValue, eine CAS-Operation (Prüfen und Ersetzen), wird ebenfalls in Put umgewandelt, wenn sie in die WAL geschrieben wird.
Ein Memstore ist eine sortierte Karte im Speicher, die Schlüsselwerte der Region enthält, aus der sie besteht; Es gibt einen Speicher pro Spaltenfamilie pro Region. Der Speicher wird als HFile auf die Festplatte geschrieben, sobald er die konfigurierte Größe erreicht hat (Standard ist 64 MB).
Das Schreiben in WAL ist optional, aber es ist erforderlich, um Datenverluste zu vermeiden, da HBase im Falle eines Absturzes eines Regionsservers alle auf diesem Regionsserver gehosteten Memstores verlieren kann. Im Falle eines Ausfalls des Regionservers werden seine WALs durch einen Log-Splitting-Prozess wiedergegeben, um die in den WALs gespeicherten Daten wiederherzustellen.
Damit die Replikation funktioniert, muss das Schreiben in WALs aktiviert sein.
Cluster-ID
Jeder HBase-Cluster hat eine Cluster-ID, einen UUID-Typ, der automatisch von HBase generiert wird. Es wird im zugrunde liegenden Dateisystem (normalerweise HDFS) gespeichert, damit es sich zwischen Neustarts nicht ändert. Diese wird im Znode /hbase/hbaseid gespeichert. Diese ID wird verwendet, um eine Master-Master-/azyklische Replikation zu erreichen. Eine WAL enthält Einträge für eine Reihe von Regionen, die auf dem Regionserver gehostet werden. Der Replikationscode liest alle Schlüsselwerte und filtert die Schlüsselwerte heraus, die für die Replikation vorgesehen sind. Dazu wird das Spaltenfamilienattribut des Schlüsselwerts betrachtet und mit der Datenstruktur der Spaltenfamilienzuordnung von WALEdit abgeglichen. Falls ein bestimmter Schlüsselwert für die Replikation vorgesehen ist, wird der clusterId-Parameter des Schlüsselwerts auf die HBase-Cluster-ID geändert.
Replikationsquelle
Die ReplicationSource ist ein Java-Thread-Objekt im regionserver-Prozess und ist für die Replikation von WAL-Einträgen zu einem bestimmten Slave-Cluster verantwortlich. Es verfügt über eine Prioritätswarteschlange, die die zu replizierenden Protokolldateien enthält. Sobald ein Protokoll verarbeitet wird, wird es aus der Warteschlange entfernt. Die Prioritätswarteschlange verwendet einen Komparator, der die Protokolldateien basierend auf ihrem Erstellungszeitstempel vergleicht (der an den Namen der Protokolldatei angehängt wird); Protokolle werden also in derselben Reihenfolge verarbeitet, in der sie erstellt wurden (ältere Protokolle werden zuerst verarbeitet). Wenn sich nur eine Protokolldatei in der Prioritätswarteschlange befindet, wird sie nicht gelöscht, da sie die aktuelle WAL darstellt.
Rolle des Tierpflegers
Zookeeper spielt eine Schlüsselrolle bei der HBase-Replikation, wo es fast alle wichtigen Replikationsaktivitäten verwaltet/koordiniert, wie z. B. das Registrieren eines Slave-Clusters, das Starten/Stoppen der Replikation, das Einreihen neuer WALs, das Handhaben von Regionserver-Failover usw. Es ist ratsam, einen gesunden Zookeeper-Quorum (mindestens 3 oder mehr Knoten), damit es ständig einsatzbereit ist. Zookeeper sollte unabhängig (und nicht von HBase) ausgeführt werden. Die folgende Abbildung zeigt ein Beispiel einer replikationsbezogenen Znodes-Struktur im Master-Cluster (der Text nach dem Doppelpunkt ist die data des znode):
/hbase/hbaseid: b53f7ec6-ed8a-4227-b088-fd6552bd6a68 …. /hbase/rs/foo1.bar.com,40020,1339435481742: /hbase/rs/foo2.bar.com,40020,1339435481973: /hbase/rs/foo3.bar.com,40020,1339435486713: /hbase/replication: /hbase/replication/state: true /hbase/replication/peers: /hbase/replication/peers/1: zk.quorum.slave:281:/hbase /hbase/replication/rs: /hbase/replication/rs/foo1.bar.com.com,40020,1339435084846: /hbase/replication/rs/foo1.bar.com,40020,1339435481973/1: /hbase/replication/rs/foo1.bar.com,40020,1339435481973/1/foo1.bar.com.1339435485769: 1243232 /hbase/replication/rs/foo3.bar.com,40020,1339435481742: /hbase/replication/rs/foo3.bar.com,40020,1339435481742/1: /hbase/replication/rs/foo3.bar.com,40020,1339435481742/1/foo3.bar..com.1339435485769: 1243232 /hbase/replication/rs/foo2.bar.com,40020,1339435089550: /hbase/replication/rs/foo2.bar.com,40020,1339435481742/1: /hbase/replication/rs/foo2.bar.com,40020,1339435481742/1/foo2.bar..com.13394354343443: 1909033
Abbildung 1. Hierarchie der Replikations-Znodes
Wie in Abbildung 1 dargestellt, gibt es im Master-Cluster drei Regionserver, nämlich foo[1-3].bar.com. Es gibt drei Znodes, die sich auf die Replikation beziehen:
- Zustand :Dieser Znode gibt an, ob die Replikation aktiviert ist oder nicht. Alle grundlegenden Schritte (z. B. ob ein neu gerolltes Protokoll in eine Replikationswarteschlange eingereiht werden soll, ob eine Protokolldatei gelesen werden soll, um WALEdits-Sendungen durchzuführen usw.), überprüfen Sie diesen booleschen Wert vor der Verarbeitung. Dies wird durch die Einstellung der Eigenschaft „hbase.replication“ in der hbase-conf.xml auf true gesetzt. Eine andere Möglichkeit, den Wert zu ändern, besteht darin, den Befehl „start/stop replication“ in der hbase-Shell zu verwenden. Dies wird im zweiten Blogpost diskutiert.
- Kollegen :Dieser Znode hat die verbundenen Peers/Slaves als Kinder. In der Abbildung gibt es einen Slave mit der peerId =1, und sein Wert ist die Verbindungszeichenfolge (Zookeeper_quorum_of_slave:Zookeeper_client_port:root_hbase_znode), wobei Zookeeper_quorum_of_slave eine durch Kommas getrennte Liste von Zookeeper-Servern ist. Der peerId-znode-Name ist derselbe wie der, der beim Hinzufügen eines Peers angegeben wurde.
- rs :Dieser Znode enthält eine Liste aktiver Regionsserver im Master-Cluster. Jeder Regionserver-Znode hat eine Liste von WALs, die repliziert werden sollen, und der Wert dieser Protokoll-Znodes ist entweder null (falls das Protokoll noch nicht für die Replikation geöffnet wurde) oder der Byte-Offset zu dem Punkt, an dem das Protokoll gelesen wurde. Der Byte-Offset-Wert für einen WAL-Znode gibt den Byte-Offset der entsprechenden WAL-Datei an, bis zu der sie gelesen und repliziert wurde. Da es mehr als einen Slave-Cluster geben kann und der Replikationsfortschritt zwischen ihnen variieren kann (z. B. kann einer ausgefallen sein), sind alle WALs eigenständig in einem peerId-Znode unter rs enthalten. In der obigen Abbildung befinden sich WALs-Znodes also unter are /rs//1, wobei „1“ die peerId ist.
Replikationsmodi
Es gibt drei Modi zum Einrichten der HBase-Replikation:
- Master-Slave:In diesem Modus erfolgt die Replikation in eine einzige Richtung, d. h. Transaktionen von einem Cluster werden zu einem anderen Cluster gepusht. Beachten Sie, dass der Slave-Cluster genau wie jeder andere Cluster ist und seine eigenen Tabellen, Verkehr usw. haben kann.
- Master-Master:In diesem Modus wird die Replikation in beide Richtungen gesendet, für unterschiedliche oder gleiche Tabellen, d. h. beide Cluster fungieren sowohl als Master als auch als Slave. Für den Fall, dass sie dieselbe Tabelle replizieren, könnte man denken, dass dies zu einer Endlosschleife führen könnte, aber dies wird vermieden, indem die ClusterId einer Mutation (Put/Delete) auf die ClusterId des ursprünglichen Clusters gesetzt wird. Abbildung 2 erklärt dies anhand von zwei Clustern, nämlich Sonne und Erde. In Abbildung 2 haben wir zwei Blöcke, die die beiden HBase-Cluster darstellen. Sie haben die ClusterId 100 bzw. 200. Jeder der Cluster hat eine Instanz von ReplicationSource, die dem Slave-Cluster entspricht, auf den er replizieren möchte; es kennt die Cluster-IDs beider Cluster.
Abbildung 2. Sonne und Erde, zwei HBase-Cluster
Nehmen wir an, Cluster#Sun erhält eine frische und gültige Mutation M in einer Tabellen- und Spaltenfamilie, die für die Replikation in beiden Clustern vorgesehen ist. Es hat eine Standard-Cluster-ID (0L). Die Replikationsquellinstanz ReplicationSrc-E setzt ihre Cluster#Id gleich der Urheber-ID (100) und sendet sie an Cluster#Earth. Wenn Cluster#Earth die Mutation empfängt, gibt er sie wieder und die Mutation wird gemäß dem normalen Ablauf in seiner WAL gespeichert. Die Cluster#ID der Mutation wird in dieser Protokolldatei unter Cluster#Earth intakt gehalten. Die Replikationsquellinstanz unter Cluster#Earth (ReplicationSrc-S) liest die Mutation und vergleicht ihre Cluster#ID mit der SlaveCluster# (100, gleich Cluster#Sonne).Da sie gleich sind, wird dieser WALEdit-Eintrag übersprungen.
- Zyklisch:In diesem Modus nehmen mehr als zwei HBase-Cluster an der Replikationseinrichtung teil, und man kann verschiedene mögliche Kombinationen von Master-Slave und Master-Master zwischen zwei beliebigen Clustern einrichten. Die beiden oben genannten decken diese Fälle gut ab; Eine Ecksituation ist, wenn wir einen Zyklus eingerichtet haben
Abbildung 3. Einrichtung einer kreisförmigen Replikation
Abbildung 3. zeigt eine zirkuläre Replikationseinrichtung, bei der Cluster#Sonne auf Cluster#Erde repliziert, Cluster#Earth auf Cluster#Venus repliziert und Cluster#Venus auf Cluster#Sonne repliziert.
Sagen wir Cluster#Sonne erhält eine frische Mutation M und ist für die Replikation über alle oben genannten Cluster ausgelegt. Es wird wie oben in der Master-Master-Replikation auf Cluster#Erde repliziert. Die Replikationsquellinstanz auf Cluster#Earth, ReplicationSrc-V, liest die WAL und sieht die Mutation und repliziert sie auf Cluster#Venus. Die Cluster#Id der Mutation wird intakt gehalten (ab Cluster#Sun), bei Cluster#Venus. In diesem Cluster erkennt die Replikationsquellinstanz für Cluster#Sun, ReplicationSrc-S, dass die Mutation dieselbe Cluster-ID hat wie ihr SlaveCluster# (ab Cluster#Sun) und überspringt daher die Replikation.
Schlussfolgerung
Die HBase-Replikation ist eine leistungsstarke Funktion, die in einem Disaster-Recovery-Szenario verwendet werden kann. Es wurde als Vorschaufunktion in der Version 0.90 hinzugefügt und wurde zusammen mit HBase im Allgemeinen weiterentwickelt, mit zusätzlichen Funktionen wie Master-Master-Replikation, azyklischer Replikation (beide in 0.92 hinzugefügt) und Aktivieren/Deaktivieren der Replikation auf Peer-Ebene (hinzugefügt in 0.94).
Im nächsten Blogpost werden wir verschiedene Betriebsfunktionen wie Konfiguration usw. und andere Fallstricke bei der HBase-Replikation besprechen.
