Dette er det andet blogindlæg om Apache HBase-replikering. Det tidligere blogindlæg, HBase Replication Overview, diskuterede use cases, arkitektur og forskellige tilstande, der understøttes i HBase-replikering. Dette blogindlæg er fra et operationelt perspektiv og vil berøre HBase-replikeringskonfiguration og nøglebegreber for brugen af det - såsom bootstrapping, skemaændring og fejltolerance.
Konfiguration
Som nævnt i HBase-replikeringsoversigten sender masterklyngen forsendelse af WALEdits til en eller flere slaveklynger. Dette afsnit beskriver de nødvendige trin for at konfigurere replikering i en master-slave-tilstand.
- Alle tabeller/kolonnefamilier, der skal replikeres, skal eksistere på begge klynger.
- Tilføj følgende egenskab i $HBASE_HOME/conf/hbase-site.xml på alle noder på begge klynger; sæt den til sand.
hbase.replication
sandt
Foretag følgende yderligere ændringer på masterklyngen:
- Indstil replikeringsomfang (REPLICATION_SCOPE attribut) på tabellen/kolonnefamilien, som skal replikeres:
hbase shell> deaktiver 'table'
hbase shell> ændre 'tabel', {NAVN => 'kolonne-familie', REPLICATION_SCOPE => 1}
hbase shell> aktiver 'tabel'
REPLICATION_SCOPE er en attribut på kolonnefamilieniveau, og dens værdi kan være enten 0 eller 1. En værdi på 0 betyder, at replikering er deaktiveret, og 1 betyder, at replikering er aktiveret. En bruger skal ændre hver kolonnefamilie med alter-kommandoen som vist ovenfor, for alle de kolonnefamilier, han ønsker at replikere.
Hvis en bruger ønsker at aktivere replikering, mens han opretter en tabel, skal han bruge følgende kommando:
hbase shell> opret 'table', 'column-family1', ''column-family2', {NAME => 'column-family1', REPLICATION_SCOPE => 1}
Ovenstående kommando vil aktivere replikering på 'column-family1' i ovenstående tabel.
2. Tilføj slave-peeren i hbase-skallen. En bruger skal angive slaveklyngens zookeeper kvorum, dets klientport og root-hbase-znoden sammen med et peerId:
hbase shell>add_peer 'peerId', "::"
peerId'et er en streng på et eller to tegn, og en tilsvarende znode oprettes under peers-znoden, som forklaret i den forrige blog. Når en bruger kører kommandoen add_peer, instansierer replikeringskode et ReplicationSource-objekt for den peer, og alle masterklyngeregionsservere forsøger at oprette forbindelse til slaveklyngens regionsservere. Den henter også slaveklyngens ClusterId (UUID, registreret på slaveklyngens zookeeper quorum). Master cluster regionserveren viser de tilgængelige regionservere for slaven ved at læse "/hbase/rs" znode og dens børn på slaveklyngens zookeeper kvorum og forbinder til det. Hver regionserver på masterklyngen vælger et undersæt fra slaveregionsserverne, afhængigt af forholdet specificeret af "replikation.kilde.forhold", med standardværdien 0,1. Dette betyder, at hver master cluster regionserver vil forsøge at oprette forbindelse til 10 % af det samlede antal slave cluster regionservere. Mens der sendes transaktionsbatchen, vil hovedklyngeregionsserveren vælge en tilfældig regionsserver fra disse forbundne regionsservere. (Bemærk:Replikering udføres ikke for katalogtabeller, .META. og _ROOT_.)
For at opsætte en master-master-tilstand skal ovenstående trin gentages på begge klynger.
Skemaændring
Som nævnt i det foregående afsnit skal replikeret tabel- og kolonnefamilie eksistere i begge klynger. Dette afsnit diskuterer forskellige mulige scenarier for, hvad der sker under en skemaændring, når replikeringen stadig er i gang:
a) Slet kolonnefamilien i master:Sletning af en kolonnefamilie vil ikke påvirke replikationen af eventuelle ventende mutationer for denne familie. Dette skyldes, at replikeringskoden læser WAL og kontrollerer replikeringsomfanget for kolonnefamilierne for hver WALEdit. Hver WALEdit har et kort over de replikeringsaktiverede kolonnefamilier; kontrollen udføres på hele den konstituerende nøgleværdis kolonnefamilie (uanset om de er omfattet eller ej). Hvis det er til stede på kortet, tilføjes det til forsendelsen. Da WALEdit-objektet er oprettet før kolonnefamilien blev slettet, vil dets replikering ikke blive påvirket.
b) Slet kolonnefamilien i slave:WALEdits sendes fra master cluster til en bestemt slave regionserver, som behandler den som en normal HBase klient (ved hjælp af et HTablePool objekt). Da kolonnefamilien er slettet, vil put-operationen mislykkes, og denne undtagelse kastes til masterregionserver-klyngen.
Start/stop replikering
Start/Stop-kommandoer fungerer som en kill switch. Når stop_replication-kommandoen køres på HBase-skallen, ændres værdien af /hbase/replikation/state til false. Det vil stoppe alle replikeringskildeobjekterne i at læse logfilerne; men de eksisterende læseposter vil blive sendt. Hvis en bruger bruger kommandoen stop replikering, vil de nyligt rullede logfiler ikke blive sat i kø til replikering. Tilsvarende vil udstedelse af en start_replikeringskommando starte replikeringen fra den aktuelle WAL (som kan indeholde nogle tidligere transaktioner), og ikke fra det tidspunkt, hvor kommandoen blev udstedt.
Figur 1 forklarer start-stop-kontaktens adfærd, hvor rækkefølgen af begivenheder flyder i pilenes retning.
Versionskompatibilitet
Master cluster regionservers opretter forbindelse til slave cluster regionservere som normale HBase-klienter. Den samme regel for kompatibilitet gælder for, om en HBase-klient på version xxx er understøttet på en HBase-server på version yyy.
På et andet punkt, da replikering stadig udvikler sig (flere og flere funktionaliteter tilføjes løbende til det), bør en bruger være opmærksom på de eksisterende funktionaliteter. For eksempel er der i CDH4, som er baseret på HBase 0.92-grenen, understøttelse af master-master og cyklisk replikering. Aktivering/deaktivering af replikeringskilden på peer-niveau tilføjes i HBase 0.94-grenen.
Boot-strapping
Replikering fungerer ved at læse WAL'erne for hovedklyngeregionsserverne. Hvis en bruger ønsker at replikere gamle data, kan de køre en copyTable-kommando (der definerer start- og sluttidsstempel), mens replikeringen aktiveres. CopyTable-kommandoen kopierer de data, der er omfattet af start/sluttidsstempler, og replikering vil tage sig af aktuelle data. Den overordnede tilgang kan opsummeres som:
- Start replikeringen (bemærk tidsstemplet).
- Kør kommandoen copyTable med et sluttidsstempel svarende til ovenstående tidsstempel.
- Da replikering starter fra nuværende WAL, kan der være nogle nøgleværdier, som kopieres til slave af både replikerings- og copyTable-job. Dette er stadig okay, da det er en idempotent operation.
I tilfælde af master-master-replikering, bør man køre copyTable-jobbet, før du starter replikeringen. Dette skyldes, at hvis en bruger starter et copyTable-job efter at have aktiveret replikering, vil den anden master sende dataene til den første master igen, da copyTable ikke redigerer clusterId'et i mutationsobjekterne. Den overordnede tilgang kan opsummeres som:
- Kør copyTable-jobbet (bemærk jobbets starttidsstempling).
- Start replikeringen.
- Kør copyTable igen med starttidspunktet svarende til starttiden noteret i trin 1.
Dette medfører også, at nogle data bliver skubbet frem og tilbage mellem de to klynger; men det minimerer dens størrelse.
Fejltolerance
Master Cluster Region Server Failover
Alle regionsservere i masterklyngen opretter en znode under "/hbase/replikation/rs", som nævnt i Arkitektur-sektionen. En regionserver tilføjer en underordnet znode for hver WAL, med en byte offset under dens znode i replikeringshierarkiet, som vist i figur 1. Hvis en regionserver fejler, skal andre regionservere tage sig af den døde regionservers logfiler, som er opført under det. regionservers znode. Alle regionservere holder øje med andre regionserverznodes ("/hbase/rs") znode; så når en regionserver fejler, vil andre regionservere få hændelsen, da master markerer denne regionserver som død. I dette tilfælde kører alle andre regionservere om at overføre WAL'erne fra død regionserver-znode til deres znode og tilknytte et præfiks med slave-id og død regionservernavn for at skelne fra andre normale logfiler. En separat replikeringskilde (NodeFailoverWorker-instans) instansieres for de overførte logfiler, som dør efter behandling af disse overførte logfiler.
Hvis man betragter figur 1 i HBase-replikeringsoversigten som basisfiguren for replikerings-znode-hierarki, viser figur 2 det nye replikerings-znode-hierarki i tilfælde af, at serveren foo1.bar.com dør, og foo2.bar.com overtager dens kø. Bemærk den nye znode "1-foo1.bar.com,40020,1339435481973", som er oprettet under 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/replikation:/hbase/replikation/state:sand /hbase:/replication /hbase/replikation/peers/1:zk.quorum.slave:281:/hbase /hbase/replikation/rs:/hbase/replikation/rs/foo1.bar.com.com,40020,1339435084846:/hbase/replikation/ rs/foo1.bar.com,40020,1339435481973/1:/hbase/replikation/rs/foo1.bar.com,40020, 1339435481973/1/foo1.bar.com.13394354852762/3forreplication/3forreplication/2basro .bar.com,40020,1339435481742:/hbase/replikation/rs/foo3.bar.com,40020,1339435481742/1:/hbase/replikation/rs/foo3.bar.com,40020, 548174o.bar. ... foo2.bar.com,40020, 1339435481742/1/foo2.bar..com.13394354343443:1909033 /hbase/replikation/rs/foo2.bar.com,40020,1339443418.com,31020,1339434249.com,40020,13394354209.com,3101-1339434249.com,31o /foo1.bar.com.1339435485769:1243232
Figur 2. Regionserver failover znodes hierarki
I mellemtiden kan logopdeling starte og kan arkivere serverlogfilerne for døde regioner. Replikeringskilden søger efter logfilerne i både almindelig og arkiveret mappe.
Langsom/ikke-responsiv slaveklynge (eller regionsservere)
Når en slaveklynge er nede, eller hvis der er en midlertidig netværkspartition, vil logfiler, som endnu ikke er replikeret til slaven, ikke blive slettet af HBase-logrenseren.
Logrensning håndteres af LogCleaner-klassen, som fortsætter med at køre efter en konfigureret tid. Replikeringskode tilføjer ReplicationLogCleaner-plugin til LogCleaner-klassen. Når sidstnævnte forsøger at slette en specifik log, vil ReplicationLogCleaner se for at se, om denne log findes i replikeringsznodehierarkiet (under /hbase/replikation/rs/ znode). Hvis loggen findes, betyder det, at loggen endnu ikke skal replikeres, og den vil springe over sletningen. Når loggen er replikeret, vil dens znode blive slettet fra replikeringshierarkiet. I sin næste kørsel vil LogCleaner slette logfilen med succes, når den er replikeret.
Bekræftelse
For en mindre mængde data kan man blot se efter tabelrækkerne ved hjælp af hbase-skallen ved slaveklyngen for at verificere, om de er replikeret eller ej. En standard måde at verificere på er at køre verifyrep mapreduce-jobbet, der følger med HBase. Den skal køres på masterklyngen og kræve slave clusterId og måltabelnavnet. Man kan også give yderligere argumenter såsom start/stop tidsstempel og kolonnefamilier. Den udskriver to tællere, nemlig GOODROWS og BADROWS, der angiver antallet af henholdsvis replikerede og ikke-replikerede rækker.
Replikeringsmetrics
Replikeringsrammerne afslører nogle nyttige målinger, som kan bruges til at kontrollere replikeringsfremskridtet. Nogle af de vigtige er:
- sizeOfLogQueue:antal HLogs, der skal behandles (ekskluderer den, der behandles) ved replikeringskilden
- shippedOpsRate:rate af mutationer afsendt
- logEditsReadRate:mutationshastighed læst fra HLogs ved replikeringskilden
- ageOfLastShippedOp:alder for sidste batch, der blev sendt af replikeringskilden
Fremtidigt arbejde
Med alle de nuværende funktioner i den nuværende HBase-replikering er der stadig plads til yderligere forbedringer. Det varierer fra ydeevne såsom reduktion af replikeringstidsforsinkelsen mellem master og slave til mere robust håndtering af regionsserverfejl (HBase-2611). Yderligere forbedringsområder omfatter aktivering af tabelreplikering på peer-niveau og korrekt håndtering af IncrementColumnValue (HBase-2804).
Konklusion
Dette indlæg diskuterede HBase-replikering fra en operatørs synspunkt, herunder konfiguration (af forskellige tilstande), bootstrapping af en eksisterende klynge, effekter af skemaændringer og fejltolerance.