Jak skonfigurować replikację asynchroniczną z klastra Galera na samodzielny serwer MySQL z GTID

Replikacja hybrydowa, czyli połączenie replikacji Galera i asynchronicznej MySQL w tej samej konfiguracji, stała się znacznie łatwiejsza od czasu wprowadzenia GTID w MySQL 5.6. Chociaż replikacja z samodzielnego serwera MySQL do klastra Galera była dość prosta, zrobienie tego na odwrót (Galera → samodzielny MySQL) było nieco trudniejsze. Przynajmniej do czasu przybycia GTID.

Istnieje kilka dobrych powodów, aby dołączyć asynchroniczne urządzenie podrzędne do klastra Galera. Po pierwsze, długotrwałe raportowanie/zapytania typu OLAP w węźle Galera mogą spowolnić cały klaster, jeśli obciążenie raportowania jest tak duże, że węzeł musi poświęcić dużo czasu na radzenie sobie z nim. Dzięki temu zapytania raportujące mogą być wysyłane na samodzielny serwer, skutecznie izolując Galera od obciążenia raportowania. W podejściu z pasami i szelkami asynchroniczne urządzenie podrzędne może również służyć jako zdalne kopie zapasowe na żywo.

W tym poście na blogu pokażemy, jak zreplikować klaster Galera na serwer MySQL z identyfikatorem GTID oraz jak przełączyć replikację w tryb awaryjny w przypadku awarii węzła głównego.

Hybrydowa replikacja w MySQL 5.5

W MySQL 5.5 wznowienie przerwanej replikacji wymaga określenia ostatniego pliku i pozycji dziennika binarnego, które są różne we wszystkich węzłach Galera, jeśli włączone jest logowanie binarne. Możemy zilustrować tę sytuację za pomocą następującego rysunku:

Jeśli master MySQL ulegnie awarii, replikacja zostanie przerwana i slave będzie musiał przełączyć się na innego mastera. Będziesz musiał wybrać nowy węzeł Galera i ręcznie określić nowy plik dziennika binarnego i pozycję ostatniej transakcji wykonanej przez urządzenie podrzędne. Inną opcją jest zrzucenie danych z nowego węzła głównego, przywrócenie ich na serwerze podrzędnym i rozpoczęcie replikacji z nowym węzłem głównym. Te opcje są oczywiście wykonalne, ale niezbyt praktyczne w produkcji.

Jak GTID rozwiązuje problem

GTID (Global Transaction Identifier) ​​zapewnia lepsze mapowanie transakcji między węzłami i jest obsługiwany w MySQL 5.6. W Galera Cluster wszystkie węzły będą generować różne pliki binlog. Zdarzenia binlog są takie same iw tej samej kolejności, ale nazwy i przesunięcia plików binlog mogą się różnić. Dzięki GTID urządzenia podrzędne mogą zobaczyć unikalną transakcję przychodzącą od kilku urządzeń nadrzędnych, co można łatwo zmapować na listę wykonania urządzeń podrzędnych, jeśli konieczne będzie ponowne uruchomienie lub wznowienie replikacji.

Wszystkie niezbędne informacje do synchronizacji z masterem są pozyskiwane bezpośrednio ze strumienia replikacji. Oznacza to, że gdy używasz identyfikatorów GTID do replikacji, nie musisz uwzględniać opcji MASTER_LOG_FILE ani MASTER_LOG_POS w instrukcji CHANGE MASTER TO. Zamiast tego konieczne jest tylko włączenie opcji MASTER_AUTO_POSITION. Więcej informacji na temat identyfikatora GTID można znaleźć na stronie Dokumentacja MySQL.

Ręczne konfigurowanie replikacji hybrydowej

Upewnij się, że węzły Galera (nadrzędne) i podrzędne działają na MySQL 5.6, zanim przejdziesz do tej konfiguracji. W Galera mamy bazę danych o nazwie sbtest, którą zreplikujemy do węzła podrzędnego.

1. Włącz wymagane opcje replikacji, określając następujące wiersze wewnątrz pliku my.cnf każdego węzła bazy danych (w tym węzła podrzędnego):

Dla węzłów głównych (Galera):

gtid_mode=ON
log_bin=binlog
log_slave_updates=1
enforce_gtid_consistency
expire_logs_days=7
server_id=1         # 1 for master1, 2 for master2, 3 for master3
binlog_format=ROW

Dla węzła podrzędnego:

gtid_mode=ON
log_bin=binlog
log_slave_updates=1
enforce_gtid_consistency
expire_logs_days=7
server_id=101         # 101 for slave
binlog_format=ROW
replicate_do_db=sbtest
slave_net_timeout=60

2. Wykonaj stopniowe ponowne uruchomienie klastra Galera Cluster (z ClusterControl UI> Manage> Upgrade> Rolling Restart). Spowoduje to ponowne załadowanie każdego węzła z nowymi konfiguracjami i włączenie GTID. Zrestartuj również urządzenie podrzędne.

3. Utwórz użytkownika replikacji podrzędnej i uruchom następującą instrukcję na jednym z węzłów Galera:

mysql> GRANT REPLICATION SLAVE ON *.* TO 'slave'@'%' IDENTIFIED BY 'slavepassword';

4. Zaloguj się do slave i zrzuć bazę danych sbtest z jednego z węzłów Galera:

$ mysqldump -uroot -p -h192.168.0.201 --single-transaction --skip-add-locks --triggers --routines --events sbtest > sbtest.sql

5. Przywróć plik zrzutu na serwer podrzędny:

$ mysql -uroot -p < sbtest.sql

