Wysoka dostępność w usłudze Azure Database for MySQL

Usługa Azure Database for MySQL — elastyczny serwer umożliwia skonfigurowanie wysokiej dostępności z automatycznym trybem failover. To rozwiązanie zapewnia, że awarie nigdy nie powodują utraty zatwierdzonych danych i że baza danych nie jest pojedynczym punktem awarii w architekturze oprogramowania. Podczas konfigurowania wysokiej dostępności serwer elastyczny automatycznie aprowizuje replikę rezerwową i zarządza nią. Płacisz za aprowizowane zasoby obliczeniowe i magazyn zarówno dla replik podstawowych, jak i pomocniczych. Dostępne są dwa modele architektury wysokiej dostępności:

• Wysoka dostępność z redundancją strefową. Ta opcja zapewnia pełną izolację i redundancję infrastruktury w wielu strefach dostępności. Zapewnia najwyższy poziom dostępności, ale wymaga skonfigurowania nadmiarowości aplikacji w różnych strefach. Wybierz wysoką dostępność strefową, jeśli chcesz zabezpieczyć się przed jakimikolwiek awariami infrastruktury w strefie dostępności i gdy akceptowalne jest opóźnienie między strefami dostępności. Strefową nadmiarowość wysokiej dostępności można włączyć tylko podczas tworzenia serwera. Strefowo nadmiarowa wysoka dostępność jest dostępna w podzestawie regionów platformy Azure, w których region obsługuje wiele stref dostępności i strefowo nadmiarowe udziały plików Premium są dostępne.

• Lokalna redundancja z wysoką dostępnością. Ta opcja zapewnia nadmiarowość infrastruktury z mniejszym opóźnieniem sieci, ponieważ serwery podstawowe i rezerwowe znajdują się w tej samej strefie dostępności. Zapewnia wysoką dostępność bez konieczności konfigurowania nadmiarowości aplikacji między strefami. Wybierz lokalną redundantną wysoką dostępność (HA), jeśli chcesz uzyskać najwyższy poziom dostępności w pojedynczej strefie dostępności z najniższym opóźnieniem sieciowym. Lokalna redundancja wysokiej dostępności jest dostępna we wszystkich regionach Azure, w których można używać Serwera Elastycznego Azure Database dla MySQL.

Architektura wysokiej dostępności rozłożona na strefy (HA).

Podczas wdrażania serwera z strefowo nadmiarową wysoką dostępnością platforma Azure tworzy dwa serwery:

• Serwer podstawowy w jednej strefie dostępności.
• Serwer repliki rezerwowej w innej strefie dostępności w tym samym regionie świadczenia usługi Azure. Serwer repliki rezerwowej ma taką samą konfigurację jak serwer podstawowy, w tym warstwę obliczeniową, rozmiar obliczeniowy, rozmiar magazynu i konfigurację sieci.

Możesz wybrać strefę dostępności zarówno dla serwera podstawowego, jak i repliki rezerwowej. Umieszczenie rezerwowych serwerów bazy danych i aplikacji rezerwowych w tej samej strefie zmniejsza opóźnienie. Pomaga również przygotować się do sytuacji odzyskiwania po awarii i scenariuszy redukcji stref.

Pliki danych i dziennika są hostowane w magazynie strefowo nadmiarowym (ZRS). Serwer rezerwowy stale odczytuje i odtwarza pliki dziennika z konta magazynu na serwerze podstawowym, które jest chronione przez replikację na poziomie magazynu.

Jeśli nastąpi przełączenie awaryjne:

• Replika rezerwowa aktywuje się.
• Pliki dziennika binarnego serwera podstawowego nadal mają zastosowanie do serwera rezerwowego w celu przełączenia go w tryb online do ostatniej zatwierdzonej transakcji na serwerze podstawowym.

Dzienniki w magazynach ZRS są dostępne nawet wtedy, gdy serwer podstawowy jest niedostępny. Ta dostępność pomaga zapewnić brak utraty danych. Po aktywowaniu repliki rezerwowej i zastosowaniu dzienników binarnych bieżący serwer repliki rezerwowej przejmuje rolę serwera podstawowego. Aktualizacje DNS tak, aby połączenia klienta były kierowane bezpośrednio do nowego serwera głównego, gdy klient ponownie się łączy. Tryb failover jest w pełni niewidoczny dla aplikacji klienckiej i nie wymaga żadnej akcji od Ciebie. Następnie rozwiązanie wysokiej dostępności przywraca stary serwer podstawowy, gdy to możliwe, i umieszcza go jako rezerwę.

