Jak odzyskać klaster MySQL Galera z asynchronicznego urządzenia podrzędnego?

Wprowadzenie

Podczas uruchamiania Galera Cluster powszechną praktyką jest dodawanie co najmniej jednego asynchronicznego urządzenia podrzędnego w tym samym lub w innym centrum danych. Daje nam to plan awaryjny z niskim RTO i niskimi kosztami operacyjnymi. W przypadku nieodwracalnego problemu w naszym klastrze możemy szybko przełączyć się na niego, aby aplikacje mogły nadal mieć dostęp do danych.

Korzystając z tego typu konfiguracji, nie możemy po prostu odbudować naszego klastra z poprzedniej kopii zapasowej. Ponieważ asynchroniczny slave jest teraz nowym źródłem prawdy, musimy odbudować z niego klaster.

Nie oznacza to, że mamy na to tylko jeden sposób, może jest nawet lepszy! Zachęcamy do przekazania nam swoich sugestii w sekcji komentarzy na końcu tego posta.

Topologia

Powyżej widzimy przykładową topologię z Galera Cluster i asynchroniczną repliką/slave.

Następnie zobaczymy, jak możemy odtworzyć nasz klaster, zaczynając od niewolnika, w przypadku znalezienia czegoś takiego:

Jeśli spojrzymy na poprzedni obraz, widzimy, że nasze 3 węzły Galera są wyłączone. Nasze urządzenie podrzędne nie może połączyć się z urządzeniem głównym Galera, ale znajduje się w stanie „Uruchomiony”.

Promuj niewolnika

Ponieważ nasz niewolnik działa prawidłowo, możemy go wypromować na mastera i skierować do niego nasze aplikacje. W tym celu musimy wyłączyć parametr tylko do odczytu w naszym urządzeniu podrzędnym i zresetować konfigurację urządzenia podrzędnego.

W naszym niewolniku (mysql1):

mysql> SET GLOBAL read_only=0;
Query OK, 0 rows affected (0.00 sec)
mysql> STOP SLAVE;
Query OK, 0 rows affected (0.00 sec)
mysql> RESET SLAVE;
Query OK, 0 rows affected (0.18 sec)

Utwórz nowy klaster

Następnie, aby rozpocząć odzyskiwanie naszego uszkodzonego klastra, utworzymy nowy klaster Galera. Można to łatwo zrobić za pomocą ClusterControl ClusterControl, przewiń w dół tego bloga, aby zobaczyć, jak to zrobić.

Po wdrożeniu naszego nowego klastra Galera otrzymamy coś takiego:

Replikacja

Musimy upewnić się, że mamy skonfigurowane parametry replikacji.

W przypadku węzłów Galera (galera1, galera2, galera3):

server_id=<ID>         # Different value in each node
binlog_format=ROW
log_bin = /var/lib/mysql-binlog/binlog
log_slave_updates = ON
gtid_mode = ON
enforce_gtid_consistency = true
relay_log = relay-bin
expire_logs_days = 7

Dla węzła głównego (mysql1):

server_id=<ID>         # Different value in each node
binlog_format=ROW
log_bin=binlog
log_slave_updates=1
gtid_mode=ON
enforce_gtid_consistency=1
relay_log=relay-bin
expire_logs_days=7
read_only=ON
sync_binlog=1
report_host=<HOSTNAME or IP>    # Local server

Aby nasz nowy slave (galera1) mógł połączyć się z naszym nowym masterem (mysql1), musimy utworzyć użytkownika z uprawnieniami do replikacji w naszym master.

W naszym nowym masterze (mysql1):

mysql> GRANT REPLICATION SLAVE ON *.* TO 'slave_user'@'%' IDENTIFIED BY 'slave_password';

Uwaga:możemy zastąpić „%” adresem IP węzła Galera Cluster, który będzie naszym niewolnikiem, w naszym przykładzie galera1.

Kopia zapasowa

Jeśli go nie mamy, musimy stworzyć spójną kopię zapasową naszego mastera (mysql1) i załadować ją do naszego nowego klastra Galera. W tym celu możemy skorzystać z narzędzia XtraBackup lub mysqldump. Zobaczmy obie opcje.

W naszym przykładzie używamy bazy danych sakila dostępnej do testowania.

Narzędzie XtraBackup

Generujemy kopię zapasową w nowym masterze (mysql1). W naszym przypadku wysyłamy go do lokalnego katalogu /root/backup:

$ innobackupex /root/backup/

Musimy otrzymać wiadomość:

180705 22:08:14 completed OK!

Kompresujemy kopię zapasową i wysyłamy do węzła, który będzie naszym niewolnikiem (galera1):

$ cd /root/backup
$ tar zcvf 2018-07-05_22-08-07.tar.gz 2018-07-05_22-08-07
$ scp /root/backup/2018-07-05_22-08-07.tar.gz galera1:/root/backup/

W galera1 wyodrębnij kopię zapasową:

$ tar zxvf /root/backup/2018-07-05_22-08-07.tar.gz

Zatrzymujemy klaster (jeśli jest uruchomiony). W tym celu zatrzymujemy usługi mysql 3 węzłów:

$ service mysql stop

W galera1 zmieniamy nazwę katalogu danych mysql i ładujemy kopię zapasową:

$ mv /var/lib/mysql /var/lib/mysql.bak
$ innobackupex --copy-back /root/backup/2018-07-05_22-08-07

Musimy otrzymać wiadomość:

180705 23:00:01 completed OK!

Przypisujemy odpowiednie uprawnienia do katalogu danych:

$ chown -R mysql.mysql /var/lib/mysql

Następnie musimy zainicjować klaster.