6. Rozpocznij replikację w węźle podrzędnym:

mysql> STOP SLAVE;
mysql> CHANGE MASTER TO MASTER_HOST = '192.168.0.201', MASTER_PORT = 3306, MASTER_USER = 'slave', MASTER_PASSWORD = 'slavepassword', MASTER_AUTO_POSITION = 1;
mysql> START SLAVE;

Aby sprawdzić, czy replikacja działa poprawnie, sprawdź dane wyjściowe statusu urządzenia podrzędnego:

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

Konfigurowanie replikacji hybrydowej za pomocą ClusterControl

W poprzednim akapicie opisaliśmy wszystkie niezbędne kroki, aby włączyć logi binarne, ponownie uruchomić węzeł klastra po węźle, skopiować dane, a następnie skonfigurować replikację. Procedura jest żmudnym zadaniem i możesz łatwo popełnić błędy w jednym z tych kroków. W ClusterControl zautomatyzowaliśmy wszystkie niezbędne kroki.

1. Użytkownicy ClusterControl mogą przejść do węzłów na stronie Węzły i włączyć logowanie binarne.

Spowoduje to otwarcie okna dialogowego, które pozwala ustawić wygaśnięcie dziennika binarnego, włączyć GTID i automatyczny restart.

To inicjuje zadanie, które bezpiecznie zapisze te zmiany w konfiguracji, utworzy użytkowników replikacji z odpowiednimi uprawnieniami i bezpiecznie zrestartuje węzeł.

Powtórz ten proces dla każdego węzła Galera w klastrze, aż wszystkie węzły wskażą, że są nadrzędne.

2. Dodaj asynchroniczne urządzenie podrzędne replikacji do klastra

I to wszystko, co musisz zrobić. Cały proces opisany w poprzednim akapicie został zautomatyzowany przez ClusterControl.

Zmiana mistrza

Jeśli wyznaczony master ulegnie awarii, slave spróbuje ponownie połączyć się ponownie w wartości slave_net_timeout (nasza konfiguracja to 60 sekund - domyślnie 1 godzina). Powinieneś zobaczyć następujący błąd dotyczący statusu urządzenia podrzędnego:

       Last_IO_Errno: 2003
       Last_IO_Error: error reconnecting to master '[email protected]:3306' - retry-time: 60  retries: 1

Ponieważ używamy Galery z włączonym GTID, główne przełączanie awaryjne jest obsługiwane przez ClusterControl, gdy automatyczne przywracanie klastrów i węzłów została włączona. Niezależnie od tego, czy master ulegnie awarii z powodu połączenia sieciowego, czy z jakiegokolwiek innego powodu, ClusterControl automatycznie przełączy się na najbardziej odpowiedni inny węzeł master w klastrze.

Jeśli chcesz ręcznie wykonać przełączanie awaryjne, po prostu zmień węzeł główny w następujący sposób:

mysql> STOP SLAVE;
mysql> CHANGE MASTER TO MASTER_HOST = '192.168.0.202', MASTER_PORT = 3306, MASTER_USER = 'slave', MASTER_PASSWORD = 'slavepassword', MASTER_AUTO_POSITION = 1;
mysql> START SLAVE;

W niektórych przypadkach po zmianie węzła głównego może wystąpić błąd „Duplikat wpisu... dla klucza”:

       Last_Errno: 1062
       Last_Error: Could not execute Write_rows event on table sbtest.sbtest; Duplicate entry '1089775' for key 'PRIMARY', Error_code: 1062; handler error HA_ERR_FOUND_DUPP_KEY; the event's master log mysqld-bin.000009, end_log_pos 85789000

W starszych wersjach MySQL możesz po prostu użyć SET GLOBAL SQL_SLAVE_SKIP_COUNTER =n aby pominąć instrukcje, ale nie działa z GTID. Miguel z Percony napisał świetny post na blogu, jak to naprawić, wstrzykując puste transakcje.

Innym podejściem, w przypadku mniejszych baz danych, może być po prostu pobranie świeżego zrzutu z dowolnego dostępnego węzła Galera, przywrócenie go i użycie instrukcji RESET MASTER:

mysql> STOP SLAVE;
mysql> RESET MASTER;
mysql> DROP SCHEMA sbtest; CREATE SCHEMA sbtest; USE sbtest;
mysql> SOURCE /root/sbtest_from_galera2.sql; -- repeat step #4 above to get this dump
mysql> CHANGE MASTER TO MASTER_HOST = '192.168.0.202', MASTER_PORT = 3306, MASTER_USER = 'slave', MASTER_PASSWORD = 'slavepassword', MASTER_AUTO_POSITION = 1;
mysql> START SLAVE;

Możesz również użyć sumy kontrolnej pt-table-check, aby zweryfikować integralność replikacji, więcej informacji w tym poście na blogu.

Uwaga:Ponieważ w replikacji MySQL aplikacja podrzędna jest domyślnie nadal jednowątkowa, nie oczekuj, że wydajność replikacji asynchronicznej będzie taka sama jak replikacja równoległa Galera. W przypadku MySQL 5.6 i 5.7 istnieją opcje, aby asynchroniczna replikacja była wykonywana równolegle na węzłach podrzędnych, ale w zasadzie ta replikacja nadal zależy od prawidłowej kolejności transakcji wewnątrz tego samego schematu. Jeśli obciążenie replikacją jest intensywne i ciągłe, opóźnienie podrzędne będzie po prostu rosło. Widzieliśmy przypadki, w których niewolnik nigdy nie mógł dogonić pana.