Nazwa serwera bazy danych służy do łączenia aplikacji z serwerem podstawowym. Rozwiązanie nie uwidacznia informacji o replikach rezerwowych dla bezpośredniego dostępu. Zatwierdzenia i zapisy są potwierdzane po opróżnieniu plików dziennika w magazynach ZRS serwera podstawowego. Ze względu na technologię replikacji synchronizacji używaną w magazynie ZRS można oczekiwać 5–10 procent zwiększonego opóźnienia dla zapisów i zatwierdzeń aplikacji.

Automatyczne kopie zapasowe, zarówno migawki, jak i kopie zapasowe dzienników, są wykonywane w magazynie strefowo nadmiarowym z podstawowego serwera bazy danych.

Architektura wysokiej dostępności (HA) o lokalnej redundancji

Podczas wdrażania serwera z lokalnie nadmiarową wysoką dostępnością należy utworzyć dwa serwery w tej samej strefie:

• Serwer podstawowy
• Serwer repliki rezerwowej, który ma taką samą konfigurację jak serwer podstawowy (warstwa obliczeniowa, rozmiar obliczeniowy, rozmiar magazynu i konfiguracja sieci)

Serwer rezerwowy zapewnia nadmiarowość infrastruktury z oddzielną maszyną wirtualną (przetwarzanie). Ta nadmiarowość zmniejsza czas pracy w trybie failover i opóźnienie sieci między aplikacją a serwerem bazy danych z powodu kolokacji.

Pliki danych i dziennika są hostowane w magazynie lokalnie nadmiarowym (LRS). Serwer rezerwowy stale odczytuje i odtwarza pliki dziennika z konta magazynu serwera podstawowego, które jest chronione przez replikację na poziomie magazynu.

Jeśli nastąpi przełączenie awaryjne:

• Replika rezerwowa aktywuje się.
• Pliki dziennika binarnego serwera podstawowego nadal mają zastosowanie do serwera rezerwowego w celu przełączenia go w tryb online do ostatniej zatwierdzonej transakcji na serwerze podstawowym.

Dzienniki w magazynach LRS są dostępne nawet wtedy, gdy serwer podstawowy jest niedostępny. Ta dostępność pomaga zapewnić brak utraty danych. Po aktywowaniu repliki rezerwowej i zastosowaniu dzienników binarnych bieżąca replika rezerwowa przyjmuje rolę serwera podstawowego. System DNS jest aktualizowany w celu przekierowania połączeń do nowego serwera podstawowego podczas ponownego nawiązywania połączenia przez klienta. Tryb failover jest w pełni niewidoczny dla aplikacji klienckiej i nie wymaga żadnej akcji od Ciebie. Następnie rozwiązanie wysokiej dostępności przywraca stary serwer podstawowy, gdy to możliwe, i umieszcza go jako rezerwę.

Nazwa serwera bazy danych łączy aplikacje z serwerem podstawowym. Informacje o repliki rezerwowej nie są uwidocznione w celu uzyskania bezpośredniego dostępu. Zatwierdzenia i zapisy są potwierdzane po opróżnieniu plików dziennika w magazynach LRS serwera podstawowego. Ponieważ replika podstawowa i rezerwowa znajdują się w tej samej strefie, opóźnienie replikacji jest mniejsze i mniejsze opóźnienie między serwerem aplikacji a serwerem bazy danych. Konfiguracja lokalnej redundancji nie zapewnia wysokiej dostępności, gdy infrastruktura zależna jest niedostępna dla określonej strefy dostępności. Występuje przerwa, dopóki wszystkie usługi zależne nie zostaną ponownie dostępne online dla tej strefy dostępności.

Automatyczne kopie zapasowe, zarówno migawki, jak i kopie zapasowe dzienników, są wykonywane w magazynie lokalnie nadmiarowym z podstawowego serwera bazy danych.

Uwaga

W przypadku strefowo redundantnej i lokalnie redundantnej HA:

