Die Replikation (in diesem vorherigen Blog-Artikel behandelt) ist seit einiger Zeit veröffentlicht und gehört zu den am häufigsten verwendeten Funktionen von Apache HBase. Cluster, die Daten mit verschiedenen Peers replizieren, sind eine sehr häufige Bereitstellung, sei es als DR-Strategie oder einfach als nahtlose Möglichkeit, Daten zwischen Produktions-/Staging-/Entwicklungsumgebungen zu replizieren. Obwohl es eine effiziente Möglichkeit ist, verschiedene HBase-Datenbanken innerhalb einer Latenzzeit von weniger als einer Sekunde synchron zu halten, funktioniert die Replikation nur über Daten, die aufgenommen wurden, nachdem die Funktion aktiviert wurde. Das bedeutet, dass alle bereits vorhandenen Daten auf allen Clustern, die an der Replikationsbereitstellung beteiligt sind, noch auf andere Weise zwischen den Peers kopiert werden müssen. Es gibt einige Tools, die verwendet werden können, um bereits vorhandene Daten auf verschiedenen Peer-Clustern zu synchronisieren. Snapshots, BulkLoad, CopyTable sind bekannte Beispiele für solche Tools, die in früheren Cloudera-Blogbeiträgen behandelt wurden. In diesem Artikel behandeln wir HashTable/SyncTable, Einzelheiten zu einigen seiner internen Implementierungslogik, den Vor- und Nachteilen seiner Verwendung und wie es mit einigen der anderen oben erwähnten Datenkopiertechniken verglichen wird.
HashTable/SyncTable auf den Punkt gebracht
HashTable/SyncTable ist ein Tool, das als zwei Map-Reduce-Jobs implementiert ist, die als einzelne Schritte ausgeführt werden. Sie sieht der CopyTable ähnlich Tool, das sowohl teilweise als auch vollständige Kopien von Tabellendaten durchführen kann. Im Gegensatz zu CopyTable Es kopiert nur divergierende Daten zwischen Zielclustern und spart sowohl Netzwerk- als auch Rechenressourcen während des Kopiervorgangs.
Der erste auszuführende Schritt in diesem Prozess ist die HashTable Map-Reduce-Job. Dies sollte auf dem Cluster ausgeführt werden, dessen Daten zum Remote-Peer kopiert werden sollen, normalerweise dem Quellcluster. Unten sehen Sie ein kurzes Beispiel für die Ausführung. Eine ausführliche Erläuterung der einzelnen erforderlichen Parameter finden Sie weiter unten in diesem Artikel:
hbase org.apache.hadoop.hbase.mapreduce.HashTable --families=cf my-table /hashes/test-tbl … 20/04/28 05:05:48 INFO mapreduce.Job: map 100% reduce 100% 20/04/28 05:05:49 INFO mapreduce.Job: Job job_1587986840019_0001 completed successfully 20/04/28 05:05:49 INFO mapreduce.Job: Counters: 68 … File Input Format Counters Bytes Read=0 File Output Format Counters Bytes Written=6811788
Einmal die HashTable Jobausführung mit dem obigen Befehl abgeschlossen ist, wurden einige Ausgabedateien in der Quelle hdfs /hashes/my-table generiert Verzeichnis:
hdfs dfs -ls -R /hashes/test-tbl drwxr-xr-x - root supergroup 0 2020-04-28 05:05 /hashes/test-tbl/hashes -rw-r--r-- 2 root supergroup 0 2020-04-28 05:05 /hashes/test-tbl/hashes/_SUCCESS drwxr-xr-x - root supergroup 0 2020-04-28 05:05 /hashes/test-tbl/hashes/part-r-00000 -rw-r--r-- 2 root supergroup 6790909 2020-04-28 05:05 /hashes/test-tbl/hashes/part-r-00000/data -rw-r--r-- 2 root supergroup 20879 2020-04-28 05:05 /hashes/test-tbl/hashes/part-r-00000/index -rw-r--r-- 2 root supergroup 99 2020-04-28 05:04 /hashes/test-tbl/manifest -rw-r--r-- 2 root supergroup 153 2020-04-28 05:04 /hashes/test-tbl/partitions
Diese werden als Eingabe für die SyncTable benötigt Lauf. SyncTable muss beim Zielpeer gestartet werden. Der folgende Befehl führt SyncTable aus für die Ausgabe von HashTable aus dem vorherigen Beispiel. Es verwendet den Trockenlauf später in diesem Artikel erläuterte Option:
hbase org.apache.hadoop.hbase.mapreduce.SyncTable --dryrun --sourcezkcluster=zk1.example.com,zk2.example.com,zk3.example.com:2181:/hbase hdfs://source-cluster-active-nn/hashes/test-tbl test-tbl test-tbl … org.apache.hadoop.hbase.mapreduce.SyncTable$SyncMapper$Counter BATCHES=97148 HASHES_MATCHED=97146 HASHES_NOT_MATCHED=2 MATCHINGCELLS=17 MATCHINGROWS=2 RANGESNOTMATCHED=2 ROWSWITHDIFFS=2 SOURCEMISSINGCELLS=1 TARGETMISSINGCELLS=1
Als schnelle Referenz können Sie einfach die angegebenen Parameter in beiden Beispielen durch Ihre tatsächlichen Umgebungswerte ersetzen. Der Rest dieses Artikels behandelt die Implementierungsdetails ausführlicher.
Warum zwei verschiedene Schritte?
Das Hauptziel dieses Tools besteht darin, nur Daten zu identifizieren und zu kopieren, die zwischen den beiden Clustern fehlen. HashTable arbeitet als Sharding-/Indexierungsjob, analysiert Batches der Tabellendaten und generiert Hash-Indizes für jede dieser Chargen. Dies sind die Ausgaben, die in die Dateien unter /hashes/my-table geschrieben werden hdfs-Verzeichnis, das als einer der Jobparameter übergeben wird. Wie bereits erwähnt, wird diese Ausgabe von der SyncTable benötigt Arbeit. SyncTable scannt die Zieltabelle lokal in denselben Stapelgrößen wie von HashTable, verwendet und berechnet auch Hash-Werte für diese Stapel mit der gleichen Funktion, die von HashTable verwendet wird. Anschließend wird der lokale Batch-Hash verglichen Wert mit dem aus der HashTable Ausgang. Wenn die Hash-Werte gleich sind, bedeutet dies, dass der gesamte Stapel in den beiden Clustern identisch ist und nichts auf dieses Segment kopiert werden muss. Andernfalls wird ein Scan für den Stapel im Quellcluster geöffnet, wobei überprüft wird, ob jede der Zellen bereits im Zielcluster vorhanden ist, und nur die abweichenden Zellen kopiert werden. Bei spärlichen, leicht unterschiedlichen Datensätzen würde dies dazu führen, dass viel weniger Daten zwischen den beiden Clustern kopiert werden. Es würde auch erfordern, dass nur eine kleine Anzahl von Zellen in der Quelle gescannt wird, um auf Nichtübereinstimmungen zu prüfen.
Erforderliche Parameter
HashTable erfordert nur zwei Parameter:den Tabellennamen und den Ausgabepfad, in den zugehörige Hashes und andere Meta-Info-Dateien geschrieben werden. SyncTable verwendet HashTable Ausgabeverzeichnis als Eingabe, zusammen mit den Tabellennamen im Quell- bzw. im Zielcluster. Da wir HashTable verwenden /SyncTable um Daten zwischen entfernten Clustern zu verschieben, sourcezkcluster Option muss für SyncTable definiert werden . Dies sollte die Zookeeper-Quorumadresse des Quellclusters sein. In diesem Artikelbeispiel hatten wir auch direkt auf die aktive Namenode-Adresse des Quellclusters verwiesen, sodass SyncTable liest die Hash-Ausgabedatei direkt aus dem Quellcluster. Alternativ HashTable Die Ausgabe kann manuell vom Quell-Cluster zum Remote-Cluster kopiert werden (z. B. mit distcp).
| HINWEIS:Das Arbeiten mit Remote-Clustern unter verschiedenen Kerberos-Realms wird erst ab CDH 6.2.1 unterstützt. |
Erweiterte Optionen
Sowohl HashTable und SyncTable bieten zusätzliche optionale Optionen, die für optimale Ergebnisse abgestimmt werden können.
HashTable ermöglicht das Filtern der Daten sowohl nach Zeilenschlüssel als auch nach Änderungszeit mit startrow/starttime, stoprow/stoptime Eigenschaften bzw. Der Datensatzbereich kann auch durch Versionen eingeschränkt werden und Familien Eigenschaften. Die Batchgröße -Eigenschaft definiert die Größe jedes Teils, der gehasht wird. Dies wirkt sich direkt auf die Synchronisierungsleistung aus. In Fällen von sehr wenigen Diskrepanzen kann das Festlegen größerer Stapelgrößenwerte zu einer besseren Leistung führen, da größere Teile des Datensatzes ignoriert würden, ohne dass er von SyncTable. gescannt werden müsste
SyncTable bietet einen Probelauf Option, die eine Vorschau der Änderungen ermöglicht, die im Ziel angewendet werden sollen.
SyncTable Das Standardverhalten besteht darin, die Quelldaten auf der Zielseite zu spiegeln, sodass jede zusätzliche Zelle, die im Ziel vorhanden ist, aber in der Quelle fehlt, auf der Zielseite gelöscht wird. Dies kann beim Synchronisieren von Clustern unter einer Active-Active-Replikationskonfiguration unerwünscht sein, und in solchen Fällen doDeletes Die Optionen können auf false gesetzt werden, wodurch die Replikation von Löschungen auf dem Ziel übersprungen wird. Es gibt auch ein ähnliches doPuts Flag für Fälle, in denen keine zusätzlichen Zellen in den Zielcluster eingefügt werden sollen.
Analyse der Ergebnisse
HashTable gibt einige Dateien mit Metainformationen für SyncTable, aus diese sind jedoch nicht für Menschen lesbar. Es führt keine Änderungen an vorhandenen Daten durch, sodass zugehörige Informationen für einen Benutzerkontext von geringem Interesse sind.
SyncTable ist der Schritt, der die Änderungen wirklich auf das Ziel anwendet, und es kann wichtig sein, seine Zusammenfassung zu überprüfen, bevor Sie die Zielclusterdaten tatsächlich ändern (siehe Dryrun oben genannte Möglichkeit). Es veröffentlicht einige relevante Zähler am Ende der Karte, um die Ausführung zu reduzieren. Wenn wir uns die Werte aus dem obigen Beispiel ansehen, können wir sehen, dass es 97148 waren Partitionen gehasht (gemeldet von BATCHES Zähler), die SyncTable entdeckte Abweichungen in nur zwei von ihnen (gemäß HASHES_MATCHED und HASHES_NOT_MACTHED Zähler). Außerdem gibt es innerhalb der beiden Partitionen mit unterschiedlichen Hashes 17 Zellen über 2 Zeilen übereinstimmen (wie von MATCHING_CELLS gemeldet). und MATCHING_ROWS, bzw.), aber es gab auch 2 Zeilen divergierend, auf diesen beiden Partitionen (gemäß RANGESNOTMATCHED und ROWSWITHDIFFS ). Schließlich SOURCEMISSINGCELLS und TARGETMISSINGCELLS Teilen Sie uns im Detail mit, ob Zellen nur im Quell- oder Zielcluster vorhanden waren. In diesem Beispiel hatte der Quellcluster eine Zelle, die sich nicht auf dem Ziel befand, aber das Ziel hatte auch eine Zelle, die sich nicht auf der Quelle befand. Seit SyncTable wurde ohne Angabe von dryrun ausgeführt Option und Einstellung doDeletes Option auf false , Der Job hat die zusätzliche Zelle im Zielcluster gelöscht und die in der Quelle gefundene zusätzliche Zelle zum Zielcluster hinzugefügt. Angenommen keine Schreibvorgänge auf beiden Clustern passieren, eine nachfolgende Ausführung derselben SyncTable Befehl im Zielcluster würde keine Unterschiede zeigen:
hbase org.apache.hadoop.hbase.mapreduce.SyncTable --sourcezkcluster=zk1.example.com,zk2.example.com,zk3.example.com:2181:/hbase hdfs://nn:9000/hashes/test-tbl test-tbl test-tbl … org.apache.hadoop.hbase.mapreduce.SyncTable$SyncMapper$Counter BATCHES=97148 HASHES_MATCHED=97148 …
Anwendbare Szenarien
Datensynchronisierung
Auf den ersten Blick HashTable/SyncTable scheint sich mit der CopyTable zu überschneiden Tool, aber es gibt immer noch bestimmte Szenarien, in denen beide Tools besser geeignet wären. Als erstes Vergleichsbeispiel die Verwendung von HashTable/SyncTable für einen anfänglichen Ladevorgang einer Tabelle mit 100.004 Zeilen und einer Gesamtdatengröße von 5,17 GB allein für SyncTable einige Minuten benötigt zu vervollständigen:
... 20/04/29 03:48:00 INFO mapreduce.Job: Running job: job_1587985272792_0011 20/04/29 03:48:09 INFO mapreduce.Job: Job job_1587985272792_0011 running in uber mode : false 20/04/29 03:48:09 INFO mapreduce.Job: map 0% reduce 0% 20/04/29 03:54:08 INFO mapreduce.Job: map 100% reduce 0% 20/04/29 03:54:09 INFO mapreduce.Job: Job job_1587985272792_0011 completed successfully … org.apache.hadoop.hbase.mapreduce.SyncTable$SyncMapper$Counter BATCHES=97148 EMPTY_BATCHES=97148 HASHES_NOT_MATCHED=97148 RANGESNOTMATCHED=97148 ROWSWITHDIFFS=100004 TARGETMISSINGCELLS=749589 TARGETMISSINGROWS=100004
Selbst bei einem so kleinen Datensatz, CopyTable schneller ausgeführt (ungefähr 3 Minuten, während SyncTable dauerte 6 Minuten, um den gesamten Datensatz zu kopieren):
... 20/04/29 05:12:07 INFO mapreduce.Job: Running job: job_1587986840019_0005 20/04/29 05:12:24 INFO mapreduce.Job: Job job_1587986840019_0005 running in uber mode : false 20/04/29 05:12:24 INFO mapreduce.Job: map 0% reduce 0% 20/04/29 05:13:16 INFO mapreduce.Job: map 25% reduce 0% 20/04/29 05:13:49 INFO mapreduce.Job: map 50% reduce 0% 20/04/29 05:14:37 INFO mapreduce.Job: map 75% reduce 0% 20/04/29 05:15:14 INFO mapreduce.Job: map 100% reduce 0% 20/04/29 05:15:14 INFO mapreduce.Job: Job job_1587986840019_0005 completed successfully … HBase Counters BYTES_IN_REMOTE_RESULTS=2787236791 BYTES_IN_RESULTS=5549784428 MILLIS_BETWEEN_NEXTS=130808 NOT_SERVING_REGION_EXCEPTION=0 NUM_SCANNER_RESTARTS=0 NUM_SCAN_RESULTS_STALE=0 REGIONS_SCANNED=4 REMOTE_RPC_CALLS=1334 REMOTE_RPC_RETRIES=0 ROWS_FILTERED=0 ROWS_SCANNED=100004 RPC_CALLS=2657 RPC_RETRIES=0
Lassen Sie uns nun beide Tools erneut verwenden, um mit spärlichen Unterschieden im Datensatz umzugehen. Das test-tbl Tabelle, die in all diesen Beispielen verwendet wird, hat vier Regionen im Quellcluster. Nachdem im vorherigen Beispiel der gesamte ursprüngliche Datensatz in den Zielcluster kopiert worden war, fügten wir vier zusätzliche Zeilen nur auf der Quellseite hinzu, eine für jede der vorhandenen Regionen, und führten dann HashTable/SyncTable aus erneut zum Synchronisieren beide Cluster:
20/04/29 05:29:23 INFO mapreduce.Job: Running job: job_1587985272792_0013 20/04/29 05:29:39 INFO mapreduce.Job: Job job_1587985272792_0013 running in uber mode : false 20/04/29 05:29:39 INFO mapreduce.Job: map 0% reduce 0% 20/04/29 05:29:53 INFO mapreduce.Job: map 50% reduce 0% 20/04/29 05:30:42 INFO mapreduce.Job: map 100% reduce 0% 20/04/29 05:30:42 INFO mapreduce.Job: Job job_1587985272792_0013 completed successfully … org.apache.hadoop.hbase.mapreduce.SyncTable$SyncMapper$Counter BATCHES=97148 HASHES_MATCHED=97144 HASHES_NOT_MATCHED=4 MATCHINGCELLS=42 MATCHINGROWS=5 RANGESNOTMATCHED=4 ROWSWITHDIFFS=4 TARGETMISSINGCELLS=4 TARGETMISSINGROWS=4
Wir können das mit nur vier sehen Partitionen stimmen nicht überein, SyncTable war erheblich schneller (etwa eine Minute bis zur Fertigstellung). Verwenden von CopyTable um dieselbe Synchronisierung durchzuführen zeigte die folgenden Ergebnisse:
20/04/29 08:32:38 INFO mapreduce.Job: Running job: job_1587986840019_0008 20/04/29 08:32:52 INFO mapreduce.Job: Job job_1587986840019_0008 running in uber mode : false 20/04/29 08:32:52 INFO mapreduce.Job: map 0% reduce 0% 20/04/29 08:33:38 INFO mapreduce.Job: map 25% reduce 0% 20/04/29 08:34:15 INFO mapreduce.Job: map 50% reduce 0% 20/04/29 08:34:48 INFO mapreduce.Job: map 75% reduce 0% 20/04/29 08:35:31 INFO mapreduce.Job: map 100% reduce 0% 20/04/29 08:35:32 INFO mapreduce.Job: Job job_1587986840019_0008 completed successfully … HBase Counters BYTES_IN_REMOTE_RESULTS=2762547723 BYTES_IN_RESULTS=5549784600 MILLIS_BETWEEN_NEXTS=340672 NOT_SERVING_REGION_EXCEPTION=0 NUM_SCANNER_RESTARTS=0 NUM_SCAN_RESULTS_STALE=0 REGIONS_SCANNED=4 REMOTE_RPC_CALLS=1323 REMOTE_RPC_RETRIES=0 ROWS_FILTERED=0 ROWS_SCANNED=100008 RPC_CALLS=2657 RPC_RETRIES=0
CopyTable Das Synchronisieren der Tabellen dauerte genauso lange wie das Kopieren des gesamten Datensatzes, obwohl es nur vier waren Zellen zu kopieren. Dies war für diesen sehr kleinen Datensatz und mit einem inaktiven Cluster immer noch in Ordnung, aber unter Produktionsanwendungsfällen mit größeren Datensätzen und wo der Zielcluster möglicherweise auch von vielen Clientanwendungen verwendet wird, die Daten darauf schreiben, CopyTable Leistungsabfall im Vergleich zu SyncTable wäre sogar noch höher.
Erwähnenswert ist, dass es auch zusätzliche Tools/Funktionen gibt, die in Kombination für ein anfängliches Laden eines Zielclusters verwendet werden könnten (das Ziel hat überhaupt keine Daten), wie z. B. Snapshot-Export, Massenladen oder sogar eine direkte Kopie des Originals Tabellenverzeichnisse aus dem Quellcluster. Erstellen Sie für anfängliche Ladevorgänge mit großen zu kopierenden Datenmengen einen Tabellen-Snapshot und verwenden Sie dann den ExportSnapshot Tool wird Online-Kopiertools wie SyncTable übertreffen oder CopyTable.
Überprüfen der Replikationsintegrität
Eine weitere häufige Verwendung von HashTable/SyncTable ist die Überwachung des Replikationsstatus zwischen Clustern bei der Fehlerbehebung möglicher Replikationsprobleme. In diesem Szenario fungiert es als Alternative zum VerifyReplication-Tool. Wenn der Status zwischen zwei Clustern überprüft wird, gibt es in der Regel entweder überhaupt keine Diskrepanzen oder ein vorübergehendes Problem hat dazu geführt, dass ein kleiner Teil des größeren Datensatzes nicht mehr synchron ist. In der Testumgebung, die wir für unser vorheriges Beispiel verwendet haben, sollten 100.008 Zeilen mit übereinstimmenden Werten in beiden Clustern vorhanden sein. Durch Ausführen von SyncTable auf dem Zielcluster mit der Dryrun-Option können wir alle Unterschiede identifizieren:
20/05/04 10:47:25 INFO mapreduce.Job: Running job: job_1588611199158_0004 … 20/05/04 10:48:48 INFO mapreduce.Job: map 100% reduce 0% 20/05/04 10:48:48 INFO mapreduce.Job: Job job_1588611199158_0004 completed successfully … HBase Counters BYTES_IN_REMOTE_RESULTS=3753476784 BYTES_IN_RESULTS=5549784600 ROWS_SCANNED=100008 … org.apache.hadoop.hbase.mapreduce.SyncTable$SyncMapper$Counter BATCHES=97148 HASHES_MATCHED=97148 ... Unlike SyncTable we must run the VerifyReplication tool on the source cluster. We pass the peer id as one of its parameters so that it can find the remote cluster to scan for comparison: 20/05/04 11:01:58 INFO mapreduce.Job: Running job: job_1588611196128_0001 … 20/05/04 11:04:39 INFO mapreduce.Job: map 100% reduce 0% 20/05/04 11:04:39 INFO mapreduce.Job: Job job_1588611196128_0001 completed successfully … HBase Counters BYTES_IN_REMOTE_RESULTS=2761955495 BYTES_IN_RESULTS=5549784600 … org.apache.hadoop.hbase.mapreduce.replication.VerifyReplication$Verifier$Counters GOODROWS=100008 ...
Ohne Unterschiede findet SyncTable alle Hashes, die zwischen Quell- und Zielpartitionen übereinstimmen, und vermeidet somit die Notwendigkeit, den Remote-Quellcluster erneut zu scannen. VerifyReplication führt einen Eins-zu-eins-Vergleich für jede Zelle in beiden Clustern durch, was selbst bei so kleinen Datensätzen bereits hohe Netzwerkkosten verursachen kann.
Hinzufügen einer zusätzlichen Zeile im Quellcluster und erneutes Durchführen der Überprüfungen. Mit VerifyReplication:
20/05/05 11:14:05 INFO mapreduce.Job: Running job: job_1588611196128_0004 … 20/05/05 11:16:32 INFO mapreduce.Job: map 100% reduce 0% 20/05/05 11:16:32 INFO mapreduce.Job: Job job_1588611196128_0004 completed successfully … org.apache.hadoop.hbase.mapreduce.replication.VerifyReplication$Verifier$Counters BADROWS=1 GOODROWS=100008 ONLY_IN_SOURCE_TABLE_ROWS=1 …
Bevor wir SyncTable verwenden können, müssen wir erneut Hashes auf der Quelle mit HashTable generieren, da es jetzt eine neue Zelle gibt:
20/05/04 11:31:48 INFO mapreduce.Job: Running job: job_1588611196128_0003 … 20/05/04 11:33:15 INFO mapreduce.Job: Job job_1588611196128_0003 completed successfully ...
Jetzt SyncTable:
20/05/07 05:47:51 INFO mapreduce.Job: Running job: job_1588611199158_0014 … 20/05/07 05:49:20 INFO mapreduce.Job: Job job_1588611199158_0014 completed successfully … org.apache.hadoop.hbase.mapreduce.SyncTable$SyncMapper$Counter BATCHES=97148 HASHES_NOT_MATCHED=97148 MATCHINGCELLS=749593 MATCHINGROWS=100008 RANGESMATCHED=97147 RANGESNOTMATCHED=1 ROWSWITHDIFFS=1 TARGETMISSINGCELLS=1 TARGETMISSINGROWS=1
Wir können die Verlängerung der Ausführungszeit aufgrund des zusätzlichen Scans und Zellvergleichs zwischen den beiden Remote-Clustern erkennen. In der Zwischenzeit zeigte die Ausführungszeit von VerifyReplication nur geringe Schwankungen.
Schlussfolgerung
HashTable/SyncTable ist ein wertvolles Werkzeug zum Verschieben von Daten, wenn es um spärliche Diskrepanzen zwischen zwei Cluster-Datensätzen geht. Es nutzt Datenpartitionierung und Hashing, um Unterschiede in Bereichen aus den beiden Datensätzen effizient zu erkennen, die Anzahl der zu scannenden Zellen zu reduzieren, während Daten aus den beiden Clustern verglichen werden, während auch unnötige Eingaben bereits vorhandener Werte im Zielcluster vermieden werden. Es ist jedoch keine Wunderwaffe, wie einige der obigen Beispiele zeigen, obwohl es scheint, dass es sich in der Funktion mit der CopyTable überschneidet Tool kann letzteres eine bessere Leistung bieten, wenn ein größerer, sequentieller Bereich von nicht übereinstimmenden Zellen verarbeitet wird. In diesem Sinne HashTable/SyncTable wäre am besten in Fällen anwendbar, in denen beide Cluster bereits einige Daten gespeichert haben, oder in Fällen, in denen eine vorhandene Replikationskonfiguration durch vorübergehende Nichtverfügbarkeit eines der Peers unterbrochen wurde.
Verwandte Artikel:
https://blog.cloudera.com/apache-hbase-replication-overview/
https://blog.cloudera.com/approaches-to-backup-and-disaster-recovery-in-hbase/
https://blog.cloudera.com/online-apache-hbase-backups-with-copytable/
https://blog.cloudera.com/introduction-to-apache-hbase-snapshots/
