Apache HBase Replication è un modo per copiare i dati da un cluster HBase a un cluster HBase diverso e possibilmente distante. Funziona in base al principio che le transazioni dal cluster di origine vengono inviate a un altro cluster. Nel gergo HBase, il cluster che esegue il push è chiamato master e quello che riceve le transazioni è chiamato slave. Questo push delle transazioni viene eseguito in modo asincrono e queste transazioni vengono raggruppate in una dimensione configurabile (l'impostazione predefinita è 64 MB). La modalità asincrona comporta un sovraccarico minimo sul master e la spedizione delle modifiche in un batch aumenta il throughput complessivo.
Questo post sul blog discute i possibili casi d'uso, l'architettura sottostante e le modalità di replica HBase supportate in CDH4 (che è basato su 0.92). Discuteremo la configurazione della replica, il bootstrap e la tolleranza agli errori in un post del blog di follow-up.
Usa casi
La replica HBase supporta la replica dei dati tra i data center. Questo può essere utilizzato per scenari di ripristino di emergenza, in cui possiamo fare in modo che il cluster slave serva il traffico in tempo reale nel caso in cui il sito master sia inattivo. Poiché la replica HBase non è concepita per il failover automatico, l'atto di passare dal cluster master al cluster slave per iniziare a servire il traffico viene eseguito dall'utente. Successivamente, una volta che il cluster master è di nuovo attivo, è possibile eseguire un lavoro CopyTable per copiare i delta nel cluster master (fornendo i timestamp di inizio/fine) come descritto nel post del blog di CopyTable.
Un altro caso d'uso della replica è quando un utente desidera eseguire lavori MapReduce a carico intensivo sul proprio cluster HBase; si può farlo sul cluster slave mentre subisce una leggera diminuzione delle prestazioni sul cluster master.
Architettura
Il principio alla base della replica HBase è di riprodurre tutte le transazioni dal master allo slave. Questo viene fatto riproducendo i WALEdits (voci del registro Write Ahead) nei WAL (Write Ahead Log) dal cluster master, come descritto nella sezione successiva. Questi WALEdits vengono inviati ai server della regione del cluster slave, dopo il filtraggio (indipendentemente dal fatto che una modifica specifica sia nell'ambito della replica o meno) e la spedizione in una dimensione batch personalizzata (l'impostazione predefinita è 64 MB). Nel caso in cui il lettore WAL raggiunga la fine del WAL corrente, spedirà tutti i WALEdits letti fino a quel momento. Poiché si tratta di una modalità di replica asincrona, il cluster slave potrebbe rimanere indietro rispetto al master in un'applicazione pesante in scrittura dell'ordine di minuti.
WAL/WALEdits/Memstore
In HBase, tutte le operazioni di mutazione (Puts/Deletes) vengono scritte in un memstore che appartiene a una regione specifica e anche aggiunte a un file di registro write ahead (WAL) sotto forma di WALEdit. Un WALEdit è un oggetto che rappresenta una transazione e può avere più di un'operazione di mutazione. Poiché HBase supporta una singola transazione a livello di riga, un WALEdit può avere voci per una sola riga. I WAL vengono ripetuti ripetutamente dopo un periodo di tempo configurato (l'impostazione predefinita è 60 minuti) in modo tale che in un dato momento vi sia un solo WAL attivo per regionserver.
Anche IncrementColumnValue, un'operazione CAS (check and replacement), viene convertita in un Put quando viene scritta nel WAL.
Un memstore è una mappa ordinata in memoria contenente i valori chiave della regione di composizione; c'è un memstore per ogni famiglia di colonne per regione. Il memstore viene scaricato sul disco come file H una volta raggiunta la dimensione configurata (l'impostazione predefinita è 64 MB).
La scrittura in WAL è facoltativa, ma è necessaria per evitare la perdita di dati perché in caso di arresto anomalo di un regionserver, HBase potrebbe perdere tutti i memstore ospitati sul server della regione. In caso di errore del regionserver, i suoi WAL vengono riprodotti da un processo di suddivisione del registro per ripristinare i dati archiviati nei WAL.
Affinché la replica funzioni, è necessario abilitare la scrittura su WAL.
ID cluster
Ogni cluster HBase ha un clusterID, un tipo UUID generato automaticamente da HBase. Viene mantenuto nel filesystem sottostante (di solito HDFS) in modo che non cambi tra i riavvii. Questo è memorizzato all'interno dello znode /hbase/hbaseid. Questo ID viene utilizzato per ottenere la replica master-master/aciclica. Un WAL contiene voci per un certo numero di regioni che sono ospitate sul regionserver. Il codice di replica legge tutti i valori chiave e filtra i valori chiave con ambito per la replica. Lo fa esaminando l'attributo della famiglia di colonne del valore chiave e abbinandolo alla struttura dei dati della mappa della famiglia di colonne di WALEdit. Nel caso in cui un valore chiave specifico sia nell'ambito della replica, modifica il parametro clusterId del valore chiave nell'ID cluster HBase.
Fonte di replica
ReplicationSource è un oggetto Thread java nel processo regionserver ed è responsabile della replica delle voci WAL in un cluster slave specifico. Ha una coda di priorità che contiene i file di registro che devono essere replicati. Non appena un registro viene elaborato, viene rimosso dalla coda. La coda di priorità utilizza un comparatore che confronta i file di registro in base al timestamp di creazione (che viene aggiunto al nome del file di registro); quindi, i registri vengono elaborati nello stesso ordine in cui sono stati creati (i registri più vecchi vengono elaborati per primi). Se è presente un solo file di registro nella coda di priorità, non verrà eliminato poiché rappresenta il WAL corrente.
Ruolo del guardiano dello zoo
Zookeeper svolge un ruolo chiave nella replica HBase, dove gestisce/coordina quasi tutte le principali attività di replica, come la registrazione di un cluster slave, l'avvio/arresto della replica, l'accodamento di nuovi WAL, la gestione del failover del regionserver, ecc. quorum Zookeeper (almeno 3 o più nodi) in modo da averlo sempre attivo e funzionante. Zookeeper dovrebbe essere eseguito in modo indipendente (e non da HBase). La figura seguente mostra un esempio di struttura di znode correlata alla replica nel cluster principale (il testo dopo i due punti è il dati dello znodo):
/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
Figura 1. Gerarchia degli znodi di replica
Come nella Figura 1, ci sono tre regionserver nel cluster principale, ovvero foo[1-3].bar.com. Esistono tre znode relativi alla replica:
- stato :Questo znode indica se la replica è abilitata o meno. Tutti i passaggi fondamentali (come accodare un registro appena compilato in una coda di replica, leggere un file di registro per effettuare spedizioni WALEdits, ecc.), Controllare questo valore booleano prima dell'elaborazione. Questo è impostato dall'impostazione della proprietà "hbase.replication" su true in hbase-conf.xml. Un altro modo per modificarne il valore è usare il comando "start/stop replication" nella shell di hbase. Questo sarà discusso nel secondo post del blog.
- compagni :Questo znode ha i peer/slave connessi come figli. Nella figura è presente uno slave con peerId =1 e il suo valore è la stringa di connessione (Zookeeper_quorum_of_slave:Zookeeper_client_port:root_hbase_znode), dove Zookeeper_quorum_of_slave è un elenco separato da virgole di server zookeeper. Il nome dello znode peerId è lo stesso fornito durante l'aggiunta di un peer.
- r :questo znode contiene un elenco di regionserver attivi nel cluster master. Ogni znode di regionserver ha un elenco di WAL che devono essere replicati e il valore di questi znode di registro è null (nel caso in cui il registro non sia ancora aperto per la replica) o l'offset di byte al punto in cui il registro è stato letto. Il valore di offset di byte per uno znode WAL indica l'offset di byte del file WAL corrispondente fino al quale è stato letto e replicato. Poiché può esserci più di un cluster slave e l'avanzamento della replica può variare tra di essi (uno potrebbe essere inattivo, ad esempio), tutti i WAL sono contenuti in uno znode peerId in rs. Pertanto, nella figura sopra, gli znode WAL si trovano sotto are /rs//1, dove "1" è il peerId.
Modalità di replica
Sono disponibili tre modalità per configurare la replica HBase:
- Master-Slave:in questa modalità, la replica viene eseguita in un'unica direzione, ovvero le transazioni da un cluster vengono inviate a un altro cluster. Nota che il cluster slave è come qualsiasi altro cluster e può avere le proprie tabelle, traffico, ecc.
- Master-Master:in questa modalità, la replica viene inviata in entrambe le direzioni, per tabelle diverse o uguali, ovvero entrambi i cluster agiscono sia come master che come slave. Nel caso in cui stiano replicando la stessa tabella, si potrebbe pensare che possa portare a un ciclo infinito, ma ciò viene evitato impostando il clusterId di una mutazione (Put/Delete) sul clusterId del cluster di origine. La Figura 2 lo spiega utilizzando due ammassi, ovvero il Sole e la Terra. Nella figura 2, abbiamo due blocchi che rappresentano i due cluster HBase. Hanno clusterId 100 e 200 rispettivamente. Ciascuno dei cluster ha un'istanza di ReplicationSource, corrispondente al cluster slave su cui vuole replicare; conosce i cluster #ID di entrambi i cluster.
Figura 2. Sole e Terra, due cluster HBase
Diciamo che cluster#Sun riceve una mutazione M fresca e valida su una famiglia di tabelle e colonne che ha lo scopo di replicare in entrambi i cluster. Avrà un clusterID predefinito (0L). L'istanza di origine di replica ReplicationSrc-E imposterà il proprio cluster#Id uguale all'ID origine (100) e lo spedirà al cluster#Earth. Quando il cluster#Earth riceve la mutazione, la riproduce e la mutazione viene salvata nel suo WAL, come da flusso normale. Il cluster#Id della mutazione viene mantenuto intatto in questo file di registro in cluster#Earth. L'istanza di origine della replica in cluster#Earth, (ReplicationSrc-S, leggerà la mutazione e ne verificherà il cluster#ID con slaveCluster# (100, uguale a cluster#Sun). Poiché sono uguali, salterà questa voce di WALEdit.
- Ciclico:in questa modalità, ci sono più di due cluster HBase che prendono parte alla configurazione della replica e uno può avere varie possibili combinazioni di master-slave e master-master impostate tra due cluster qualsiasi. I due precedenti coprono bene quei casi; una situazione d'angolo è quando abbiamo impostato un ciclo
Figura 3. Una replica circolare impostata
La Figura 3. mostra una configurazione di replica circolare, in cui il cluster#Sole si replica nel cluster#Earth, il cluster#Earth si replica nel cluster#Venus e il cluster#Venus si replica nel cluster#Sun.
Diciamo che cluster#Sun riceve una nuova mutazione M ed è mirato alla replicazione in tutti i cluster sopra. Verrà replicato su cluster#Earth come spiegato sopra nella replica master master. L'istanza di origine della replica in cluster#Earth, ReplicationSrc-V, leggerà il WAL, vedrà la mutazione e la replicherà in cluster#Venus. Il cluster#Id della mutazione viene mantenuto intatto (a partire dal cluster#Sole), al cluster#Venus. In questo cluster, l'istanza di origine della replica per cluster#Sun, ReplicationSrc-S, vedrà che la mutazione ha lo stesso clusterId del relativo slaveCluster# (a partire da cluster#Sun) e, pertanto, non verrà eseguita la replica.
Conclusione
Replica HBase è una potente funzionalità che può essere utilizzata in uno scenario di ripristino di emergenza. È stato aggiunto come funzionalità di anteprima nella versione 0.90 e si è evoluto insieme a HBase in generale, con l'aggiunta di funzionalità come la replica master-master, la replica aciclica (entrambe aggiunte nella 0.92) e l'abilitazione-disabilitazione della replica a livello di peer (aggiunto in 0,94).
Nel prossimo post del blog, discuteremo di varie funzionalità operative come la configurazione, ecc. e altri trucchi con HBase Replication.
