Migracja sieci bez przestojów za pomocą klastra MySQL Galera przy użyciu węzła przekaźnikowego

Automatyczne przydzielanie węzłów Galera Cluster upraszcza złożoność skalowania klastra bazy danych z gwarantowaną spójnością danych. SST i IST poprawiają użyteczność początkowej synchronizacji danych bez konieczności ręcznego tworzenia kopii zapasowej bazy danych i kopiowania jej do nowego węzła. W połączeniu ze zdolnością Galery do tolerowania różnych konfiguracji sieci (np. replikacji WAN), możemy teraz migrować bazę danych między różnymi odizolowanymi sieciami bez zakłóceń usług.

W tym poście na blogu przyjrzymy się, jak przeprowadzić migrację naszego klastra MySQL Galera bez przestojów. Przeniesiemy bazę danych z Amazon Web Service (AWS) EC2 do Google Cloud Platform (GCP) Compute Engine za pomocą węzła przekaźnikowego. Zwróć uwagę, że w przeszłości mieliśmy podobny post na blogu, ale ten wykorzystuje inne podejście.

Poniższy diagram upraszcza nasz plan migracji:

Przygotowanie starej strony

Ponieważ obie witryny nie mogą komunikować się ze sobą z powodu grupy zabezpieczeń lub izolacji VPC, musimy mieć węzeł przekaźnikowy, aby połączyć te dwie witryny razem. Ten węzeł może znajdować się w dowolnej witrynie, ale musi być w stanie połączyć się z jednym lub większą liczbą węzłów po drugiej stronie na portach 3306 (MySQL), 4444 (SST), 4567 (gcomm) i 4568 (IST). Oto, co już mamy i jak skalujemy starą witrynę:

Możesz również użyć istniejącego węzła Galera (np. trzeciego węzła) jako węzła przekaźnikowego, o ile ma on łączność z drugą stroną. Minusem jest to, że pojemność klastra zostanie zmniejszona do dwóch, ponieważ jeden węzeł będzie używany do SST i przekazywania strumienia replikacji Galera między lokacjami. W zależności od rozmiaru zbioru danych i połączenia między lokacjami może to spowodować problemy z niezawodnością bazy danych w bieżącym klastrze.

Dlatego użyjemy czwartego węzła, aby zmniejszyć ryzyko w bieżącym klastrze produkcyjnym podczas synchronizacji z drugą stroną. Najpierw utwórz nową instancję w AWS Dashboard z publicznym adresem IP (aby mogła komunikować się ze światem zewnętrznym) i zezwól na wymagane porty komunikacyjne Galera (TCP 3306, 4444, 4567-4568).

Wdróż czwarty węzeł (węzeł przekaźnikowy) w starej lokacji. Jeśli używasz ClusterControl, możesz po prostu użyć funkcji „Dodaj węzeł”, aby skalować klaster (nie zapomnij wcześniej skonfigurować bezhasłowego protokołu SSH z węzła ClusterControl do czwartego hosta):

Upewnij się, że węzeł przekaźnikowy jest zsynchronizowany z bieżącym klastrem i może komunikować się z drugą stroną.

Z nowej witryny połączymy się z węzłem przekaźnikowym, ponieważ jest to jedyny węzeł, który ma łączność ze światem zewnętrznym.

Wdrożenie nowej witryny

W nowej lokacji wdrożymy podobną konfigurację z jednym węzłem ClusterControl i trzema węzłami Galera Cluster. Obie strony muszą używać tej samej wersji MySQL. Oto nasza architektura na nowej stronie:

Dzięki ClusterControl od wdrożenia nowego klastra dzieli Cię zaledwie kilka kliknięć i jest to bezpłatna funkcja w wersji Community. Przejdź do ClusterControl -> Wdróż klaster bazy danych -> MySQL Galera i postępuj zgodnie z kreatorem wdrażania:

Kliknij Wdróż i monitoruj postęp w Aktywność -> Zadania -> Utwórz klaster. Po zakończeniu powinieneś mieć na pulpicie następujące informacje:

W tym momencie masz dwa oddzielne klastry Galera — 4 węzły w starej lokacji i 3 węzły w nowej lokacji.

