W tej trzyczęściowej serii blogów przedstawiliśmy strukturę wysokiej dostępności (HA) dla hostingu MySQL w części I, a w części II omówiliśmy szczegóły replikacji półsynchronicznej MySQL. Teraz w części III omówimy, w jaki sposób framework obsługuje niektóre z ważnych scenariuszy awarii MySQL i przywraca ich wysoką dostępność.
Scenariusze awarii MySQL
Scenariusz 1 – Upadek Master MySQL
- Framework Corosync i Pacemaker wykrywa, że główny MySQL nie jest już dostępny. Pacemaker degraduje zasób główny i próbuje odzyskać, jeśli to możliwe, po ponownym uruchomieniu usługi MySQL.
- W tym momencie, ze względu na semisynchroniczny charakter replikacji, wszystkie transakcje dokonane na urządzeniu głównym zostały odebrane przez co najmniej jeden z urządzeń podrzędnych.
- Pacemaker czeka, aż wszystkie otrzymane transakcje zostaną zastosowane na niewolnikach i pozwala niewolnikom zgłosić swoje wyniki awansu. Obliczanie wyniku odbywa się w taki sposób, że wynik wynosi „0”, jeśli niewolnik jest całkowicie zsynchronizowany z urządzeniem głównym, a w przeciwnym razie jest liczbą ujemną.
- Pacemaker wybiera slave'a, które zgłosiło wynik 0 i promuje to slave'a, które teraz przejmuje rolę nadrzędnego MySQL, na którym zapis jest dozwolony.
- Po promocji podrzędnej agent zasobów wyzwala moduł przekierowywania DNS. Moduł aktualizuje wpis serwera proxy o adres IP nowego mastera, ułatwiając w ten sposób przekierowanie wszystkich zapisów aplikacji do nowego mastera.
- Rozrusznik ustawia również dostępne urządzenia podrzędne, aby rozpocząć replikację z tego nowego urządzenia głównego.
Tak więc, za każdym razem, gdy główny MySQL ulegnie awarii (z powodu awarii MySQL, awarii systemu operacyjnego, ponownego uruchomienia systemu itp.), nasz framework HA wykrywa go i promuje odpowiedni moduł podrzędny do przejąć rolę mistrza. Gwarantuje to, że system będzie nadal dostępny dla aplikacji.
#Objaśnienie struktury wysokiej dostępności MySQL – Część III:Scenariusze awariiKliknij, aby tweetować
Scenariusz 2 – Upadek niewolnika MySQL
- Framework Corosync i Pacemaker wykrywa, że podrzędny MySQL nie jest już dostępny.
- Pacemaker próbuje odzyskać zasób, próbując ponownie uruchomić MySQL w węźle. Jeśli się pojawi, jest dodawany z powrotem do aktualnego mastera jako slave i replikacja jest kontynuowana.
- Jeśli odzyskiwanie nie powiedzie się, Pacemaker zgłasza, że zasób jest wyłączony — na podstawie tego, które alerty lub powiadomienia mogą być generowane. W razie potrzeby zespół wsparcia ScaleGrid zajmie się odzyskaniem tego węzła.
- W tym przypadku nie ma wpływu na dostępność usług MySQL.
Scenariusz 3 – Partycja sieciowa – Zerwanie łączności między węzłami nadrzędnym i podrzędnym
Jest to klasyczny problem w każdym systemie rozproszonym, w którym każdy węzeł myśli, że inne węzły są wyłączone, podczas gdy w rzeczywistości zerwana jest tylko komunikacja sieciowa między węzłami. Ten scenariusz jest powszechnie znany jako scenariusz podziału mózgu i jeśli nie zostanie odpowiednio obsłużony, może prowadzić do tego, że więcej niż jeden węzeł będzie podawał się za główny MySQL, co z kolei prowadzi do niespójności i uszkodzenia danych.
Skorzystajmy z przykładu, aby sprawdzić, jak nasza platforma radzi sobie ze scenariuszami podziału mózgu w klastrze. Zakładamy, że z powodu problemów z siecią klaster podzielił się na dwie grupy – master w jednej i 2 slave w drugiej, co oznaczymy jako [(M), (S1,S2)].
- Corosync wykrywa, że węzeł główny nie jest w stanie komunikować się z węzłami podrzędnymi, a węzły podrzędne mogą komunikować się ze sobą, ale nie z węzłem głównym .
- Węzeł główny nie będzie w stanie zatwierdzić żadnych transakcji, ponieważ replikacja półsynchroniczna oczekuje potwierdzenia od co najmniej jednego z podrzędnych, zanim główny będzie mógł zatwierdzić. W tym samym czasie Pacemaker wyłącza MySQL w węźle głównym z powodu braku kworum w oparciu o ustawienie Pacemakera „no-quorum-policy =stop”. Kworum oznacza tutaj większość węzłów lub dwa z trzech w konfiguracji klastra z trzema węzłami. Ponieważ w tej partycji klastra działa tylko jeden węzeł główny, wyzwalane jest ustawienie braku kworum, co prowadzi do zamknięcia głównego węzła MySQL.
- Teraz Pacemaker na partycji [(S1), (S2)] wykrywa brak dostępnego wzorca w klastrze i inicjuje proces promocji. Zakładając, że S1 jest na bieżąco z masterem (co gwarantuje replikacja półsynchroniczna), jest on następnie promowany jako nowy master.
- Ruch aplikacji zostanie przekierowany do tego nowego głównego węzła MySQL, a podrzędny S2 rozpocznie replikację z nowego głównego węzła.
Zatem widzimy, że framework MySQL HA skutecznie radzi sobie ze scenariuszami podziału mózgu, zapewniając zarówno spójność danych, jak i dostępność w przypadku zerwania łączności sieciowej między węzłami głównymi i podrzędnymi.
To zakończenie naszej trzyczęściowej serii blogów na temat frameworka MySQL High Availability (HA) przy użyciu replikacji półsynchronicznej i stosu Corosync plus Pacemaker. W ScaleGrid oferujemy wysoce dostępny hosting dla MySQL na AWS i MySQL na Azure, który jest wdrażany w oparciu o koncepcje wyjaśnione w tej serii blogów. Odwiedź konsolę ScaleGrid, aby uzyskać bezpłatną wersję próbną naszych rozwiązań.
