W tej trzyczęściowej serii blogów wyjaśnimy szczegóły i funkcjonalność frameworka High Availability (HA) dla hostingu MySQL przy użyciu półsynchronicznej replikacji MySQL i stosu Corosync plus Pacemaker. W części I przeprowadzimy Cię przez podstawy wysokiej dostępności, składników frameworka HA, a następnie wprowadzimy Cię do frameworka HA dla MySQL.
Co to jest wysoka dostępność?
Dostępność systemu komputerowego to procent czasu, przez jaki usługi są dostępne w danym okresie czasu. Zwykle wyraża się ją jako serię 9-tych. Na przykład poniższa tabela pokazuje dostępność i odpowiadający jej czas przestoju mierzony w ciągu jednego roku.
| % dostępności | Przestój rocznie |
| 90% („jeden 9 „) | 36,53 dni |
| 99% („dwie dziewiątki „) | 3,65 dnia |
| 99,9% („trzy dziewiątki „) | 8,77 godziny |
| 99,99% („cztery dziewiątki „) | 52,60 minut |
| 99,999% („pięć dziewiątek „) | 5,26 minuty |
| 99,9999% („sześć dziewiątek „) | 31,56 sekundy |
Znaczenie wysokiej dostępności różni się w zależności od wymagań aplikacji i firmy. Na przykład, jeśli nie możesz sobie pozwolić na przestoje w swojej usłudze dłuższe niż kilka minut rocznie, mówimy, że usługa musi mieć 99,999% wysokiej dostępności.
Komponenty HA Framework
Istotą wysokiej dostępności jest możliwość natychmiastowego przywrócenia sprawności po awariach, które mogą wystąpić w dowolnej części systemu. W każdym frameworku HA istnieją cztery bardzo istotne komponenty, które muszą współpracować w sposób zautomatyzowany, aby umożliwić tę odzyskiwalność. Przyjrzyjmy się szczegółowo tym komponentom:
1. Redundancja w infrastrukturze i danych
Aby usługa była wysoce dostępna, musimy zapewnić nadmiarowość w hostingu infrastruktury, a także aktualna nadmiarowość kopia danych, z których korzysta lub udostępnia serwis. Działa to jako usługa rezerwowa gotowa do przejęcia w przypadku awarii głównej.
2. Mechanizm wykrywania i korygowania awarii
Niezwykle ważne jest natychmiastowe wykrycie wszelkich awarii w dowolnej części systemu podstawowego, które mogą wpłynąć na jego dostępność. Umożliwi to ramom podjęcie działań naprawczych w tym samym systemie podstawowym lub przełączenie usług w tryb awaryjny na system rezerwowy.
3. Mechanizm przełączania awaryjnego
Ten składnik odpowiada za przełączanie awaryjne usług w infrastrukturze rezerwowej. Należy pamiętać, że w przypadku dostępności wielu systemów nadmiarowych, ten składnik mechanizmu przełączania awaryjnego musi zidentyfikować najbardziej odpowiedni system spośród nich i promować go jako usługę podstawową.
4. Mechanizm przekierowywania aplikacji/użytkowników
Gdy systemy rezerwowe przejmą rolę podstawowego, ten składnik zapewnia, że wszystkie połączenia aplikacji i użytkowników zaczną przychodzić do nowego podstawowego.
Objaśnienie struktury wysokiej dostępności MySQL — część IKliknij, aby tweetować
Szkielet HA dla MySQL
W oparciu o powyższy model, używamy następującego frameworka HA dla naszego hostingu MySQL w ScaleGrid:
- Konfiguracja 3-węzłowa Master-Slave wykorzystująca półsynchroniczną replikację MySQL w celu zapewnienia nadmiarowości infrastruktury i danych.
- Stos Corosync plus Pacemaker zapewniający wykrywanie awarii, korekcję i mechanizm przełączania awaryjnego.
- Mapowanie DNS lub komponent wirtualnego adresu IP w celu zapewnienia mechanizmu przekierowywania aplikacji i użytkowników.
Sprawdź poniższy diagram, aby zwizualizować stos oprogramowania tej architektury:
Przyjrzyjmy się funkcjonalności niektórych kluczowych komponentów w tej strukturze.
-
Korosync
Corosync zapewnia strukturę komunikacji dla węzłów z niezawodnym przekazywaniem wiadomości między nimi. Tworzy pierścień węzłów klastra i śledzi dołączanie i opuszczanie klastra przez węzły poprzez członkostwo w klastrze. Corosync ściśle współpracuje z Pacemakerem, aby komunikować się o dostępności węzła, aby Pacemaker mógł podejmować odpowiednie decyzje.
-
Rozrusznik
Pacemaker, znany również jako Cluster Resource Manager (CRM), zapewnia wysoką dostępność MySQL działającego w klastrze oraz wykrywa i obsługuje awarie na poziomie węzła, łącząc się z Corosync. Wykrywa również i obsługuje awarie MySQL, łącząc się z agentem zasobów (RA). Pacemaker konfiguruje i zarządza zasobami MySQL poprzez uruchamianie, zatrzymywanie, monitorowanie, promowanie i degradowanie operacji.
-
Agent zasobów
Agent zasobów działa jako interfejs między MySQL a Pacemakerem. Implementuje operacje uruchamiania, zatrzymywania, promowania, degradowania i monitorowania, które są wywoływane przez Stymulator. Istnieje w pełni funkcjonalny agent zasobów o nazwie Percona Replication Manager (PRM) dla MySQL zaimplementowany przez Perconę. Zostało to ulepszone przez ScaleGrid i jest dostępne na naszej stronie GitHub.
-
Komponent mapowania DNS
Agent zasobów, po udanym przełączeniu awaryjnym, wywołuje ten komponent, który aktualizuje rekordy DNS głównego serwera MySQL o adres IP nowego głównego serwera. Zauważ, że klienci zawsze używają nadrzędnej nazwy DNS do łączenia się z serwerem MySQL, a zarządzając mapowaniem tej nazwy DNS na adres IP bieżącego nadrzędnego, możemy zapewnić, że klienci nie będą musieli zmieniać swoich parametrów połączenia lub właściwości, gdy jest awaria.
W części drugiej tej serii blogów dowiesz się o krytycznym komponencie redundancji danych, który jest osiągany za pomocą półsynchronicznej replikacji MySQL. Zagłębimy się również w szczegóły i konfiguracje replikacji półsynchronicznej, których używamy, aby osiągnąć nasze wsparcie wysokiej dostępności, a na koniec przejrzymy różne scenariusze awarii w części III oraz sposób, w jaki struktura reaguje i odzyskuje z tych warunków.
