Dit is de tweede blogpost over Apache HBase-replicatie. In de vorige blogpost, Overzicht van HBase-replicatie, werden gebruiksscenario's, architectuur en verschillende modi besproken die in HBase-replicatie worden ondersteund. Deze blogpost is vanuit een operationeel perspectief en gaat in op de configuratie van HBase-replicatie en de belangrijkste concepten voor het gebruik ervan, zoals bootstrapping, schemawijziging en fouttolerantie.
Configuratie
Zoals vermeld in HBase-replicatieoverzicht, verzendt het mastercluster verzending van WALEdits naar een of meer slave-clusters. In dit gedeelte worden de stappen beschreven die nodig zijn om replicatie in een master-slave-modus te configureren.
- Alle tabellen/kolomfamilies die moeten worden gerepliceerd, moeten op beide clusters voorkomen.
- Voeg de volgende eigenschap toe in $HBASE_HOME/conf/hbase-site.xml op alle knooppunten op beide clusters; zet het op true.
hbase.replication
waar
Breng de volgende aanvullende wijzigingen aan in het hoofdcluster:
- Replicatiebereik instellen (REPLICATION_SCOPE attribuut) op de tabel/kolomfamilie die moet worden gerepliceerd:
hbase shell> schakel 'table' uit
hbase shell> alter ‘table’, {NAME => ‘column-family’, REPLICATION_SCOPE => 1}
hbase shell> 'tabel' inschakelen
REPLICATION_SCOPE is een attribuut op kolomfamilieniveau en de waarde kan 0 of 1 zijn. De waarde 0 betekent dat replicatie is uitgeschakeld en 1 betekent dat replicatie is ingeschakeld. Een gebruiker moet elke kolomfamilie wijzigen met het alter-commando zoals hierboven weergegeven, voor alle kolomfamilies die hij wil repliceren.
Als een gebruiker replicatie wil inschakelen tijdens het maken van een tabel, moet hij de volgende opdracht gebruiken:
hbase shell> maak ‘table’, ‘column-family1’, ‘‘column-family2’, {NAME => ‘column-family1’, REPLICATION_SCOPE => 1}
De bovenstaande opdracht maakt replicatie mogelijk op 'column-family1' van de bovenstaande tabel.
2. Voeg in de hbase-shell de slave-peer toe. Een gebruiker wordt verondersteld het zookeeper-quorum van het slavecluster, de clientpoort en de root-hbase-znode op te geven, samen met een peerId:
hbase shell>add_peer ‘peerId’, “::”
De peerId is een tekenreeks van één of twee tekens en een bijbehorende znode wordt gemaakt onder de peer-znode, zoals uitgelegd in de vorige blog. Zodra een gebruiker de opdracht add_peer uitvoert, start de replicatiecode een ReplicationSource-object voor die peer en proberen alle regioservers van het mastercluster verbinding te maken met de regionservers van het slavecluster. Het haalt ook de ClusterId van het slavencluster op (UUID, geregistreerd op het zookeeperquorum van het slavencluster). De mastercluster regionserver somt de beschikbare regionservers van de slaaf op door "/hbase/rs" znode en zijn kinderen te lezen in het dierentuinwachtersquorum van de slavecluster, en maakt er verbinding mee. Elke regionserver op het mastercluster kiest een subset uit de slave regionservers, afhankelijk van de ratio gespecificeerd door "replication.source.ratio", met standaardwaarde 0.1. Dit betekent dat elke regioserver van het mastercluster zal proberen verbinding te maken met 10% van het totaal aan regioservers van het slavecluster. Tijdens het verzenden van de transactiebatch kiest de mastercluster regionserver een willekeurige regionserver uit deze verbonden regionservers. (Opmerking:er wordt niet gerepliceerd voor catalogustabellen, .META. en _ROOT_.)
Om een master-master-modus in te stellen, moeten de bovenstaande stappen op beide clusters worden herhaald.
Schemawijziging
Zoals vermeld in de vorige sectie, moeten gerepliceerde tabel- en kolomfamilies in beide clusters voorkomen. In deze sectie worden verschillende mogelijke scenario's besproken met betrekking tot wat er gebeurt tijdens een schemawijziging terwijl de replicatie nog bezig is:
a) Verwijder de kolomfamilie in master:Het verwijderen van een kolomfamilie heeft geen invloed op de replicatie van eventuele mutaties die in behandeling zijn voor die familie. Dit komt omdat de replicatiecode de WAL leest en het replicatiebereik van de kolomfamilies voor elke WALEdit controleert. Elke WALEdit heeft een kaart van de kolomfamilies die voor replicatie zijn ingeschakeld; de controle wordt uitgevoerd op alle kolomfamilies van de sleutelwaarden (of ze nu binnen het bereik vallen of niet). Als het op de kaart staat, wordt het aan de zending toegevoegd. Aangezien het WALEdit-object is gemaakt voordat de kolomfamilie werd verwijderd, wordt de replicatie ervan niet beïnvloed.
b) Verwijder de kolomfamilie in slave:de WALEdits worden verzonden van het mastercluster naar een bepaalde slave-regioserver, die het verwerkt als een normale HBase-client (met behulp van een HTablePool-object). Aangezien de kolomfamilie is verwijderd, mislukt de put-bewerking en wordt die uitzondering naar het hoofdregioservercluster gegooid.
Replicatie starten/stoppen
Start/Stop-commando's werken als een kill-schakelaar. Wanneer de opdracht stop_replication wordt uitgevoerd op de HBase-shell, wordt de waarde van /hbase/replication/state gewijzigd in false. Het zal voorkomen dat alle replicatiebronobjecten de logs lezen; maar de bestaande gelezen items worden verzonden. Als een gebruiker de opdracht stop replicatie gebruikt, worden de nieuw opgerolde logboeken niet in de wachtrij geplaatst voor replicatie. Evenzo zal het geven van een start_replication-opdracht de replicatie starten vanaf de huidige WAL (die enkele eerdere transacties kan bevatten), en niet vanaf het moment waarop de opdracht werd gegeven.
Afbeelding 1 legt het gedrag van de start-stopschakelaar uit, waarbij de reeks gebeurtenissen in de richting van pijlen stroomt.
Versiecompatibiliteit
Master cluster regionservers maken verbinding met slave cluster regionservers als normale HBase-clients. Dezelfde compatibiliteitsregel is van toepassing op de vraag of een HBase-client op versie xxx wordt ondersteund op een HBase-server op versie yyy.
Op een ander punt, aangezien replicatie nog steeds in ontwikkeling is (er worden steeds meer functionaliteiten aan toegevoegd), moet een gebruiker zich bewust zijn van de bestaande functionaliteiten. In CDH4, dat is gebaseerd op de tak HBase 0.92, is er bijvoorbeeld ondersteuning voor master-master en cyclische replicatie. Het in-/uitschakelen van de replicatiebron op peer-niveau is toegevoegd in de HBase 0.94-tak.
Bootstrappen
Replicatie werkt door de WAL's van de hoofdcluster-regioservers te lezen. Als een gebruiker oude gegevens wil repliceren, kunnen ze een copyTable-opdracht uitvoeren (definiëren van begin- en eindtijdstempel), terwijl de replicatie wordt ingeschakeld. De opdracht copyTable kopieert de gegevens die door de begin-/eindtijdstempels worden bestreken, en replicatie zorgt voor de huidige gegevens. De algemene aanpak kan worden samengevat als:
- Start de replicatie (let op de tijdstempel).
- Voer de opdracht copyTable uit met een eindtijdstempel dat gelijk is aan het bovenstaande tijdstempel.
- Aangezien replicatie begint vanaf de huidige WAL, kunnen er enkele sleutelwaarden zijn die naar de slave worden gekopieerd door zowel replicatie- als copyTable-taken. Dit is nog steeds oké, want het is een idempotente operatie.
In het geval van master-master-replicatie, moet men de copyTable-taak uitvoeren voordat de replicatie wordt gestart. Dit komt omdat als een gebruiker een copyTable-taak start nadat replicatie is ingeschakeld, de tweede master de gegevens opnieuw naar de eerste master verzendt, omdat copyTable de clusterId in de mutatie-objecten niet bewerkt. De algemene aanpak kan worden samengevat als:
- Voer de copyTable-taak uit (let op de starttijdstempel van de taak).
- Start de replicatie.
- Voer de copyTable opnieuw uit met een starttijd die gelijk is aan de starttijd die is genoteerd in stap 1.
Dit houdt ook in dat sommige gegevens heen en weer worden geduwd tussen de twee clusters; maar het minimaliseert de grootte.
Fouttolerantie
Failover van hoofdclusterregioserver
Alle regionservers in het mastercluster maken een znode aan onder "/hbase/replication/rs", zoals vermeld in de sectie Architectuur. Een regionserver voegt een onderliggende znode toe voor elke WAL, met een byte-offset onder zijn znode in de replicatiehiërarchie, zoals weergegeven in figuur 1. Als een regionserver faalt, moeten andere regionservers zorgen voor de logs van de dode regionserver, die daaronder worden vermeld znode van regionserver. Alle regionservers houden andere regionserver znodes (“/hbase/rs”) znode in de gaten; dus als een regionserver uitvalt, zullen andere regionservers de gebeurtenis als master krijgen en deze regionserver als dood markeren. In dit geval racen alle andere regionservers om de WAL's over te dragen van dode regionserver znode naar hun znode, en voegen er een prefix aan toe met slave-id en dode regionserver-naam, om te onderscheiden van andere normale logs. Er wordt een afzonderlijke replicatiebron (NodeFailoverWorker-instantie) gemaakt voor de overgedragen logboeken, die sterft na het verwerken van deze overgedragen logboeken.
Als men figuur 1 van het HBase-replicatieoverzicht beschouwt als de basisfiguur van de replicatie-znodes-hiërarchie, toont figuur 2. de nieuwe replicatie-znodes-hiërarchie voor het geval server foo1.bar.com sterft en foo2.bar.com de wachtrij overneemt. Let op de nieuwe znode "1-foo1.bar.com,40020,1339435481973" die is gemaakt onder 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/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 /hbase/replication/rs/foo2.bar.com,40020,1339435481742/1- foo1.bar.com,40020,1339435481973 /foo1.bar.com.1339435485769:1243232
Afbeelding 2. Hiërarchie van znodes voor failover van regioserver
Ondertussen kan het splitsen van logboeken beginnen en kunnen de serverlogboeken van de dode regio worden gearchiveerd. De replicatiebron zoekt naar de logs in zowel de gewone als de gearchiveerde map.
Langzaam/niet-reagerend slavecluster (of regionservers)
Wanneer een slavecluster niet beschikbaar is of als er een tijdelijke netwerkpartitie is, worden logboeken die nog niet naar de slave zijn gerepliceerd, niet verwijderd door de HBase-logboekopschoner.
Het opschonen van logboeken wordt afgehandeld door de LogCleaner-klasse, die na een geconfigureerde tijd blijft werken. Replicatiecode voegt ReplicationLogCleaner-plug-in toe aan de LogCleaner-klasse. Wanneer de laatste een specifiek logboek probeert te verwijderen, zal ReplicationLogCleaner kijken of dat logboek bestaat in de replicatie-znode-hiërarchie (onder de /hbase/replication/rs/znode). Als het logboek wordt gevonden, betekent dit dat het logboek nog moet worden gerepliceerd en dat het wordt verwijderd. Zodra het logboek is gerepliceerd, wordt de znode verwijderd uit de replicatiehiërarchie. Bij de volgende run zal LogCleaner het logbestand met succes verwijderen zodra het is gerepliceerd.
Verificatie
Voor een kleinere hoeveelheid gegevens kan men eenvoudig naar de tabelrijen zoeken met behulp van de hbase-shell in het slavecluster om te verifiëren of ze zijn gerepliceerd of niet. Een standaardmanier om te verifiëren is om de taak verifier mapreduce uit te voeren, die bij HBase wordt geleverd. Het moet worden uitgevoerd op het mastercluster en er zijn slave-cluster-ID en de naam van de doeltabel vereist. Men kan ook aanvullende argumenten geven, zoals start/stop-tijdstempel en kolomfamilies. Het drukt twee tellers af, namelijk GOODROWS en BADROWS, wat respectievelijk het aantal gerepliceerde en niet-gerepliceerde rijen aangeeft.
Replicatiestatistieken
Het replicatieraamwerk onthult enkele nuttige metrieken die kunnen worden gebruikt om de replicatievoortgang te controleren. Enkele van de belangrijkste zijn:
- sizeOfLogQueue:aantal HLogs dat moet worden verwerkt (exclusief degene die wordt verwerkt) bij de replicatiebron
- shippedOpsRate:snelheid van verzonden mutaties
- logEditsReadRate:snelheid van mutaties gelezen uit HLogs bij de replicatiebron
- ageOfLastShippedOp:leeftijd van de laatste batch die is verzonden door de replicatiebron
Toekomstig werk
Met alle huidige functies die aanwezig zijn in de huidige HBase-replicatie, is er nog ruimte voor verdere verbetering. Het varieert van prestaties, zoals het verminderen van de replicatievertraging tussen master en slave, tot robuustere afhandeling van regioserverstoringen (HBase-2611). Andere verbeterpunten zijn onder meer het inschakelen van tabelreplicatie op peer-niveau en de juiste verwerking van IncrementColumnValue (HBase-2804).
Conclusie
Dit bericht besprak HBase-replicatie vanuit het oogpunt van een operator, inclusief configuratie (van verschillende modi), bootstrapping van een bestaand cluster, effecten van schemawijzigingen en fouttolerantie.