Questo è il secondo post sul blog sulla replica HBase di Apache. Il post precedente del blog, Panoramica della replica HBase, ha discusso dei casi d'uso, dell'architettura e delle diverse modalità supportate nella replica HBase. Questo post del blog è da una prospettiva operativa e toccherà la configurazione della replica HBase e i concetti chiave per utilizzarla, come il bootstrap, la modifica dello schema e la tolleranza agli errori.
Configurazione
Come menzionato in Panoramica sulla replica HBase, il cluster master invia la spedizione di WALEdits a uno o più cluster slave. Questa sezione descrive i passaggi necessari per configurare la replica in modalità master-slave.
- Tutte le tabelle/famiglie di colonne che devono essere replicate devono esistere su entrambi i cluster.
- Aggiungi la seguente proprietà in $HBASE_HOME/conf/hbase-site.xml su tutti i nodi su entrambi i cluster; impostalo su true.
hbase.replication
vero
Sul master cluster, apporta le seguenti modifiche aggiuntive:
- Imposta l'ambito di replica (REPLICATION_SCOPE attributo) sulla famiglia di tabelle/colonne da replicare:
hbase shell> disabilita "tabella"
hbase shell> alter 'table', {NAME => 'column-family', REPLICATION_SCOPE => 1}
shell hbase> abilita "tabella"
REPLICATION_SCOPE è un attributo a livello di famiglia di colonne e il suo valore può essere 0 o 1. Un valore di 0 significa che la replica è disabilitata e 1 significa che la replica è abilitata. Un utente deve modificare ogni famiglia di colonne con il comando alter come mostrato sopra, per tutte le famiglie di colonne che vuole replicare.
Se un utente desidera abilitare la replica durante la creazione di una tabella, deve utilizzare il seguente comando:
hbase shell> crea 'table', 'column-family1', ''column-family2', {NAME => 'column-family1', REPLICATION_SCOPE => 1}
Il comando sopra abiliterà la replica su 'column-family1' della tabella sopra.
2. Nella shell hbase, aggiungi il peer slave. Si suppone che un utente fornisca il quorum zookeeper del cluster slave, la sua porta client e lo znode root hbase, insieme a un peerId:
hbase shell>add_peer 'peerId', “::”
Il peerId è una stringa di uno o due caratteri e uno znode corrispondente viene creato sotto lo znode peers, come spiegato nel blog precedente. Dopo che un utente esegue il comando add_peer, il codice di replica crea un'istanza di un oggetto ReplicationSource per quel peer e tutti i server regionali del cluster master tentano di connettersi ai server regionali del cluster slave. Recupera anche ClusterId (UUID, registrato nel quorum zookeeper del cluster di slave) del cluster di slave. Il regionserver del cluster master elenca i regionserver disponibili dello slave leggendo "/hbase/rs" znode e i suoi figli nel quorum zookeeper del cluster di slave e si collega ad esso. Ogni regionserver del cluster master sceglie un sottoinsieme dai regionserver slave, a seconda del rapporto specificato da “replication.source.ratio”, con valore predefinito 0.1. Ciò significa che ogni regionserver del cluster master tenterà di connettersi al 10% del totale dei regionserver del cluster slave. Durante l'invio del batch di transazione, il server delle regioni del cluster principale selezionerà un server delle regioni casuale da questi server delle regioni collegati. (Nota:la replica non viene eseguita per le tabelle del catalogo, .META. e _ROOT_.)
Per impostare una modalità master-master, i passaggi precedenti devono essere ripetuti su entrambi i cluster.
Cambio di schema
Come accennato nella sezione precedente, la tabella replicata e la famiglia di colonne devono esistere in entrambi i cluster. Questa sezione discute vari possibili scenari su cosa succede durante una modifica dello schema quando la replica è ancora in corso:
a) Elimina la famiglia di colonne nel master:l'eliminazione di una famiglia di colonne non influirà sulla replica di eventuali mutazioni in sospeso per quella famiglia. Questo perché il codice di replica legge il WAL e controlla l'ambito di replica delle famiglie di colonne per ogni WALEdit. Ogni WALEdit ha una mappa delle famiglie di colonne abilitate alla replica; il controllo viene eseguito su tutta la famiglia di colonne del valore-chiave costituente (indipendentemente dal fatto che siano con scope o meno). Se è presente nella mappa, viene aggiunto alla spedizione. Poiché l'oggetto WALEdit viene creato prima dell'eliminazione della famiglia di colonne, la sua replica non sarà interessata.
b) Eliminare la famiglia di colonne in slave:i WALEdits vengono spediti dal cluster master a un particolare regionserver slave, che lo elabora come un normale client HBase (utilizzando un oggetto HTablePool). Poiché la famiglia di colonne viene eliminata, l'operazione put avrà esito negativo e l'eccezione verrà generata nel cluster del server delle regioni master.
Avvia/Arresta replica
I comandi Start/Stop funzionano come kill switch. Quando il comando stop_replication viene eseguito sulla shell HBase, cambierà il valore di /hbase/replication/state in false. Interromperà la lettura dei registri a tutti gli oggetti di origine della replica; ma le voci di lettura esistenti verranno spedite. Se un utente utilizza il comando di arresto della replica, i log appena raccolti non verranno messi in coda per la replica. Allo stesso modo, l'emissione di un comando start_replication avvierà la replica dal WAL corrente (che potrebbe contenere alcune transazioni precedenti) e non dal momento in cui è stato emesso il comando.
La figura 1 spiega il comportamento dell'interruttore start-stop, in cui la sequenza di eventi scorre nella direzione delle frecce.
Compatibilità delle versioni
I server regionali del cluster master si connettono ai server regionali del cluster slave come normali client HBase. La stessa regola di compatibilità si applica se un client HBase nella versione xxx è supportato su un server HBase nella versione yyy.
Su un altro punto, poiché la replica è ancora in evoluzione (ad essa vengono continuamente aggiunte sempre più funzionalità), un utente dovrebbe essere a conoscenza delle funzionalità esistenti. Ad esempio, in CDH4, che si basa sul ramo HBase 0.92, è disponibile il supporto per la replica master-master e ciclica. L'abilitazione/disabilitazione dell'origine della replica a livello di peer viene aggiunta nel ramo HBase 0.94.
Fissaggio degli stivali
La replica funziona leggendo i WAL dei server regionali del cluster master. Se un utente desidera replicare i vecchi dati, può eseguire un comando copyTable (definendo il timestamp di inizio e fine), mentre abilita la replica. Il comando copyTable copierà i dati nell'ambito dei timestamp di inizio/fine e la replica si occuperà dei dati correnti. L'approccio generale può essere riassunto come:
- Avvia la replica (nota il timestamp).
- Esegui il comando copyTable con un timestamp di fine uguale al timestamp sopra.
- Poiché la replica inizia dal WAL corrente, potrebbero esserci alcuni valori chiave che vengono copiati nello slave sia dai lavori di replica che da copyTable. Questo va ancora bene, poiché si tratta di un'operazione idempotente.
Nel caso di replica master-master, è necessario eseguire il lavoro copyTable prima di avviare la replica. Questo perché se un utente avvia un processo copyTable dopo aver abilitato la replica, il secondo master invierà nuovamente i dati al primo master, poiché copyTable non modifica il clusterId negli oggetti di mutazione. L'approccio generale può essere riassunto come:
- Esegui il lavoro copyTable, (nota il timestamp di inizio del lavoro).
- Avvia la replica.
- Esegui nuovamente copyTable con starttime uguale a starttime annotato nel passaggio 1.
Ciò comporta anche che alcuni dati vengano spinti avanti e indietro tra i due cluster; ma ne riduce al minimo le dimensioni.
Tolleranza ai guasti
Failover del server della regione del cluster master
Tutti i regionserver nel master cluster creano uno znode in "/hbase/replication/rs", come menzionato nella sezione Architettura. Un regionserver aggiunge uno znode figlio per ogni WAL, con un byte offset sotto il relativo znode nella gerarchia di replica, come mostrato nella Figura 1. Se un regionserver si guasta, gli altri regionserver devono occuparsi dei registri del regionserver morto, che sono elencati sotto quello znode di regionserver. Tutti i regionserver tengono d'occhio gli altri znode del regionserver ("/hbase/rs") znode; quindi, quando un regionserver si guasta, gli altri regionserver riceveranno l'evento come master contrassegna questo regionserver come morto. In questo caso, tutti gli altri regionserver fanno a gara per trasferire i WAL da dead regionserver znode al loro znode e allegano un prefisso con ID slave e nome del regionserver morto, in modo da distinguerli dagli altri registri normali. Viene creata un'istanza di replica separata (istanza NodeFailoverWorker) per i log trasferiti, che muore dopo l'elaborazione di questi log trasferiti.
Se si considera la Figura 1 della panoramica della replica HBase come la figura di base della gerarchia degli znodi di replica, la Figura 2 mostra la nuova gerarchia degli znodi di replica nel caso in cui il server foo1.bar.com muoia e foo2.bar.com prenda il controllo della sua coda. Nota il nuovo znode "1-foo1.bar.com,40020,1339435481973" creato in foo2.bar.com znode
/hbase/hbaseid:b53f7ec6-ed8a-4227-b088-fd6552bd6a68 …. /hbase/rs/foo2.bar.com,40020,1339435481973:/hbase/rs/foo3.bar.com,40020,1339435486713:/hbase/replica:/hbase/replica/stato:vero /hbase/replica/peers:/hbase/replica/peers/1:zk.quorum.slave:281:/hbase /hbase/replication/rs:/hbase/replication/rs/foo1.bar.com.com,40020,1339435084846:/hbase/replica/ 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 /hbase/replication/rs/foo2.bar.com,40020,1339435481742/1- foo1.bar.com,40020,133943548 /foo1.bar.com.1339435485769:1243232
Figura 2. Gerarchia degli znodi di failover di Regionserver
Nel frattempo, la suddivisione del registro potrebbe iniziare e archiviare i registri del server della regione morta. L'origine della replica cerca i log sia nella directory normale che in quella archiviata.
Cluster (o server regionali) lento/non rispondente
Quando un cluster slave è inattivo o se è presente una partizione di rete temporanea, i registri che non sono ancora stati replicati sullo slave non verranno eliminati dal pulitore dei registri HBase.
La pulizia del registro è gestita dalla classe LogCleaner, che continua a funzionare dopo un tempo configurato. Il codice di replica aggiunge il plug-in ReplicationLogCleaner alla classe LogCleaner. Quando quest'ultimo tenta di eliminare un registro specifico, ReplicationLogCleaner cercherà di vedere se quel registro esiste nella gerarchia znode di replica (sotto /hbase/replication/rs/znode). Se il registro viene trovato, significa che il registro deve ancora essere replicato e ne salterà l'eliminazione. Una volta replicato il log, il relativo znode verrà eliminato dalla gerarchia di replica. Nella sua esecuzione successiva, LogCleaner eliminerà correttamente il file di registro una volta replicato.
Verifica
Per quantità inferiori di dati, è possibile cercare semplicemente le righe della tabella utilizzando la shell hbase nel cluster slave per verificare se vengono replicate o meno. Un metodo standard per la verifica consiste nell'eseguire il lavoro di verifica di verifica mapreduce, fornito con HBase. Dovrebbe essere eseguito sul cluster master e richiedere clusterId slave e il nome della tabella di destinazione. Si possono anche fornire argomenti aggiuntivi come il timestamp di inizio/fine e le famiglie di colonne. Stampa due contatori, GOODROWS e BADROWS, che indicano rispettivamente il numero di righe replicate e non replicate.
Metriche di replica
Il framework di replica espone alcune utili metriche che possono essere utilizzate per verificare l'avanzamento della replica. Alcuni di quelli importanti sono:
- sizeOfLogQueue:numero di HLog da elaborare (escluso quello in elaborazione) all'origine della replica
- shippedOpsRate:tasso di mutazioni spedite
- logEditsReadRate:tasso di mutazioni lette da HLogs all'origine della replica
- ageOfLastShippedOp:età dell'ultimo batch spedito dall'origine della replica
Lavori futuri
Con tutte le attuali funzionalità presenti nell'attuale replica HBase, c'è ancora spazio per ulteriori miglioramenti. Varia da prestazioni come la riduzione del ritardo di replica tra master e slave, a una gestione più solida degli errori del server della regione (HBase-2611). Ulteriori aree di miglioramento includono l'abilitazione della replica delle tabelle a livello di pari e la corretta gestione di IncrementColumnValue (HBase-2804).
Conclusione
Questo post ha discusso la replica HBase dal punto di vista di un operatore, inclusa la configurazione (di varie modalità), il bootstrap di un cluster esistente, gli effetti delle modifiche allo schema e la tolleranza agli errori.
