Apache HBase-replicatie is een manier om gegevens van het ene HBase-cluster naar een ander en mogelijk ver verwijderd HBase-cluster te kopiëren. Het werkt volgens het principe dat de transacties van het oorspronkelijke cluster naar een ander cluster worden gepusht. In HBase-jargon wordt het cluster dat de push uitvoert de master genoemd en degene die de transacties ontvangt de slave. Deze push van transacties wordt asynchroon uitgevoerd en deze transacties worden gegroepeerd in een configureerbare grootte (standaard is 64 MB). De asynchrone modus brengt minimale overhead met zich mee voor de master, en verzendingsbewerkingen in een batch verhogen de algehele doorvoer.
Deze blogpost bespreekt de mogelijke use-cases, onderliggende architectuur en modi van HBase-replicatie zoals ondersteund in CDH4 (gebaseerd op 0.92). We zullen replicatieconfiguratie, bootstrapping en fouttolerantie bespreken in een vervolgblog.
Gebruikssituaties
HBase-replicatie ondersteunt het repliceren van gegevens in datacenters. Dit kan worden gebruikt voor scenario's voor noodherstel, waarbij we het slavecluster realtime verkeer kunnen laten verzorgen voor het geval de mastersite niet beschikbaar is. Aangezien HBase-replicatie niet bedoeld is voor automatische failover, wordt het overschakelen van de master naar de slave-cluster om te beginnen met het bedienen van verkeer door de gebruiker gedaan. Daarna, als het mastercluster weer up is, kan men een CopyTable-taak doen om de delta's naar het mastercluster te kopiëren (door de start/stop-tijdstempels op te geven) zoals beschreven in de CopyTable-blogpost.
Een ander gebruiksscenario voor replicatie is wanneer een gebruiker belastingintensieve MapReduce-taken op zijn HBase-cluster wil uitvoeren; men kan dit doen op het slave-cluster terwijl er een lichte prestatievermindering optreedt op het master-cluster.
Architectuur
Het onderliggende principe van HBase-replicatie is om alle transacties van de master naar de slave opnieuw af te spelen. Dit wordt gedaan door de WALEdits (Write Ahead Log-vermeldingen) in de WAL's (Write Ahead Log) van het hoofdcluster opnieuw af te spelen, zoals beschreven in de volgende sectie. Deze WALEdits worden naar de slave-clusterregioservers gestuurd, na filtering (of een specifieke bewerking al dan niet binnen het bereik van replicatie valt) en verzonden in een aangepaste batchgrootte (standaard is 64 MB). In het geval dat de WAL Reader het einde van de huidige WAL bereikt, zal het de WALEdits verzenden die tot dan toe zijn gelezen. Aangezien dit een asynchrone replicatiemodus is, kan het slavecluster minutenlang achterblijven bij de master in een zware schrijftoepassing.
WAL/WALEdits/Memstore
In HBase worden alle mutatiebewerkingen (Puts/Deletes) geschreven naar een geheugenopslag die tot een specifieke regio behoort en ook toegevoegd aan een write-ahead logbestand (WAL) in de vorm van een WALEdit. Een WALEdit is een object dat één transactie vertegenwoordigt en meer dan één mutatiebewerking kan hebben. Aangezien HBase één transactie op rijniveau ondersteunt, kan één WALEdit vermeldingen voor slechts één rij hebben. De WAL's worden herhaaldelijk gerold na een geconfigureerde tijdsperiode (standaard is 60 minuten), zodat er op elk moment slechts één actieve WAL per regioserver is.
IncrementColumnValue, een CAS-bewerking (controleren en vervangen), wordt ook omgezet in een Put wanneer deze naar de WAL wordt geschreven.
Een memstore is een in-memory, gesorteerde kaart met sleutelwaarden van de samenstellende regio; er is één geheugenopslag per kolomfamilie per regio. De memstore wordt als een HFile naar de schijf gespoeld zodra deze de geconfigureerde grootte heeft bereikt (standaard is 64 MB).
Schrijven naar WAL is optioneel, maar het is vereist om gegevensverlies te voorkomen, want in het geval dat een regioserver crasht, kan HBase alle geheugenopslagplaatsen die op die regioserver worden gehost, kwijtraken. In het geval van een storing in de regionserver, worden de WAL's opnieuw afgespeeld door middel van een logboeksplitsingsproces om de gegevens te herstellen die in de WAL's zijn opgeslagen.
Om replicatie te laten werken, moet schrijven naar WAL's zijn ingeschakeld.
Cluster-ID
Elk HBase-cluster heeft een clusterID, een UUID-type dat automatisch wordt gegenereerd door HBase. Het wordt bewaard in het onderliggende bestandssysteem (meestal HDFS) zodat het niet verandert tussen herstarts. Dit wordt opgeslagen in de /hbase/hbaseid znode. Deze id wordt gebruikt om master-master/acyclische replicatie te verkrijgen. Een WAL bevat vermeldingen voor een aantal regio's die op de regionserver worden gehost. De replicatiecode leest alle sleutelwaarden en filtert de sleutelwaarden uit die binnen het bereik van replicatie vallen. Het doet dit door te kijken naar het kolomfamiliekenmerk van de sleutelwaarde en dit te matchen met de WALEdit's kolomfamiliekaartgegevensstructuur. In het geval dat een specifieke sleutelwaarde binnen het bereik van replicatie valt, wordt de parameter clusterId van de sleutelwaarde bewerkt tot de HBase-cluster-ID.
Replicatiebron
De ReplicationSource is een Java Thread-object in het regionserver-proces en is verantwoordelijk voor het repliceren van WAL-vermeldingen naar een specifiek slave-cluster. Het heeft een prioriteitswachtrij die de logbestanden bevat die moeten worden gerepliceerd. Zodra een log is verwerkt, wordt deze uit de wachtrij verwijderd. De prioriteitswachtrij gebruikt een comparator die de logbestanden vergelijkt op basis van hun aanmaaktijdstempel (dat is toegevoegd aan de naam van het logbestand); logs worden dus in dezelfde volgorde verwerkt als de aanmaaktijd (oudere logs worden eerst verwerkt). Als er slechts één logbestand in de prioriteitswachtrij staat, wordt dit niet verwijderd omdat het de huidige WAL vertegenwoordigt.
Rol van dierenverzorger
Zookeeper speelt een sleutelrol in HBase Replication, waar het bijna alle belangrijke replicatieactiviteiten beheert/coördineert, zoals het registreren van een slavecluster, het starten/stoppen van replicatie, het in de wachtrij plaatsen van nieuwe WAL's, het afhandelen van regionserver-failover, enz. Het is raadzaam om een gezond Zookeeper-quorum (minstens 3 of meer knooppunten) zodat het altijd actief is. Zookeeper moet onafhankelijk worden gerund (en niet door HBase). De volgende afbeelding toont een voorbeeld van een replicatie-gerelateerde znodes-structuur in het hoofdcluster (de tekst na de dubbele punt is de data van de znode):
/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
Afbeelding 1. Hiërarchie van replicatie-znodes
Volgens afbeelding 1 zijn er drie regionservers in het hoofdcluster, namelijk foo[1-3].bar.com. Er zijn drie znodes gerelateerd aan replicatie:
- staat :Deze znode vertelt of replicatie is ingeschakeld of niet. Alle fundamentele stappen (zoals het al dan niet in een wachtrij plaatsen van een nieuw gerold log in een replicatiewachtrij, het lezen van een logbestand om WALEdits-zendingen te maken, enz.), controleer deze booleaanse waarde voordat deze wordt verwerkt. Dit wordt ingesteld door de eigenschap "hbase.replication" in te stellen op true in de hbase-conf.xml. Een andere manier om de waarde ervan te wijzigen, is door de opdracht "start/stop replicatie" in hbase-shell te gebruiken. Dit wordt besproken in de tweede blogpost.
- genoten :Deze znode heeft de aangesloten peers/slaves als kinderen. In de afbeelding is er één slaaf met de peerId =1, en de waarde ervan is de verbindingsreeks (Zookeeper_quorum_of_slave:Zookeeper_client_port:root_hbase_znode), waarbij de Zookeeper_quorum_of_slave een door komma's gescheiden lijst van dierenverzorger-servers is. De peerId znode-naam is dezelfde als die is opgegeven bij het toevoegen van een peer.
- rs :Deze znode bevat een lijst met actieve regionservers in het mastercluster. Elke regionserver znode heeft een lijst met WAL's die moeten worden gerepliceerd, en de waarde van deze log-znodes is ofwel null (in het geval dat log nog niet is geopend voor replicatie), of de byte-offset naar het punt waar het logboek is gelezen. De byte-offsetwaarde voor een WAL-znode geeft de byte-offset aan van het corresponderende WAL-bestand tot waar het is gelezen en gerepliceerd. Omdat er meer dan één slave-cluster kan zijn en de voortgang van de replicatie tussen deze clusters kan variëren (een kan bijvoorbeeld niet beschikbaar zijn), zijn alle WAL's op zichzelf staand in een peerId znode onder rs. In de bovenstaande afbeelding bevinden WAL's znodes zich dus onder de are /rs//1, waarbij "1" de peerId is.
Replicatiemodi
Er zijn drie modi voor het instellen van HBase-replicatie:
- Master-Slave:in deze modus wordt de replicatie in één richting gedaan, d.w.z. transacties van het ene cluster worden naar het andere cluster gepusht. Merk op dat het slave-cluster net als elk ander cluster is en zijn eigen tabellen, verkeer, enz. kan hebben.
- Master-Master:in deze modus wordt replicatie in beide richtingen verzonden, voor verschillende of dezelfde tabellen, d.w.z. beide clusters fungeren zowel als master als als slave. In het geval dat ze dezelfde tabel repliceren, zou men kunnen denken dat dit kan leiden tot een oneindige lus, maar dit wordt vermeden door de clusterId van een mutatie (Put/Delete) in te stellen op de clusterId van de oorspronkelijke cluster. Figuur 2 verklaart dit aan de hand van twee clusters, namelijk de zon en de aarde. In figuur 2 hebben we twee blokken die de twee HBase-clusters vertegenwoordigen. Ze hebben respectievelijk clusterId 100 en 200. Elk van de clusters heeft een exemplaar van ReplicationSource, dat overeenkomt met het slavecluster waarnaar het wil repliceren; het kent cluster #Ids van beide clusters.
Afbeelding 2. Zon en aarde, twee HBase-clusters
Stel dat cluster#Sun een nieuwe en geldige mutatie M ontvangt op een tabel- en kolomfamilie die in beide clusters kan worden gerepliceerd. Het heeft een standaard clusterID (0L). De replicatiebroninstantie ReplicationSrc-E stelt de cluster#Id gelijk aan de originator-ID (100) en verzendt deze naar cluster#Earth. Wanneer cluster#Earth de mutatie ontvangt, wordt deze opnieuw afgespeeld en wordt de mutatie opgeslagen in zijn WAL, volgens de normale stroom. De cluster#Id van de mutatie wordt intact gehouden in dit logbestand op cluster#Earth.The Replication source instance at cluster#Earth, (ReplicationSrc-S, zal de mutatie lezen en zijn cluster#ID controleren met de slaveCluster# (100, gelijk aan cluster#Sun). Omdat ze gelijk zijn, wordt dit WALEdit-item overgeslagen.
- Cyclisch:in deze modus zijn er meer dan twee HBase-clusters die deelnemen aan de replicatie-installatie, en men kan verschillende mogelijke combinaties van master-slave en master-master instellen tussen twee willekeurige clusters. De bovenstaande twee dekken die gevallen goed; een hoeksituatie is wanneer we een cyclus hebben opgezet
Figuur 3. Een circulaire replicatie opgezet
Afbeelding 3. toont een circulaire replicatie-opstelling, waarbij cluster#Zon repliceert naar cluster#Aarde, cluster#Earth repliceert naar cluster#Venus en cluster#Venus repliceert naar cluster#Sun.
Laten we zeggen cluster#Sun ontvangt een nieuwe mutatie M en is gericht op replicatie over alle bovenstaande clusters. Het wordt gerepliceerd naar cluster#Earth zoals hierboven uitgelegd in de mastermasterreplicatie. De replicatiebroninstantie op cluster#Earth, ReplicationSrc-V, leest de WAL en ziet de mutatie en repliceert deze naar cluster#Venus. Het cluster#Id van de mutatie wordt intact gehouden (vanaf cluster#Sun), bij cluster#Venus. Bij dit cluster zal de replicatiebroninstantie voor cluster#Sun, ReplicationSrc-S, zien dat de mutatie dezelfde cluster-ID heeft als zijn slaveCluster# (vanaf cluster#Sun), en daarom sla dit over van repliceren.
Conclusie
HBase-replicatie is een krachtige functionaliteit die kan worden gebruikt in een scenario voor noodherstel. Het is toegevoegd als een preview-functie in de 0.90-release en is samen met HBase in het algemeen geëvolueerd, met toevoeging van functionaliteiten zoals master-master-replicatie, acyclische replicatie (beide toegevoegd in 0.92) en replicatie inschakelen-uitschakelen op peer-niveau (toegevoegd in 0,94).
In de volgende blogpost zullen we verschillende operationele functies bespreken, zoals configuratie, enz., en andere problemen met HBase-replicatie.