Wysoka dostępność w Azure Database for MySQL

Korzystając z usługi Azure Database for MySQL Flexible Server, można skonfigurować wysoką dostępność z automatycznym przełączeniem awaryjnym. 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 storage zarówno dla replik podstawowych, jak i pomocniczych. Dostępne są dwa modele architektury wysokiej dostępności:

• Strefowa nadmiarowość wysokiej dostępności. Ta opcja zapewnia pełną izolację i nadmiarowość 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ść z redundantnością strefową, jeśli chcesz chronić przed jakimikolwiek awariami infrastruktury w strefie dostępności i gdy latencja w strefie dostępności jest akceptowalna. Wysoką dostępność strefowo nadmiarową można włączyć tylko podczas tworzenia serwera. Strefowo nadmiarowa wysoka dostępność jest dostępna w podzbiorze regionów Azure, gdzie region obsługuje wiele stref dostępności i dostępne są strefowo nadmiarowe udziały plików Premium.

• Wysoka dostępność lokalnie nadmiarowa. 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 w różnych strefach. Wybierz lokalnie nadmiarową wysoką dostępność, jeśli chcesz uzyskać najwyższy poziom dostępności w jednej strefie dostępności z najniższym opóźnieniem sieci. Wysoka dostępność lokalnie nadmiarowa jest dostępna we wszystkich regionach Azure gdzie można użyć serwera elastycznego Azure Database for MySQL.

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

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

• Serwer podstawowy w jednej strefie dostępności.
• Serwer repliki rezerwowej w innej strefie dostępności tego samego regionu 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 serwera podstawowego i serwera rezerwowego w tej samej strefie zmniejsza opóźnienia, natomiast umieszczenie ich w różnych strefach pomaga przygotować się do sytuacji odzyskiwania po awarii i scenariuszy stref w dół.

Pliki danych i dziennika są hostowane w magazynowaniu z nadmiarowością strefową (ZRS). Serwer zapasowy stale odczytuje i odtwarza pliki dziennika z konta magazynu danych serwera podstawowego, które chroni replikacja na poziomie magazynu danych.

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 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 są wprowadzane tak, aby połączenia klienckie były kierowane do nowego serwera podstawowego po ponownym połączeniu klienta. Tryb failover jest całkowicie niewidoczny dla aplikacji klienckiej i nie wymaga żadnego działania z Twojej strony. Rozwiązanie HA następnie przywraca stary serwer podstawowy, gdy to możliwe, i umieszcza go w trybie zapasowym.

Nazwa serwera bazy danych służy do łączenia aplikacji z serwerem podstawowym. Rozwiązanie nie ujawnia informacji o replikach oczekujących dla bezpośredniego dostępu. Zatwierdzenia i zapisy są potwierdzane po wyczyszczeniu plików dziennika w ZRS serwera głównego. ** Ze względu na technologię replikacji synchronicznej stosowaną w magazynowaniu ZRS, można spodziewać się, że opóźnienia przy zapisie i zatwierdzaniu aplikacji wzrastają o 5–10 procent.

Podstawowy serwer bazy danych automatycznie tworzy kopie zapasowe zarówno migawek, jak i kopii zapasowych dzienników w strefowej pamięci z nadmiarowością.

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

Podczas wdrażania serwera z lokalnie redundantną architekturą HA 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 przechowywania i konfiguracja sieci)

Serwer rezerwowy zapewnia nadmiarowość infrastruktury przy użyciu oddzielnej maszyny wirtualnej (obliczeniowej). Ta nadmiarowość zmniejsza czas przerzutu awaryjnego i opóźnienie sieci między aplikacją a serwerem bazy danych ze względu na kolokację.

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

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 systemie 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 przejmuje 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 całkowicie niewidoczny dla aplikacji klienckiej i nie wymaga żadnego działania z Twojej strony. Rozwiązanie HA następnie przywraca stary serwer podstawowy, gdy to możliwe, i umieszcza go w trybie zapasowym.

