W części I przedstawiliśmy framework wysokiej dostępności (HA) dla hostingu MySQL i omówiliśmy różne komponenty i ich funkcjonalność. Teraz w części II omówimy szczegóły replikacji półsynchronicznej MySQL i powiązane ustawienia konfiguracyjne, które pomogą nam zapewnić nadmiarowość i spójność danych w naszej konfiguracji HA. Pamiętaj, aby ponownie zajrzeć do Części III, w której omówimy różne scenariusze awarii, które mogą się pojawić, oraz sposób, w jaki struktura reaguje i odzyskuje z tych warunków.
Co to jest replikacja półsynchroniczna MySQL?
Po prostu mówiąc, w konfiguracji replikacji półsynchronicznej MySQL, master zatwierdza transakcje w silniku pamięci masowej dopiero po otrzymaniu potwierdzenia od co najmniej jednego z urządzeń slave. Urządzenia podrzędne zapewniłyby potwierdzenie dopiero po odebraniu zdarzeń i skopiowaniu ich do dzienników przekaźników, a także zrzuceniu ich na dysk. Gwarantuje to, że dla wszystkich transakcji zatwierdzonych i zwróconych do klienta dane znajdują się na co najmniej 2 węzłach. Termin „semi” w języku semisynchronicznym (replikacja) wynika z faktu, że master zatwierdza transakcje po odebraniu zdarzeń i opróżnieniu ich do dziennika przekaźników, ale niekoniecznie w plikach danych na urządzeniu podrzędnym. Jest to przeciwieństwo replikacji w pełni synchronicznej, w której transakcja zostałaby zatwierdzona zarówno na urządzeniu podrzędnym, jak i na urządzeniu głównym, zanim sesja powróci do klienta.
Replikacja półsynchroniczna, która jest natywnie dostępna w MySQL, pomaga frameworkowi HA zapewnić spójność danych i nadmiarowość dla zatwierdzonych transakcji. W przypadku awarii urządzenia nadrzędnego wszystkie transakcje dokonane na urządzeniu nadrzędnym zostałyby zreplikowane do co najmniej jednego z urządzeń podrzędnych (zapisane w dziennikach przekaźników). W rezultacie przełączenie awaryjne do tego urządzenia podrzędnego byłoby bezstratne, ponieważ urządzenie podrzędne jest aktualne (po całkowitym opróżnieniu dzienników przekaźników urządzenia podrzędnego).
Ustawienia związane z replikacją i semisynchronią
Omówmy niektóre z kluczowych ustawień MySQL używanych do zapewnienia optymalnego zachowania w celu zapewnienia wysokiej dostępności i spójności danych w naszym frameworku.
Zarządzanie szybkością wykonywania niewolników
Pierwszą kwestią jest obsługa „pół-” zachowania replikacji półsynchronicznej, która gwarantuje jedynie, że dane zostały odebrane i opróżnione do dzienników przekaźnika przez wątek we/wy slave, ale niekoniecznie popełniony przez wątek SQL. Domyślnie wątek SQL w podrzędnym serwerze MySQL jest jednowątkowy i nie będzie w stanie dotrzymać kroku wątkowi nadrzędnemu, który jest wielowątkowy. Oczywistym skutkiem tego jest to, że w przypadku awarii urządzenia nadrzędnego, urządzenie podrzędne nie będzie aktualne, ponieważ jego wątek SQL nadal przetwarza zdarzenia w dzienniku przekaźnika. Spowoduje to opóźnienie procesu przełączania awaryjnego, ponieważ nasza struktura oczekuje, że urządzenie podrzędne będzie w pełni aktualne, zanim będzie można je promować. Jest to konieczne do zachowania spójności danych. Aby rozwiązać ten problem, włączamy wielowątkowe urządzenia podrzędne z opcją slave_parallel_workers, aby ustawić liczbę równoległych wątków SQL do przetwarzania zdarzeń w dziennikach przekaźnika.
Ponadto konfigurujemy poniższe ustawienia, które zapewniają, że urządzenie podrzędne nie wejdzie w żaden stan, w którym nie było urządzenia głównego:
- slave-parallel-type =ZEGAR_LOGICZNY
- slave_preserve_commit_order =1
Zapewnia nam to większą spójność danych. Dzięki tym ustawieniom będziemy w stanie uzyskać lepszą równoległość i prędkość na urządzeniu podrzędnym, ale jeśli jest zbyt wiele równoległych wątków, obciążenie związane z koordynacją między wątkami również wzrośnie i niestety może zniwelować korzyści.
Kolejną konfiguracją, której możemy użyć do zwiększenia wydajności wykonywania równoległego na urządzeniach podrzędnych, jest dostrojenie binlog_group_commit_sync_delay na urządzeniu głównym. Ustawiając to na master, wpisy dziennika binarnego na urządzeniu master, a tym samym wpisy dziennika przekaźnika na urządzeniu podrzędnym, będą zawierały partie transakcji, które mogą być przetwarzane równolegle przez wątki SQL. Zostało to szczegółowo wyjaśnione na blogu J-F Gagné, gdzie odnosi się do tego zachowania jako „spowalnianie mistrza, aby przyspieszyć niewolnika” .
Jeśli zarządzasz wdrożeniami MySQL za pomocą konsoli ScaleGrid, masz możliwość ciągłego monitorowania i otrzymywania alertów w czasie rzeczywistym o opóźnieniach replikacji urządzeń podrzędnych. Pozwala również na dynamiczne dostrajanie powyższych parametrów, aby upewnić się, że urządzenia podrzędne współpracują z urządzeniem głównym, minimalizując w ten sposób czas związany z procesem przełączania awaryjnego.
Objaśnienie struktury wysokiej dostępności MySQL — część IIKliknij, aby tweetować
Ważne opcje replikacji półsynchronicznej
Półsynchroniczna replikacja MySQL z założenia może wrócić do trybu asynchronicznego w oparciu o ustawienia limitu czasu potwierdzenia urządzenia podrzędnego lub liczbę dostępnych w dowolnym momencie urządzeń podrzędnych obsługujących półsynchronię. Tryb asynchroniczny z definicji nie zapewnia gwarancji, że zatwierdzone transakcje są replikowane do urządzenia podrzędnego, a zatem utrata urządzenia głównego prowadziłaby do utraty danych, które nie zostały zreplikowane. Domyślny projekt struktury ScaleGrid HA polega na unikaniu powrotu do trybu asynchronicznego. Przyjrzyjmy się konfiguracjom, które wpływają na to zachowanie.
-
rpl_semi_sync_master_wait_for_slave_count
Ta opcja jest używana do konfiguracji liczby urządzeń podrzędnych, które muszą wysłać potwierdzenie, zanim semisynchroniczny master będzie mógł zatwierdzić transakcję. W konfiguracji z trzema węzłami master-slave ustawiamy to na 1, więc zawsze mamy pewność, że dane są dostępne w co najmniej jednym urządzeniu podrzędnym, jednocześnie unikając wpływu na wydajność związanego z oczekiwaniem na potwierdzenie od obu urządzeń podrzędnych.
-
rpl_semi_sync_master_timeout
Ta opcja jest używana do konfiguracji czasu, przez który półsynchroniczny master czeka na potwierdzenie od slave'a przed przełączeniem z powrotem do trybu asynchronicznego. Ustawiamy to na stosunkowo wysoką wartość limitu czasu, aby nie było powrotu do trybu asynchronicznego.
Ponieważ pracujemy z 2 urządzeniami podrzędnymi, a rpl_semi_sync_master_wait_for_slave_count jest ustawione na 1, zauważyliśmy, że co najmniej jeden z urządzeń podrzędnych potwierdza w rozsądnym czasie, a urządzenie główne nie przełącza się w tryb asynchroniczny podczas tymczasowych zakłóceń sieci.
-
rpl_semi_sync_master_wait_no_slave
Kontroluje, czy urządzenie nadrzędne czeka na wygaśnięcie limitu czasu skonfigurowanego przez rpl_semi_sync_master_timeout, nawet jeśli liczba urządzeń podrzędnych spadnie poniżej liczby urządzeń podrzędnych skonfigurowanej przez rpl_semi_sync_master_wait_for_slave_count w tym okresie. Zachowujemy domyślną wartość ON, aby master nie wracał do replikacji asynchronicznej.
Wpływ utraty wszystkich półsynchronicznych niewolników
Jak widzieliśmy powyżej, nasza struktura uniemożliwia masterowi przełączenie się na replikację asynchroniczną, jeśli wszystkie urządzenia podrzędne przestaną działać lub staną się niedostępne dla mastera. Bezpośrednim skutkiem tego jest to, że zapisy zostają zatrzymane na wzorcu, co ma wpływ na dostępność usługi. Jest to zasadniczo zgodne z opisem twierdzenia CAP o ograniczeniach dowolnego systemu rozproszonego. Twierdzenie mówi, że w obecności partycji sieciowej będziemy musieli wybrać dostępność lub spójność, ale nie obie. Partycja sieciowa, w tym przypadku, może być traktowana jako podrzędna MySQL odłączona od mastera, ponieważ jest wyłączona lub niedostępna.
Naszym celem spójności jest zapewnienie, że dla wszystkich zatwierdzonych transakcji dane są dostępne w co najmniej 2 węzłach. W rezultacie w takich przypadkach struktura ScaleGrid HA sprzyja spójności nad dostępnością. Dalsze zapisy nie będą akceptowane od klientów, chociaż master MySQL będzie nadal obsługiwał żądania odczytu. Jest to świadoma decyzja projektowa, którą podjęliśmy jako zachowanie domyślne, które można oczywiście skonfigurować w oparciu o wymagania aplikacji.
Zasubskrybuj blog ScaleGrid, aby nie przegapić Części III, w której omówimy więcej scenariuszy awarii i możliwości odzyskiwania frameworka MySQL HA . Bądź na bieżąco!!
