Apache HBase Replication to sposób kopiowania danych z jednego klastra HBase do innego i prawdopodobnie odległego klastra HBase. Działa na zasadzie, że transakcje z klastra inicjującego są wypychane do innego klastra. W żargonie HBase klaster wykonujący push nazywa się master, a ten, który odbiera transakcje, nazywa się slave. To przesyłanie transakcji odbywa się asynchronicznie, a te transakcje są grupowane w konfigurowalnym rozmiarze (domyślnie 64 MB). Tryb asynchroniczny powoduje minimalne obciążenie urządzenia głównego, a edycje wysyłki w partii zwiększają ogólną przepustowość.
W tym wpisie na blogu omówiono możliwe przypadki użycia, podstawową architekturę i tryby replikacji HBase obsługiwane w CDH4 (opartym na 0,92). Omówimy konfigurację replikacji, ładowanie początkowe i odporność na błędy w kolejnym wpisie na blogu.
Przypadki użycia
Replikacja HBase obsługuje replikację danych w centrach danych. Można to wykorzystać w scenariuszach odzyskiwania po awarii, w których klaster podrzędny obsługuje ruch w czasie rzeczywistym w przypadku awarii witryny głównej. Ponieważ replikacja HBase nie jest przeznaczona do automatycznego przełączania awaryjnego, czynność przełączania z klastra master na klaster slave w celu rozpoczęcia obsługi ruchu jest wykonywana przez użytkownika. Następnie, po ponownym uruchomieniu klastra głównego, można wykonać zadanie CopyTable, aby skopiować delty do klastra głównego (podając sygnatury czasowe rozpoczęcia/zatrzymania), jak opisano we wpisie na blogu CopyTable.
Innym przypadkiem użycia replikacji jest sytuacja, gdy użytkownik chce uruchomić intensywne zadania MapReduce w klastrze HBase; można to zrobić na klastrze podrzędnym, mając jednocześnie niewielki spadek wydajności na klastrze głównym.
Architektura
Podstawową zasadą replikacji HBase jest odtworzenie wszystkich transakcji od urządzenia nadrzędnego do podrzędnego. Odbywa się to poprzez odtwarzanie wpisów WALEdit (wpisy dziennika zapisu z wyprzedzeniem) w warstwach WAL (dziennik zapisu z wyprzedzeniem) z klastra głównego, zgodnie z opisem w następnej sekcji. Te edycje WALEdit są wysyłane do serwerów regionu klastra podrzędnego po przefiltrowaniu (niezależnie od tego, czy określona zmiana jest objęta zakresem replikacji, czy nie) i dostarczeniu w niestandardowym rozmiarze partii (domyślnie 64 MB). W przypadku, gdy czytnik WAL osiągnie koniec bieżącego WAL, wyśle wszystko, co WALEdits przeczytano do tego czasu. Ponieważ jest to asynchroniczny tryb replikacji, klaster podrzędny może pozostawać w tyle w stosunku do urządzenia nadrzędnego w przypadku aplikacji o dużym obciążeniu zapisem o kilka minut.
WAL/WALEdits/Memstore
W HBase wszystkie operacje mutacji (Puts/Deletes) są zapisywane w pamięci, która należy do określonego regionu, a także dołączane do pliku dziennika zapisu z wyprzedzeniem (WAL) w postaci WALEdit. WALEdit to obiekt, który reprezentuje jedną transakcję i może mieć więcej niż jedną operację mutacji. Ponieważ HBase obsługuje transakcję na poziomie pojedynczego wiersza, jeden WALEdit może mieć wpisy tylko dla jednego wiersza. Warstwy WAL są wielokrotnie odtwarzane po skonfigurowanym okresie (wartość domyślna to 60 minut), tak że w danym momencie istnieje tylko jedna aktywna warstwa WAL na serwer regionu.
IncrementColumnValue, operacja CAS (sprawdzanie i zastępowanie), jest również konwertowana na Put podczas zapisywania do WAL.
Magazyn pamięci to posortowana mapa znajdująca się w pamięci, zawierająca kluczowe wartości regionu komponowania; istnieje jeden memstore na każdą rodzinę kolumn na region. Pamięć pamięci jest opróżniana na dysk jako plik HFile, gdy osiągnie skonfigurowany rozmiar (domyślnie 64 MB).
Zapisywanie do WAL jest opcjonalne, ale jest wymagane, aby uniknąć utraty danych, ponieważ w przypadku awarii serwera regionu HBase może utracić wszystkie magazyny pamięci hostowane na tym serwerze regionu. W przypadku awarii serwera regionalnego jego listy WAL są odtwarzane przez proces dzielenia dziennika w celu przywrócenia danych przechowywanych w warstwach WAL.
Aby replikacja działała, zapis do WAL musi być włączony.
Identyfikator klastra
Każdy klaster HBase ma clusterID, typ UUID generowany automatycznie przez HBase. Jest przechowywany w podstawowym systemie plików (zwykle HDFS), aby nie zmieniał się między restartami. Jest on przechowywany w strefie /hbase/hbaseid. Ten identyfikator jest używany do uzyskania replikacji master-master/acyklicznej. WAL zawiera wpisy dla wielu regionów, które są hostowane na serwerze regionu. Kod replikacji odczytuje wszystkie pary kluczy i odfiltrowuje te, które są objęte zakresem replikacji. Robi to, patrząc na atrybut rodziny kolumn pary klucz-wartość i dopasowując go do struktury danych mapy rodziny kolumn WALEdit. W przypadku, gdy określony klucz jest objęty zakresem replikacji, edytuje parametr clusterId pary klucza na identyfikator klastra HBase.
Źródło replikacji
ReplicationSource jest obiektem wątku Java w procesie regionalserver i jest odpowiedzialny za replikację wpisów WAL do określonego klastra podrzędnego. Ma kolejkę priorytetową, w której przechowywane są pliki dziennika, które mają zostać zreplikowane. Natychmiast po przetworzeniu dziennika jest on usuwany z kolejki. Kolejka priorytetowa używa komparatora, który porównuje pliki dziennika na podstawie ich znacznika czasu utworzenia (który jest dołączany do nazwy pliku dziennika); więc logi są przetwarzane w tej samej kolejności, w jakiej zostały utworzone (starsze logi są przetwarzane w pierwszej kolejności). Jeśli w kolejce priorytetowej znajduje się tylko jeden plik dziennika, nie zostanie on usunięty, ponieważ reprezentuje bieżący plik WAL.
Rola dozorcy
Zookeeper odgrywa kluczową rolę w replikacji HBase, gdzie zarządza/koordynuje prawie wszystkie główne działania replikacji, takie jak rejestrowanie klastra podrzędnego, uruchamianie/zatrzymywanie replikacji, kolejkowanie nowych warstw WAL, obsługa przełączania awaryjnego serwera regionu itp. Wskazane jest, aby mieć sprawny Kworum dozorców (co najmniej 3 lub więcej węzłów), tak aby było stale włączone. Zookeeper powinien być uruchamiany niezależnie (a nie przez HBase). Poniższy rysunek przedstawia przykładową strukturę znodes związaną z replikacją w klastrze głównym (tekst po dwukropku to dane strefy):
/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
Rysunek 1. Hierarchia węzłów replikacji
Jak na rysunku 1, w klastrze głównym znajdują się trzy serwery regionalne, a mianowicie foo[1-3].bar.com. Istnieją trzy strefy związane z replikacją:
- stan :Ten węzeł informuje, czy replikacja jest włączona, czy nie. Wszystkie podstawowe kroki (takie jak kolejkowanie nowo wylosowanego dziennika w kolejce replikacji, odczytanie pliku dziennika w celu wykonania wysyłek WALEdits itp.) Sprawdź tę wartość logiczną przed przetworzeniem. Jest to ustawiane przez ustawienie właściwości „hbase.replication” na true w hbase-conf.xml. Innym sposobem zmiany jego wartości jest użycie polecenia „uruchom/zatrzymaj replikację” w powłoce hbase. Zostanie to omówione w drugim poście na blogu.
- rówieśnicy :Ten węzeł ma podłączonych rówieśników/slave jako dzieci. Na rysunku jest jeden slave o identyfikatorze peerId =1, a jego wartością jest ciąg połączenia (Zookeeper_quorum_of_slave:Zookeeper_client_port:root_hbase_znode), gdzie Zookeeper_quorum_of_slave jest oddzieloną przecinkami listą serwerów zookeeper. Nazwa węzła peerId jest taka sama jak ta podana podczas dodawania peera.
- r :Ten znode zawiera listę aktywnych regionów serwerów w klastrze głównym. Każdy region znode serwera regionalnego ma listę warstw WAL, które mają zostać zreplikowane, a wartość tych węzłów dziennika jest albo null (w przypadku, gdy dziennik nie jest jeszcze otwarty do replikacji), albo jest przesunięty w bajtach do punktu, w którym dziennik został odczytany. Wartość przesunięcia bajtów dla węzła WAL wskazuje przesunięcie bajtów odpowiedniego pliku WAL, do którego został odczytany i zreplikowany. Ponieważ może istnieć więcej niż jeden klaster podrzędny, a postęp replikacji może się w nich różnić (na przykład jeden może być wyłączony), wszystkie warstwy WAL są samodzielne w znodzie peerId w ramach rs. Tak więc na powyższym rysunku węzły WAL znajdują się pod /rs//1, gdzie „1” jest identyfikatorem peerId.
Tryby replikacji
Istnieją trzy tryby konfiguracji HBase Replication:
- Master-Slave:W tym trybie replikacja jest wykonywana w jednym kierunku, tj. transakcje z jednego klastra są przesyłane do innego klastra. Zwróć uwagę, że klaster podrzędny jest taki sam jak każdy inny klaster i może mieć własne tabele, ruch itp.
- Master-Master:W tym trybie replikacja jest przesyłana w obu kierunkach, dla różnych lub tych samych tabel, tj. oba klastry działają zarówno jako master, jak i slave. W przypadku, gdy replikują tę samą tabelę, można pomyśleć, że może to prowadzić do niekończącej się pętli, ale można tego uniknąć, ustawiając identyfikator klastra mutacji (wstaw/usuń) na identyfikator klastra klastra, z którego pochodzi. Rysunek 2 wyjaśnia to za pomocą dwóch gromad, a mianowicie Słońca i Ziemi. Na rysunku 2 mamy dwa bloki reprezentujące dwa klastry HBase. Mają identyfikator klastra 100 i 200 odpowiednio. Każdy z klastrów ma instancję ReplicationSource, odpowiadającą klasterowi podrzędnemu, do którego chce przeprowadzić replikację; zna #Id klastrów obu klastrów.
Rysunek 2. Słońce i Ziemia, dwa klastry HBase
Załóżmy, że klaster#Słońce otrzymuje nową i prawidłową mutację M w rodzinie tabeli i kolumn, która jest objęta zakresem replikacji w obu klastrach. Będzie miał domyślny klasterID (0L). Wystąpienie źródła replikacji ReplicationSrc-E ustawi identyfikator klastra#Id równy identyfikatorowi nadawcy (100) i wyśle je do klastra#Earth. Kiedy klaster # Ziemia otrzyma mutację, odtwarza ją, a mutacja jest zapisywana w jego WAL, zgodnie z normalnym przepływem. Identyfikator klastra#Id mutacji jest zachowywany w tym pliku dziennika w klastrze#Earth. Wystąpienie źródła replikacji w klastrze#Earth, (ReplicationSrc-S odczyta mutację i sprawdzi swój klaster#ID z klastrem slaveCluster# (100, equal to cluster#Sun). Ponieważ są one równe, pominie ten wpis WALEdit.
- Cykliczny:W tym trybie w konfiguracji replikacji biorą udział więcej niż dwa klastry HBase, a pomiędzy dowolnymi dwoma klastrami można skonfigurować różne kombinacje master-slave i master-master. Powyższe dwa dobrze opisują te przypadki; jedna sytuacja narożna to sytuacja, w której ustawiliśmy cykl
Rysunek 3. Konfiguracja replikacji kołowej
Rysunek 3. przedstawia konfigurację replikacji cyklicznej, w której klaster#Słońce replikuje się do klastra#Ziemia, klaster#Earth replikuje się do klastra#Wenus, a klaster#Wenus replikuje się do klastra#Słońce.
Powiedzmy, że klaster#Słońce otrzymuje nową mutację M i jest objęty zakresem replikacji we wszystkich powyższych klastrach. Zostanie on zreplikowany do klastra#Earth, jak wyjaśniono powyżej w głównej replikacji głównej. Wystąpienie źródła replikacji w klastrze#Earth, ReplicationSrc-V, odczyta WAL, zobaczy mutację i zreplikuje ją do klastra#Wenus. Klaster#Id mutacji jest utrzymywany w stanie nienaruszonym (od klastra#Słońce), w klastrze#Venus. W tym klastrze instancja źródłowa replikacji dla klastra#Sun, ReplicationSrc-S, zobaczy, że mutacja ma ten sam identyfikator klastra, co jej slaveCluster# (od klastra#Sun), dlatego pominie to podczas replikacji.
Wniosek
HBase Replication to zaawansowana funkcja, której można użyć w scenariuszu odzyskiwania po awarii. Został dodany jako funkcja podglądu w wersji 0.90 i ogólnie ewoluował wraz z HBase, dodając funkcje, takie jak replikacja master-master, replikacja acykliczna (obie dodane w wersji 0.92) oraz włączanie i wyłączanie replikacji na poziomie równorzędnym (dodane w 0.94).
W następnym wpisie na blogu omówimy różne funkcje operacyjne, takie jak konfiguracja itp., I inne problemy związane z replikacją HBase.
