Share via

Omówienie ciągłości działania za pomocą usługi Azure Database for MariaDB

  • Artykuł

Ważne

Usługa Azure Database for MariaDB znajduje się na ścieżce wycofania. Zdecydowanie zalecamy przeprowadzenie migracji do usługi Azure Database for MySQL. Aby uzyskać więcej informacji na temat migracji do usługi Azure Database for MySQL, zobacz Co się dzieje z usługą Azure Database for MariaDB?.

W tym artykule opisano możliwości zapewniane przez usługę Azure Database for MariaDB ciągłość działania i odzyskiwanie po awarii. Dowiedz się więcej o opcjach odzyskiwania po zdarzeniach powodujących zakłócenia, które mogą spowodować utratę danych lub spowodowanie niedostępności bazy danych i aplikacji. Dowiedz się, co zrobić, gdy błąd użytkownika lub błąd aplikacji ma wpływ na integralność danych, region świadczenia usługi Azure ma awarię lub aplikacja wymaga konserwacji.

Funkcje ciągłości działania

Podczas opracowywania planu ciągłości działania należy zrozumieć następujące elementy:

  • Cel czasu odzyskiwania (RTO): maksymalny dopuszczalny czas, po jakim aplikacja w pełni odzyska sprawność po wystąpieniu zdarzenia powodującego zakłócenia.
  • Cel punktu odzyskiwania (RPO) : maksymalna ilość najnowszych aktualizacji danych (interwał czasu), które aplikacja może tolerować utratę w przypadku odzyskiwania po wystąpieniu zdarzenia powodującego zakłócenia.

Usługa Azure Database for MariaDB udostępnia funkcje ciągłości działania i odzyskiwania po awarii, które obejmują geograficznie nadmiarowe kopie zapasowe z możliwością inicjowania przywracania geograficznego i wdrażania replik do odczytu w innym regionie. Każda z tych funkcji charakteryzuje się różnymi cechami czasu odzyskiwania i potencjalnej utraty danych.

W przypadku przywracania geograficznego usługa Azure Database for MariaDB tworzy nowy serwer przy użyciu danych kopii zapasowej replikowanych z innego regionu. Całkowity czas przywracania i odzyskiwania zależy od rozmiaru bazy danych i ilości danych dziennika do odzyskania. Całkowity czas ustanawiania serwera może się trwać od kilku minut do kilku godzin.

W przypadku replik do odczytu dzienniki transakcji z podstawowej bazy danych są asynchronicznie przesyłane strumieniowo do repliki. Jeśli występuje awaria podstawowej bazy danych z powodu błędu na poziomie strefy lub na poziomie regionu, przełączenie w tryb failover do repliki zapewnia krótszy cel czasu odzyskiwania i zmniejszenie utraty danych.

Uwaga

Opóźnienie między podstawową bazą danych a repliką zależy od opóźnienia między lokacjami, ilością przesyłanych danych i (co najważniejsze) obciążeniem zapisu serwera podstawowego. Duże obciążenia zapisu mogą generować znaczne opóźnienie.

Ze względu na asynchroniczny charakter replikacji używanej na potrzeby replik do odczytu nie należy traktować replik do odczytu jako rozwiązania o wysokiej dostępności. Wyższe opóźnienia mogą oznaczać wyższy cel czasu odzyskiwania i cel punktu odzyskiwania. Repliki do odczytu mogą działać jako alternatywa wysokiej dostępności tylko w przypadku obciążeń, w których opóźnienie pozostaje mniejsze w godzinach szczytowych i poza szczytem. W przeciwnym razie repliki do odczytu są przeznaczone do prawdziwej skali odczytu dla obciążeń z dużym obciążeniem odczytu i scenariuszy odzyskiwania po awarii.

W poniższej tabeli porównaliśmy cel czasu odzyskiwania i cel punktu odzyskiwania w typowym scenariuszu obciążenia :

Możliwość Podstawowy Ogólnego przeznaczenia Optymalizacja pod kątem pamięci
Przywracanie do punktu w czasie z kopii zapasowej Dowolny punkt przywracania w okresie przechowywania
Cel czasu odzyskiwania różni się
Cel punktu odzyskiwania jest krótszy niż 15 minut		 Dowolny punkt przywracania w okresie przechowywania
Cel czasu odzyskiwania różni się
Cel punktu odzyskiwania jest krótszy niż 15 minut		 Dowolny punkt przywracania w okresie przechowywania
Cel czasu odzyskiwania różni się
Cel punktu odzyskiwania jest krótszy niż 15 minut
Przywracanie geograficzne z kopii zapasowych replikowanych geograficznie Nieobsługiwane Cel czasu odzyskiwania różni się
Cel punktu odzyskiwania jest dłuższy niż 24 godziny		 Cel czasu odzyskiwania różni się
Cel punktu odzyskiwania jest dłuższy niż 24 godziny
Repliki do odczytu Cel czasu odzyskiwania to minuty
Cel punktu odzyskiwania jest krótszy niż 5 minut		 Cel czasu odzyskiwania to minuty
Cel punktu odzyskiwania jest krótszy niż 5 minut		 Cel czasu odzyskiwania to minuty
Cel punktu odzyskiwania jest krótszy niż 5 minut

