Apache HBase Replication er en måde at kopiere data fra en HBase-klynge til en anden og muligvis fjerntliggende HBase-klynge. Det fungerer ud fra princippet om, at transaktionerne fra den oprindelige klynge skubbes til en anden klynge. I HBase-jargon kaldes klyngen, der udfører pushet, masteren, og den, der modtager transaktionerne, kaldes slaven. Denne push af transaktioner udføres asynkront, og disse transaktioner samles i en konfigurerbar størrelse (standard er 64 MB). Asynkron tilstand medfører minimal overhead på masteren, og forsendelsesredigeringer i en batch øger den samlede gennemstrømning.
Dette blogindlæg diskuterer mulige use cases, underliggende arkitektur og tilstande for HBase-replikering som understøttet i CDH4 (som er baseret på 0.92). Vi vil diskutere replikeringskonfiguration, bootstrapping og fejltolerance i et opfølgende blogindlæg.
Brugstilfælde
HBase-replikering understøtter replikering af data på tværs af datacentre. Dette kan bruges til katastrofegendannelsesscenarier, hvor vi kan få slaveklyngen til at betjene realtidstrafik, hvis masterwebstedet er nede. Da HBase-replikering ikke er beregnet til automatisk failover, udføres handlingen med at skifte fra master- til slaveklyngen for at begynde at betjene trafik af brugeren. Bagefter, når master-klyngen er oppe igen, kan man udføre et CopyTable-job for at kopiere deltaerne til master-klyngen (ved at angive start/stop-tidsstempler) som beskrevet i CopyTable-blogposten.
Et andet replikeringsbrug er, når en bruger ønsker at køre belastningsintensive MapReduce-job på deres HBase-klynge; man kan gøre det på slaveklyngen, mens den bærer et lille ydelsesfald på masterklyngen.
Arkitektur
Det underliggende princip for HBase-replikering er at genafspille alle transaktioner fra master til slave. Dette gøres ved at afspille WALEdits (Write Ahead Log-indgange) i WAL'erne (Write Ahead Log) fra master-klyngen, som beskrevet i næste afsnit. Disse WALE-redigeringer sendes til slaveklyngeregionsserverne efter filtrering (uanset om en specifik redigering er beregnet til replikering eller ej) og forsendelse i en tilpasset batchstørrelse (standard er 64 MB). Hvis WAL-læseren når slutningen af den aktuelle WAL, vil den sende de WALE-redigeringer, der er blevet læst indtil da. Da dette er en asynkron replikationstilstand, kan slaveklyngen halte bagud i forhold til masteren i en skrivetung applikation i størrelsesordenen minutter.
WAL/WALEdits/Memstore
I HBase skrives alle mutationsoperationerne (Puts/Deletes) til et memstore, der tilhører en specifik region, og tilføjes også til en Write Ahead-logfil (WAL) i form af en WALEdit. En WALEdit er et objekt, som repræsenterer én transaktion og kan have mere end én mutationsoperation. Da HBase understøtter transaktioner på enkelt rækkeniveau, kan én WALEdit kun have poster for én række. WAL'erne rulles gentagne gange efter en konfigureret tidsperiode (standard er 60 minutter), således at der på ethvert givet tidspunkt kun er én aktiv WAL pr. regionserver.
IncrementColumnValue, en CAS-operation (check og substitut), konverteres også til en Put, når den skrives til WAL.
Et memstore er et sorteret kort i hukommelsen, der indeholder nøgleværdier for det komponerende område; der er et memstore pr. hver kolonnefamilie pr. region. Memstore tømmes til disken som en HF-fil, når den når den konfigurerede størrelse (standard er 64MB).
Det er valgfrit at skrive til WAL, men det er påkrævet for at undgå tab af data, fordi i tilfælde af at en regionserver går ned, kan HBase miste alle memstores, der er hostet på denne regionsserver. I tilfælde af regionserverfejl afspilles dens WAL'er ved en logopdelingsproces for at gendanne de data, der er gemt i WAL'erne.
For at replikering skal fungere, skal skriv til WAL'er være aktiveret.
ClusterId
Hver HBase-klynge har et clusterID, en UUID-type automatisk genereret af HBase. Det opbevares i det underliggende filsystem (normalt HDFS), så det ikke ændres mellem genstarter. Dette er gemt inde i /hbase/hbaseid znode. Dette id bruges til at opnå master-master/acyklisk replikering. En WAL indeholder indgange for et antal regioner, som er hostet på regionsserveren. Replikeringskoden læser alle nøgleværdierne og bortfiltrerer de nøgleværdier, som er omfattet af replikering. Det gør det ved at se på kolonnefamilieattributten for nøgleværdien og matche den med WALEdits kolonnefamiliekortdatastruktur. I tilfælde af, at en specifik nøgleværdi er omfattet af replikering, redigerer den clusterId-parameteren for nøgleværdien til HBase-klynge-id'et.
ReplicationSource
ReplicationSource er et Java Thread-objekt i regionserver-processen og er ansvarlig for at replikere WAL-poster til en specifik slaveklynge. Den har en prioritetskø, som indeholder de logfiler, der skal replikeres. Så snart en log er behandlet, fjernes den fra køen. Prioritetskøen bruger en komparator, der sammenligner logfilerne baseret på deres oprettelsestidsstempel (som er tilføjet logfilnavnet); så logfiler behandles i samme rækkefølge som deres oprettelsestid (ældre logfiler behandles først). Hvis der kun er én logfil i prioritetskøen, slettes den ikke, da den repræsenterer den aktuelle WAL.
Rolle som Zookeeper
Zookeeper spiller en nøglerolle i HBase-replikering, hvor den administrerer/koordinerer næsten al den store replikeringsaktivitet, såsom registrering af en slaveklynge, start/stop af replikering, opstilling af nye WAL'er, håndtering af regionserver-failover osv. Det er tilrådeligt at have en sund Zookeeper kvorum (mindst 3 eller flere noder) for at have det oppe og køre hele tiden. Zookeeper bør drives uafhængigt (og ikke af HBase). Følgende figur viser et eksempel på replikeringsrelaterede znodestrukturer i masterklyngen (teksten efter kolon er data af 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. Replikeringsznodehierarki
Som i figur 1 er der tre regionservere i master-klyngen, nemlig foo[1-3].bar.com. Der er tre znoder relateret til replikering:
- stat :Denne znode fortæller, om replikering er aktiveret eller ej. Alle grundlæggende trin (såsom om man skal sætte en nyligt rullet log i en replikeringskø, læse en logfil for at foretage WALEdits-forsendelser osv.), kontroller denne booleske værdi før behandling. Dette indstilles ved at sætte egenskaben "hbase.replication" til true i hbase-conf.xml. En anden måde at ændre dens værdi på er at bruge kommandoen "start/stop replikering" i hbase shell. Dette vil blive diskuteret i det andet blogindlæg.
- peers :Denne znode har de tilsluttede peers/slaver som børn. I figuren er der én slave med peerId =1, og dens værdi er forbindelsesstrengen (Zookeeper_quorum_of_slave:Zookeeper_client_port:root_hbase_znode), hvor Zookeeper_quorum_of_slave er en kommasepareret liste over zookeeper-servere. PeerId-znodenavnet er det samme som det, der blev givet under tilføjelse af en peer.
- rs :Denne znode indeholder en liste over aktive regionservere i masterklyngen. Hver regionserver-znode har en liste over WAL'er, der skal replikeres, og værdien af disse log-znoder er enten null (i tilfælde af, at log ikke er åbnet for replikering endnu), eller byte-offset til det punkt, hvor loggen er blevet læst. Byte-offset-værdien for en WAL-znode angiver byte-offset for den tilsvarende WAL-fil, indtil den er blevet læst og replikeret. Da der kan være mere end én slaveklynge, og replikeringsfremskridtene kan variere på tværs af dem (man kan f.eks. være nede), er alle WAL'erne selvstændige i en peerId-znode under rs. I ovenstående figur er WALs znoder således under er /rs//1, hvor "1" er peerId.
Replikeringstilstande
Der er tre tilstande til opsætning af HBase Replication:
- Master-Slave:I denne tilstand udføres replikeringen i en enkelt retning, dvs. transaktioner fra en klynge skubbes til en anden klynge. Bemærk, at slaveklyngen er ligesom enhver anden klynge og kan have sine egne tabeller, trafik osv.
- Master-Master:I denne tilstand sendes replikering på tværs i begge retninger, for forskellige eller samme tabeller, dvs. begge klynger fungerer både som master og slave. I tilfælde af at de replikerer den samme tabel, kan man tro, at det kan føre til en uendelig løkke, men dette undgås ved at indstille clusterId for en Mutation (Put/Delete) til clusterId af den oprindelige cluster. Figur 2 forklarer dette ved at bruge to klynger, nemlig Solen og Jorden. I figur 2 har vi to blokke, der repræsenterer de to HBase-klynger. De har henholdsvis clusterId 100 og 200. Hver af klyngerne har en forekomst af ReplicationSource, svarende til den slaveklynge, den ønsker at replikere til; den kender cluster #Ids for begge klyngerne.
Figur 2. Sol og Jord, to HBase-klynger
Lad os sige, at klynge#Sun modtager en frisk og gyldig mutation M på en tabel- og kolonnefamilie, som er beregnet til replikation i begge klynger. Det vil have et standard clusterID (0L). Replikeringskildeinstansen ReplicationSrc-E vil sætte sin klynge#Id lig med original-id'et (100) og sender den til klynge#Earth. Når klynge#Earth modtager mutationen, afspiller den den igen, og mutationen gemmes i dens WAL i henhold til det normale flow. Mutationens klynge#Id holdes intakt i denne logfil på klynge#Earth. Replikeringskildeforekomsten ved klynge#Earth, (ReplicationSrc-S, vil læse mutationen og tjekke dens klynge#ID med slaveCluster# (100, lig med klynge#Sun). Da de er ens, vil den springe denne WALedit-indgang over.
- Cyklisk:I denne tilstand er der mere end to HBase-klynger, der deltager i replikeringsopsætningen, og man kan have forskellige mulige kombinationer af master-slave og master-master sat op mellem to vilkårlige klynger. Ovenstående to dækker de sager godt; en hjørnesituation er, når vi har oprettet en cyklus
Figur 3. Opsætning af en cirkulær replikering
Figur 3 viser en cirkulær replikeringsopsætning, hvor klynge#Sun replikerer til klynge#Jorden, klynge#Jorden replikerer til klynge#Venus, og klynge#Venus replikerer til klynge#Sun.
Lad os sige klynge#Sun. modtager en frisk mutation M og er scoped til replikation på tværs af alle ovennævnte klynger. Det vil blive replikeret til cluster#Earth som forklaret ovenfor i master master-replikeringen. Replikeringskildeinstansen ved cluster#Earth, ReplicationSrc-V, vil læse WAL'en og se mutationen og replikere den til cluster#Venus. Klynge#Id for mutationen holdes intakt (fra klynge#Sun), ved klynge#Venus. På denne klynge vil replikeringskildeforekomsten for klynge#Sun, ReplicationSrc-S, se, at mutationen har samme klynge-id som dens slaveKlynge# (som klynge#Sun), og derfor springe denne fra replikering.
Konklusion
HBase Replication er kraftfuld funktionalitet, som kan bruges i et scenarie for gendannelse efter katastrofe. Den blev tilføjet som en preview-funktion i 0.90-udgivelsen og har udviklet sig sammen med HBase generelt, med tilføjelse af funktioner såsom master-master-replikering, acyklisk replikering (begge tilføjet i 0.92) og aktivering-deaktivering af replikering på peer-niveau (tilført i 0,94).
I det næste blogindlæg vil vi diskutere forskellige operationelle funktioner såsom konfiguration osv. og andre gotchas med HBase Replication.