Konfigurowanie replikacji klastra Apache HBase w sieciach wirtualnych platformy Azure
Dowiedz się, jak skonfigurować replikację bazy danych Apache HBase w sieci wirtualnej lub między dwiema sieciami wirtualnymi na platformie Azure.
Replikacja klastra używa metodologii wypychania źródłowego. Klaster HBase może być źródłem lub miejscem docelowym lub może jednocześnie spełniać obie role. Replikacja jest asynchroniczna. Celem replikacji jest spójność ostateczna. Gdy źródło odbiera edycję do rodziny kolumn po włączeniu replikacji, edycja jest propagowana do wszystkich klastrów docelowych. Gdy dane są replikowane z jednego klastra do innego, klaster źródłowy i wszystkie klastry, które już używają śledzonych danych, aby zapobiec pętli replikacji.
W tym artykule skonfigurowaliśmy replikację źródłową. Aby zapoznać się z innymi topologiami klastrów, zobacz przewodnik referencyjny apache HBase.
Poniżej przedstawiono przypadki użycia replikacji bazy danych HBase dla pojedynczej sieci wirtualnej:
- Równoważenie obciążenia. Można na przykład uruchamiać skanowania lub zadania MapReduce w klastrze docelowym i pozyskiwać dane w klastrze źródłowym.
- Dodawanie wysokiej dostępności.
- Migrowanie danych z jednego klastra HBase do innego.
- Uaktualnianie klastra usługi Azure HDInsight z jednej wersji do innej.
Poniżej przedstawiono przypadki użycia replikacji bazy danych HBase dla dwóch sieci wirtualnych:
- Konfigurowanie odzyskiwania po awarii.
- Równoważenie obciążenia i partycjonowanie aplikacji.
- Dodawanie wysokiej dostępności.
Klastry można replikować przy użyciu skryptów akcji z usługi GitHub.
Wymagania wstępne
Przed rozpoczęciem tego artykułu musisz mieć subskrypcję platformy Azure. Zobacz Uzyskiwanie bezpłatnej wersji próbnej platformy Azure.
Konfigurowanie środowisk
Dostępne są trzy opcje konfiguracji:
- Dwa klastry Apache HBase w jednej sieci wirtualnej platformy Azure.
- Dwa klastry Apache HBase w dwóch różnych sieciach wirtualnych w tym samym regionie.
- Dwa klastry Apache HBase w dwóch różnych sieciach wirtualnych w dwóch różnych regionach (replikacja geograficzna).
W tym artykule opisano scenariusz replikacji geograficznej.
Aby ułatwić konfigurowanie środowisk, utworzyliśmy kilka szablonów usługi Azure Resource Manager. Jeśli wolisz skonfigurować środowiska przy użyciu innych metod, zobacz:
- Tworzenie klastrów Apache Hadoop w usłudze HDInsight
- Tworzenie klastrów Apache HBase w usłudze Azure Virtual Network
Konfigurowanie dwóch sieci wirtualnych w dwóch różnych regionach
Aby użyć szablonu, który tworzy dwie sieci wirtualne w dwóch różnych regionach i połączenie sieci VPN między sieciami wirtualnymi, wybierz następujący przycisk Wdróż na platformie Azure .
Niektóre z zakodowanych wartości w szablonie:
Sieć wirtualna 1
Właściwości | Wartość |
---|---|
Lokalizacja | Zachodnie stany USA |
Nazwa sieci wirtualnej | <Nazwa_klastraPrevix-vnet1> |
Prefiks przestrzeni adresowej | 10.1.0.0/16 |
Nazwa podsieci | podsieć 1 |
Prefiks podsieci | 10.1.0.0/24 |
Nazwa podsieci (bramy) | GatewaySubnet (nie można go zmienić) |
Prefiks podsieci (bramy) | 10.1.255.0/27 |
Nazwa bramy | vnet1gw |
Typ bramy | Vpn |
Typ sieci VPN bramy | RouteBased |
Jednostka SKU bramy | Podstawowy |
Adres IP bramy | vnet1gwip |
Sieć wirtualna 2
Właściwości | Wartość |
---|---|
Lokalizacja | Wschodnie stany USA |
Nazwa sieci wirtualnej | <Nazwa_klastraPrevix-vnet2> |
Prefiks przestrzeni adresowej | 10.2.0.0/16 |
Nazwa podsieci | podsieć 1 |
Prefiks podsieci | 10.2.0.0/24 |
Nazwa podsieci (bramy) | GatewaySubnet (nie można go zmienić) |
Prefiks podsieci (bramy) | 10.2.255.0/27 |
Nazwa bramy | vnet2gw |
Typ bramy | Vpn |
Typ sieci VPN bramy | RouteBased |
Jednostka SKU bramy | Podstawowy |
Adres IP bramy | vnet1gwip |
Alternatywnie wykonaj poniższe kroki, aby ręcznie skonfigurować dwie różne sieci wirtualne i maszyny wirtualne
- Tworzenie dwóch sieci wirtualnych (sieci wirtualnej) w innym regionie
- Włącz komunikację równorzędną w obu sieciach wirtualnych. Przejdź do pozycji Sieć wirtualna utworzona w powyższych krokach, a następnie kliknij pozycję Komunikacja równorzędna i dodaj link komunikacji równorzędnej w innym regionie. Zrób to zarówno dla sieci wirtualnej.
- Utwórz najnowszą wersję systemu UBUNTU w każdej sieci wirtualnej.
Konfigurowanie systemu DNS
W ostatniej sekcji szablon tworzy maszynę wirtualną z systemem Ubuntu w każdej z dwóch sieci wirtualnych. W tej sekcji zainstalujesz powiązanie na dwóch maszynach wirtualnych DNS, a następnie skonfigurujesz przekazywanie DNS na dwóch maszynach wirtualnych.
Aby zainstalować usługę Bind, yon musi znaleźć publiczny adres IP dwóch maszyn wirtualnych DNS.
- Otwórz portal Azure Portal.
- Otwórz maszynę wirtualną DNS, wybierając pozycję Grupy > zasobów [nazwa grupy zasobów] > [vnet1DNS]. Nazwa grupy zasobów to nazwa utworzona w ostatniej procedurze. Domyślne nazwy maszyn wirtualnych DNS to vnet1DNS i vnet2NDS.
- Wybierz pozycję Właściwości , aby otworzyć stronę właściwości sieci wirtualnej.
- Zapisz publiczny adres IP, a także zweryfikuj prywatny adres IP. Prywatny adres IP musi mieć wartość 10.1.0.4 dla sieci vnet1DNS i 10.2.0.4 dla sieci vnet2DNS.
- Zmień serwery DNS dla obu sieci wirtualnych, aby używać domyślnych (azure-provided) serwerów DNS, aby zezwolić na dostęp przychodzący i wychodzący do pobierania pakietów w celu zainstalowania powiązania w poniższych krokach.
Aby zainstalować powiązanie, wykonaj następującą procedurę:
Użyj protokołu SSH, aby nawiązać połączenie z publicznym adresem IP maszyny wirtualnej DNS. Poniższy przykład nawiązuje połączenie z maszyną wirtualną pod adresem 40.68.254.142:
ssh sshuser@40.68.254.142
Zastąp
sshuser
ciąg kontem użytkownika SSH określonym podczas tworzenia maszyny wirtualnej DNS.Uwaga
Istnieje wiele sposobów uzyskania
ssh
narzędzia. W systemach Linux, Unix i macOS jest on dostarczany jako część systemu operacyjnego. Jeśli używasz systemu Windows, rozważ jedną z następujących opcji:Aby zainstalować program Bind, użyj następujących poleceń z sesji SSH:
sudo apt-get update -y sudo apt-get install bind9 -y
Skonfiguruj powiązanie z przekazywaniem żądań rozpoznawania nazw do lokalnego serwera DNS. W tym celu użyj następującego tekstu jako zawartości
/etc/bind/named.conf.options
pliku:acl goodclients { 10.1.0.0/16; # Replace with the IP address range of the virtual network 1 10.2.0.0/16; # Replace with the IP address range of the virtual network 2 localhost; localhost; }; options { directory "/var/cache/bind"; recursion yes; allow-query { goodclients; }; forwarders { 168.63.129.16; #This is the Azure DNS server }; dnssec-validation auto; auth-nxdomain no; # conform to RFC1035 listen-on-v6 { any; }; };
Ważne
Zastąp wartości w
goodclients
sekcji zakresem adresów IP dwóch sieci wirtualnych. W tej sekcji zdefiniowano adresy, z których ten serwer DNS akceptuje żądania.Aby edytować ten plik, użyj następującego polecenia:
sudo nano /etc/bind/named.conf.options
Aby zapisać plik, użyj Ctrl+X, Y, a następnie wprowadź.
W sesji SSH użyj następującego polecenia:
hostname -f
To polecenie zwraca wartość podobną do następującego tekstu:
vnet1DNS.icb0d0thtw0ebifqt0g1jycdxd.ex.internal.cloudapp.net
Tekst
icb0d0thtw0ebifqt0g1jycdxd.ex.internal.cloudapp.net
jest sufiksem DNS dla tej sieci wirtualnej. Zapisz tę wartość, ponieważ jest używana później.Należy również znaleźć sufiks DNS z innego serwera DNS. Potrzebujesz go w następnym kroku.
Aby skonfigurować powiązanie w celu rozpoznawania nazw DNS dla zasobów w sieci wirtualnej, użyj następującego tekstu jako zawartości
/etc/bind/named.conf.local
pliku:// Replace the following with the DNS suffix for your virtual network zone "v5ant3az2hbe1edzthhvwwkcse.bx.internal.cloudapp.net" { type forward; forwarders {10.2.0.4;}; # The Azure recursive resolver };
Ważne
Musisz zastąpić sufiks
v5ant3az2hbe1edzthhvwwkcse.bx.internal.cloudapp.net
DNS innej sieci wirtualnej. A adres IP usługi przesyłania dalej jest prywatnym adresem IP serwera DNS w innej sieci wirtualnej.Aby edytować ten plik, użyj następującego polecenia:
sudo nano /etc/bind/named.conf.local
Aby zapisać plik, użyj Ctrl+X, Y, a następnie wprowadź.
Aby uruchomić powiązanie, użyj następującego polecenia:
sudo service bind9 restart
Aby sprawdzić, czy powiązanie może rozpoznać nazwy zasobów w innej sieci wirtualnej, użyj następujących poleceń:
sudo apt install dnsutils nslookup vnet2dns.v5ant3az2hbe1edzthhvwwkcse.bx.internal.cloudapp.net
Ważne
Zastąp
vnet2dns.v5ant3az2hbe1edzthhvwwkcse.bx.internal.cloudapp.net
element w pełni kwalifikowaną nazwą domeny (FQDN) maszyny wirtualnej DNS w innej sieci.Zastąp
10.2.0.4
element wewnętrznym adresem IP niestandardowego serwera DNS w innej sieci wirtualnej.Odpowiedź jest podobna do następującego tekstu:
Server: 10.2.0.4 Address: 10.2.0.4#53 Non-authoritative answer: Name: vnet2dns.v5ant3az2hbe1edzthhvwwkcse.bx.internal.cloudapp.net Address: 10.2.0.4
Do tej pory nie można wyszukać adresu IP z innej sieci bez określonego adresu IP serwera DNS.
Konfigurowanie sieci wirtualnej do używania niestandardowego serwera DNS
Aby skonfigurować sieć wirtualną do używania niestandardowego serwera DNS zamiast rekursywnego rozpoznawania nazw platformy Azure, wykonaj następujące kroki:
W witrynie Azure Portal wybierz sieć wirtualną, a następnie wybierz pozycję Serwery DNS.
Wybierz pozycję Niestandardowy i wprowadź wewnętrzny adres IP niestandardowego serwera DNS. Na koniec wybierz pozycję Zapisz.
Otwórz maszynę wirtualną serwera DNS w sieci vnet1, a następnie kliknij przycisk Uruchom ponownie. Aby konfiguracja DNS weszła w życie, należy ponownie uruchomić wszystkie maszyny wirtualne w sieci wirtualnej.
Powtórz kroki konfigurowania niestandardowego serwera DNS dla sieci vnet2.
Aby przetestować konfigurację DNS, można nawiązać połączenie z dwiema maszynami wirtualnymi DNS przy użyciu protokołu SSH i wysłać polecenie ping do serwera DNS innej sieci wirtualnej przy użyciu nazwy hosta. Jeśli nie działa, użyj następującego polecenia, aby sprawdzić stan DNS:
sudo service bind9 status
Tworzenie klastrów Apache HBase
Utwórz klaster Apache HBase w każdej z dwóch sieci wirtualnych z następującą konfiguracją:
- Nazwa grupy zasobów: użyj tej samej nazwy grupy zasobów, która została utworzona w sieciach wirtualnych.
- Typ klastra: HBase
- Wersja: HBase 1.1.2 (HDI 3.6)
- Lokalizacja: użyj tej samej lokalizacji co sieć wirtualna. Domyślnie sieć vnet1 to Zachodnie stany USA, a sieć vnet2 to Wschodnie stany USA.
- Magazyn: utwórz nowe konto magazynu dla klastra.
- Sieć wirtualna (w obszarze Ustawienia zaawansowane w portalu): wybierz sieć vnet1 utworzoną w ostatniej procedurze.
- Podsieć: domyślna nazwa używana w szablonie to subnet1.
Aby upewnić się, że środowisko jest poprawnie skonfigurowane, musisz mieć możliwość ping nazwy FQDN węzła głównego między dwoma klastrami.
Ładowanie danych testowych
Podczas replikacji klastra należy określić tabele, które mają być replikowane. W tej sekcji załadujesz dane do klastra źródłowego. W następnej sekcji włączysz replikację między dwoma klastrami.
Aby utworzyć tabelę Kontakty i wstawić dane w tabeli, postępuj zgodnie z instrukcjami w samouczku apache HBase: Rozpoczynanie korzystania z bazy danych Apache HBase w usłudze HDInsight.
Uwaga
Jeśli chcesz replikować tabele z niestandardowej przestrzeni nazw, upewnij się, że odpowiednie niestandardowe przestrzenie nazw są również zdefiniowane w klastrze docelowym.
Włączanie replikacji
W poniższych krokach opisano sposób wywoływania skryptu akcji w witrynie Azure Portal. Aby uzyskać informacje na temat uruchamiania akcji skryptu przy użyciu programu Azure PowerShell i klasycznego interfejsu wiersza polecenia platformy Azure, zobacz Dostosowywanie klastrów usługi HDInsight przy użyciu akcji skryptu.
Aby włączyć replikację bazy danych HBase w witrynie Azure Portal
Zaloguj się w witrynie Azure Portal.
Otwórz źródłowy klaster HBase.
W menu klastra wybierz pozycję Akcje skryptu.
W górnej części strony wybierz pozycję Prześlij nowy.
Wybierz lub wprowadź następujące informacje:
- Nazwa: wprowadź włącz replikację.
- Adres URL skryptu powłoki Bash: wprowadź .https://raw.githubusercontent.com/Azure/hbase-utils/master/replication/hdi_enable_replication.sh
- Nagłówek: Upewnij się, że ten parametr jest zaznaczony. Wyczyść inne typy węzłów.
- Parametry: Następujące przykładowe parametry umożliwiają replikację dla wszystkich istniejących tabel, a następnie skopiuj wszystkie dane z klastra źródłowego do klastra docelowego:
-m hn1 -s <source hbase cluster name> -d <destination hbase cluster name> -sp <source cluster Ambari password> -dp <destination cluster Ambari password> -copydata
Uwaga
Użyj nazwy hosta zamiast nazwy FQDN zarówno dla źródłowej, jak i docelowej nazwy DNS klastra.
W tym przewodniku przyjęto założenie, że hn1 jest aktywnym węzłem głównym. Sprawdź klaster, aby zidentyfikować aktywny węzeł główny.
Wybierz pozycję Utwórz. Uruchomienie skryptu może zająć trochę czasu, zwłaszcza w przypadku użycia argumentu -copydata .
Wymagane argumenty:
Nazwa/nazwisko | opis |
---|---|
-s, --src-cluster | Określa nazwę DNS źródłowego klastra HBase. Na przykład: -s hbsrccluster, --src-cluster=hbsrccluster |
-d, --dst-cluster | Określa nazwę DNS klastra HBase docelowego (repliki). Na przykład: -s dsthbcluster, --src-cluster=dsthbcluster |
-sp, --src-ambari-password | Określa hasło administratora systemu Ambari w źródłowym klastrze HBase. |
-dp, --dst-ambari-password | Określa hasło administratora systemu Ambari w docelowym klastrze HBase. |
Argumenty opcjonalne:
Nazwa/nazwisko | opis |
---|---|
-su, --src-ambari-user | Określa nazwę użytkownika administratora systemu Ambari w źródłowym klastrze HBase. Wartością domyślną jest administrator. |
-du, --dst-ambari-user | Określa nazwę użytkownika administratora systemu Ambari w docelowym klastrze HBase. Wartością domyślną jest administrator. |
-t, --table-list | Określa tabele, które mają być replikowane. Na przykład: --table-list="table1; table2; table3". Jeśli nie określisz tabel, wszystkie istniejące tabele bazy danych HBase zostaną zreplikowane. |
-m, --machine | Określa węzeł główny, w którym jest uruchamiana akcja skryptu. Wartość należy wybrać na podstawie tego, na którym jest aktywny węzeł główny. Użyj tej opcji, gdy uruchamiasz skrypt $0 jako akcję skryptu z portalu usługi HDInsight lub programu Azure PowerShell. |
-cp, -copydata | Umożliwia migrację istniejących danych w tabelach, w których włączono replikację. |
-rpm, -replicate-phoenix-meta | Włącza replikację w tabelach systemowych Phoenix. Użyj tej opcji z ostrożnością. Zalecamy ponowne utworzenie tabel Phoenix w klastrach replik przed użyciem tego skryptu. |
-h, --help | Wyświetla informacje o użyciu. |
Sekcja print_usage()
skryptu zawiera szczegółowe wyjaśnienie parametrów.
Po pomyślnym wdrożeniu akcji skryptu można użyć protokołu SSH do nawiązania połączenia z docelowym klastrem HBase, a następnie sprawdzić, czy dane zostały zreplikowane.
Scenariusze replikacji
Na poniższej liście przedstawiono niektóre ogólne przypadki użycia i ich ustawienia parametrów:
Włącz replikację we wszystkich tabelach między dwoma klastrami. Ten scenariusz nie wymaga kopiowania ani migrowania istniejących danych w tabelach i nie korzysta z tabel Phoenix. Użyj następujących parametrów:
-m hn1 -s <source hbase cluster name> -d <destination hbase cluster name> -sp <source cluster Ambari password> -dp <destination cluster Ambari password>
Włącz replikację dla określonych tabel. Aby włączyć replikację w tabeli table1, table2 i table3, użyj następujących parametrów:
-m hn1 -s <source hbase cluster name> -d <destination hbase cluster name> -sp <source cluster Ambari password> -dp <destination cluster Ambari password> -t "table1;table2;table3"
Włącz replikację dla określonych tabel i skopiuj istniejące dane. Aby włączyć replikację w tabeli table1, table2 i table3, użyj następujących parametrów:
-m hn1 -s <source hbase cluster name> -d <destination hbase cluster name> -sp <source cluster Ambari password> -dp <destination cluster Ambari password> -t "table1;table2;table3" -copydata
Włącz replikację we wszystkich tabelach i zreplikuj metadane Phoenix ze źródła do miejsca docelowego. Replikacja metadanych phoenix nie jest idealna. Należy go używać z ostrożnością. Użyj następujących parametrów:
-m hn1 -s <source hbase cluster name> -d <destination hbase cluster name> -sp <source cluster Ambari password> -dp <destination cluster Ambari password> -t "table1;table2;table3" -replicate-phoenix-meta
Konfigurowanie replikacji między klastrami ESP
Wymagania wstępne
- Oba klastry ESP powinny znajdować się w tym samym obszarze (domenie). Sprawdź
/etc/krb5.conf
domyślną właściwość obszaru pliku, aby potwierdzić. - Wspólny użytkownik powinien mieć dostęp do odczytu i zapisu w obu klastrach
- Jeśli na przykład oba klastry mają tego samego użytkownika administratora klastra (na przykład
admin@abc.example.com
), ten użytkownik może służyć do uruchamiania skryptu replikacji. - Jeśli oba klastry korzystają z tej samej grupy użytkowników, możesz dodać nowego użytkownika lub użyć istniejącego użytkownika z grupy.
- Jeśli oba klastry korzystają z innej grupy użytkowników, możesz dodać nowego użytkownika, aby użyć istniejącego użytkownika z grup.
- Jeśli na przykład oba klastry mają tego samego użytkownika administratora klastra (na przykład
Kroki wykonywania skryptu replikacji
Uwaga
Wykonaj następujące kroki tylko wtedy, gdy usługa DNS nie może rozpoznać nazwy hosta poprawnie klastra docelowego.
- Skopiuj mapowanie klastra ujścia hostów IP i nazwy hosta w źródłowych węzłach klastra /etc/hosts.
- Skopiuj węzeł główny, węzeł roboczy i węzły zooKeeper host i mapowanie adresów IP z pliku /etc/hosts klastra docelowego(ujścia).
- Dodaj skopiowany wpis źródłowy klaster /etc/hosts. Te wpisy należy dodać do węzłów głównych, węzłów procesu roboczego i węzłów usługi ZooKeeper.
Krok 1. Tworzenie pliku keytab dla użytkownika przy użyciu polecenia ktutil
.
$ ktutil
addent -password -p admin@ABC.EXAMPLE.COM -k 1 -e RC4-HMAC
- Poproś o uwierzytelnienie hasła, podaj hasło użytkownika
wkt /etc/security/keytabs/admin.keytab
Uwaga
Upewnij się, że plik tab klucza jest przechowywany w /etc/security/keytabs/
folderze w <username>.keytab
formacie .
Krok 2. Uruchamianie akcji skryptu z opcją -ku
- Podaj
-ku <username>
w klastrach ESP.
Nazwa/nazwisko | opis |
---|---|
-ku, --krb-user |
W przypadku klastrów ESP wspólny użytkownik protokołu Kerberos, który może uwierzytelniać zarówno klastry źródłowe, jak i docelowe |
Kopiowanie i migrowanie danych
Istnieją dwa oddzielne skrypty akcji dostępne do kopiowania lub migrowania danych po włączeniu replikacji:
Skrypt dla małych tabel (tabele o rozmiarze kilku gigabajtów, a ogólna kopia powinna zakończyć się w mniej niż jedną godzinę)
Skrypt dla dużych tabel (tabele , które mają potrwać dłużej niż jedną godzinę do skopiowania)
Możesz wykonać tę samą procedurę, która została opisana w temacie Włączanie replikacji w celu wywołania akcji skryptu. Użyj następujących parametrów:
-m hn1 -t <table1:start_timestamp:end_timestamp;table2:start_timestamp:end_timestamp;...> -p <replication_peer> [-everythingTillNow]
Sekcja print_usage()
skryptu zawiera szczegółowy opis parametrów.
Scenariusze
Skopiuj określone tabele (test1, test2 i test3) dla wszystkich wierszy edytowanych do tej pory (bieżąca sygnatura czasowa):
-m hn1 -t "test1::;test2::;test3::" -p "<zookeepername1>;<zookeepername2>;<zookeepername3>:2181:/hbase-unsecure" -everythingTillNow
Lub:
-m hn1 -t "test1::;test2::;test3::" --replication-peer="<zookeepername1>;<zookeepername2>;<zookeepername3>:2181:/hbase-unsecure" -everythingTillNow
Skopiuj określone tabele z określonym zakresem czasu:
-m hn1 -t "table1:0:452256397;table2:14141444:452256397" -p "<zookeepername1>;<zookeepername2>;<zookeepername3>:2181:/hbase-unsecure"
Wyłączanie replikacji
Aby wyłączyć replikację, użyj innego skryptu akcji z usługi GitHub. Możesz wykonać tę samą procedurę, która została opisana w temacie Włączanie replikacji w celu wywołania akcji skryptu. Użyj następujących parametrów:
-m hn1 -s <source hbase cluster name> -sp <source cluster Ambari password> <-all|-t "table1;table2;...">
Sekcja print_usage()
skryptu zawiera szczegółowe wyjaśnienie parametrów.
Scenariusze
Wyłącz replikację we wszystkich tabelach:
-m hn1 -s <source hbase cluster name> -sp Mypassword\!789 -all
lub
--src-cluster=<source hbase cluster name> --dst-cluster=<destination hbase cluster name> --src-ambari-user=<source cluster Ambari user name> --src-ambari-password=<source cluster Ambari password>
Wyłącz replikację w określonych tabelach (table1, table2 i table3):
-m hn1 -s <source hbase cluster name> -sp <source cluster Ambari password> -t "table1;table2;table3"
Uwaga
Jeśli zamierzasz usunąć klaster docelowy, upewnij się, że został on usunięty z listy równorzędnej klastra źródłowego. Można to zrobić, uruchamiając polecenie remove_peer "1" w powłoce hbase w klastrze źródłowym. Niepowodzenie tego klastra źródłowego może nie działać prawidłowo.
Następne kroki
W tym artykule przedstawiono sposób konfigurowania replikacji bazy danych Apache HBase w sieci wirtualnej lub między dwiema sieciami wirtualnymi. Aby dowiedzieć się więcej o usługach HDInsight i Apache HBase, zobacz następujące artykuły: