HA dla MySQL i MariaDB — porównanie replikacji Master-Master z klastrem Galera

Replikacja Galera jest stosunkowo nowa w porównaniu z replikacją MySQL, która jest natywnie obsługiwana od wersji MySQL 3.23. Chociaż replikacja MySQL jest przeznaczona do jednokierunkowej replikacji master-slave, można ją skonfigurować jako aktywną konfigurację master-master z replikacją dwukierunkową. Chociaż konfiguracja jest łatwa, a niektóre przypadki użycia mogą odnieść korzyści z tego „hackowania”, istnieje wiele zastrzeżeń. Z drugiej strony klaster Galera to inny rodzaj technologii do nauki i zarządzania. Czy warto?

W tym poście na blogu porównamy replikację master-master z klastrem Galera.

Koncepcje replikacji

Zanim przejdziemy do porównania, wyjaśnijmy podstawowe pojęcia stojące za tymi dwoma mechanizmami replikacji.

Generalnie każda modyfikacja bazy danych MySQL generuje zdarzenie w formacie binarnym. To zdarzenie jest transportowane do innych węzłów w zależności od wybranej metody replikacji — replikacja MySQL (natywna) lub replikacja Galera (poprawiona za pomocą interfejsu API wsrep).

Replikacja MySQL

Poniższe diagramy ilustrują przepływ danych udanej transakcji z jednego węzła do drugiego przy użyciu replikacji MySQL:

Zdarzenie binarne jest zapisywane w dzienniku binarnym urządzenia nadrzędnego. Urządzenia podrzędne przez slave_IO_thread pobierze zdarzenia binarne z dziennika binarnego mastera i zreplikuje je do swojego dziennika przekaźnikowego. wątek_slave_SQL następnie zastosuje zdarzenie z dziennika przekaźnika asynchronicznie. Ze względu na asynchroniczną naturę replikacji, serwer podrzędny nie ma gwarancji, że otrzyma dane, gdy master dokona zmiany.

Idealnie, replikacja MySQL będzie miała serwer podrzędny, który będzie skonfigurowany jako serwer tylko do odczytu, ustawiając read_only=ON lub super_read_only=ON. Jest to środek ostrożności chroniący urządzenie podrzędne przed przypadkowymi zapisami, które mogą prowadzić do niespójności danych lub awarii podczas przełączania awaryjnego urządzenia głównego (np. błędnych transakcji). Jednak w konfiguracji replikacji master-master aktywna-aktywna opcja tylko do odczytu musi być wyłączona na drugim master, aby umożliwić jednoczesne przetwarzanie zapisów. Główny master musi być skonfigurowany do replikacji z wtórnego mastera za pomocą instrukcji CHANGE MASTER, aby włączyć replikację cykliczną.

Replikacja Galery

Poniższe diagramy ilustrują przepływ replikacji danych pomyślnej transakcji z jednego węzła do drugiego dla klastra Galera:

Zdarzenie jest hermetyzowane w zestawie zapisów i rozgłaszane z węzła nadawcy do innych węzłów w klastrze przy użyciu replikacji Galera. Zestaw zapisów przechodzi certyfikację na każdym węźle Galera i jeśli przejdzie pomyślnie, wątki aplikujące zastosują zestaw zapisów asynchronicznie. Oznacza to, że serwer podrzędny ostatecznie stanie się spójny, po uzgodnieniu wszystkich uczestniczących węzłów w globalnym porządku całkowitym. Jest logicznie synchroniczny, ale faktyczne pisanie i zatwierdzanie w przestrzeni tabel odbywa się niezależnie, a zatem asynchronicznie w każdym węźle z gwarancją, że zmiana będzie propagowana we wszystkich węzłach.

Unikanie kolizji kluczy głównych

Aby wdrożyć replikację MySQL w konfiguracji master-master, należy dostosować wartość automatycznego przyrostu, aby uniknąć kolizji klucza podstawowego dla INSERT między dwoma lub więcej replikowanymi masterami. Pozwala to na przeplatanie się wartości klucza podstawowego na urządzeniach głównych i zapobiega dwukrotnemu użyciu tego samego numeru automatycznego przyrostu na dowolnym węźle. To zachowanie należy skonfigurować ręcznie, w zależności od liczby wzorców w konfiguracji replikacji. Wartość auto_increment_increment równa się liczbie replikowanych wzorców i auto_increment_offset musi być między nimi wyjątkowy. Na przykład następujące wiersze powinny znajdować się wewnątrz odpowiedniego my.cnf:

Mistrz1:

log-slave-updates
auto_increment_increment=2
auto_increment_offset=1

Mistrz2:

log-slave-updates
auto_increment_increment=2
auto_increment_offset=2

Podobnie Galera Cluster wykorzystuje tę samą sztuczkę, aby uniknąć kolizji kluczy podstawowych, kontrolując wartość automatycznego przyrostu i automatycznie przesuwając za pomocą wsrep_auto_increment_control zmienny. Jeśli jest ustawiony na 1 (domyślnie), automatycznie dostosuje auto_increment_increment i auto_increment_offset zmienne zgodnie z rozmiarem klastra i kiedy zmienia się rozmiar klastra. Pozwala to uniknąć konfliktów replikacji z powodu auto_increment. W środowisku master-slave tę zmienną można ustawić na WYŁ.

Konsekwencją tej konfiguracji jest to, że wartość automatycznego przyrostu nie będzie w kolejności sekwencyjnej, jak pokazano w poniższej tabeli trzywęzłowego klastra Galera:

Jeśli aplikacja wykonuje operacje wstawiania w następujących węzłach w następującej kolejności:

• Węzeł1, Węzeł3, Węzeł2, Węzeł3, Węzeł3, Węzeł1, Węzeł3 ..

Wtedy wartość klucza podstawowego, która zostanie zapisana w tabeli, będzie następująca:

• 1, 6, 8, 9, 12, 13, 15 ..

Mówiąc najprościej, podczas korzystania z replikacji master-master (replikacja MySQL lub Galera), Twoja aplikacja musi być w stanie tolerować niesekwencyjne wartości automatycznego przyrostu w swoim zbiorze danych.

Użytkownicy ClusterControl powinni pamiętać, że obsługuje on wdrażanie replikacji MySQL master-master z limitem dwóch masterów na klaster replikacji, tylko w przypadku konfiguracji typu aktywny-pasywny. Dlatego ClusterControl nie konfiguruje celowo masterów za pomocą auto_increment_increment i auto_increment_offset zmienne.

Spójność danych

Galera Cluster jest wyposażony w mechanizm kontroli przepływu, w którym każdy węzeł w klastrze musi nadążać za replikacją, w przeciwnym razie wszystkie inne węzły będą musiały zwolnić, aby umożliwić dogonienie najwolniejszemu węzłowi. Zasadniczo minimalizuje to prawdopodobieństwo opóźnienia niewolnika, chociaż może się to zdarzyć, ale nie tak znaczące jak w replikacji MySQL. Domyślnie Galera pozwala węzłom być opóźnionym o co najmniej 16 transakcji przy aplikowaniu przez zmienną gcs.fc_limit . Jeśli chcesz wykonywać krytyczne odczyty (wybór SELECT, który musi zwracać najbardziej aktualne informacje), prawdopodobnie chcesz użyć zmiennej sesji wsrep_sync_wait .

Z drugiej strony Galera Cluster jest wyposażony w zabezpieczenie przed niespójnością danych, dzięki któremu węzeł zostanie usunięty z klastra, jeśli z jakichkolwiek powodów nie zastosuje żadnego zbioru zapisu. Na przykład, gdy węzeł Galera nie zastosuje zestawu zapisu z powodu błędu wewnętrznego bazowego silnika pamięci masowej (MySQL/MariaDB), węzeł wyciągnie się z klastra z następującym błędem:

150305 16:13:14 [ERROR] WSREP: Failed to apply trx 1 4 times
150305 16:13:14 [ERROR] WSREP: Node consistency compromized, aborting..

Aby naprawić spójność danych, węzeł naruszający musi zostać ponownie zsynchronizowany, zanim będzie mógł dołączyć do klastra. Można to zrobić ręcznie lub usuwając katalog danych, aby uruchomić transfer stanu migawki (pełna synchronizacja od dawcy).

Replikacja MySQL master-master nie wymusza ochrony spójności danych, a slave może się różnić, np. replikować podzbiór danych lub pozostaje w tyle, co sprawia, że ​​slave jest niespójny z masterem. Jest przeznaczony do replikowania danych w jednym przepływie - od urządzenia nadrzędnego do urządzenia podrzędnego. Kontrole spójności danych muszą być wykonywane ręcznie lub za pomocą narzędzi zewnętrznych, takich jak Percona Toolkit pt-table-checksum lub mysql-replication-check.

Rozwiązywanie konfliktów

Generalnie replikacja master-master (lub multi-master lub dwukierunkowa) umożliwia więcej niż jeden element w klastrze na przetwarzanie zapisów. Dzięki replikacji MySQL, w przypadku konfliktu replikacji, wątek SQL urządzenia podrzędnego po prostu przestaje stosować następne zapytanie do czasu rozwiązania konfliktu, albo przez ręczne pominięcie zdarzenia replikacji, naprawienie nieprawidłowych wierszy lub ponowną synchronizację urządzenia podrzędnego. Mówiąc najprościej, nie ma obsługi automatycznego rozwiązywania konfliktów dla replikacji MySQL.

Galera Cluster zapewnia lepszą alternatywę, ponawiając naruszającą transakcję podczas replikacji. Używając wsrep_retry_autocommit zmiennej, można poinstruować Galerę, aby automatycznie ponawiała nieudaną transakcję z powodu konfliktów obejmujących cały klaster, przed zwróceniem błędu do klienta. Jeśli jest ustawiona na 0, nie będą podejmowane żadne próby, natomiast wartość 1 (domyślna) lub większa określa liczbę prób. Może to być przydatne, aby pomóc aplikacjom korzystającym z automatycznego zatwierdzania w celu uniknięcia zakleszczeń.

Konsensus węzłów i przełączanie awaryjne

Galera używa systemu komunikacji grupowej (GCS) do sprawdzania konsensusu i dostępności węzłów między członkami klastra. Jeśli węzeł jest w złym stanie, zostanie automatycznie usunięty z klastra po gmcast.peer_timeout wartość, domyślnie 3 sekundy. Prawidłowy węzeł Galera w stanie „Zsynchronizowany” jest uważany za niezawodny węzeł obsługujący odczyty i zapisy, podczas gdy inne nie. Ten projekt znacznie upraszcza procedury kontroli stanu z wyższych poziomów (system równoważenia obciążenia lub aplikacja).

W replikacji MySQL, master nie dba o swoich slave'ów, podczas gdy slave ma konsensus tylko ze swoim jedynym masterem poprzez wątek_slave_IO_thread proces podczas replikacji zdarzeń binarnych z dziennika binarnego mastera. Jeśli master ulegnie awarii, przerwie to replikację, a próba ponownego ustanowienia połączenia będzie podejmowana co slave_net_timeout (domyślnie 60 sekund). Z perspektywy aplikacji lub modułu równoważenia obciążenia procedury sprawdzania kondycji podrzędnego replikacji muszą obejmować przynajmniej sprawdzenie następującego stanu:

• Seconds_Behind_Master
• Slave_IO_Running
• Slave_SQL_Running
• zmienna tylko do odczytu
• zmienna super_read_only (MySQL 5.7.8 i nowsze)

Jeśli chodzi o przełączanie awaryjne, generalnie replikacja master-master i węzły Galera są równe. Posiadają ten sam zestaw danych (chociaż można replikować podzbiór danych w replikacji MySQL, ale jest to rzadkie w przypadku master-master) i pełnią tę samą rolę co mastery, mogąc jednocześnie obsługiwać odczyty i zapisy. Dlatego w rzeczywistości nie ma przełączania awaryjnego z punktu widzenia bazy danych ze względu na tę równowagę. Tylko od strony aplikacji, która wymagałaby przełączenia awaryjnego, aby pominąć niedziałające węzły. Należy pamiętać, że ponieważ replikacja MySQL jest asynchroniczna, możliwe jest, że nie wszystkie zmiany wprowadzone na masterze zostaną przeniesione na inny master.

Obsługa obsługi węzła

Proces synchronizowania węzła z klastrem przed rozpoczęciem replikacji jest nazywany udostępnianiem. W replikacji MySQL udostępnienie nowego węzła jest procesem ręcznym. Przed skonfigurowaniem łącza replikacji należy wykonać kopię zapasową mastera i przywrócić ją do nowego węzła. W przypadku istniejącego węzła replikacji, jeśli logi binarne mastera zostały poddane rotacji (na podstawie expire_logs_days , domyślnie 0 oznacza brak automatycznego usuwania), może być konieczne ponowne udostępnienie węzła przy użyciu tej procedury. Istnieją również narzędzia zewnętrzne, takie jak Percona Toolkit pt-table-sync i ClusterControl, które mogą Ci w tym pomóc. ClusterControl obsługuje ponowną synchronizację urządzenia podrzędnego za pomocą zaledwie dwóch kliknięć. Masz opcje ponownej synchronizacji, pobierając kopię zapasową z aktywnej kopii zapasowej lub istniejącej kopii zapasowej.

W Galera można to zrobić na dwa sposoby - przyrostowy transfer stanu (IST) lub transfer migawki stanu (SST). Proces IST jest preferowaną metodą, w której tylko brakujące transakcje są przesyłane z pamięci podręcznej dawcy. Proces SST jest podobny do pobierania pełnej kopii zapasowej od dawcy, zwykle wymaga dużych zasobów. Galera automatycznie określi, który proces synchronizacji ma zostać uruchomiony, na podstawie stanu dołączającego. W większości przypadków, jeśli węzeł nie może dołączyć do klastra, po prostu wyczyść katalog danych MySQL problematycznego węzła i uruchom usługę MySQL. Proces udostępniania Galera jest znacznie prostszy, jest bardzo przydatny podczas skalowania klastra lub ponownego wprowadzania problematycznego węzła z powrotem do klastra.

Luźno i mocno sprzężone

Replikacja MySQL działa bardzo dobrze nawet w przypadku wolniejszych połączeń i połączeń, które nie są ciągłe. Może być również używany na różnych urządzeniach, środowiskach i systemach operacyjnych. Obsługuje ją większość silników pamięci masowej, w tym MyISAM, Aria, MEMORY i ARCHIVE. Ta luźno powiązana konfiguracja pozwala replikacji MySQL master-master działać dobrze w mieszanym środowisku z mniejszymi ograniczeniami.

Węzły Galera są ściśle powiązane, a wydajność replikacji jest tak wysoka, jak w przypadku najwolniejszego węzła. Galera wykorzystuje mechanizm kontroli przepływu do kontrolowania przepływu replikacji między członkami i eliminowania wszelkich opóźnień podrzędnych. Replikacja może przebiegać szybko lub wolno na każdym węźle i jest dostosowywana automatycznie przez Galerę. Dlatego zaleca się stosowanie jednolitych specyfikacji sprzętowych dla wszystkich węzłów Galera, szczególnie w odniesieniu do procesora, pamięci RAM, podsystemu dysku, karty interfejsu sieciowego i opóźnień sieciowych między węzłami w klastrze.

Wnioski

Podsumowując, Galera Cluster jest lepszy w porównaniu z replikacją MySQL master-master ze względu na obsługę replikacji synchronicznej o dużej spójności, a także bardziej zaawansowane funkcje, takie jak automatyczna kontrola członkostwa, automatyczne przydzielanie węzłów i wielowątkowe urządzenia podrzędne. Ostatecznie zależy to od interakcji aplikacji z serwerem bazy danych. Niektóre starsze aplikacje zbudowane dla samodzielnego serwera bazy danych mogą nie działać dobrze w konfiguracji klastrowej.

Aby uprościć powyższe uwagi, następujące powody uzasadniają użycie replikacji MySQL master-master:

• Rzeczy, które nie są obsługiwane przez Galerę:
  • Replikacja dla tabel innych niż InnoDB/XtraDB, takich jak MyISAM, Aria, MEMORY lub ARCHIVE.
  • Transakcje XA.
  • Replikacja oparta na deklaracjach między masterami (np. gdy przepustowość jest bardzo droga).
  • Poleganie na jawnym blokowaniu, takim jak instrukcja LOCK TABLES.
  • Ogólny dziennik zapytań i wolny dziennik zapytań muszą być kierowane do tabeli, a nie do pliku.
• Luźno powiązana konfiguracja, w której specyfikacje sprzętu, wersja oprogramowania i szybkość połączenia są znacząco różne na każdym urządzeniu głównym.
• Gdy masz już łańcuch replikacji MySQL i chcesz dodać kolejny aktywny/kopiowy master w celu zapewnienia nadmiarowości, aby przyspieszyć przełączanie awaryjne i czas odzyskiwania w przypadku, gdy jeden z masterów jest niedostępny.
• Jeśli Twoja aplikacja nie może zostać zmodyfikowana w celu obejścia ograniczeń Galera Cluster i posiadanie systemu równoważenia obciążenia obsługującego MySQL, takiego jak ProxySQL lub MaxScale, nie jest opcją.

Powody, dla których warto wybrać Galera Cluster zamiast MySQL master-master:

• Możliwość bezpiecznego pisania do wielu mistrzów.
• Spójność danych automatycznie zarządzana (i gwarantowana) w różnych bazach danych.
• Łatwo wprowadzać i synchronizować nowe węzły bazy danych.
• Automatycznie wykryto awarie lub niespójności.
• Ogólnie bardziej zaawansowane i niezawodne funkcje wysokiej dostępności.