Detta är det andra blogginlägget om Apache HBase-replikering. Det föregående blogginlägget, HBase Replication Overview, diskuterade användningsfall, arkitektur och olika lägen som stöds i HBase-replikering. Det här blogginlägget är ur ett operativt perspektiv och kommer att beröra HBase-replikeringskonfigurationen och nyckelbegrepp för att använda den – som bootstrapping, schemaändring och feltolerans.
Konfiguration
Som nämnts i HBase-replikeringsöversikten, skickar masterklustret leverans av WALEdits till ett eller flera slavkluster. Det här avsnittet beskriver de steg som krävs för att konfigurera replikering i ett master-slave-läge.
- Alla tabeller/kolumnfamiljer som ska replikeras måste finnas på båda klustren.
- Lägg till följande egenskap i $HBASE_HOME/conf/hbase-site.xml på alla noder i båda klustren; ställ in det till sant.
hbase.replication
sant
Gör följande ytterligare ändringar i huvudklustret:
- Ange replikeringsomfång (REPLICATION_SCOPE attribut) på tabellen/kolumnfamiljen som ska replikeras:
hbase shell> inaktivera 'tabell'
hbase shell> ändra 'tabell', {NAME => 'column-family', REPLICATION_SCOPE => 1}
hbase shell> aktivera "tabell"
REPLICATION_SCOPE är ett attribut på kolumnfamiljnivå och dess värde kan vara antingen 0 eller 1. Ett värde på 0 betyder att replikering är inaktiverad och 1 betyder att replikering är aktiverad. En användare måste ändra varje kolumnfamilj med alter-kommandot som visas ovan, för alla kolumnfamiljer han vill replikera.
Om en användare vill aktivera replikering medan han skapar en tabell, bör han använda följande kommando:
hbase-skal> skapa 'tabell', 'kolumn-familj1', ''kolumn-familj2', {NAME => 'kolumn-familj1', REPLICATION_SCOPE => 1}
Kommandot ovan kommer att möjliggöra replikering på 'column-family1' i tabellen ovan.
2. Lägg till slavpeern i hbase-skalet. En användare ska tillhandahålla slavklustrets zookeeper-quorum, dess klientport och root-hbase-znoden, tillsammans med ett peerId:
hbase shell>add_peer 'peerId', "::"
peerId är en en eller två tecken lång sträng, och en motsvarande znod skapas under peers-znoden, som förklarats i föregående blogg. När en användare kör kommandot add_peer, instansierar replikeringskoden ett ReplicationSource-objekt för den peeren, och alla huvudklusterregionservrar försöker ansluta till slavklustrets regionservrar. Den hämtar också slavklustrets ClusterId (UUID, registrerat på slavklustrets djurparksföreståndarquorum). Huvudklustrets regionserver listar de tillgängliga regionservrarna för slaven genom att läsa "/hbase/rs"-znoden och dess underordnade i slavklustrets djurparksförvaltares kvorum, och kopplar till det. Varje regionserver i masterklustret väljer en delmängd från slavregionservrarna, beroende på förhållandet som specificeras av "replication.source.ratio", med standardvärdet 0.1. Detta innebär att varje huvudklusterregionserver kommer att försöka ansluta till 10 % av det totala antalet slavklusterregionservrar. När transaktionsbatchen skickas kommer huvudklusterregionservern att välja en slumpmässig regionserver från dessa anslutna regionservrar. (Obs:Replikering görs inte för katalogtabeller, .META. och _ROOT_.)
För att ställa in ett master-master-läge, bör ovanstående steg upprepas på båda klustren.
Schemaändring
Som nämnts i föregående avsnitt måste replikerad tabell- och kolumnfamilj finnas i båda klustren. Det här avsnittet diskuterar olika möjliga scenarier för vad som händer under en schemaändring när replikeringen fortfarande pågår:
a) Ta bort kolumnfamiljen i master:Borttagning av en kolumnfamilj kommer inte att påverka replikeringen av några pågående mutationer för den familjen. Detta beror på att replikeringskoden läser WAL och kontrollerar replikeringsomfånget för kolumnfamiljerna för varje WALEdit. Varje WALEdit har en karta över de replikeringsaktiverade kolumnfamiljerna; kontrollen görs på alla konstituerande nyckelvärdes kolumnfamiljer (oavsett om de är omfångade eller inte). Om den finns på kartan läggs den till i försändelsen. Eftersom WALEdit-objektet skapas innan kolumnfamiljen togs bort, kommer dess replikering inte att påverkas.
b) Ta bort kolumnfamiljen i slav:WALEdits skickas från masterklustret till en viss slavregionserver, som bearbetar den som en vanlig HBase-klient (med ett HTablePool-objekt). Eftersom kolumnfamiljen tas bort kommer putsoperationen att misslyckas och det undantaget kastas till huvudregionserverklustret.
Starta/stoppa replikering
Start/Stopp-kommandon fungerar som en avbrytare. När stop_replication-kommandot körs i HBase-skalet kommer det att ändra värdet på /hbase/replikation/state till false. Det kommer att stoppa alla replikeringskällobjekt från att läsa loggarna; men de befintliga läsposterna kommer att skickas. Om en användare använder kommandot stopp replikering ställs de nyligen rullade loggarna inte i kö för replikering. På samma sätt kommer att utfärda ett start_replikeringskommando att starta replikeringen från den aktuella WAL (som kan innehålla några tidigare transaktioner), och inte från den tidpunkt då kommandot utfärdades.
Figur 1 förklarar start-stopp-brytarens beteende, där händelseförloppet flyter i pilarnas riktning.
Versionskompatibilitet
Masterklusterregionservrar ansluter till slavklusterregionservrar som vanliga HBase-klienter. Samma regel för kompatibilitet gäller om en HBase-klient på version xxx stöds på en HBase-server på version yyy.
På en annan punkt, eftersom replikering fortfarande utvecklas (fler och fler funktioner läggs till kontinuerligt), bör en användare vara medveten om de befintliga funktionerna. Till exempel, i CDH4, som är baserad på HBase 0.92-grenen, finns det stöd för master-master och cyklisk replikering. Aktivering/inaktivering av replikeringskälla på peer-nivå läggs till i HBase 0.94-grenen.
Startband
Replikering fungerar genom att läsa WAL:erna för huvudklustrets regionservrar. Om en användare vill replikera gamla data kan de köra ett copyTable-kommando (definierar start- och sluttidsstämpel) samtidigt som replikeringen aktiveras. Kommandot copyTable kommer att kopiera data som omfattas av start-/sluttidsstämplarna, och replikering tar hand om aktuella data. Det övergripande tillvägagångssättet kan sammanfattas som:
- Starta replikeringen (notera tidsstämpeln).
- Kör kommandot copyTable med en sluttidsstämpel som är lika med tidsstämpeln ovan.
- Eftersom replikering startar från nuvarande WAL kan det finnas några nyckelvärden som kopieras till slav av både replikerings- och copyTable-jobb. Detta är fortfarande okej, eftersom det är en idempotent operation.
I fallet med master-master-replikering bör man köra copyTable-jobbet innan replikeringen påbörjas. Detta beror på att om en användare startar ett copyTable-jobb efter att ha aktiverat replikering, kommer den andra mastern att skicka om data till den första mastern, eftersom copyTable inte redigerar clusterId i mutationsobjekten. Det övergripande tillvägagångssättet kan sammanfattas som:
- Kör copyTable-jobbet, (notera jobbets starttidsstämpel).
- Starta replikeringen.
- Kör copyTable igen med starttiden lika med starttiden som noterades i steg 1.
Detta innebär också att vissa data skjuts fram och tillbaka mellan de två klustren; men den minimerar storleken.
Feltolerans
Master Cluster Region Server Failover
Alla regionservrar i masterklustret skapar en znod under "/hbase/replikering/rs", som nämnts i avsnittet Arkitektur. En regionserver lägger till en underordnad znod för varje WAL, med en byteoffset under dess znod i replikeringshierarkin, som visas i figur 1. Om en regionserver misslyckas måste andra regionservrar ta hand om den döda regionserverns loggar, som listas under den regionserverns znod. Alla regionservrar håller koll på andra regionserverznoder (“/hbase/rs”) znode; så när en regionserver misslyckas kommer andra regionservrar att få händelsen eftersom master markerar denna regionserver som död. I det här fallet tävlar alla andra regionservrar om att överföra WALs från död regionserver-znod till sin znod, och bifogar ett prefix med slav-id och död regionservernamn, för att skilja från andra normala loggar. En separat replikeringskälla (NodeFailoverWorker-instans) instansieras för de överförda loggarna, som dör efter bearbetning av dessa överförda loggar.
Om man betraktar figur 1 i HBase-replikeringsöversikten som basfiguren för replikeringsznodshierarkin, visar figur 2 den nya replikeringsznodshierarkin i fall server foo1.bar.com dör och foo2.bar.com tar över dess kö. Notera den nya znoden "1-foo1.bar.com,40020,1339435481973" som skapas 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:sant /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/2basrreplication/2basrreplication/2 .bar.com,40020,1339435481742:/hbase/replikation/rs/foo3.bar.com,40020,1339435481742/1:/hbase/replikation/rs/foo3.bar.com,40020, 5413974o.bar/338174o.bar. ... foo2.bar.com,40020, 1339435481742/1/foo2.bar..com.13394354343443:1909033 /hbase/replikation/rs/foo2.bar.com,40020,13394435419.com,31o /foo1.bar.com.1339435485769:1243232
Figur 2. Hierarki för zonnoder för regionserverfel
Under tiden kan loggdelning starta och kan arkivera serverloggarna för döda regioner. Replikeringskällan letar efter loggarna i både vanlig och arkiverad katalog.
Långsamt/svarar inte slavkluster (eller regionservrar)
När ett slavkluster är nere, eller om det finns en tillfällig nätverkspartition, kommer inte loggar som ännu inte har replikerats till slaven att raderas av HBase-loggrensaren.
Loggrensning hanteras av LogCleaner-klassen, som fortsätter att köras efter en konfigurerad tid. Replikeringskoden lägger till ReplicationLogCleaner-plugin, till LogCleaner-klassen. När den senare försöker ta bort en specifik logg, kommer ReplicationLogCleaner att titta för att se om den loggen finns i replikeringsznodhierarkin (under /hbase/replikation/rs/ znode). Om loggen hittas betyder det att loggen ännu inte har replikerats, och den kommer att hoppa över raderingen. När loggen är replikerad kommer dess znod att tas bort från replikeringshierarkin. I nästa körning kommer LogCleaner att radera loggfilen framgångsrikt när den har replikerats.
Verifiering
För mindre mängd data kan man helt enkelt leta efter tabellraderna med hjälp av hbase-skalet i slavklustret för att verifiera om de är replikerade eller inte. Ett standardsätt att verifiera är att köra verifyrep mapreduce-jobbet, som följer med HBase. Det bör köras på masterklustret och kräva slavklusterId och måltabellens namn. Man kan också ge ytterligare argument som start/stopp tidsstämpel och kolumnfamiljer. Den skriver ut två räknare, nämligen GOODROWS och BADROWS, som anger antalet replikerade respektive oreplicerade rader.
Replikeringsstatistik
Replikeringsramverket avslöjar några användbara mätvärden som kan användas för att kontrollera replikeringsförloppet. Några av de viktiga är:
- sizeOfLogQueue:antal HLogs att bearbeta (exkluderar den som bearbetas) vid replikeringskällan
- shippedOpsRate:frekvensen av mutationer som skickas
- logEditsReadRate:mutationshastighet som läses från HLogs vid replikeringskällan
- ageOfLastShippedOp:ålder för senaste batch som skickades av replikeringskällan
Framtida arbete
Med alla nuvarande funktioner som finns i nuvarande HBase-replikering finns det fortfarande utrymme för ytterligare förbättringar. Det varierar från prestanda som att minska replikeringsfördröjningen mellan master och slav, till mer robust hantering av regionserverfel (HBase-2611). Ytterligare förbättringsområden inkluderar att möjliggöra tabellreplikering på peer-nivå och korrekt hantering av IncrementColumnValue (HBase-2804).
Slutsats
Det här inlägget diskuterade HBase-replikering ur en operatörs synvinkel inklusive konfiguration (av olika lägen), bootstrapping av ett befintligt kluster, effekter av schemaändringar och feltolerans.