Omówienie ciągłości działania za pomocą usługi Azure Database for MySQL — serwer elastyczny
DOTYCZY: 
Azure Database for MySQL — serwer elastyczny
Usługa Azure Database for MySQL — elastyczny serwer umożliwia ciągłość działania, które chronią bazy danych w przypadku planowanej i nieplanowanej awarii. Funkcje, takie jak automatyczne kopie zapasowe i wysoka dostępność, dotyczą różnych poziomów ochrony przed błędami z różnymi czasami odzyskiwania i ekspozycjami na utratę danych. Podczas tworzenia architektury aplikacji w celu ochrony przed błędami należy wziąć pod uwagę cel czasu odzyskiwania (RTO) i cel punktu odzyskiwania (RPO) dla każdej aplikacji. Cel czasu odzyskiwania to tolerancja przestojów, a cel punktu odzyskiwania to tolerancja utraty danych po przerwie w działaniu usługi bazy danych.
W poniższej tabeli przedstawiono funkcje oferowanych przez usługę Azure Database for MySQL — serwer elastyczny.
| Funkcja | Opis | Ograniczenia |
|---|---|---|
| Tworzenie kopii zapasowych i odzyskiwanie | Usługa automatycznie wykonuje codzienne kopie zapasowe plików bazy danych i stale wykonuje kopie zapasowe dzienników transakcji. Kopie zapasowe mogą być przechowywane przez dowolny okres od 1 do 35 dni. Serwer bazy danych można przywrócić do dowolnego punktu w czasie w okresie przechowywania kopii zapasowej. Czas odzyskiwania zależy od rozmiaru danych do przywrócenia i czasu do wykonania odzyskiwania dziennika. Aby uzyskać więcej informacji, zobacz Pojęcia — tworzenie kopii zapasowych i przywracanie . | Dane kopii zapasowej pozostają w regionie |
| Lokalnie nadmiarowa kopia zapasowa | Kopie zapasowe usługi są automatycznie i bezpiecznie przechowywane w magazynie lokalnie nadmiarowym w regionie i w tej samej strefie dostępności. Lokalnie nadmiarowe kopie zapasowe replikują pliki danych kopii zapasowej serwera trzy razy w jednej lokalizacji fizycznej w regionie podstawowym. Lokalnie nadmiarowy magazyn kopii zapasowych zapewnia co najmniej 99,9999999999% (11 dziewiątek) trwałości obiektów w danym roku. Aby uzyskać więcej informacji, zobacz Pojęcia — tworzenie kopii zapasowych i przywracanie . | Dotyczy we wszystkich regionach |
| Geograficznie nadmiarowa kopia zapasowa | Kopie zapasowe usługi można skonfigurować jako geograficznie nadmiarowe w czasie tworzenia. Włączenie nadmiarowości geograficznej replikuje pliki danych kopii zapasowej serwera w regionie podstawowymâ € ™s sparowany region w celu zapewnienia odporności regionalnej. Geograficznie nadmiarowy magazyn kopii zapasowych zapewnia co najmniej 99,999999999999999% (16 dziewiątek) trwałości obiektów w danym roku. Aby uzyskać więcej informacji, zobacz Pojęcia — tworzenie kopii zapasowych i przywracanie . | Dostępne we wszystkich sparowanych regionach platformy Azure |
| Strefowo nadmiarowa wysoka dostępność | Usługę można wdrożyć w trybie wysokiej dostępności, który wdraża serwery podstawowe i rezerwowe w dwóch różnych strefach dostępności w regionie. Strefowo nadmiarowa wysoka dostępność chroni przed awariami na poziomie strefy, a także pomaga zmniejszyć przestoje aplikacji podczas planowanych i nieplanowanych zdarzeń przestojów. Dane z serwera podstawowego są synchronicznie replikowanie do repliki rezerwowej. Podczas każdego zdarzenia przestoju serwer bazy danych jest automatycznie przełączany w tryb failover do repliki rezerwowej. Aby uzyskać więcej informacji, zobacz Pojęcia — wysoka dostępność . | Obsługiwane w warstwach ogólnego przeznaczenia i Krytyczne dla działania firmy obliczeniowych. Dostępne tylko w regionach, w których dostępnych jest wiele stref. |
| Udziały plików w warstwie Premium | Pliki bazy danych są przechowywane w wysoce trwałych i niezawodnych udziałach plików w warstwie Premium platformy Azure, które zapewniają nadmiarowość danych z trzema kopiami repliki przechowywanymi w strefie dostępności z funkcjami automatycznego odzyskiwania danych. Aby uzyskać więcej informacji, zobacz Udziały plików w warstwie Premium. | Dane przechowywane w strefie dostępności |
Planowane ograniczenie przestojów
Poniżej przedstawiono niektóre scenariusze planowanej konserwacji, które powodują przestoje:
Po skonfigurowaniu serwera elastycznego z strefowo nadmiarową wysoką dostępnością serwer elastyczny najpierw wykonuje operacje na serwerze rezerwowym, a następnie na serwerze podstawowym bez trybu failover. Aby uzyskać więcej informacji, zobacz Pojęcia — wysoka dostępność .
Ograniczanie niezaplanowanych przestojów
Nieplanowane przestoje mogą wystąpić w wyniku nieprzewidzianych awarii, w tym podstawowych błędów sprzętowych, problemów z siecią i usterek oprogramowania. Jeśli serwer bazy danych ulegnie nieoczekiwanie awarii, jeśli skonfigurowano wysoką dostępność [HA], replika rezerwowa zostanie aktywowana. Jeśli nie, nowy serwer bazy danych jest automatycznie aprowizowany. Chociaż nie można uniknąć nieplanowanego przestoju, serwer elastyczny ogranicza przestoje, automatycznie wykonując operacje odzyskiwania zarówno na serwerze bazy danych, jak i w warstwach magazynu bez konieczności interwencji człowieka.
Nieplanowany przestój: scenariusze awarii i odzyskiwanie usługi
Poniżej przedstawiono niektóre nieplanowane scenariusze awarii i proces odzyskiwania:
| Scenariusz | Proces odzyskiwania [bez wysokiej dostępności] | Proces odzyskiwania [HA] |
|---|---|---|
| Błąd serwera bazy danych | Jeśli serwer bazy danych nie działa z powodu niektórych podstawowych błędów sprzętowych, aktywne połączenia zostaną porzucone, a wszystkie transakcje w locie zostaną przerwane. Platforma Azure próbuje ponownie uruchomić serwer bazy danych. Jeśli to się powiedzie, zostanie wykonane odzyskiwanie bazy danych. Jeśli ponowne uruchomienie zakończy się niepowodzeniem, próba ponownego uruchomienia serwera bazy danych zostanie podjęta w innym węźle fizycznym. Czas odzyskiwania (RTO) zależy od różnych czynników, w tym działania w momencie wystąpienia błędu, takiego jak duża transakcja i ilość odzyskiwania do wykonania podczas procesu uruchamiania serwera bazy danych. Cel punktu odzyskiwania wynosi zero, ponieważ nie oczekuje się utraty danych dla zatwierdzonych transakcji. Aplikacje korzystające z baz danych MySQL muszą być tworzone w sposób, w jaki wykrywają i ponawiają próby porzuconych połączeń i nieudanych transakcji. Gdy aplikacja ponawia próbę, połączenia są kierowane do nowo utworzonego serwera bazy danych. Inne dostępne opcje są przywracane z kopii zapasowej. Możesz użyć przywracania do punktu w czasie lub przywracania geograficznego z sparowanego regionu. PITR : RTO: Varies, RPO=0sec Przywracanie geograficzne: cel czasu odzyskiwania: zmienia cel punktu odzyskiwania <1 godz. Replikę do odczytu można również użyć jako rozwiązania odzyskiwania po awarii . Replikację można zatrzymać, co powoduje, że replika do odczytu i zapisu (autonomiczna, a następnie przekierowuje ruch aplikacji do tej bazy danych). Cel czasu odzyskiwania w większości przypadków wynosi kilka minut i cel punktu odzyskiwania < 1 h. Cel czasu odzyskiwania i cel punktu odzyskiwania mogą być znacznie wyższe w niektórych przypadkach w zależności od różnych czynników, w tym opóźnienia między lokacjami, ilości danych, które mają być przesyłane, i co ważne, obciążenia zapisu podstawowej bazy danych. |
Jeśli zostanie wykryta awaria serwera bazy danych lub błędy niemożliwe do odzyskania, serwer bazy danych rezerwowej zostanie aktywowany, co zmniejsza czas przestoju. Aby uzyskać więcej informacji, zapoznaj się ze stroną pojęć dotyczących wysokiej dostępności. Cel czasu odzyskiwania powinien wynosić od 60 do 120 s, a cel punktu odzyskiwania = 0. Uwaga: opcje procesu odzyskiwania [bez wysokiej dostępności] są również stosowane tutaj. |
| Błąd magazynu | Aplikacje nie widzą żadnego wpływu na problemy związane z magazynem, takie jak awaria dysku lub uszkodzenie fizycznego bloku. Ponieważ dane są przechowywane w trzech kopiach, kopia danych jest obsługiwana przez magazyn ocalały. Uszkodzenia bloków są automatycznie poprawiane. Jeśli kopia danych zostanie utracona, zostanie automatycznie utworzona nowa kopia danych. W rzadkim lub najgorszym scenariuszu, jeśli wszystkie kopie są uszkodzone, możemy użyć przywracania z przywracania geograficznego (sparowany region). Cel punktu odzyskiwania to < 1 h, a cel czasu odzyskiwania będzie się różnić. Replikę do odczytu można również użyć jako rozwiązania odzyskiwania po awarii zgodnie z powyższym opisem. |
W tym scenariuszu opcje są takie same jak w przypadku procesu odzyskiwania [non-HA] . |
| Błędy logiczne/użytkownika | Odzyskiwanie po błędach użytkownika, takich jak przypadkowo porzucone tabele lub niepoprawnie zaktualizowane dane, polega na wykonaniu odzyskiwania do punktu w czasie (PITR), przywracając i odzyskując dane do momentu tuż przed wystąpieniem błędu. Usunięty zasób serwera elastycznego można odzyskać w ciągu pięciu dni od momentu usunięcia serwera. Aby uzyskać szczegółowy przewodnik dotyczący przywracania usuniętego serwera, [zapoznaj się z udokumentowanymi krokami] (.. /flexible-server/how-to-restore-dropped-server.md). Aby chronić zasoby serwera po wdrożeniu przed przypadkowym usunięciem lub nieoczekiwanymi zmianami, administratorzy mogą używać blokad zarządzania. |
Te błędy użytkownika nie są chronione wysoką dostępnością, ponieważ wszystkie operacje użytkownika są również replikowane do trybu wstrzymania. W tym scenariuszu opcje są takie same jak w przypadku procesu odzyskiwania [non-HA] |
| Awaria strefy dostępności | Chociaż jest to rzadkie zdarzenie, jeśli chcesz odzyskać sprawność po awarii na poziomie strefy, możesz wykonać przywracanie geograficzne z do sparowanego regionu. Cel punktu odzyskiwania to <1 h, a cel czasu odzyskiwania będzie się różnić. Replikę do odczytu można również użyć jako rozwiązania odzyskiwania po awarii , tworząc replikę w inną strefę dostępności. Cel punktu odzyskiwania\cel punktu odzyskiwania przypomina to, co zostało opisane powyżej. |
Jeśli włączono strefowo nadmiarową wysoką dostępność, serwer elastyczny wykonuje automatyczne przełączanie w tryb failover do lokacji rezerwowej. Aby uzyskać więcej informacji, zapoznaj się z pojęciami dotyczącymi wysokiej dostępności. Cel czasu odzyskiwania powinien wynosić od 60 do 120 s, a cel punktu odzyskiwania = 0. Inne dostępne opcje są przywracane z kopii zapasowej. Możesz użyć przywracania do punktu w czasie lub przywracania geograficznego z sparowanego regionu. PITR: RTO: Varies, RPO=0 sec Przywracanie geograficzne: cel czasu odzyskiwania: różni się, cel punktu odzyskiwania <1 godz. Uwaga: jeśli włączono tę samą strefę wysokiej dostępności, opcje są takie same jak w przypadku procesu odzyskiwania [bez wysokiej dostępności]. |
| Błąd regionu | Chociaż jest to rzadkie zdarzenie, jeśli chcesz odzyskać sprawność po awarii na poziomie regionu, możesz wykonać odzyskiwanie bazy danych, tworząc nowy serwer przy użyciu najnowszej geograficznie nadmiarowej kopii zapasowej dostępnej w ramach tej samej subskrypcji, aby uzyskać najnowsze dane. Nowy serwer elastyczny jest wdrażany w wybranym regionie. Czas potrzebny na przywrócenie zależy od poprzedniej kopii zapasowej i liczby dzienników transakcji do odzyskania. Cel punktu odzyskiwania w większości przypadków wynosi <1 h, a cel czasu odzyskiwania będzie się różnić. | W tym scenariuszu opcje są takie same jak w przypadku procesu odzyskiwania [non-HA] . |
Wymagania i ograniczenia
Miejsce przechowywania danych regionów
Domyślnie usługa Azure Database for MySQL — elastyczny serwer nie przenosi ani nie przechowuje danych klientów z regionu, w którym jest wdrażany. Klienci mogą jednak opcjonalnie włączyć geograficznie nadmiarowe kopie zapasowe lub skonfigurować replikację między regionami na potrzeby przechowywania danych w innym regionie.
Następne kroki
- Dowiedz się więcej o wysokiej dostępności strefowo nadmiarowej
- Dowiedz się więcej o tworzeniu kopii zapasowych i odzyskiwaniu