Łączenie obu stron

W nowej lokacji (GCP) wybierz jeden węzeł do komunikacji z węzłem przekazującym w starej lokacji. Wybierzemy galera-gcp1 jako złącze do węzła przekaźnikowego (galera-aws4). Poniższy diagram ilustruje nasz plan pomostowy:

Ważne rzeczy do skonfigurowania to następujące parametry:

wsrep_sst_donor :wsrep_node_name węzła dawcy. Na galera-gcp1 ustaw dawcę na galera-aws4.
wsrep_sst_auth :Poświadczenia użytkownika SST w formacie nazwa użytkownika:hasło muszą być zgodne ze starą witryną (AWS).
wsrep_sst_receive_address :Adres IP, który otrzyma SST w węźle dołączającym. W galera-gcp1 ustaw publiczny adres IP tego węzła.
wsrep_cluster_address :ciąg połączenia Galera. W galera-gcp1 dodaj publiczny adres IP galera-aws4.
wsrep_provider_options :
- gmcast.segment:domyślna wartość to 0. Ustaw inną liczbę całkowitą dla wszystkich węzłów w GCP.

W węźle przekaźnikowym (galera-aws4) pobierz wsrep_node_name:

$ mysql -uroot -p -e 'SELECT @@wsrep_node_name'
Enter password:
+-------------------+
| @@wsrep_node_name |
+-------------------+
| 10.0.0.13         |
+-------------------+

W pliku my.cnf galera-gcp1 ustaw wsrep_sst_donor wartość do wsrep_node_name węzła przekaźnikowego i wsrep_sst_receive_address na publiczny adres IP galera-gcp1:
```
wsrep_sst_donor=10.0.0.13
wsrep_sst_receive_address=35.197.136.232
```
We wszystkich węzłach w GCP upewnij się, że wsrep_sst_auth wartość jest identyczna po starej witrynie (AWS) i zmień segment Galera na 1 (aby Galera wiedziała, że obie witryny znajdują się w różnych sieciach):
```
wsrep_sst_auth=backupuser:mysecretP4ssW0rd
wsrep_provider_options="base_port=4567; gcache.size=512M; gmcast.segment=1"
```
W galera-gcp1 ustaw wsrep_cluster_address aby uwzględnić publiczny adres IP węzła przekaźnikowego:
```
wsrep_cluster_address=gcomm://10.148.0.2,10.148.0.3,10.148.0.4,13.229.247.149
```
**Modyfikuj tylko wsrep_cluster_address na galera-gcp1. Nie zmieniaj tego parametru w galera-gcp2 i galera-gcp3.
Zatrzymaj wszystkie węzły w GCP. Jeśli używasz ClusterControl, przejdź do listy rozwijanej Akcje klastra -> Zatrzymaj klaster. Musisz również wyłączyć automatyczne odzyskiwanie zarówno na poziomie klastra, jak i węzła, aby ClusterControl nie próbował odzyskać uszkodzonych węzłów.

Teraz część synchronizująca. Uruchom galera-gcp1. W dzienniku błędów MySQL w węźle dawcy można zobaczyć, że SST jest inicjowane między węzłem przekazującym (10.0.0.13) przy użyciu adresu publicznego na galera-gcp1 (35.197.136.232):