• Jeśli wystąpi awaria, czas potrzebny do przejęcia roli podstawowej przez replikę zapasową zależy od czasu potrzebnego na ponowne odtworzenie dziennika binarnego z podstawowego konta magazynowego do zapasowego. Aby skrócić czas pracy w trybie failover, użyj kluczy podstawowych we wszystkich tabelach. Czasy przełączenia awaryjnego zwykle trwają od 60 do 120 sekund.
• Serwer rezerwowy nie jest dostępny dla operacji odczytu ani zapisu. Jest to pasywna rezerwa umożliwiająca szybkie przejście w tryb failover.
• Zawsze używaj w pełni kwalifikowanej nazwy domeny (FQDN), aby nawiązać połączenie z serwerem podstawowym. Unikaj używania adresu IP do nawiązania połączenia. Jeśli nastąpi przejście w tryb failover, po przełączeniu ról serwera podstawowego i rezerwowego rekord DNS A może ulec zmianie. Ta zmiana uniemożliwia aplikacji nawiązywanie połączenia z nowym serwerem podstawowym, jeśli w parametrach połączenia jest używany adres IP.

Proces trybu failover

Podczas procesu trybu failover w usłudze Azure Database for MySQL system automatycznie przełącza się z serwera podstawowego do repliki rezerwowej. Ten przełącznik zapewnia ciągłość i minimalizuje przestoje. Gdy system wykryje awarię, promuje replikę rezerwową, aby stała się nowym serwerem podstawowym. System stosuje pliki dziennika binarnego z oryginalnego serwera podstawowego do repliki rezerwowej. Ten proces synchronizuje replikę rezerwowa z ostatnią zatwierdzoną transakcją i zapewnia brak utraty danych. To bezproblemowe przejście pomaga zachować wysoką dostępność i niezawodność usługi bazy danych.

Uwaga

Aby zmniejszyć zależność czasu przełączania awaryjnego od buforowania DNS, począwszy od października 2025 r., wszystkie nowe serwery wysokiej dostępności utworzone z dostępem publicznym lub łączem prywatnym przyjmą nową architekturę z dedykowanym SLB dla każdego serwera wysokiej dostępności. Zarządzając ścieżką ruchu danych MySQL, SLB eliminuje konieczność zmian DNS podczas pracy w trybie failover i znacznie poprawia wydajność pracy w trybie failover. Przekierowuje ruch do bieżącego wystąpienia podstawowego podczas przełączania awaryjnego, wykorzystując reguły równoważenia obciążenia. Istniejące serwery z dostępem publicznym lub łączem prywatnym zostaną zmigrowane stopniowo w celu zminimalizowania wpływu. Klienci, którzy wolą wczesną migrację, mogą wyłączyć i ponownie włączyć wysoką dostępność. Ta funkcja nie jest obsługiwana w przypadku serwerów korzystających z dostępu prywatnego z integracją z siecią wirtualną.

Zaplanowane: wymuszone przejście w tryb failover

Usługa Azure Database for MySQL — serwer elastyczny zmuszony do trybu failover umożliwia ręczne wymuszenie przejścia w tryb failover. Ta funkcja pozwala przetestować funkcje w scenariuszach aplikacji i pomóc w przygotowaniu się do awarii.

Wymuszone przejście w tryb failover wyzwala przejście w tryb failover, który aktywuje replikę rezerwową, aby stała się serwerem podstawowym z taką samą nazwą serwera baz danych, przez zaktualizowanie rekordu DNS. Oryginalny serwer podstawowy uruchamia się ponownie i przełącza do repliki rezerwowej. Połączenia klientów rozłączają się i muszą ponownie połączyć się, aby kontynuować operacje.

Ogólny czas przejścia w tryb failover zależy od bieżącego obciążenia i ostatniego punktu kontrolnego. Ogólnie rzecz biorąc, zajmuje to od 60 do 120 sekund.

Uwaga

