Dies ist der zweite Blogpost über die Apache HBase-Replikation. Im vorherigen Blogpost HBase Replication Overview wurden Anwendungsfälle, Architektur und verschiedene Modi erörtert, die bei der HBase-Replikation unterstützt werden. Dieser Blogpost ist aus betrieblicher Sicht und behandelt die HBase-Replikationskonfiguration und Schlüsselkonzepte für deren Verwendung – wie Bootstrapping, Schemaänderung und Fehlertoleranz.
Konfiguration
Wie unter Übersicht über die HBase-Replikation erwähnt, sendet der Master-Cluster WALEdits an einen oder mehrere Slave-Cluster. Dieser Abschnitt beschreibt die Schritte, die zum Konfigurieren der Replikation im Master-Slave-Modus erforderlich sind.
- Alle Tabellen/Spaltenfamilien, die repliziert werden sollen, müssen auf beiden Clustern vorhanden sein.
- Fügen Sie die folgende Eigenschaft in $HBASE_HOME/conf/hbase-site.xml auf allen Knoten in beiden Clustern hinzu; auf wahr setzen.
hbase.replication
wahr
Nehmen Sie auf dem Master-Cluster die folgenden zusätzlichen Änderungen vor:
- Replikationsbereich festlegen (REPLICATION_SCOPE Attribut) auf die zu replizierende Tabellen-/Spaltenfamilie:
hbase shell> „Tabelle“ deaktivieren
hbase shell> alter ‘table’, {NAME => ‘column-family’, REPLICATION_SCOPE => 1}
hbase Shell> aktivieren Sie „Tabelle“
REPLICATION_SCOPE ist ein Attribut auf Spaltenfamilienebene und sein Wert kann entweder 0 oder 1 sein. Ein Wert von 0 bedeutet, dass die Replikation deaktiviert ist, und 1 bedeutet, dass die Replikation aktiviert ist. Ein Benutzer muss jede Spaltenfamilie mit dem alter-Befehl wie oben gezeigt für alle Spaltenfamilien ändern, die er replizieren möchte.
Wenn ein Benutzer beim Erstellen einer Tabelle die Replikation aktivieren möchte, sollte er den folgenden Befehl verwenden:
hbase shell> erstelle „Tabelle“, „Spaltenfamilie1“, „Spaltenfamilie2“, {NAME => „Spaltenfamilie1“, REPLICATION_SCOPE => 1}
Der obige Befehl aktiviert die Replikation auf „Spaltenfamilie1“ der obigen Tabelle.
2. Fügen Sie in der hbase-Shell den Slave-Peer hinzu. Ein Benutzer muss das Zookeeper-Quorum des Slave-Clusters, seinen Client-Port und den Root-hbase-Znode zusammen mit einer peerId bereitstellen:
hbase shell>add_peer ‚peerId‘, „::“
Die peerId ist eine ein oder zwei Zeichen lange Zeichenfolge, und ein entsprechender Znode wird unter dem Peer-Znode erstellt, wie im vorherigen Blog erläutert. Sobald ein Benutzer den Befehl add_peer ausführt, instanziiert der Replikationscode ein ReplicationSource-Objekt für diesen Peer, und alle Regionsserver des Master-Clusters versuchen, eine Verbindung zu den Regionsservern des Slave-Clusters herzustellen. Es ruft auch die ClusterId des Slave-Clusters (UUID, registriert im Zookeeper-Quorum des Slave-Clusters) ab. Der Master-Cluster-Regionsserver listet die verfügbaren Regionsserver des Slaves auf, indem er „/hbase/rs“ znode und seine untergeordneten Knoten im Zookeeper-Quorum des Slave-Clusters liest und eine Verbindung zu ihm herstellt. Jeder Regionserver im Master-Cluster wählt eine Teilmenge der Slave-Regionserver aus, abhängig von dem durch „replication.source.ratio“ angegebenen Verhältnis, mit dem Standardwert 0,1. Dies bedeutet, dass jeder Master-Cluster-Regionsserver versucht, eine Verbindung zu 10 % aller Slave-Cluster-Regionsserver herzustellen. Beim Senden des Transaktionsstapels wählt der Master-Cluster-Regionsserver einen zufälligen Regionsserver aus diesen verbundenen Regionsservern aus. (Hinweis:Für Katalogtabellen, .META. und _ROOT_ wird keine Replikation durchgeführt.)
Um einen Master-Master-Modus einzurichten, sollten die obigen Schritte auf beiden Clustern wiederholt werden.
Schemaänderung
Wie im vorherigen Abschnitt erwähnt, müssen replizierte Tabellen und Spaltenfamilien in beiden Clustern vorhanden sein. In diesem Abschnitt werden verschiedene mögliche Szenarien erörtert, was während einer Schemaänderung passiert, wenn die Replikation noch im Gange ist:
a) Spaltenfamilie im Master löschen:Das Löschen einer Spaltenfamilie wirkt sich nicht auf die Replikation ausstehender Mutationen für diese Familie aus. Dies liegt daran, dass der Replikationscode die WAL liest und den Replikationsbereich der Spaltenfamilien für jede WALEdit überprüft. Jeder WALEdit verfügt über eine Zuordnung der replikationsfähigen Spaltenfamilien; Die Prüfung wird für alle Spaltenfamilien des Schlüsselwerts durchgeführt (unabhängig davon, ob sie bereichsabhängig sind oder nicht). Wenn es in der Karte vorhanden ist, wird es der Sendung hinzugefügt. Da das WALEdit-Objekt erstellt wird, bevor die Spaltenfamilie gelöscht wurde, wird seine Replikation nicht beeinträchtigt.
b) Löschen Sie die Spaltenfamilie im Slave:Die WALEdits werden vom Master-Cluster an einen bestimmten Slave-Regionsserver gesendet, der sie wie ein normaler HBase-Client verarbeitet (unter Verwendung eines HTablePool-Objekts). Da die Spaltenfamilie gelöscht wird, schlägt die Put-Operation fehl und diese Ausnahme wird an den Master-Regionserver-Cluster geworfen.
Replikation starten/stoppen
Start/Stopp-Befehle funktionieren als Kill-Schalter. Wenn der Befehl stop_replication auf der HBase-Shell ausgeführt wird, ändert er den Wert von /hbase/replication/state in false. Dadurch werden alle Replikationsquellobjekte daran gehindert, die Protokolle zu lesen. aber die vorhandenen gelesenen Einträge werden versendet. Wenn ein Nutzer den Befehl zum Stoppen der Replikation verwendet, werden die neu gerollten Protokolle nicht für die Replikation in die Warteschlange eingereiht. Ebenso startet die Ausgabe eines start_replication-Befehls die Replikation von der aktuellen WAL (die einige frühere Transaktionen enthalten kann) und nicht von dem Zeitpunkt an, an dem der Befehl ausgegeben wurde.
Abbildung 1 erläutert das Verhalten des Start-Stopp-Schalters, wobei die Abfolge von Ereignissen in Richtung der Pfeile fließt.
Versionskompatibilität
Master-Cluster-Regionsserver verbinden sich mit Slave-Cluster-Regionsservern als normale HBase-Clients. Es gilt die gleiche Kompatibilitätsregel, ob ein HBase-Client der Version xxx auf einem HBase-Server der Version yyy unterstützt wird.
Da sich die Replikation noch in der Entwicklung befindet (immer mehr Funktionalitäten werden kontinuierlich hinzugefügt), sollte sich ein Benutzer der bestehenden Funktionalitäten bewusst sein. Beispielsweise gibt es in CDH4, das auf dem HBase 0.92-Zweig basiert, Unterstützung für Master-Master- und zyklische Replikation. Das Aktivieren/Deaktivieren der Replikationsquelle auf Peer-Ebene wurde im HBase 0.94-Zweig hinzugefügt.
Bootstrapping
Die Replikation funktioniert durch Lesen der WALs der Master-Cluster-Regionsserver. Wenn ein Benutzer alte Daten replizieren möchte, kann er einen copyTable-Befehl ausführen (der Start- und Endzeitstempel definiert), während er die Replikation aktiviert. Der copyTable-Befehl kopiert die Daten, die durch die Start-/Endzeitstempel begrenzt sind, und die Replikation kümmert sich um die aktuellen Daten. Der Gesamtansatz kann wie folgt zusammengefasst werden:
- Starten Sie die Replikation (beachten Sie den Zeitstempel).
- Führen Sie den copyTable-Befehl mit einem Endzeitstempel aus, der dem obigen Zeitstempel entspricht.
- Da die Replikation von der aktuellen WAL aus gestartet wird, kann es einige Schlüsselwerte geben, die sowohl von Replikations- als auch von copyTable-Jobs auf den Slave kopiert werden. Das ist noch in Ordnung, da es sich um eine idempotente Operation handelt.
Im Falle einer Master-Master-Replikation sollte man den copyTable-Job ausführen, bevor man die Replikation startet. Denn wenn ein Benutzer einen copyTable-Job startet, nachdem er die Replikation aktiviert hat, sendet der zweite Master die Daten erneut an den ersten Master, da copyTable die clusterId in den Mutationsobjekten nicht bearbeitet. Der Gesamtansatz kann wie folgt zusammengefasst werden:
- Führen Sie den copyTable-Job aus (beachten Sie den Startzeitstempel des Jobs).
- Starten Sie die Replikation.
- Führen Sie copyTable erneut aus, wobei die Startzeit gleich der in Schritt 1 notierten Startzeit ist.
Dabei werden auch einige Daten zwischen den beiden Clustern hin- und hergeschoben; aber es minimiert seine Größe.
Fehlertoleranz
Server-Failover der Master-Cluster-Region
Alle Regionserver im Master-Cluster erstellen einen Znode unter „/hbase/replication/rs“, wie im Abschnitt „Architektur“ erwähnt. Ein Regionsserver fügt einen untergeordneten Znode für jede WAL hinzu, mit einem Byte-Offset unter seinem Znode in der Replikationshierarchie, wie in Abbildung 1 gezeigt. Wenn ein Regionsserver ausfällt, müssen sich andere Regionsserver um die Protokolle des toten Regionsservers kümmern, die darunter aufgeführt sind znode des regionservers. Alle Regionserver überwachen andere Regionserver-Znodes („/hbase/rs“) znode; Wenn also ein Regionserver ausfällt, erhalten andere Regionserver das Ereignis, da der Master diesen Regionserver als tot markiert. In diesem Fall versuchen alle anderen Regionserver, die WALs vom toten Regionserver-Znode auf ihren Znode zu übertragen und ein Präfix mit der Slave-ID und dem Namen des toten Regionservers anzuhängen, um sie von anderen normalen Protokollen zu unterscheiden. Für die übertragenen Protokolle wird eine separate Replikationsquelle (NodeFailoverWorker-Instanz) instanziiert, die nach der Verarbeitung dieser übertragenen Protokolle stirbt.
Betrachtet man Abbildung 1 der HBase-Replikationsübersicht als Basisabbildung der Replikations-Znodes-Hierarchie, zeigt Abbildung 2 die neue Replikations-Znodes-Hierarchie für den Fall, dass der Server foo1.bar.com stirbt und foo2.bar.com seine Warteschlange übernimmt. Beachten Sie den neuen Znode „1-foo1.bar.com,40020,1339435481973“, der unter foo2.bar.com znode
erstellt wird/hbase/hbaseid:b53f7ec6-ed8a-4227-b088-fd6552bd6a68 …. /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 ... foo2.bar.com,40020, 1339435481742/1/foo2.bar.com.13394354343443:1909033 /hbase/replication/rs/foo2.bar.com,40020,1339435481742/1- foo1.bar.com,40020,1339435481973.481973.481973 /foo1.bar.com.1339435485769:1243232
Abbildung 2. Regionserver-Failover-Znodes-Hierarchie
In der Zwischenzeit kann das Log-Splitting einsetzen und die Server-Logs der toten Region archivieren. Die Replikationsquelle sucht nach den Protokollen sowohl im regulären als auch im archivierten Verzeichnis.
Langsamer/nicht reagierender Slave-Cluster (oder Regionsserver)
Wenn ein Slave-Cluster ausgefallen ist oder eine temporäre Netzwerkpartition vorhanden ist, werden Protokolle, die noch nicht auf den Slave repliziert wurden, nicht vom HBase-Protokollreiniger gelöscht.
Die Protokollbereinigung wird von der LogCleaner-Klasse durchgeführt, die nach einer konfigurierten Zeit weiter ausgeführt wird. Der Replikationscode fügt der LogCleaner-Klasse das ReplicationLogCleaner-Plugin hinzu. Wenn letzterer versucht, ein bestimmtes Protokoll zu löschen, prüft ReplicationLogCleaner, ob dieses Protokoll in der Replikations-Znode-Hierarchie (unter /hbase/replication/rs/znode) vorhanden ist. Wenn das Protokoll gefunden wird, bedeutet dies, dass das Protokoll noch repliziert werden muss und seine Löschung übersprungen wird. Sobald das Protokoll repliziert ist, wird sein znode aus der Replikationshierarchie gelöscht. Bei der nächsten Ausführung löscht LogCleaner die Protokolldatei erfolgreich, sobald sie repliziert wurde.
Verifizierung
Bei kleineren Datenmengen kann man einfach mit der hbase-Shell im Slave-Cluster nach den Tabellenzeilen suchen, um zu überprüfen, ob sie repliziert werden oder nicht. Eine standardmäßige Überprüfungsmethode besteht darin, den Auftrag verifyrep mapreduce auszuführen, der mit HBase geliefert wird. Es sollte auf dem Master-Cluster ausgeführt werden und die Slave-Cluster-ID und den Namen der Zieltabelle erfordern. Man kann auch zusätzliche Argumente wie Start-/Stopp-Zeitstempel und Spaltenfamilien angeben. Es gibt zwei Zähler aus, nämlich GOODROWS und BADROWS, die die Anzahl der replizierten bzw. nicht replizierten Zeilen angeben.
Replikationsmetriken
Das Replikationsframework stellt einige nützliche Metriken bereit, die verwendet werden können, um den Replikationsfortschritt zu überprüfen. Einige der wichtigsten sind:
- sizeOfLogQueue:Anzahl der zu verarbeitenden HLogs (ohne den gerade verarbeiteten) an der Replikationsquelle
- shippedOpsRate:Rate der versendeten Mutationen
- logEditsReadRate:Mutationsrate, die von HLogs an der Replikationsquelle gelesen wird
- ageOfLastShippedOp:Alter des letzten Stapels, der von der Replikationsquelle versendet wurde
Zukunftsarbeit
Mit all den aktuellen Funktionen, die in der aktuellen HBase-Replikation vorhanden sind, gibt es immer noch Spielraum für weitere Verbesserungen. Sie reicht von der Leistung, wie z. B. der Verringerung der Replikationszeitverzögerung zwischen Master und Slave, bis hin zu einer robusteren Behandlung des Ausfalls von Regionsservern (HBase-2611). Weitere Verbesserungsbereiche umfassen die Aktivierung der Peer-Level-Tabellenreplikation und die ordnungsgemäße Handhabung von IncrementColumnValue (HBase-2804).
Schlussfolgerung
In diesem Beitrag wurde die HBase-Replikation aus der Sicht eines Betreibers erörtert, einschließlich Konfiguration (verschiedener Modi), Bootstrapping eines vorhandenen Clusters, Auswirkungen von Schemaänderungen und Fehlertoleranz.
