Това е втората публикация в блога за репликацията на Apache HBase. В предишната публикация в блога, Преглед на репликацията на HBase, се обсъждат случаи на употреба, архитектура и различни режими, поддържани в репликацията на HBase. Тази публикация в блога е от оперативна гледна точка и ще засегне конфигурацията за репликация на HBase и ключови концепции за използването й – като стартиране, промяна на схемата и толерантност на грешки.
Конфигурация
Както бе споменато в Обзор на репликацията на HBase, главният клъстер изпраща изпращане на WALEdits към един или повече подчинени клъстери. Този раздел описва стъпките, необходими за конфигуриране на репликация в режим главен-подчинен.
- Всички семейства таблици/колони, които трябва да бъдат репликирани, трябва да съществуват и в двата клъстера.
- Добавете следното свойство в $HBASE_HOME/conf/hbase-site.xml на всички възли и в двата клъстера; задайте го на true.
hbase.replication
вярно
В главния клъстер направете следните допълнителни промени:
- Задаване на обхват на репликация (REPLICATION_SCOPE атрибут) в семейството на таблицата/колоната, която трябва да се репликира:
shbase shell> деактивирайте „таблица“
hbase shell> alter ‘table’, {NAME => ‘column-family’, REPLICATION_SCOPE => 1}
hbase shell> активирайте „таблица“
REPLICATION_SCOPE е атрибут на ниво семейство колона и неговата стойност може да бъде 0 или 1. Стойност 0 означава, че репликацията е деактивирана, а 1 означава, че репликацията е активирана. Потребителят трябва да промени всяко семейство колони с командата alter, както е показано по-горе, за всички семейства колони, които иска да репликира.
Ако потребител иска да активира репликация, докато създава таблица, той трябва да използва следната команда:
hbase shell> създайте ‘таблица’, ‘column-family1’, ‘‘column-family2’, {NAME => ‘column-family1’, REPLICATION_SCOPE => 1}
Горената команда ще активира репликация на „column-family1“ от горната таблица.
2. В обвивката hbase добавете подчинения партньор. Потребителят трябва да предостави кворума на zookeeper на подчинения клъстер, своя клиентски порт и root hbase znode, заедно с peerId:
hbase shell>add_peer ‘peerId’, “::”
PeerId е низ с дължина от един или два знака и съответен znode се създава под peer znode, както е обяснено в предишния блог. След като потребител изпълни командата add_peer, кодът за репликация създава инстанция на обект ReplicationSource за този партньор и всички регионални сървъри на главния клъстер се опитват да се свържат с регионалните сървъри на подчинения клъстер. Той също така извлича ClusterId на подчинения клъстер (UUID, регистриран в кворума на зоопарка на подчинения клъстер). Регионалният сървър на главния клъстер изброява наличните регионални сървъри на подчинения, като чете „/hbase/rs“ znode и неговите деца в кворума на zookeeper на подчинения клъстер и прави връзка с него. Всеки регионен сървър в главния клъстер избира подмножество от подчинените регионални сървъри, в зависимост от съотношението, определено от “replication.source.ratio”, със стойност по подразбиране 0.1. Това означава, че всеки регионален сървър на главния клъстер ще се опита да се свърже с 10% от общия регион сървър на подчинен клъстер. Докато изпраща пакета от транзакции, главният регионен сървър на клъстер ще избере произволен регионален сървър от тези свързани регионални сървъри. (Забележка:Репликацията не се извършва за каталожни таблици, .META. и _ROOT_.)
За да настроите режим главен-главен, горните стъпки трябва да се повторят и на двата клъстера.
Промяна на схема
Както бе споменато в предишния раздел, репликираната таблица и семейство колони трябва да съществуват и в двата клъстера. Този раздел обсъжда различни възможни сценарии за това какво се случва по време на промяна на схемата, когато репликацията все още е в ход:
a) Изтриване на семейството на колони в master:Изтриването на семейство колони няма да повлияе на репликацията на предстоящи мутации за това семейство. Това е така, защото кодът за репликация чете WAL и проверява обхвата на репликация на семействата колони за всеки WALEdit. Всеки WALEdit има карта на семействата колони с активирана репликация; проверката се извършва на цялото семейство от колони, съставляващо ключови стойности (независимо дали са с обхват или не). Ако присъства в картата, се добавя към пратката. Тъй като обектът WALEdit е създаден преди семейството колони да бъде изтрито, репликацията му няма да бъде засегната.
б) Изтриване на семейството колони в подчинен:WALEdits се изпращат от главния клъстер към конкретен подчинен регион сървър, който го обработва като нормален HBase клиент (използвайки обект HTablePool). Тъй като семейството на колоните е изтрито, операцията за поставяне ще бъде неуспешна и това изключение се прехвърля към главния регионен сървърен клъстер.
Стартиране/Спиране на репликацията
Командите Старт/Стоп работят като превключвател за изключване. Когато командата stop_replication се изпълни в обвивката на HBase, тя ще промени стойността на /hbase/replication/state на false. Той ще спре всички изходни обекти за репликация да четат регистрационните файлове; но съществуващите прочетени записи ще бъдат изпратени. Ако потребител използва командата за спиране на репликацията, новопрехвърлените регистрационни файлове няма да бъдат поставени в опашката за репликация. По същия начин, издаването на команда start_replication ще започне репликацията от текущия WAL (който може да съдържа някои предишни транзакции), а не от момента, в който е била издадена командата.
Фигура 1 обяснява поведението на превключвателя старт-стоп, при който последователността от събития протича в посоката на стрелките.
Съвместимост на версиите
Сървърите на региона на главния клъстер се свързват с регионалните сървъри на подчинен клъстер като нормални клиенти на HBase. Същото правило за съвместимост важи и за това дали HBase клиент на версия xxx се поддържа на HBase сървър на версия yyy.
От друга страна, тъй като репликацията все още се развива (все повече и повече функционалности се добавят непрекъснато към нея), потребителят трябва да е наясно със съществуващите функционалности. Например, в CDH4, който е базиран на клона HBase 0.92, има поддръжка за главен-главен и циклична репликация. Разрешаването/деактивирането на източника на репликация на ниво партньор се добавя в клона HBase 0.94.
Свързване на зареждане
Репликацията работи чрез четене на WAL на главните регионални сървъри на клъстера. Ако потребител иска да репликира стари данни, той може да изпълни команда copyTable (дефиниране на начална и крайна времева марка), като същевременно разрешава репликацията. Командата copyTable ще копира данните, обхванати от началните/крайните времеви марки, а репликацията ще се погрижи за текущите данни. Цялостният подход може да се обобщи като:
- Стартирайте репликацията (обърнете внимание на времевата марка).
- Изпълнете командата copyTable с крайно времеви клеймо, равно на горното.
- Тъй като репликацията започва от текущия WAL, може да има някои ключови стойности, които се копират в подчинен от заданията за репликация и copyTable. Това все още е наред, тъй като е идемпотентна операция.
В случай на репликация главен-главен, трябва да стартирате заданието copyTable, преди да стартирате репликацията. Това е така, защото ако потребителят започне работа с copyTable след разрешаване на репликация, вторият главен източник ще изпрати отново данните на първия главен, тъй като copyTable не редактира clusterId в обектите на мутацията. Цялостният подход може да се обобщи като:
- Изпълнете заданието copyTable, (обърнете внимание на началната дата на заданието).
- Стартирайте репликацията.
- Стартирайте отново copyTable с начален час, равен на началния час, отбелязан в стъпка 1.
Това също води до преместване на някои данни напред-назад между двата клъстера; но намалява размера му.
Толерантност на грешки
Отпадане на сървъра за региона на главния клъстер
Всички регионални сървъри в главния клъстер създават znode под „/hbase/replication/rs“, както е споменато в секцията Архитектура. Регионалният сървър добавя дъщерен znode за всеки WAL с байтово изместване под неговия znode в йерархията на репликация, както е показано на фигура 1. Ако регионен сървър се провали, други регионални сървъри трябва да се погрижат за регистрите на мъртвия регион сървър, които са изброени под това znode на регионалния сървър. Всички регионални сървъри наблюдават други регионални сървъри (“/hbase/rs”) znode; така че, когато регионалният сървър се повреди, други регионални сървъри ще получат събитието, тъй като master маркира този регионален сървър като мъртъв. В този случай всички други регионални сървъри се надпреварват да прехвърлят WAL от мъртъв регион сървър znode към своя znode и да му прикачат префикс с подчинен идентификатор и име на мъртъв регион сървър, за да се разграничат от другите нормални журнали. Отделен източник на репликация (екземпляр NodeFailoverWorker) се създава за прехвърлените регистрационни файлове, които умират след обработка на тези прехвърлени регистрационни файлове.
Ако разгледаме Фигура 1 от Обзора на репликацията на HBase като основна фигура на йерархията на репликационните znodes, Фигура 2 показва новата йерархия на znodes за репликация в случай, че сървърът foo1.bar.com умре и foo2.bar.com поеме неговата опашка. Обърнете внимание на новия znode „1-foo1.bar.com,40020,1339435481973“, който е създаден под 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/ /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.1339435485732 .bar.com,40020,1339435481742:/hbase/replication/rs/foo3.bar.com,40020,1339435481742/1:/hbase/replication/rs/foo3.bar.com,40020, 14137bar ... foo2.bar.com,40020, 1339435481742/1/foo2.bar..com.13394354343443:1909033 /hbase/replication/rs/foo2.bar.com,40020,1331743134040,13394334040,40020,1331743334040,133943134040400000000 /foo1.bar.com.1339435485769:1243232
Фигура 2. Йерархия на znodes при отказ на регионалния сървър
Междувременно разделянето на регистрационни файлове може да започне и да архивира регистрите на сървъра на мъртвия регион. Източникът на репликация търси регистрационните файлове както в обикновена, така и в архивирана директория.
Бавен/неотзивчив подчинен клъстер (или регионални сървъри)
Когато подчинен клъстер не работи или ако има временен мрежов дял, регистрационните файлове, които все още не са репликирани на подчинения, няма да бъдат изтрити от програмата за почистване на регистрационни файлове на HBase.
Почистването на журнала се обработва от клас LogCleaner, който продължава да работи след конфигурирано време. Кодът за репликация добавя плъгин ReplicationLogCleaner към класа LogCleaner. Когато последният се опита да изтрие конкретен дневник, ReplicationLogCleaner ще провери дали този дневник съществува в йерархията на znode на репликация (под /hbase/replication/rs/ znode). Ако регистрационният файл бъде намерен, това означава, че дневникът все още предстои да бъде репликиран и ще пропусне изтриването му. След като дневникът бъде репликиран, неговият znode ще бъде изтрит от йерархията на репликацията. При следващото си изпълнение LogCleaner ще изтрие успешно регистрационния файл, след като бъде репликиран.
Проверка
За по-малко количество данни, можете просто да потърсите редовете на таблицата с помощта на обвивката hbase в подчинения клъстер, за да проверите дали са репликирани или не. Стандартен начин за проверка е да стартирате заданието verifyrep mapreduce, което идва с HBase. Трябва да се изпълнява в главния клъстер и да изисква slave clusterId и името на целевата таблица. Може също така да се предоставят допълнителни аргументи като времеви печат за начало/стоп и семейства на колони. Той отпечатва два брояча, а именно GOODROWS и BADROWS, което означава съответно броя на репликираните и нерепликираните редове.
Показатели за репликация
Рамката за репликация разкрива някои полезни показатели, които могат да се използват за проверка на напредъка на репликацията. Някои от важните са:
- sizeOfLogQueue:брой HLlogs за обработка (с изключение на този, който се обработва) в източника на репликация
- shippedOpsRate:процент на изпратените мутации
- logEditsReadRate:процент на мутации, прочетени от HLogs при източника на репликация
- ageOfLastShippedOp:възраст на последната партида, която е била изпратена от източника на репликация
Бъдеща работа
С всички настоящи функции, присъстващи в текущата репликация на HBase, все още има поле за по-нататъшно подобрение. Тя варира от производителност, като например намаляване на забавянето на репликация между главен и подчинен, до по-стабилна обработка на повреда на регионалния сървър (HBase-2611). Допълнителни области на подобрение включват позволяване на репликация на таблица на ниво равностойност и правилно боравене с IncrementColumnValue (HBase-2804).
Заключение
Тази публикация обсъжда репликацията на HBase от гледна точка на оператора, включително конфигурация (на различни режими), стартиране на съществуващ клъстер, ефекти от промени в схемата и толерантност на грешки.