Zdarzenie usługi Azure Resource Health jest generowane podczas planowanego przejścia w tryb failover. Zdarzenie reprezentuje czas pracy w trybie failover, w którym serwer jest niedostępny. Zdarzenia wyzwalane można zobaczyć po wybraniu w usłudze Resource Health w okienku po lewej stronie. Stan reprezentuje zainicjowane przez użytkownika lub ręczne przejście w tryb failover jako "Niedostępne" i oznaczone jako "Planowane". Przykład : "Operacja przejścia w tryb failover została wyzwolona przez autoryzowanego użytkownika (Planned)". Jeśli zasób pozostaje w tym stanie przez dłuższy czas, otwórz zgłoszenie do pomocy technicznej, a my Ci pomożemy.

Niezaplanowane: automatyczne przejście w tryb failover

Nieplanowany przestój usługi może wystąpić z powodu usterek oprogramowania lub błędów infrastruktury, takich jak awarie zasobów obliczeniowych, sieci lub magazynu. Awarie zasilania mogą również mieć wpływ na dostępność bazy danych. Jeśli baza danych stanie się niedostępna, replikacja do repliki rezerwowej zostanie zatrzymana, a replika rezerwowa stanie się podstawową bazą danych. Występują aktualizacje DNS, a klienci ponownie łączą się z serwerem bazy danych, wznawiając swoje operacje.

Ogólny czas przełączania awaryjnego wynosi zwykle od 60 do 120 sekund. Jednak w zależności od działania na podstawowym serwerze bazy danych w momencie przejścia w tryb failover (na przykład dużych transakcji i czasu odzyskiwania) przejście w tryb failover może trwać dłużej.

Uwaga

Zdarzenie usługi Azure Resource Health jest generowane podczas nieplanowanego trybu failover. Zdarzenie reprezentuje czas pracy awaryjnej, gdy serwer jest niedostępny. Po wybraniu pozycji Resource Health w okienku po lewej stronie zobaczysz wyzwalane zdarzenia. Automatyczne przełączanie awaryjne wyświetla stan "Niedostępny" i jest opisany jako "Nieplanowane".

Na przykład Niedostępność: operacja przełączenia awaryjnego została wyzwolona automatycznie (nieplanowane). Jeśli zasób pozostaje w tym stanie przez długi czas, otwórz zgłoszenie do pomocy technicznej, a my Ci pomożemy.

Jak działa automatyczne wykrywanie trybu failover na serwerach z włączoną wysoką dostępnością

Serwer podstawowy i serwer pomocniczy mają dwa punkty końcowe sieci:

• Punkt końcowy klienta: klienci łączą się z wystąpieniem i uruchamiają zapytania przy użyciu tego punktu końcowego.
• Punkt końcowy zarządzania: używany wewnętrznie do komunikacji między usługami a składnikami zarządzania i nawiązywania połączenia z magazynem zaplecza.

Składnik monitora kondycji stale przeprowadza następujące kontrole:

• Monitor wysyła polecenie ping do punktu końcowego sieci zarządzającej węzła. Jeśli to sprawdzenie zakończy się niepowodzeniem dwa razy z rzędu, wyzwala automatyczną operację przełączenia awaryjnego. Ta kontrola kondycji rozwiązuje scenariusze, takie jak niedostępność węzła lub brak odpowiedzi z powodu problemów z systemem operacyjnym, problemów z siecią między składnikami zarządzania i węzłami oraz podobnych problemów.
• Monitor uruchamia proste zapytanie w wystąpieniu. Jeśli wykonywanie zapytań nie powiedzie się, zostaje uruchomione automatyczne przełączanie awaryjne. To sprawdzenie kondycji dotyczy scenariuszy, takich jak awarie demona MySQL, zatrzymywanie się lub zawieszanie oraz problemy z pamięcią zaplecza i podobne zagadnienia.

Uwaga

Kontrola kondycji nie monitoruje problemów z siecią między aplikacją a punktem końcowym sieci klienta (dostęp prywatny/publiczny). Te problemy mogą wystąpić w ścieżce sieciowej, w punkcie końcowym lub w problemach DNS po stronie klienta. Jeśli używasz dostępu prywatnego, upewnij się, że reguły grupy zabezpieczeń sieci dla sieci wirtualnej nie blokują komunikacji z punktem końcowym sieci klienta instancji na porcie 3306. W przypadku dostępu publicznego upewnij się, że reguły zapory są ustawione, a ruch sieciowy jest dozwolony na porcie 3306 (jeśli ścieżka sieciowa ma inne zapory). Musisz również zadbać o rozwiązanie DNS po stronie aplikacji klienckiej.