Nazwa serwera bazy danych łączy aplikacje z serwerem podstawowym. Informacje o repliki zapasowej nie są udostępnione do bezpośredniego dostępu. Zatwierdzenia i zapisy są potwierdzane po wyczyszczeniu plików dziennika w LRS serwera głównego. Ponieważ replika podstawowa i rezerwowa znajdują się w tej samej strefie, opóźnienie replikacji oraz latencja między serwerem aplikacji a serwerem bazy danych są niższe. ** Lokalnie redundantna konfiguracja nie zapewnia wysokiej dostępności, gdy zależne infrastruktury są wyłączone w określonej strefie 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.

Podstawowy serwer bazy danych automatycznie tworzy kopie zapasowe zarówno migawek, jak i dzienników do lokalnie nadmiarowego magazynowania.

Migrowanie z istniejącego serwera do serwera strefowo nadmiarowego

Jeśli pierwotnie zaopatrzyłeś serwer Azure Database for MySQL jako serwer bez wysokiej dostępności (HA), możesz włączyć w nim lokalnie redundantną architekturę wysokiej dostępności (HA). Jeśli jednak chcesz włączyć ją dla architektury wysokiej dostępności z nadmiarowością strefową, musisz utworzyć nowy serwer z odpowiednią konfiguracją i przeprowadzić do niego migrację, wykonując następujące kroki:

1. Utwórz nowy serwer z włączoną strefowo nadmiarową wysoką dostępnością, postępując zgodnie z instrukcjami dla preferowanego narzędzia wdrażania:

   • portal Azure: Zarządzanie wysoką dostępnością redundantną strefowo w Azure Database for MySQL za pomocą portalu Azure
   • Azure CLI: Zarządzanie wysoką dostępnością z nadmiarowością strefową w Azure Database for MySQL za pomocą Azure CLI

2. Przeprowadź migrację obciążenia na nowy serwer, wykonując jedną z tych metod. W zależności od podejścia do migracji może być wymagany przestój.

   • Podejścia do migracji w trybie offline: Jeśli aplikacja może sobie pozwolić na przestój, migracje offline są zawsze preferowanym wyborem, ponieważ są proste i łatwe do wykonania. W przypadku migracji w trybie offline serwer źródłowy jest przełączony w tryb offline, a zrzut i przywracanie baz danych są wykonywane na serwerze docelowym. Ta opcja wymaga największego przestoju. Czas przestoju jest określany przez czas potrzebny do wykonania przywracania na serwerze docelowym.

     • Data Migration Service (DMS): Aby dowiedzieć się, jak używać usługi DMS, zobacz Jak migrować z MySQL do Azure Database for MySQL w trybie offline korzystając z DMS za pośrednictwem portalu Azure.

       Mimo że w samouczku opisano kroki migracji z lokalnego serwera MySQL do Azure Database for MySQL, można użyć tej samej procedury migracji danych z jednego serwera Azure Database for MySQL, który nie obsługuje stref dostępności do innej obsługującej strefy dostępności.

     • Narzędzia typu open source: Migrację w trybie offline można przeprowadzić przy użyciu narzędzi typu open source, takich jak MySQL Workbench, mydumper/myloader lub mysqldump , aby utworzyć kopię zapasową i przywrócić bazę danych. Aby uzyskać informacje na temat korzystania z tych narzędzi, zobacz Opcje migracji Azure Database for MySQL z jednoserwerowego do serwera elastycznego. Mimo że w tym samouczku opisano kroki migracji z serwera pojedynczego Azure MySQL do serwera elastycznego, można użyć tej samej procedury migracji danych z jednego serwera elastycznego Azure Database for MySQL, który nie obsługuje stref dostępności do innej obsługującej strefy dostępności.

   • Podejścia do migracji online: Migracje online minimalizują przestoje aplikacji. Serwer źródłowy zezwala na aktualizacje, a rozwiązanie migracyjne replikuje ciągłe zmiany między serwerem źródłowym a docelowym, wraz z początkowym zrzutem i przywracaniem danych na serwerze docelowym. Jednak te podejścia są bardziej złożone do zaimplementowania niż migracja w trybie offline.

     • Data Migration Service (DMS): Aby dowiedzieć się, jak używać usługi DMS, sprawdź w Migracja z MySQL do Azure Database dla MySQL online za pomocą DMS przez portal Azure.

       Mimo że w samouczku opisano kroki migracji z lokalnego serwera MySQL do Azure Database for MySQL, można użyć tej samej procedury migracji danych z jednego serwera Azure Database for MySQL, który nie obsługuje stref dostępności do innej obsługującej strefy dostępności.

     • Narzędzia typu open source: Możesz użyć kombinacji narzędzi typu open source, takich jak mydumper/myloader wraz z replikacją typu Data-in.

