Apache HBase Replication är ett sätt att kopiera data från ett HBase-kluster till ett annat och möjligen avlägset HBase-kluster. Det fungerar enligt principen att transaktionerna från det ursprungliga klustret skjuts till ett annat kluster. I HBase-jargong kallas klustret som gör pushen master, och den som tar emot transaktionerna kallas slav. Denna push av transaktioner görs asynkront, och dessa transaktioner grupperas i en konfigurerbar storlek (standard är 64 MB). Asynkront läge medför minimal overhead på mastern, och fraktredigeringar i en batch ökar den totala genomströmningen.
Det här blogginlägget diskuterar möjliga användningsfall, underliggande arkitektur och lägen för HBase-replikering som stöds i CDH4 (som är baserat på 0.92). Vi kommer att diskutera replikeringskonfiguration, bootstrapping och feltolerans i ett uppföljande blogginlägg.
Användningsfall
HBase-replikering stöder replikering av data över datacenter. Detta kan användas för katastrofåterställningsscenarier, där vi kan låta slavklustret betjäna trafik i realtid om huvudplatsen är nere. Eftersom HBase-replikering inte är avsedd för automatisk failover, görs handlingen att byta från master till slavklustret för att börja betjäna trafik av användaren. Efteråt, när huvudklustret är uppe igen, kan man göra ett CopyTable-jobb för att kopiera deltan till masterklustret (genom att tillhandahålla start/stopptidsstämplar) som beskrivs i CopyTable-blogginlägget.
Ett annat användningsfall för replikering är när en användare vill köra belastningsintensiva MapReduce-jobb på sitt HBase-kluster; man kan göra det på slavklustret samtidigt som det bär en liten prestandaminskning på masterklustret.
Arkitektur
Den underliggande principen för HBase-replikering är att spela upp alla transaktioner från mastern till slaven. Detta görs genom att spela om WALEdits (Write Ahead Log-poster) i WALs (Write Ahead Log) från masterklustret, som beskrivs i nästa avsnitt. Dessa WALE-redigeringar skickas till servrarna för slavklusterregionen, efter filtrering (oavsett om en specifik redigering är avsedd för replikering eller inte) och frakt i en anpassad batchstorlek (standard är 64 MB). Om WAL Reader når slutet av den nuvarande WAL, kommer den att skicka alla WALE-redigeringar som har lästs fram till dess. Eftersom detta är ett asynkront sätt för replikering, kan slavklustret släpa efter från mastern i en skrivtung applikation i storleksordningen minuter.
WAL/WALEdits/Memstore
I HBase skrivs alla mutationsoperationer (Puts/Deletes) till ett memstore som tillhör en specifik region och läggs även till en Write Ahead-loggfil (WAL) i form av en WALEdit. En WALEdit är ett objekt som representerar en transaktion och kan ha mer än en mutationsoperation. Eftersom HBase stöder en transaktion på radnivå, kan en WALEdit ha poster för endast en rad. WAL:erna rullas upprepade gånger efter en konfigurerad tidsperiod (standard är 60 minuter) så att det vid varje given tidpunkt endast finns en aktiv WAL per regionserver.
IncrementColumnValue, en CAS-operation (kontrollera och ersätt), konverteras också till en Put när den skrivs till WAL.
En memstore är en i minnet, sorterad karta som innehåller nyckelvärden för den komponerande regionen; det finns ett memstore per kolumnfamilj per region. Memstore spolas till disken som en HF-fil när den når den konfigurerade storleken (standard är 64MB).
Att skriva till WAL är valfritt, men det krävs för att undvika dataförlust eftersom om en regionserver kraschar kan HBase förlora alla memstores som finns på den regionservern. I händelse av regionserverfel, spelas dess WALs upp genom en loggdelningsprocess för att återställa data som lagrats i WALs.
För att replikering ska fungera måste skriv till WAL:er vara aktiverat.
ClusterId
Varje HBase-kluster har ett clusterID, en UUID-typ som genereras automatiskt av HBase. Det hålls i underliggande filsystem (vanligtvis HDFS) så att det inte ändras mellan omstarter. Detta lagras inuti /hbase/hbaseid-znoden. Detta id används för att uppnå master-master/acyklisk replikering. En WAL innehåller poster för ett antal regioner som finns på regionservern. Replikeringskoden läser alla nyckelvärden och filtrerar bort nyckelvärdena som är omfångade för replikering. Den gör detta genom att titta på kolumnfamiljens attribut för nyckelvärdet och matcha det med WALEdits kolumnfamiljekartadatastruktur. Om ett specifikt nyckelvärde är omfångat för replikering, redigerar det clusterId-parametern för nyckelvärdet till HBase-kluster-ID.
ReplicationSource
ReplicationSource är ett Java Thread-objekt i regionserverprocessen och ansvarar för att replikera WAL-poster till ett specifikt slavkluster. Den har en prioritetskö som innehåller loggfilerna som ska replikeras. Så snart en logg bearbetats tas den bort från kön. Prioritetskön använder en komparator som jämför loggfilerna baserat på deras skapande tidsstämpel, (som läggs till loggfilens namn); så loggar bearbetas i samma ordning som när de skapades (äldre loggar bearbetas först). Om det bara finns en loggfil i prioritetskön kommer den inte att tas bort eftersom den representerar den aktuella WAL.
Roll som djurskötare
Zookeeper spelar en nyckelroll i HBase Replication, där den hanterar/koordinerar nästan all större replikeringsaktivitet, som att registrera ett slavkluster, starta/stoppa replikering, ställa nya WAL i kö, hantera regionserver-failover, etc. Det är tillrådligt att ha en hälsosam Djurskötarens kvorum (minst 3 eller fler noder) för att ha det igång hela tiden. Zookeeper bör drivas oberoende (och inte av HBase). Följande figur visar ett exempel på replikeringsrelaterade znodstrukturer i masterklustret (texten efter kolon är data av znoden):
/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
Figur 1. Replikeringsznodernas hierarki
Som i figur 1 finns det tre regionservrar i huvudklustret, nämligen foo[1-3].bar.com. Det finns tre znoder relaterade till replikering:
- tillstånd :Denna znod talar om om replikering är aktiverad eller inte. Alla grundläggande steg (som huruvida en nyrullad logg ska ställas i kö i en replikeringskö, läsa en loggfil för att göra WALEdits-försändelser, etc), kontrollera detta booleska värde innan bearbetning. Detta ställs in av egenskapen "hbase.replication" till true i filen hbase-conf.xml. Ett annat sätt att ändra dess värde är att använda kommandot "start/stopp replikering" i hbase-skalet. Detta kommer att diskuteras i det andra blogginlägget.
- kamrater :Denna znod har anslutna kamrater/slavar som barn. I figuren finns det en slav med peerId =1, och dess värde är anslutningssträngen (Zookeeper_quorum_of_slave:Zookeeper_client_port:root_hbase_znode), där Zookeeper_quorum_of_slave är en kommaseparerad lista över zookeeper-servrar. PeerId-znodnamnet är detsamma som det som angavs när en peer lades till.
- rs :Denna znod innehåller en lista över aktiva regionservrar i masterklustret. Varje regionserver-znod har en lista över WALs som ska replikeras, och värdet på dessa logg-znoder är antingen null (om loggen inte har öppnats för replikering ännu), eller bytens förskjutning till den punkt där loggen har lästs. Byteoffsetvärdet för en WAL-znod indikerar byteoffset för motsvarande WAL-fil till vilken den har lästs och replikerats. Eftersom det kan finnas mer än ett slavkluster, och replikeringsförloppet kan variera mellan dem (ett kan vara nere till exempel), är alla WALs självförsörjande i en peerId-znod under rs. I figuren ovan ligger WALs znoder under are /rs//1, där "1" är peerId.
Replikeringslägen
Det finns tre lägen för att ställa in HBase Replication:
- Master-Slave:I det här läget görs replikeringen i en enda riktning, dvs. transaktioner från ett kluster skjuts till ett annat kluster. Observera att slavklustret är precis som alla andra kluster och kan ha sina egna tabeller, trafik etc.
- Master-Master:I det här läget skickas replikering i båda riktningarna, för olika eller samma tabeller, dvs. båda klustren agerar både som master och slav. I fallet att de replikerar samma tabell kan man tro att det kan leda till en aldrig sinande loop, men detta undviks genom att sätta clusterId för en mutation (Put/Delete) till clusterId för ursprungsklustret. Figur 2 förklarar detta genom att använda två kluster, nämligen solen och jorden. I figur 2 har vi två block som representerar de två HBase-klustren. De har clusterId 100 respektive 200. Vart och ett av klustren har en instans av ReplicationSource, motsvarande det slavkluster som det vill replikera till; den känner till kluster #Ids för båda klustren.
Figur 2. Solen och jorden, två HBase-kluster
Låt oss säga att kluster#Sun tar emot en färsk och giltig mutation M på en tabell- och kolumnfamilj som är inriktad på replikering i båda klustren. Den kommer att ha ett standardkluster-ID (0L). Replikeringskällan-instansen ReplicationSrc-E ställer in sitt kluster#Id lika med ursprungs-id (100) och skickar det till kluster#Earth. När kluster#Earth tar emot mutationen, spelar den upp den igen och mutationen sparas i dess WAL, enligt det normala flödet. Klustret#Id för mutationen hålls intakt i den här loggfilen på kluster#Earth. Replikeringskällan i kluster#Earth, (ReplicationSrc-S, läser mutationen och kontrollerar dess kluster#ID med slaveCluster# (100, lika med kluster#Sun). Eftersom de är lika, hoppar den över denna WALEredigera-post.
- Cyklisk:I det här läget finns det fler än två HBase-kluster som deltar i replikeringsinställningen, och man kan ha olika möjliga kombinationer av master-slave och master-master inställda mellan två valfria kluster. Ovanstående två täcker de fallen väl; en hörnsituation är när vi har satt upp en cykel
Figur 3. En cirkulär replikering
Figur 3 visar en cirkulär replikeringsinställning, där kluster#Sun replikerar till kluster#Earth, kluster#Earth replikerar till kluster#Venus och kluster#Venus replikerar till kluster#Sun.
Låt oss säga kluster#Sun. mottar en ny mutation M och är scoped till replikering över alla ovanstående kluster. Det kommer att replikeras till kluster#Earth som förklarats ovan i mastermasterreplikeringen. Replikeringskällan i kluster#Earth, ReplicationSrc-V, kommer att läsa WAL och se mutationen och replikera den till kluster#Venus. Mutationens kluster#Id hålls intakt (från och med kluster#Sun), vid kluster#Venus. I det här klustret kommer replikeringskällan för kluster#Sun, ReplicationSrc-S, att se att mutationen har samma klusterId som dess slavKluster# (från kluster#Sun), och hoppar därför över detta från att replikera.
Slutsats
HBase Replication är kraftfull funktionalitet som kan användas i ett återställningsscenario. Den lades till som en förhandsgranskningsfunktion i 0.90-versionen och har utvecklats tillsammans med HBase i allmänhet, med tillägg av funktioner som master-master-replikering, acyklisk replikering (båda tillagda i 0.92) och att aktivera-inaktivera replikering på peer-nivå (läggs till i 0,94).
I nästa blogginlägg kommer vi att diskutera olika operativa funktioner som konfiguration, etc, och andra gotchas med HBase Replication.