Po zainicjowaniu pierwszego węzła musimy uruchomić usługę MySQL dla pozostałych węzłów, eliminując wszelkie poprzednie kopie pliku grastate.dat, a następnie sprawdzić, czy nasze dane są zaktualizowane.

$ rm /var/lib/mysql/grastate.dat
$ service mysql start

Uwaga:Sprawdź, czy użytkownik używany przez XtraBackup został utworzony w naszym zainicjowanym węźle i jest taki sam w każdym węźle.

mysqldump

Ogólnie rzecz biorąc, nie zalecamy robienia tego za pomocą mysqldump, ponieważ może być dość powolny przy dużej ilości danych. Ale jest to alternatywa do wykonania zadania.

Generujemy kopię zapasową w nowym masterze (mysql1):

$ mysqldump -uroot -p --single-transaction --skip-add-locks --triggers --routines --events --databases sakila > /root/backup/sakila_dump.sql

Kompresujemy go i wysyłamy do naszego węzła podrzędnego (galera1):

$ gzip /root/backup/sakila_dump.sql
$ scp /root/backup/sakila_dump.sql.gz galera1:/root/backup/

Załadujemy zrzut do galera1.

$ gunzip /root/backup/sakila_dump.sql.gz
$ mysql -p < /root/backup/sakila_dump.sql

Gdy zrzut zostanie załadowany w galera1, musimy ponownie uruchomić usługę MySQL na pozostałych węzłach, usuwając plik grastate.dat i sprawdzić, czy nasze dane zostały zaktualizowane.

$ rm /var/lib/mysql/grastate.dat
$ service mysql start

Uruchom replikację podrzędną

Bez względu na to, którą opcję wybierzemy, XtraBackup czy mysqldump, jeśli wszystko poszło dobrze, w tym kroku możemy już włączyć replikację w węźle, który będzie naszym niewolnikiem (galera1).

$ mysql> CHANGE MASTER TO MASTER_HOST = 'mysql1', MASTER_PORT = 3306, MASTER_USER = 'slave_user', MASTER_PASSWORD = 'slave_password', MASTER_AUTO_POSITION = 1;
$ mysql> START SLAVE;

Weryfikujemy, czy urządzenie podrzędne działa:

mysql> SHOW SLAVE STATUS\G
       Slave_IO_Running: Yes
       Slave_SQL_Running: Yes

W tym momencie mamy coś takiego:

Po zaktualizowaniu NewGalera1 możemy ponownie skierować aplikację do naszego nowego klastra Galera i ponownie skonfigurować replikację asynchroniczną.

ClusterControl

Jak wspomnieliśmy wcześniej, za pomocą ClusterControl możemy wykonać kilka z wyżej wymienionych zadań za pomocą kilku prostych kliknięć. Posiada również opcje automatycznego odzyskiwania, zarówno dla węzłów, jak i klastra. Zobaczmy kilka zadań, w których może pomóc.

Aby przeprowadzić wdrożenie, po prostu wybierz opcję „Wdróż klaster bazy danych” i postępuj zgodnie z wyświetlanymi instrukcjami.

Do wyboru mamy różne rodzaje technologii i dostawców. Musimy określić Użytkownika, Klucz lub Hasło i port, aby połączyć się przez SSH z naszymi serwerami. Potrzebujemy również nazwy dla naszego nowego klastra i jeśli chcemy, aby ClusterControl zainstalował dla nas odpowiednie oprogramowanie i konfiguracje.

Po skonfigurowaniu informacji dostępowych SSH musimy zdefiniować węzły w naszym klastrze. Możemy również określić, którego repozytorium użyć. Musimy dodać nasze serwery do klastra, który zamierzamy utworzyć.

Możemy monitorować stan tworzenia naszego nowego klastra z monitora aktywności ClusterControl.

Możemy również dokonać importu naszego obecnego klastra lub bazy danych, wykonując te same kroki. W takim przypadku ClusterControl nie zainstaluje oprogramowania bazy danych, ponieważ baza danych jest już uruchomiona.

Aby dodać urządzenie podrzędne replikacji, kliknij Akcje klastra, wybierz opcję Dodaj podrzędną replikację i dodaj informacje o dostępie SSH do nowego serwera. ClusterControl połączy się z serwerem, aby dokonać niezbędnych konfiguracji dla tej akcji.

Aby zamienić jeden lub więcej węzłów Galera w serwery główne (jak w sensie tworzenia dzienników binarnych), możesz przejść do Akcji węzła i wybrać Włącz rejestrowanie binarne.

Kopie zapasowe można skonfigurować za pomocą XtraBackup (pełnego lub przyrostowego) i mysqldump, a ponadto masz inne opcje, takie jak przesyłanie kopii zapasowej do chmury, szyfrowanie, kompresja, harmonogram i inne.

Aby przywrócić kopię zapasową, przejdź do zakładki Kopia zapasowa i wybierz opcję Przywróć, a następnie wybierz serwer, na którym chcesz przywrócić.

Jeśli masz urządzenie podrzędne i chcesz zmienić mastera lub odbudować replikację, możesz przejść do Akcji węzła i wybrać opcję.

Wniosek

Jak widzieliśmy, mamy kilka sposobów na osiągnięcie naszego celu, jedne bardziej złożone, inne bardziej przyjazne dla użytkownika, ale w każdym z nich można odtworzyć klaster z asynchronicznego urządzenia podrzędnego. Xtrabackup przywracałby szybciej w przypadku większych ilości danych. Aby zabezpieczyć się przed błędem operatora (np. błędną TABELĄ UPUSZCZANIA), możesz również użyć opóźnionego niewolnika, więc miejmy nadzieję, że będziesz mieć czas na zatrzymanie propagacji instrukcji.

Mamy nadzieję, że te informacje są przydatne i nigdy nie będziesz musiał ich używać w produkcji;)