Porównanie opcji ciągłości działania i odzyskiwania po awarii
Usługa Azure Database for MySQL — serwer elastyczny udostępnia funkcje ciągłości działania w celu ochrony bazy danych w przypadku planowanych lub nieplanowanych awarii. Aby rozwiązać różne typy awarii, można zastosować różne poziomy ochrony przed błędami z różnymi czasami odzyskiwania lub ryzykiem utraty danych.
Przykłady przestojów
Poniżej przedstawiono kilka przykładowych scenariuszy dotyczących planowanych i nieplanowanych przestojów.
Scenariusze planowanych przestojów
Dwa najbardziej typowe scenariusze planowanych przestojów to skalowanie obliczeń zainicjowane przez użytkownika i zaplanowana konserwacja wykonywana przez platformę Azure.
Podczas wykonywania operacji skalowania obliczeń platforma Azure aprowizuje nowy serwer elastyczny MySQL z żądaną konfiguracją obliczeniową. Istniejący serwer umożliwia ukończenie aktywnych punktów kontrolnych, opróżnianie istniejących połączeń, anulowanie niezatwierdzonych transakcji, a następnie zamknięcie istniejącego serwera. Na tym etapie platforma Azure dołącza magazyn istniejącego serwera do nowego serwera i uruchamia bazę danych. Następnie baza danych wykonuje wszelkie operacje odzyskiwania niezbędne przed kontynuowaniem akceptowania połączeń klienckich.
Nowe funkcje i poprawki błędów są automatycznie wykonywane w ramach planowanej konserwacji usługi. Poprawki uaktualnienia wersji pomocniczej są również stosowane podczas planowanej konserwacji, co powoduje kilka sekund przestoju. Te działania można zaplanować zgodnie z opisem w poniższej sekcji "Zaplanowane przestoje i okna obsługi".
Nieplanowany przestój
Baza danych może nieoczekiwanie spaść z kilku powodów, takich jak:
- Awaria sprzętu bazy danych.
- Awaria dysku magazynu.
- Błędy aplikacji lub użytkownika (np. przypadkowe porzucanie tabel).
- Błędy strefy dostępności i regionu.
Jeśli wysoka dostępność (HA) nie jest włączona, platforma Azure próbuje odzyskać, takie jak kopiowanie utraconych danych, ponowne uruchomienie serwera, a nawet uruchomienie serwera w innym węźle fizycznym. Włączenie wysokiej dostępności może zmniejszyć lub nawet wyeliminować tego rodzaju przestoje, jak opisano w poniższej sekcji.
Wysoka dostępność
Azure Database for MySQL — serwer elastyczny zapewnia wysoką dostępność dzięki automatycznemu przejściu w tryb failover, które zapewnia rozwiązanie, które nigdy nie traci zatwierdzonych danych i zapobiega pojedynczemu punktowi awarii bazy danych. Po skonfigurowaniu wysokiej dostępności serwer elastyczny MySQL automatycznie aprowizuje replikę rezerwową i zarządza nią.
Istnieją dwa rodzaje wysokiej dostępności z różnymi kompromisami odporności na uszkodzenia i opóźnieniami: strefowo nadmiarowe i tej samej strefy.
Strefowo nadmiarowa wysoka dostępność
Strefowo nadmiarowa wysoka dostępność zapewnia nadmiarowość w wielu strefach dostępności, oferując najwyższy poziom dostępności z możliwością odzyskania nawet wtedy, gdy cała strefa ulegnie awarii. Użycie strefowo nadmiarowej konfiguracji wysokiej dostępności wprowadza dodatkowe opóźnienia, dlatego upewnij się, że jest to akceptowalne dla aplikacji. Ponadto użycie strefowo nadmiarowej konfiguracji wysokiej dostępności wymaga również, aby aplikacje klienckie bazy danych były strefowo nadmiarowe, aby upewnić się, że ogólne operacje będą kontynuowane.
Wysoka dostępność w tej samej strefie
W konfiguracji wysokiej dostępności w tej samej strefie serwery podstawowe i rezerwowe znajdują się w tej samej strefie dostępności, co minimalizuje opóźnienie. Chociaż w niektórych przypadkach może być wymagane małe opóźnienie, w przypadku konfiguracji wysokiej dostępności w tej samej strefie, jeśli strefa dostępności ulegnie awarii, wynikowy przestój będzie dłuższy, gdy serwer elastyczny MySQL zostanie odzyskany.
W przeciwieństwie do strefowo nadmiarowej wysokiej dostępności dostępność w tej samej strefie jest dostępna we wszystkich regionach, które obsługują usługę Azure Database for MySQL — serwer elastyczny.
Tworzenie kopii zapasowej i przywracanie
Kopie zapasowe serwera są kluczowym składnikiem każdej strategii ciągłości działania. Azure Database for MySQL — serwer elastyczny automatycznie tworzy kopie zapasowe przechowywane bezpiecznie w magazynie lokalnie nadmiarowym w regionie hostujących bazę danych. Za pomocą tych kopii zapasowych można przywrócić bazę danych do określonego punktu w czasie, w przypadku awarii lub uszkodzenia danych (np. błędu aplikacji lub błędu programowania).
Istnieją dwa typy kopii zapasowych. Dzięki automatycznym kopiom zapasowym serwer elastyczny MySQL tworzy migawki plików danych bazy danych, a także skojarzone dzienniki transakcji. Automatyczne kopie zapasowe migawek są wykonywane raz dziennie, a kopie zapasowe dziennika transakcji są wykonywane co pięć minut. Jeśli tworzenie kopii zapasowej zakończy się niepowodzeniem, serwer ponawia próbę co 20 minut, aż tworzenie kopii zapasowej zakończy się pomyślnie.
Dzięki kopiom zapasowym na żądanie można utworzyć kopię zapasową bazy danych w dowolnym momencie. W przypadku obu typów kopii zapasowych pliki kopii zapasowych są domyślnie przechowywane przez siedem dni. Jednak w zależności od potrzeb biznesowych można skonfigurować wartość okresu przechowywania z jednego do 35 dni.
Kopie zapasowe można przechowywać przez maksymalnie 10 lat przy użyciu funkcji przechowywania długoterminowego, obecnie w publicznej wersji zapoznawczej. Długoterminowe rozwiązanie do tworzenia kopii zapasowych może być używane oddzielnie lub oprócz zautomatyzowanych kopii zapasowych usługi Azure Database for MySQL. Długoterminowe kopie zapasowe mogą być wykonywane zgodnie z harmonogramem kontrolowanym przez klienta lub na żądanie. Kopie zapasowe są przechowywane na zarządzanych kontach magazynu usługi Azure Backup w oddzielnych domenach zabezpieczeń i błędów.
Oprócz tworzenia kopii zapasowej bazy danych można eksportować pliki kopii zapasowej do usługi Azure Blob Storage, której następnie można użyć do migracji, odzyskiwania danych lub archiwizacji. Eksporty na żądanie są obecnie dostępne w publicznej wersji zapoznawczej i są dostępne tylko w regionach chmury publicznej.
Aby przechowywać pliki kopii zapasowej, możesz wybrać jedną z kilku opcji magazynu:
W przypadku magazynu lokalnie nadmiarowego (tego samego centrum danych, tej samej strefy) pliki kopii zapasowych są przechowywane w tym samym centrum danych co baza danych. Ta opcja zapewnia jedenaście 9s (99,9999999999%) trwałości obiektów kopii zapasowych w ciągu roku. Domyślnie serwery bez wysokiej dostępności lub tej samej strefy korzystają z magazynu lokalnie nadmiarowego.
W przypadku magazynu kopii zapasowych strefowo nadmiarowych (w różnych strefach, w tym samym regionie) pliki kopii zapasowej są przechowywane w strefie dostępności serwera i replikowane do innej strefy dostępności w tym samym regionie. Ta opcja zapewnia dwunastu lat 9 (99,9999999999999%) trwałości w danym roku. Magazyn strefowo nadmiarowy jest ważny w przypadku strefowo nadmiarowej wysokiej dostępności i jest wymagany, jeśli dane muszą pozostać w jednym regionie.
W przypadku magazynu kopii zapasowych geograficznie nadmiarowych (w różnych regionach) pliki kopii zapasowych są przechowywane w regionie serwera, a następnie replikowane do innego sparowanego geograficznie regionu. Ta opcja zapewnia szesnaście lat 9 (99,99999999999999%) trwałości w danym roku. Magazyn geograficznie nadmiarowy jest obsługiwany tylko w sparowanych regionach platformy Azure.
Uwaga: W przypadku usługi Azure Database for MySQL — serwer elastyczny przestrzeń zapasowa do 100% aprowizowanego miejsca do magazynowania jest dostępna bez dodatkowych opłat. Opłata za dodatkowy magazyn jest naliczana w GB miesięcznie. Aby uzyskać więcej informacji, zobacz dokumentację dotyczącą cen.
Po utworzeniu kopii zapasowej możesz przywrócić kopię zapasową na nowy serwer elastyczny MySQL. Możesz wybrać trzy sposoby tworzenia kopii zapasowej: ręcznie wybierz pełną kopię zapasową, automatycznie wybierz najnowszy punkt przywracania lub automatycznie wybierz najszybszy punkt przywracania. Jeśli masz geograficznie nadmiarowe kopie zapasowe, możesz również przywrócić je do sparowanego regionu (między regionami).
Zaplanowane przestoje i okna obsługi
Okresowa konserwacja jest wymagana, aby zapewnić stabilną, bezpieczną i aktualną obsługę serwera zarządzanego. Podczas okien obsługi usługa otrzymuje wdrożenia nowych funkcji, aktualizacji i poprawek. Zwykle okna obsługi są zaplanowane co najmniej co 30 dni, ale krytyczne poprawki zabezpieczeń są czasami stosowane w ciągu siedmiu dni lub mniej.
Możesz wybrać harmonogram zarządzany przez system lub zdefiniować niestandardowy harmonogram dla każdego serwera elastycznego MySQL w ramach subskrypcji platformy Azure.
Powiadomienia o zaplanowanej konserwacji można otrzymywać na jeden z kilku sposobów. Powiadomienia mogą być następujące:
- Wiadomość e-mail z określonym adresem lub rolą usługi Azure Resource Manager.
- Wysłane za pośrednictwem wiadomości SMS.
- Wypychane jako powiadomienie aplikacji platformy Azure.
- Dostarczone za pośrednictwem wiadomości głosowej.
Niestandardowe okna obsługi
Domyślnie z harmonogramem zarządzanym przez system system system wybiera jednogodzinne okno między godziną 11:00 a 7:00 w strefie czasowej serwera elastycznego MySQL. Zgodnie z niestandardowym harmonogramem możesz określić okno obsługi serwera, wybierając dzień tygodnia i godzinę.
Konserwacja niemal zerowego przestoju dla serwerów wysokiej dostępności (publiczna wersja zapoznawcza)
Serwery z obsługą wysokiej dostępności korzystają z konserwacji niemal zerowej przestojów, nowej funkcji, która znacznie zmniejsza przestoje konserwacyjne. Oczekiwany przestój wynosi od 40 do 60 sekund. Konserwacja przestojów niemal zerowych ma kluczowe znaczenie dla aplikacji z bardzo wysokimi wymaganiami dotyczącymi dostępności, co wymaga minimalnych przerw w łączności z bazą danych.
Konserwacja ponownej wersji (publiczna wersja zapoznawcza)
Podczas korzystania z warstw usługi Ogólnego przeznaczenia lub Krytyczne dla działania firmy można zaplanować konserwację. W sekcji konserwacji witryny Azure Portal można ponownie zaplanować kolejną zaplanowaną konserwację do innej daty i godziny. Możesz również zainicjować konserwację na żądanie, wybierając pozycję Zmień harmonogram na Teraz.