Proces failover

Podczas procesu trybu failover w 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.

Zaplanowane: wymuszone przełączenie

Azure Database for MySQL elastyczny serwer umożliwia ręczne wymuszenie przełączenia 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 aktywację repliki rezerwowej, która staje się serwerem podstawowym, używając tej samej nazwy serwera bazy danych i aktualizując rekord 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.

Niezaplanowane: automatyczne przełączenie awaryjne

Nieplanowany przestój usługi może wystąpić z powodu usterek oprogramowania lub błędów infrastruktury, takich jak błędy obliczeniowe, sieciowe lub storage. 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.

Jak działa automatyczne wykrywanie przełączenia awaryjnego na serwerach z funkcją wysokiej 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 do zarządzania komponentami i nawiązywania połączenia z systemem magazynowania zaplecza.

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

• Monitor wysyła polecenie ping do punktu końcowego sieci zarządzania 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. Ta kontrola kondycji dotyczy scenariuszy, takich jak awarie serwisu MySQL, zatrzymania lub zawieszenia się, problemy z backendowym storage i podobne problemy.

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.

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

Ograniczenia

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

• Wysoką dostępność można skonfigurować jako strefowo nadmiarową tylko podczas tworzenia serwera.

• Warstwa obliczeniowa z możliwością rozszerzenia nie obsługuje 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 limity dotyczące replikacji przy użyciu globalnych identyfikatorów transakcji GTID.

Znane problemy

Azure Database for MySQL Flexible Server używa natywnej replikacji MySQL na zapleczu. Znany problem istnieje w programie MySQL Community Edition 8.0 i nowszym, który może przerwać replikację podczas wykonywania wielotabłowej operacji DELETE, która opiera się na ograniczeniach klucza obcego z funkcją ON DELETE CASCADE. Ten problem jest śledzony jako 102586 usterek mySQL. W związku z tym, po włączeniu wysokiej dostępności w Azure Database for MySQL Flexible Server, unikaj używania kaskadowego usuwania w połączeniu z kluczami obcymi, ponieważ ten wzorzec może prowadzić do błędów replikacji i może wpływać na dostępność serwera.

Kontrole kondycji

Podczas konfigurowania wysokiej dostępności dla Azure Database for MySQL kontrole kondycji odgrywają 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 portalu Azure. 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.
• Resource utilization: Monitoruje użycie procesora, pamięci i pamięci masowej, aby zapobiec wąskim gardłom.

Niezawodność i odporność

Aby zapoznać się z kompleksowym omówieniem niezawodności w usłudze Azure Database for MySQL, w tym obsługą błędów przejściowych, odpornością strefy dostępności, odzyskiwaniem po awarii między regionami z replikami do odczytu, tworzeniem kopii zapasowych i przywracaniem oraz konserwacją usługi, zobacz Niezawodność w usłudze Azure Database for MySQL.

Powiązana zawartość

• Wysoka dostępność (HA) — często zadawane pytania w usłudze Azure Database for MySQL
• Omówienie ciągłości działania za pomocą usługi Azure Database for MySQL — serwer elastyczny
• Niezawodność w usłudze Azure Database for MySQL