Apache HBase репликацията е начин за копиране на данни от един HBase клъстер в различен и евентуално отдалечен HBase клъстер. Работи на принципа, че транзакциите от първоначалния клъстер се прехвърлят към друг клъстер. На жаргона на HBase, клъстерът, който извършва натискане, се нарича главен, а този, който получава транзакциите, се нарича подчинен. Това натискане на транзакции се извършва асинхронно и тези транзакции се групират в конфигурируем размер (по подразбиране е 64MB). Асинхронният режим води до минимални режийни разходи за главния, а редакциите на доставка в партида увеличават общата пропускателна способност.
Тази публикация в блога обсъжда възможните случаи на използване, основната архитектура и режимите на репликация на HBase, както се поддържа в CDH4 (който е базиран на 0.92). Ще обсъдим конфигурацията на репликацията, стартирането и толерантността на грешки в последваща публикация в блога.
Случаи на употреба
Репликацията на HBase поддържа репликиране на данни в центрове за данни. Това може да се използва за сценарии за възстановяване при бедствия, където можем да накараме подчинения клъстер да обслужва трафик в реално време, в случай че главният сайт не работи. Тъй като репликацията на HBase не е предназначена за автоматично преминаване при отказ, актът на превключване от главен към подчинен клъстер, за да започне да обслужва трафик, се извършва от потребителя. След това, след като главният клъстер е пуснат отново, може да се извърши CopyTable работа, за да се копират делтите в главния клъстер (чрез предоставяне на времеви печати за начало/стоп), както е описано в публикацията в блога на CopyTable.
Друг случай на използване на репликация е, когато потребителят иска да изпълнява задачи MapReduce с интензивно натоварване на своя HBase клъстер; може да се направи това на подчинения клъстер, докато има лек спад в производителността на главния клъстер.
Архитектура
Основният принцип на репликацията на HBase е да се възпроизведат всички транзакции от главния към подчинения. Това се прави чрез повторно възпроизвеждане на WALEdits (записи в дневника за предварителна запис) в WAL (записване напред в дневник) от главния клъстер, както е описано в следващия раздел. Тези WALEdits се изпращат до сървърите на региона на подчинените клъстери след филтриране (независимо дали конкретна редакция е обхваната за репликация или не) и изпращане в персонализиран размер на партида (по подразбиране е 64MB). В случай, че WAL Reader достигне края на текущия WAL, той ще изпрати всички WALEdits, които са били прочетени дотогава. Тъй като това е асинхронен режим на репликация, подчинения клъстер може да изостава от главния в приложение с тежко записване с порядъка на минути.
WAL/WALEdits/Memstore
В HBase всички мутационни операции (Puts/Deletes) се записват в memstore, който принадлежи към конкретен регион и също така се добавя към регистрационен файл за предварителна запис (WAL) под формата на WALEdit. WALEdit е обект, който представлява една транзакция и може да има повече от една операция за мутация. Тъй като HBase поддържа транзакция на ниво един ред, един WALEdit може да има записи само за един ред. WAL се прехвърлят многократно след конфигуриран период от време (по подразбиране е 60 минути), така че във всеки даден момент има само един активен WAL на регионен сървър.
IncrementColumnValue, операция CAS (проверка и заместване), също се преобразува в Put, когато се записва в WAL.
Memstore е сортирана карта в паметта, съдържаща ключови стойности на съставящия регион; има едно memstore за всяко семейство колони за регион. Memstore се прехвърля на диска като HFile, след като достигне конфигурирания размер (по подразбиране е 64MB).
Записването в WAL е по избор, но е необходимо, за да се избегне загуба на данни, защото в случай, че регионалният сървър се срине, HBase може да загуби всички мемсторове, хоствани на този регионален сървър. В случай на повреда на регионалния сървър, неговите WAL се възпроизвеждат чрез процес на разделяне на регистрационни файлове за възстановяване на данните, съхранени в WAL.
За да работи репликацията, записът към WAL трябва да е разрешен.
ClusterId
Всеки HBase клъстер има clusterID, тип UUID, генериран автоматично от HBase. Той се съхранява в основната файлова система (обикновено HDFS), така че да не се променя между рестартирането. Това се съхранява в /hbase/hbaseid znode. Този идентификатор се използва за постигане на главен-главен/ациклична репликация. WAL съдържа записи за редица региони, които се хостват на регионалния сървър. Кодът за репликация чете всички ключови стойности и филтрира ключовите стойности, които са обхванати за репликация. Той прави това, като разглежда атрибута на семейството на колоните на ключовата стойност и го съпоставя със структурата на данните на картата на семейството на колоните на WALEdit. В случай, че конкретна ключова стойност е с обхват за репликация, тя редактира параметъра clusterId на ключовата стойност към идентификатора на клъстера HBase.
ReplicationSource
ReplicationSource е обект на java Thread в процеса на regionserver и е отговорен за репликирането на WAL записи към конкретен подчинен клъстер. Той има приоритетна опашка, която съдържа регистрационните файлове, които трябва да бъдат репликирани. Веднага след като дневникът бъде обработен, той се премахва от опашката. Опашката с приоритет използва компаратор, който сравнява регистрационните файлове въз основа на техния времеви печат на създаване (което се добавя към името на регистрационния файл); така че регистрационните файлове се обработват в същия ред като времето на тяхното създаване (първо се обработват по-старите регистрационни файлове). Ако има само един регистрационен файл в приоритетната опашка, той няма да бъде изтрит, тъй като представлява текущия WAL.
Ролята на пазач на зоопарка
Zookeeper играе ключова роля в репликацията на HBase, където управлява/координира почти всички основни дейности по репликация, като регистриране на подчинен клъстер, стартиране/спиране на репликация, поставяне в опашка на нови WAL, обработка при отказ на регионалния сървър и т.н. Препоръчително е да имате здравословен Кворум на Zookeeper (поне 3 или повече възли), така че да работи и работи през цялото време. Zookeeper трябва да се стартира независимо (а не от HBase). Следващата фигура показва примерна структура на znodes, свързана с репликация, в главния клъстер (текстът след двоеточие е данните на 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
Фигура 1. Йерархия на znodes на репликация
Съгласно Фигура 1, има три регионални сървъра в главния клъстер, а именно foo[1-3].bar.com. Има три znode, свързани с репликацията:
- състояние :Този znode казва дали репликацията е активирана или не. Всички основни стъпки (като например дали да поставите в опашката наскоро прехвърлен регистрационен файл в опашката за репликация, да прочетете регистрационен файл за извършване на изпращане на WALEdits и т.н.), проверете тази булева стойност преди обработка. Това се задава от настройката на свойството “hbase.replication” на true в hbase-conf.xml. Друг начин за промяна на стойността му е да използвате командата „старт/стоп репликация“ в hbase shell. Това ще бъде обсъдено във втората публикация в блога.
- връстници :Този znode има свързани връстници/подчинени като деца. На фигурата има един подчинен с peerId =1 и неговата стойност е низът на връзката (Zookeeper_quorum_of_slave:Zookeeper_client_port:root_hbase_znode), където Zookeeper_quorum_of_slave е разделен със запетая списък на сървърите на zoo. Името на peerId znode е същото като даденото при добавяне на партньор.
- rs :Този znode съдържа списък с активни регионални сървъри в главния клъстер. Всеки snode на регионалния сървър има списък с WAL, които трябва да бъдат репликирани, и стойността на тези log znodes е или нула (в случай, че логът все още не е отворен за репликация), или изместването на байта до точката, където е прочетен дневникът. Стойността на отместване на байта за WAL znode показва отместването на байта на съответния WAL файл, до който е бил прочетен и репликиран. Тъй като може да има повече от един подчинен клъстер и напредъкът на репликацията може да варира между тях (единият може да не работи например), всички WAL се съдържат самостоятелно в peerId znode под rs. По този начин, на горната фигура, WALs znodes са под are /rs//1, където „1“ е peerId.
Режими на репликация
Има три режима за настройка на HBase репликация:
- Master-Slave:В този режим репликацията се извършва в една посока, т.е. транзакциите от един клъстер се прехвърлят към друг клъстер. Имайте предвид, че подчинения клъстер е точно като всеки друг клъстер и може да има свои собствени таблици, трафик и т.н.
- Master-Master:В този режим репликацията се изпраща в двете посоки, за различни или едни и същи таблици, т.е. и двата клъстера действат и като главен, и като подчинен. В случай, че те репликират една и съща таблица, може да се помисли, че това може да доведе до безкраен цикъл, но това се избягва чрез задаване на clusterId на мутацията (Put/Delete) на clusterId на първоначалния клъстер. Фигура 2 обяснява това, като използва два клъстера, а именно Слънцето и Земята. На фигура 2 имаме два блока, представящи двата HBase клъстера. Те имат clusterId съответно 100 и 200. Всеки от клъстерите има екземпляр на ReplicationSource, съответстващ на подчинения клъстер, към който иска да репликира; той знае клъстер #ID и на двата клъстера.
Фигура 2. Слънце и Земя, два HBase клъстера
Да кажем, че cluster#Sun получава свежа и валидна мутация M на таблица и семейство колони, която е с обхват за репликация и в двата клъстера. Той ще има идентификатор на клъстер по подразбиране (0L). Източникът на репликация ReplicationSrc-E ще зададе своя cluster#Id равен на идентификатора на източника (100) и ще го изпрати до cluster#Earth. Когато cluster#Earth получи мутацията, тя я възпроизвежда и мутацията се запазва в своя WAL, съгласно нормалния поток. Cluster#Id на мутацията се запазва непокътнат в този регистрационен файл в cluster#Earth. Източникът на репликация в cluster#Earth, (ReplicationSrc-S, ще прочете мутацията и проверява нейния cluster#ID с slaveCluster# (100, равно на cluster#Sun). Тъй като те са равни, той ще пропусне този запис в WALEdit.
- Цикъл:В този режим има повече от два HBase клъстера, които участват в настройката на репликацията и един може да има различни възможни комбинации от главен-подчинен и главен-главен, настроен между всеки два клъстера. Горните две покриват тези случаи добре; една ъглова ситуация е, когато сме настроили цикъл
Фигура 3. Настройка на кръгова репликация
Фигура 3. показва настройка за кръгова репликация, където клъстер#Слънце се реплицира към клъстер#Земя, клъстер#Земя се реплицира към клъстер#Венера, а клъстер#Венера се репликира в клъстер#Слънце.
Да кажем клъстер#Слънце получава нова мутация М и има обхват на репликация във всички горепосочени клъстери. Той ще бъде репликиран в клъстер#Earth, както е обяснено по-горе в главната главна репликация. Източникът на репликация в клъстер#Earth, ReplicationSrc-V, ще прочете WAL и ще види мутацията и ще я репликира в клъстер#Венера. Клъстерът #Id на мутацията се запазва непокътнат (като клъстер #Слънце), в клъстер #Венера. В този клъстер екземплярът на източника на репликация за cluster#Sun, ReplicationSrc-S, ще види, че мутацията има същия clusterId като неговия slaveCluster# (от cluster#Sun) и следователно пропуснете това от репликация.
Заключение
Репликацията на HBase е мощна функционалност, която може да се използва в сценарий за възстановяване при бедствие. Той беше добавен като функция за предварителен преглед в версията 0.90 и се развива заедно с HBase като цяло, с добавяне на функционалности като главен-главен репликация, ациклична репликация (и двете добавени в 0.92) и разрешаване-деактивиране на репликация на ниво партньор (добавено в 0.94).
В следващата публикация в блога ще обсъдим различни оперативни функции като конфигуриране и т.н. и други проблеми с HBase репликацията.