Cel czasu odzyskiwania i cel punktu odzyskiwania mogą być znacznie wyższe w niektórych przypadkach, w zależności od czynników, takich jak opóźnienie między lokacjami, ilość danych do przesłania i obciążenie zapisu podstawowej bazy danych.

Odzyskiwanie serwera po błędzie użytkownika lub aplikacji

Za pomocą kopii zapasowych usługi można odzyskać serwer z różnych zdarzeń powodujących zakłócenia. Na przykład użytkownik może przypadkowo usunąć niektóre dane, przypadkowo usunąć ważną tabelę, a nawet usunąć całą bazę danych. Aplikacja może przypadkowo zastąpić dobre dane nieprawidłowymi danymi z powodu wady aplikacji.

Możesz wykonać przywracanie do punktu w czasie, aby utworzyć kopię serwera do znanego dobrego punktu w czasie. Ten punkt w czasie musi należeć do okresu przechowywania kopii zapasowej skonfigurowanego dla serwera. Po przywróceniu danych na nowy serwer można zastąpić oryginalny serwer nowo przywróconym serwerem lub skopiować potrzebne dane z przywróconego serwera na oryginalny serwer.

Ważne

Usunięte serwery można przywrócić tylko w ciągu pięciu dni od usunięcia. Po pięciu dniach kopie zapasowe zostaną usunięte. Możesz uzyskać dostęp do kopii zapasowej bazy danych i przywrócić je tylko z subskrypcji platformy Azure, która hostuje serwer. Aby przywrócić usunięty serwer, zapoznaj się z udokumentowanymi krokami. Aby chronić zasoby serwera przed przypadkowym usunięciem lub nieoczekiwanymi zmianami po wdrożeniu, administratorzy mogą używać blokad zarządzania.

Odzyskiwanie po awarii regionalnego centrum danych platformy Azure

Chociaż jest to rzadkie, centrum danych platformy Azure może mieć awarię. Gdy wystąpi awaria, powoduje to przerwy w działaniu firmy, które mogą trwać tylko kilka minut, ale mogą trwać godzinami.

Jedną z opcji jest oczekiwanie na powrót serwera do trybu online, gdy awaria centrum danych się skończyła. Jeśli centrum danych ma awarię, nie wiesz, jak długo może trwać awaria. Dlatego ta opcja działa tylko w przypadku aplikacji, które mogą sobie pozwolić na serwer w trybie offline przez jakiś czas (na przykład środowisko programistyczne).

Przywracanie geograficzne

Funkcja przywracania geograficznego przywraca serwer przy użyciu geograficznie nadmiarowych kopii zapasowych. Kopie zapasowe są hostowane w sparowanym regionie serwera. Te kopie zapasowe są dostępne nawet wtedy, gdy region, w którym jest hostowany serwer, jest w trybie offline. Możesz przywrócić z tych kopii zapasowych do dowolnego innego regionu, a następnie przywrócić serwer z powrotem do trybu online. Dowiedz się więcej na temat przywracania geograficznego w artykule dotyczącym pojęć związanych z tworzeniem kopii zapasowych i przywracaniem.

Ważne

Przywracanie geograficzne jest możliwe tylko w przypadku aprowizacji serwera z magazynem kopii zapasowych geograficznie nadmiarowych. Jeśli chcesz przełączyć się z lokalnie nadmiarowych do geograficznie nadmiarowych kopii zapasowych dla istniejącego serwera, musisz wygenerować kopię zapasową istniejącego serwera przy użyciu narzędzia mysqldump. Następnie przywróć nowo utworzony serwer skonfigurowany przy użyciu geograficznie nadmiarowych kopii zapasowych.

Repliki do odczytu między regionami

Repliki do odczytu między regionami umożliwiają ulepszenie planowania ciągłości działania i odzyskiwania po awarii. Repliki do odczytu są aktualizowane asynchronicznie za pomocą technologii replikacji bazy danych MySQL dla dzienników binarnych. Dowiedz się więcej na temat replik do odczytu, dostępnych regionów i sposobu przełączania w tryb failover w artykule dotyczącym pojęć dotyczących replik do odczytu.

Często zadawane pytania

Gdzie usługa Azure Database for MariaDB przechowuje dane klientów?

Domyślnie usługa Azure Database for MariaDB nie przenosi ani nie przechowuje danych klientów z regionu, w którym jest wdrażany. Opcjonalnie możesz jednak włączyć geograficznie nadmiarowe kopie zapasowe lub utworzyć repliki odczytu między regionami na potrzeby przechowywania danych w innym regionie.

Następne kroki