Toto je druhý příspěvek na blogu o replikaci Apache HBase. Předchozí blogový příspěvek HBase Replication Overview pojednával o případech použití, architektuře a různých režimech podporovaných replikací HBase. Tento blogový příspěvek je z provozního hlediska a dotkne se konfigurace replikace HBase a klíčových konceptů pro její použití – jako je bootstrapping, změna schématu a odolnost proti chybám.
Konfigurace
Jak je uvedeno v HBase Replication Overview, hlavní cluster odesílá zásilku WALEdits do jednoho nebo více podřízených clusterů. Tato část popisuje kroky potřebné ke konfiguraci replikace v režimu master-slave.
- Všechny tabulky/rodiny sloupců, které mají být replikovány, musí existovat v obou clusterech.
- Přidejte následující vlastnost do $HBASE_HOME/conf/hbase-site.xml na všechny uzly v obou clusterech; nastavte to na true.
hbase.replication
pravda
Na hlavním clusteru proveďte následující dodatečné změny:
- Nastavte rozsah replikace (REPLICATION_SCOPE atribut) v rodině tabulky/sloupce, která má být replikována:
hbase shell> zakázat ‘tabulku’
hbase shell> alter 'table', {NAME => 'column-family', REPLICATION_SCOPE => 1}
hbase shell> povolit ‘tabulku’
REPLICATION_SCOPE je atribut na úrovni skupiny sloupců a jeho hodnota může být 0 nebo 1. Hodnota 0 znamená, že replikace je zakázána, a 1 znamená, že replikace je povolena. Uživatel musí změnit každou rodinu sloupců pomocí příkazu alter, jak je uvedeno výše, pro všechny rodiny sloupců, které chce replikovat.
Pokud chce uživatel při vytváření tabulky povolit replikaci, měl by použít následující příkaz:
hbase shell> create 'table', 'column-family1', ''column-family2', {NAME => 'column-family1', REPLICATION_SCOPE => 1}
Výše uvedený příkaz povolí replikaci ve sloupci „column-family1“ výše uvedené tabulky.
2. Do prostředí hbase přidejte slave peer. Uživatel by měl poskytnout kvorum zookeeper podřízeného clusteru, jeho klientský port a kořenový hbase znode spolu s peerId:
hbase shell>add_peer ‘peerId’, „::“
PeerId je jeden nebo dva znaky dlouhý řetězec a odpovídající uzel se vytvoří pod uzlem peers, jak bylo vysvětleno v předchozím blogu. Jakmile uživatel spustí příkaz add_peer, kód replikace vytvoří pro tohoto peer objekt ReplicationSource a všechny regionové servery hlavního klastru se pokusí připojit k regionserverům podřízeného klastru. Načte také ClusterId (UUID, registrované v kvoru správců zoo) podřízeného clusteru. Regionserver hlavního klastru uvádí dostupné regionální servery podřízeného přečtením „/hbase/rs“ znode a jeho potomků v kvoru správců zoo podřízeného klastru a vytvoří k němu připojení. Každý regionserver na hlavním klastru vybere podmnožinu z podřízených regionserverů v závislosti na poměru určeném „replication.source.ratio“, s výchozí hodnotou 0,1. To znamená, že každý regionový server hlavního clusteru se pokusí připojit k 10 % z celkového počtu regionových serverů podřízeného clusteru. Při odesílání transakční dávky vybere hlavní klastr regionserver náhodný regionserver z těchto připojených regionserverů. (Poznámka:Replikace se neprovádí pro katalogové tabulky, .META. a _ROOT_.)
Chcete-li nastavit režim master-master, výše uvedené kroky by měly být opakovány na obou clusterech.
Změna schématu
Jak bylo zmíněno v předchozí části, replikovaná rodina tabulek a sloupců musí existovat v obou klastrech. Tato část popisuje různé možné scénáře toho, co se stane během změny schématu, když replikace stále probíhá:
a) Odstraňte rodinu sloupců v hlavní:Odstranění rodiny sloupců neovlivní replikaci žádných čekajících mutací pro tuto rodinu. Důvodem je, že kód replikace čte WAL a kontroluje rozsah replikace rodin sloupců pro každý WALEdit. Každý WALEdit má mapu rodin sloupců s povolenou replikací; kontrola se provádí u všech skupin sloupců tvořících klíčové hodnoty (bez ohledu na to, zda jsou či nejsou v rozsahu). Pokud je na mapě přítomen, je přidán do zásilky. Protože objekt WALEdit byl vytvořen před odstraněním rodiny sloupců, jeho replikace nebude ovlivněna.
b) Odstraňte rodinu sloupců v podřízeném:WALEdits jsou odeslány z hlavního clusteru na konkrétní podřízený regionserver, který je zpracovává jako normální klient HBase (pomocí objektu HTablePool). Vzhledem k tomu, že je odstraněna rodina sloupců, operace put selže a tato výjimka je vyvolána do hlavního clusteru regionserver.
Spustit/zastavit replikaci
Příkazy Start/Stop fungují jako vypínač. Když je příkaz stop_replication spuštěn v prostředí HBase, změní se hodnota /hbase/replication/state na false. Zastaví všechny zdrojové objekty replikace ve čtení protokolů; ale existující přečtené položky budou odeslány. Pokud uživatel použije příkaz zastavení replikace, nebudou nově srolované protokoly zařazeny do fronty pro replikaci. Podobně, zadání příkazu start_replication spustí replikaci z aktuální WAL (která může obsahovat některé předchozí transakce), a nikoli z doby, kdy byl příkaz vydán.
Obrázek 1 vysvětluje chování spínače start-stop, kde sled událostí plyne ve směru šipek.
Kompatibilita verzí
Regionální servery hlavního klastru se připojují k regionovým serverům slave clusteru jako normální klienti HBase. Stejné pravidlo kompatibility platí pro to, zda je klient HBase ve verzi xxx podporován na serveru HBase ve verzi yyy.
Na jiném místě, protože replikace se stále vyvíjí (neustále se k ní přidává stále více funkcí), uživatel by si měl být vědom stávajících funkcí. Například v CDH4, který je založen na větvi HBase 0.92, existuje podpora pro master-master a cyklickou replikaci. Do větve HBase 0.94 je přidáno povolení/zakázaní zdroje replikace na úrovni peer.
Zavádění popruhů
Replikace funguje tak, že čte WAL regionálních serverů hlavního clusteru. Pokud chce uživatel replikovat stará data, může spustit příkaz copyTable (definující počáteční a koncové časové razítko) a zároveň povolit replikaci. Příkaz copyTable zkopíruje data v rozsahu počátečních/koncových časových razítek a replikace se postará o aktuální data. Celkový přístup lze shrnout takto:
- Spusťte replikaci (poznamenejte si časové razítko).
- Spusťte příkaz copyTable s koncovým časovým razítkem rovným výše uvedenému časovému razítku.
- Vzhledem k tomu, že replikace začíná z aktuální WAL, mohou existovat některé klíčové hodnoty, které jsou zkopírovány do slave pomocí úloh replikace i copyTable. To je stále v pořádku, protože jde o idempotentní operaci.
V případě replikace master-master by se měla před zahájením replikace spustit úloha copyTable. Je to proto, že pokud uživatel spustí úlohu copyTable po povolení replikace, druhý hlavní server znovu odešle data prvnímu hlavnímu serveru, protože copyTable neupravuje clusterId v objektech mutace. Celkový přístup lze shrnout takto:
- Spusťte úlohu copyTable (poznamenejte si časové razítko zahájení úlohy).
- Spusťte replikaci.
- Spusťte copyTable znovu s časem zahájení rovným času zahájení uvedenému v kroku 1.
To také znamená, že se některá data posouvají tam a zpět mezi dva shluky; ale minimalizuje jeho velikost.
Tolerance chyb
Selhání serveru hlavní clusterové oblasti
Všechny regionservery v hlavním clusteru vytvoří znode pod „/hbase/replication/rs“, jak je uvedeno v části Architektura. Regionserver přidá podřízený uzel pro každý WAL s bajtovým posunem pod jeho uzlem v hierarchii replikace, jak je znázorněno na obrázku 1. Pokud regionserver selže, ostatní regionservery se musí postarat o protokoly mrtvého regionserveru, které jsou uvedeny pod tímto regionserver's znode. Všechny regionservery sledují ostatní uzly regionserver („/hbase/rs“) uzly; takže když regionserver selže, ostatní regionservery získají událost jako master označí tento regionserver jako mrtvý. V tomto případě se všechny ostatní regionservery snaží přenést WAL z mrtvého uzlu regionserveru do svého uzlu a připojit k němu předponu s slave id a mrtvým jménem regionserveru, aby se odlišily od ostatních normálních protokolů. Pro přenesené protokoly je vytvořen samostatný zdroj replikace (instance NodeFailoverWorker), který po zpracování těchto přenesených protokolů zanikne.
Pokud vezmeme v úvahu Obrázek 1 Přehledu replikace HBase jako základní obrázek hierarchie uzlů replikace, Obrázek 2 ukazuje novou hierarchii uzlů replikace v případě, že server foo1.bar.com zemře a foo2.bar.com převezme jeho frontu. Všimněte si nového znode „1-foo1.bar.com,40020,1339435481973“, který je vytvořen pod znode foo2.bar.com
/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.133944354857239:/plication .bar.com,40020,1339435481742:/hbase/replication/rs/foo3.bar.com,40020,1339435481742/1:/hbase/replication/rs/foo3.bar.com,40020, 138174235/bar. ..com.1339435485769:1243232 /hbase/replication/rs/foo2.bar.com,40020,1339435089550:/hbase/replication/rs/foo2.bar.com,40020,1339435181 /739435181 / foo2.bar.com,40020, 1339435481742/1/foo2.bar..com.13394354343443:1909033 /hbase/replication/rs/foo2.bar.com,40020,13394254817,40020,13394354817 /foo1.bar.com.1339435485769:1243232
Obrázek 2. Hierarchie uzlů převzetí služeb při selhání Regionserver
Mezitím se může spustit dělení protokolu a může archivovat protokoly serveru mrtvých regionů. Zdroj replikace hledá protokoly v běžném i archivovaném adresáři.
Pomalý/nereagující podřízený cluster (nebo regionální servery)
Když je podřízený cluster mimo provoz nebo existuje dočasný síťový oddíl, protokoly, které ještě nejsou replikovány do podřízeného clusteru, nebudou čističem protokolů HBase odstraněny.
Čištění protokolů je řešeno třídou LogCleaner, která běží po nastavené době. Replikační kód přidává plugin ReplicationLogCleaner do třídy LogCleaner. Když se druhý pokusí odstranit konkrétní protokol, ReplicationLogCleaner se podívá, zda tento protokol existuje v hierarchii uzlu replikace (v /hbase/replication/rs/znode). Pokud je protokol nalezen, znamená to, že protokol ještě není replikován a jeho vymazání se přeskočí. Jakmile je protokol replikován, jeho uzel bude odstraněn z hierarchie replikace. Při příštím spuštění LogCleaner úspěšně odstraní soubor protokolu, jakmile bude replikován.
Ověření
Pro menší množství dat lze jednoduše vyhledat řádky tabulky pomocí prostředí hbase v podřízeném clusteru a ověřit, zda jsou replikovány nebo ne. Standardním způsobem ověření je spuštění úlohy authenticrep mapreduce, která je součástí HBase. Měl by být spuštěn na hlavním klastru a vyžadovat podřízené clusterId a název cílové tabulky. Lze také poskytnout další argumenty, jako je časová značka začátku/zastavení a rodiny sloupců. Vytiskne dvě počítadla, jmenovitě, GOODROWS a BADROWS, označující počet replikovaných a nereplikovaných řádků.
Metriky replikace
Replikační rámec odkrývá některé užitečné metriky, které lze použít ke kontrole průběhu replikace. Některé z důležitých jsou:
- sizeOfLogQueue:počet HLogů ke zpracování (nezahrnuje ten, který se zpracovává) ve zdroji replikace
- shippedOpsRate:míra dodaných mutací
- logEditsReadRate:míra přečtení mutací z HLogs ve zdroji replikace
- ageOfLastShippedOp:stáří poslední dávky, která byla odeslána ze zdroje replikace
Budoucí práce
Se všemi aktuálními funkcemi přítomnými v aktuální replikaci HBase stále existuje prostor pro další vylepšení. Liší se od výkonu, jako je zkrácení časového zpoždění replikace mezi master a slave, až po robustnější řešení selhání regionálního serveru (HBase-2611). Mezi další oblasti vylepšení patří umožnění replikace tabulek na stejné úrovni a správné zacházení s IncrementColumnValue (HBase-2804).
Závěr
Tento příspěvek pojednává o replikaci HBase z pohledu operátora včetně konfigurace (různých režimů), bootstrapingu existujícího clusteru, efektů změn schématu a odolnosti proti chybám.