To jest drugi wpis na blogu dotyczący replikacji Apache HBase. W poprzednim wpisie na blogu, Przegląd replikacji HBase, omówiono przypadki użycia, architekturę i różne tryby obsługiwane w replikacji HBase. Ten wpis na blogu jest z perspektywy operacyjnej i będzie dotyczył konfiguracji replikacji HBase oraz kluczowych pojęć związanych z jej używaniem — takich jak ładowanie początkowe, zmiana schematu i odporność na błędy.
Konfiguracja
Jak wspomniano w omówieniu replikacji HBase, klaster główny wysyła dostawę WALEdits do jednego lub większej liczby klastrów podrzędnych. Ta sekcja opisuje kroki potrzebne do skonfigurowania replikacji w trybie master-slave.
- Wszystkie rodziny tabel/kolumn, które mają być replikowane, muszą istnieć w obu klastrach.
- Dodaj następującą właściwość w $HBASE_HOME/conf/hbase-site.xml na wszystkich węzłach w obu klastrach; ustaw to na prawda.
hbase.replication
prawda
W klastrze głównym wprowadź następujące dodatkowe zmiany:
- Ustaw zakres replikacji (REPLICATION_SCOPE atrybut) w rodzinie tabeli/kolumn, która ma zostać zreplikowana:
hbase shell> wyłącz „tabela”
hbase shell> alter ‘table’, {NAME => ‘column-family’, REPLICATION_SCOPE => 1}
hbase shell> włącz „tabela”
REPLICATION_SCOPE to atrybut na poziomie rodziny kolumn, a jego wartość może wynosić 0 lub 1. Wartość 0 oznacza, że replikacja jest wyłączona, a 1 oznacza, że replikacja jest włączona. Użytkownik musi zmienić każdą rodzinę kolumn za pomocą polecenia alter, jak pokazano powyżej, dla wszystkich rodzin kolumn, które chce replikować.
Jeżeli użytkownik chce włączyć replikację podczas tworzenia tabeli, powinien użyć następującego polecenia:
hbase shell> utwórz „tabele”, „rodzina-kolumn1”, „rodzina-kolumn2”, {NAME => „rodzina-kolumn1”, REPLICATION_SCOPE => 1}
Powyższe polecenie włączy replikację na „kolumna-rodzina1” powyższej tabeli.
2. W powłoce hbase dodaj peera podrzędnego. Użytkownik powinien dostarczyć kworum zookeepera klastra podrzędnego, jego port klienta i główny węzeł hbase wraz z identyfikatorem peerId:
hbase shell>add_peer ‘peerId’, „::”
Id peerId jest ciągiem o długości jednego lub dwóch znaków, a odpowiadający mu węzeł jest tworzony w obszarze węzła peers, jak wyjaśniono w poprzednim blogu. Gdy użytkownik uruchomi polecenie add_peer, kod replikacji tworzy instancję obiektu ReplicationSource dla tego elementu równorzędnego, a wszystkie serwery regionów klastra głównego próbują połączyć się z serwerami regionów klastra podrzędnego. Pobiera również ClusterId klastra podrzędnego (UUID, zarejestrowany w kworum opiekunów klastra podrzędnego). Serwer regionu klastra głównego wyświetla listę dostępnych serwerów podrzędnych, odczytując „/hbase/rs” znode i jego elementy podrzędne w kworum opiekunów klastra podrzędnego i nawiązuje z nim połączenie. Każdy serwer regionu w klastrze głównym wybiera podzbiór z serwerów regionów podrzędnych, w zależności od współczynnika określonego przez „replication.source.ratio” z domyślną wartością 0,1. Oznacza to, że każdy regionalny serwer klastra głównego będzie próbował połączyć się z 10% wszystkich serwerów regionalnych klastra podrzędnego. Podczas wysyłania partii transakcji serwer regionu głównego klastra wybierze losowy serwer regionu z tych połączonych serwerów regionów. (Uwaga:replikacja nie jest wykonywana dla tabel katalogu, .META. i _ROOT_.)
Aby skonfigurować tryb master-master, powyższe kroki należy powtórzyć w obu klastrach.
Zmiana schematu
Jak wspomniano w poprzedniej sekcji, zreplikowana rodzina tabeli i kolumn musi istnieć w obu klastrach. W tej sekcji omówiono różne możliwe scenariusze dotyczące tego, co dzieje się podczas zmiany schematu, gdy replikacja jest nadal w toku:
a) Usuń rodzinę kolumn w master:Usunięcie rodziny kolumn nie wpłynie na replikację żadnych oczekujących mutacji dla tej rodziny. Dzieje się tak, ponieważ kod replikacji odczytuje WAL i sprawdza zakres replikacji rodzin kolumn dla każdego WALEdit. Każdy WALEdit ma mapę rodzin kolumn z włączoną replikacją; sprawdzanie jest przeprowadzane na całej rodzinie kolumn tworzącej parę kluczową (niezależnie od tego, czy są objęte zakresem, czy nie). Jeśli jest obecny na mapie, zostanie dodany do przesyłki. Ponieważ obiekt WALEdit jest tworzony przed usunięciem rodziny kolumn, nie ma to wpływu na jego replikację.
b) Usuń rodzinę kolumn w urządzeniu podrzędnym:WALEdits są wysyłane z klastra głównego do określonego serwera regionu podrzędnego, który przetwarza go jak normalny klient HBase (przy użyciu obiektu HTablePool). Ponieważ rodzina kolumn została usunięta, operacja put nie powiedzie się, a wyjątek zostanie zgłoszony do głównego klastra regionalserver.
Rozpocznij/zatrzymaj replikację
Polecenia Start/Stop działają jak wyłącznik awaryjny. Gdy polecenie stop_replication zostanie uruchomione w powłoce HBase, zmieni wartość /hbase/replication/state na false. Spowoduje to zatrzymanie odczytywania dzienników przez wszystkie obiekty źródłowe replikacji; ale istniejące odczytane wpisy zostaną wysłane. Jeśli użytkownik użyje polecenia zatrzymania replikacji, nowo wylosowane dzienniki nie zostaną umieszczone w kolejce do replikacji. Podobnie, wydanie polecenia start_replication uruchomi replikację z bieżącego WAL-a (który może zawierać niektóre wcześniejsze transakcje), a nie od momentu wydania polecenia.
Rysunek 1 wyjaśnia zachowanie przełącznika start-stop, w którym sekwencja zdarzeń przebiega zgodnie z kierunkiem strzałek.
Zgodność wersji
Główne serwery regionów klastra łączą się z podrzędnymi serwerami regionów klastra jako normalni klienci HBase. Ta sama zasada zgodności dotyczy tego, czy klient HBase w wersji xxx jest obsługiwany na serwerze HBase w wersji yyy.
Z drugiej strony, ponieważ replikacja wciąż ewoluuje (coraz więcej funkcjonalności jest do niej dodawanych), użytkownik powinien być świadomy istniejących funkcjonalności. Na przykład w CDH4, który jest oparty na gałęzi HBase 0.92, istnieje wsparcie dla master-master i replikacji cyklicznej. Włączanie/wyłączanie źródła replikacji na poziomie równorzędnym zostało dodane w gałęzi HBase 0.94.
Pasowanie rozruchowe
Replikacja działa poprzez odczytywanie warstw WAL głównych serwerów regionów klastra. Jeśli użytkownik chce zreplikować stare dane, może uruchomić polecenie copyTable (określające znacznik czasu rozpoczęcia i zakończenia), jednocześnie włączając replikację. Polecenie copyTable skopiuje dane objęte zakresem znaczników czasu początku/końca, a replikacja zajmie się bieżącymi danymi. Ogólne podejście można podsumować jako:
- Rozpocznij replikację (zwróć uwagę na znacznik czasu).
- Uruchom polecenie copyTable z końcowym znacznikiem czasu równym powyższemu znacznikowi czasu.
- Ponieważ replikacja rozpoczyna się od bieżącego WAL, mogą istnieć pewne pary kluczy, które są kopiowane do urządzenia podrzędnego zarówno przez zadania replikacji, jak i zadania copyTable. To nadal jest w porządku, ponieważ jest to operacja idempotentna.
W przypadku replikacji master-master, przed rozpoczęciem replikacji należy uruchomić zadanie copyTable. Dzieje się tak, ponieważ jeśli użytkownik uruchomi zadanie copyTable po włączeniu replikacji, drugi wzorzec ponownie wyśle dane do pierwszego wzorca, ponieważ copyTable nie edytuje identyfikatora klastra w obiektach mutacji. Ogólne podejście można podsumować jako:
- Uruchom zadanie copyTable (zwróć uwagę na datę rozpoczęcia zadania).
- Rozpocznij replikację.
- Uruchom copyTable ponownie z czasem rozpoczęcia równym czasowi rozpoczęcia zanotowanemu w kroku 1.
Pociąga to za sobą również przekazywanie niektórych danych między dwoma klastrami; ale minimalizuje jego rozmiar.
Tolerancja błędów
Przełączanie awaryjne serwera regionu klastra głównego
Wszystkie regiony w klastrze głównym tworzą znode w „/hbase/replication/rs”, jak wspomniano w sekcji Architektura. Regionserver dodaje podrzędny znode dla każdego WAL, z przesunięciem bajtowym pod jego znode w hierarchii replikacji, jak pokazano na rysunku 1. Jeśli serwer regionu ulegnie awarii, inne regiony muszą zająć się dziennikami martwego serwera regionu, które są wymienione poniżej znode serwera regionu. Wszystkie regiony serwery śledzą inne regiony zwęzły („/hbase/rs”) znode; więc gdy serwer regionu ulegnie awarii, inne serwery regionów otrzymają zdarzenie jako główne, oznaczając ten serwer regionu jako martwy. W tym przypadku wszystkie inne serwery regionów dążą do przeniesienia WAL z martwego serwera regionu znode do ich znode i dołączają go przedrostkiem z identyfikatorem podrzędnym i nazwą martwego serwera regionu, aby odróżnić je od innych normalnych dzienników. Dla przesyłanych dzienników tworzone jest oddzielne źródło replikacji (instancja NodeFailoverWorker), które umiera po przetworzeniu tych przesłanych dzienników.
Jeśli weźmiemy pod uwagę rysunek 1 przeglądu replikacji HBase jako podstawowy rysunek hierarchii znodes replikacji, rysunek 2. przedstawia nową hierarchię znodes replikacji na wypadek śmierci serwera foo1.bar.com i przejęcia jego kolejki przez foo2.bar.com. Zwróć uwagę na nowy węzeł „1-foo1.bar.com,40020,1339435481973”, który jest tworzony w ramach węzła foo2.bar.com
/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
Rysunek 2. Hierarchia węzłów przełączania awaryjnego serwera regionalnego
W międzyczasie dzielenie logów może rozpocząć się i może archiwizować logi serwera martwego regionu. Źródło replikacji szuka dzienników zarówno w zwykłym, jak i zarchiwizowanym katalogu.
Powolny/nieodpowiadający klaster podrzędny (lub serwery regionalne)
Gdy klaster podrzędny nie działa lub istnieje tymczasowa partycja sieciowa, logi, które nie zostały jeszcze zreplikowane do podrzędnego, nie zostaną usunięte przez narzędzie do czyszczenia dzienników HBase.
Czyszczenie dziennika jest obsługiwane przez klasę LogCleaner, która działa po skonfigurowanym czasie. Kod replikacji dodaje wtyczkę ReplicationLogCleaner do klasy LogCleaner. Gdy ten ostatni próbuje usunąć określony dziennik, ReplicationLogCleaner sprawdzi, czy ten dziennik istnieje w hierarchii znode replikacji (w /hbase/replication/rs/znode). Jeśli dziennik zostanie znaleziony, oznacza to, że dziennik nie został jeszcze zreplikowany i pominie jego usunięcie. Po zreplikowaniu dziennika jego znode zostanie usunięty z hierarchii replikacji. W następnym uruchomieniu LogCleaner pomyślnie usunie plik dziennika po jego replikacji.
Weryfikacja
W przypadku mniejszej ilości danych można po prostu wyszukać wiersze tabeli za pomocą powłoki hbase w klastrze podrzędnym, aby sprawdzić, czy są one replikowane, czy nie. Standardowym sposobem weryfikacji jest uruchomienie zadania mapreduce Verifyrep, które jest dostarczane z HBase. Powinien być uruchamiany w klastrze głównym i wymagać identyfikatora klastra podrzędnego oraz nazwy tabeli docelowej. Można również podać dodatkowe argumenty, takie jak znacznik czasu rozpoczęcia/zatrzymania i rodziny kolumn. Wypisuje dwa liczniki, a mianowicie GOODROWS i BADROWS, oznaczające odpowiednio liczbę replikowanych i niereplikowanych wierszy.
Wskaźniki replikacji
Struktura replikacji udostępnia kilka przydatnych metryk, których można użyć do sprawdzenia postępu replikacji. Niektóre z najważniejszych to:
- sizeOfLogQueue:liczba HLlogów do przetworzenia (z wyłączeniem tego, który jest przetwarzany) w źródle replikacji
- shippedOpsRate:wskaźnik wysłanych mutacji
- logEditsReadRate:współczynnik mutacji odczytywanych z HLlogs w źródle replikacji
- ageOfLastShippedOp:wiek ostatniej partii, która została wysłana przez źródło replikacji
Praca w przyszłości
Z wszystkimi obecnymi funkcjami obecnymi w obecnej replikacji HBase nadal istnieje pole do dalszych ulepszeń. Różni się od wydajności, takiej jak zmniejszenie opóźnienia replikacji między serwerem głównym i podrzędnym, do bardziej niezawodnej obsługi awarii serwera regionu (HBase-2611). Dalsze obszary ulepszeń obejmują umożliwienie replikacji tabel na poziomie równorzędnym i właściwą obsługę IncrementColumnValue (HBase-2804).
Wniosek
W tym poście omówiono replikację HBase z punktu widzenia operatora, w tym konfigurację (różnych trybów), uruchamianie istniejącego klastra, skutki zmian schematu i odporność na błędy.