Monitorowanie wysokiej dostępności

Aby sprawdzić stan konfiguracji wysokiej dostępności serwera, użyj stanu wysokiej dostępności w okienku wysokiej dostępności serwera w portalu.

Stan	Opis
NotEnabled	Funkcja wysokiej dostępności nie została włączona.
Replikowanie danych	Serwer rezerwowy synchronizuje się z serwerem podstawowym podczas aprowizacji serwera o wysokiej dostępności lub po włączeniu opcji wysokiej dostępności.
Tryb failover	Serwer bazy danych przechodzi w tryb failover z serwera podstawowego do rezerwowego.
Zdrowy	Opcja wysokiej dostępności jest włączona.
Usuwaniestandby	Proces usuwania jest w toku po wyłączeniu opcji wysokiej dostępności.

Aby monitorować kondycję serwera o wysokiej dostępności, użyj następujących metryk.

Nazwa wyświetlana metryki	Wskaźnik	Jednostka	opis
Stan wysokiej dostępności IO	ha_io_running	Stan	Stan IO HA pokazuje stan replikacji HA. Wartość metryki wynosi 1, jeśli wątek we/wy jest uruchomiony i 0, jeśli nie.
Stan ha SQL	ha_sql_running	Stan	Stan HA SQL pokazuje stan replikacji wysokiej dostępności. Wartość metryki to 1, jeśli wątek SQL jest uruchomiony i 0, jeśli nie.
Opóźnienie replikacji wysokiej dostępności	opóźnienie_replikacji	Sekundy	Opóźnienie replikacji to liczba sekund, przez które rezerwa znajduje się w przypadku ponownego odtworzenia transakcji odebranych na serwerze podstawowym.

Ograniczenia

Podczas korzystania z wysokiej dostępności należy pamiętać o następujących kwestiach:

• Wysoką dostępność z redundancją strefową można skonfigurować tylko podczas tworzenia serwera.

• Warstwa obliczeniowa tymczasowa nie zapewnia wysokiej dostępności.

• Ponowne uruchomienie podstawowego serwera bazy danych w celu zastosowania zmian parametrów statycznych powoduje również ponowne uruchomienie repliki rezerwowej.

• Rozwiązanie włącza tryb GTID, gdyż wykorzystuje GTID. Sprawdź, czy obciążenie ma ograniczenia lub ograniczenia dotyczące replikacji przy użyciu identyfikatorów GTID.

Uwaga

Automatyczne powiększanie pamięci jest domyślnie włączone dla serwera skonfigurowanego dla wysokiej dostępności i nie można go wyłączyć.

Kontrole kondycji

Podczas konfigurowania wysokiej dostępności dla usługi Azure Database for MySQL kontrola kondycji odgrywa kluczową rolę w utrzymaniu niezawodności i wydajności bazy danych. Te testy stale monitorują stan i kondycję replik podstawowych i rezerwowych, zapewniając szybkie wykrywanie problemów. Dzięki śledzeniu różnych metryk, takich jak czas odpowiedzi serwera, opóźnienie replikacji i wykorzystanie zasobów, kontrole kondycji pomagają zapewnić bezproblemowe wykonywanie procesów trybu failover, zminimalizowanie przestojów i zapobieganie utracie danych. Prawidłowo skonfigurowane kontrole kondycji są niezbędne do osiągnięcia żądanego poziomu dostępności i odporności w konfiguracji bazy danych.

Monitorowanie kondycji

Kondycję konfiguracji wysokiej dostępności można monitorować za pośrednictwem witryny Azure Portal. Kluczowe metryki do obserwowania obejmują:

• Czas odpowiedzi serwera: wskazuje, czy serwer podstawowy jest osiągalny.
• Opóźnienie replikacji: mierzy opóźnienie między replikami podstawowymi i rezerwowymi, zapewniając spójność danych.
• Wykorzystanie zasobów: Monitoruje użycie procesora, pamięci i pamięci masowej, aby zapobiec wąskim gardłom.

Powiązana zawartość

• wysoka dostępność
• Ciągłość biznesowa
• Nadmiarowa strefowo wysoka dostępność
• kopia zapasowa i odzyskiwanie