2017-12-19T13:58:04.765238Z 0 [Note] WSREP: Initiating SST/IST transfer on DONOR side (wsrep_sst_xtrabackup-v2 --role 'donor' --address '35.197.136.232:4444/xtrabackup_sst//1' --socket '/var/lib/mysql/m
ysql.sock' --datadir '/var/lib/mysql/' --defaults-file '/etc/my.cnf' --defaults-group-suffix ''   '' --gtid 'df23adb8-b567-11e7-8c50-a386c8cc7711:151181')
2017-12-19T13:58:04.765468Z 5 [Note] WSREP: DONOR thread signaled with 0
        2017-12-19T13:58:15.158757Z WSREP_SST: [INFO] Streaming the backup to joiner at 35.197.136.232 4444
2017-12-19T13:58:52.512143Z 0 [Note] WSREP: 1.0 (10.0.0.13): State transfer to 0.0 (10.148.0.2) complete.

Zwróć uwagę, że w tym momencie galera-gcp1 zostanie zalana następującymi wierszami:

2017-12-19T13:32:47.111002Z 0 [Note] WSREP: (ed66842b, 'tcp://0.0.0.0:4567') connection to peer 00000000 with addr tcp://10.0.0.118:4567 timed out, no messages seen in PT3S
2017-12-19T13:32:48.111123Z 0 [Note] WSREP: (ed66842b, 'tcp://0.0.0.0:4567') connection to peer 00000000 with addr tcp://10.0.0.90:4567 timed out, no messages seen in PT3S
2017-12-19T13:32:50.611462Z 0 [Note] WSREP: (ed66842b, 'tcp://0.0.0.0:4567') connection to peer 00000000 with addr tcp://10.0.0.25:4567 timed out, no messages seen in PT3S

Możesz bezpiecznie zignorować to ostrzeżenie, ponieważ galera-gcp1 próbuje zobaczyć pozostałe węzły poza węzłem przekaźnikowym w AWS.

Po zakończeniu SST na galera-gcp1 ClusterControl na GCE nie będzie w stanie połączyć węzłów bazy danych z powodu brakujących GRANT (istniejące GRANT zostały zastąpione po synchronizacji z AWS). Oto, co musimy zrobić po zakończeniu SST na galera-gcp1:
```
mysql> GRANT ALL PRIVILEGES ON *.* TO [email protected]'10.148.0.5' IDENTIFIED BY 'cmon' WITH GRANT OPTION;
```
Gdy to zrobisz, ClusterControl poprawnie zgłosi stan galera-gcp1, jak zaznaczono poniżej:
Ostatnią częścią jest uruchomienie pozostałych galera-gcp2 i galera-gcp3, po jednym węźle na raz. Przejdź do ClusterControl -> Nodes -> wybierz węzeł -> Start Node. Po zsynchronizowaniu wszystkich węzłów powinieneś otrzymać 7 jako rozmiar klastra:

Klaster działa teraz w obu witrynach, a skalowanie zostało zakończone.

Wycofanie

Po zakończeniu migracji i zsynchronizowaniu wszystkich węzłów możesz zacząć przełączać aplikację do nowego klastra w GCP:

W tym momencie dane MySQL są replikowane do wszystkich węzłów aż do wycofania z eksploatacji. Wydajność replikacji będzie tak dobra, jak pozwala na to najdalszy węzeł w klastrze. Węzeł przekaźnikowy jest krytyczny, ponieważ rozgłasza zestawy zapisu na drugą stronę. Z punktu widzenia aplikacji zaleca się zapisywanie tylko do jednej witryny na raz, co oznacza, że będziesz musiał zacząć przekierowywać odczyty/zapisy z AWS i zamiast tego obsługiwać je z klastra GCP.

Aby zlikwidować stare węzły bazy danych i przenieść się do klastra w GCP, musimy wykonać bezpieczne zamknięcie (jeden węzeł na raz) w AWS. Ważne jest, aby bezpiecznie zamknąć węzły, ponieważ witryna AWS zawiera większość węzłów (4/7) dla tego klastra. Wyłączenie ich wszystkich naraz spowoduje, że klaster na GCP przejdzie w stan inny niż podstawowy, zmuszając klaster do odmowy działania. Upewnij się, że ostatni węzeł do wyłączenia po stronie AWS to węzeł przekaźnikowy.

Nie zapomnij odpowiednio zaktualizować następujących parametrów w galera-gcp1:

wsrep_cluster_address - Usuń publiczny adres IP węzła przekaźnikowego.
wsrep_sst_donor - Skomentuj tę linię. Niech Galera automatycznie wybierze dawcę.
wsrep_sst_receive_address - Skomentuj tę linię. Pozwól Galera automatycznie wybrać interfejs odbioru.

Twój klaster Galera działa teraz na zupełnie nowej platformie, hostach i sieci bez sekundy przestoju usługi bazy danych podczas migracji. Jak fajnie to jest?