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

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?.

Usługa Azure Database for MariaDB jest odpowiednia do uruchamiania baz danych o krytycznym znaczeniu, które wymagają wysokiego czasu pracy. Zapewnia wysoką dostępność podczas wykonywania:

  • Planowane zdarzenia, takie jak operacje obliczeniowe inicjowane przez użytkownika.
  • Nieplanowane zdarzenia, takie jak awarie sprzętu, oprogramowania lub sieci bazowej.

Usługa Azure Database for MariaDB zapewnia umowę dotyczącą poziomu usług wspieraną finansowo na czas pracy. Ponieważ usługa jest oparta na architekturze platformy Azure, możesz korzystać z jej możliwości w celu zapewnienia wysokiej dostępności, nadmiarowości i odporności bez konfigurowania żadnych dodatkowych składników.

Składniki w usłudze Azure Database for MariaDB

Składnik opis
Serwer bazy danych MariaDB Usługa Azure Database for MariaDB zapewnia zabezpieczenia, izolację, zabezpieczenia zasobów i możliwość szybkiego ponownego uruchamiania serwerów baz danych. Te możliwości ułatwiają operacje, takie jak skalowanie i odzyskiwanie serwera bazy danych (w sekundach) po awarii.
Modyfikacje danych na serwerze bazy danych zwykle występują w kontekście transakcji bazy danych. Wszystkie zmiany bazy danych są rejestrowane synchronicznie w postaci dzienników z wyprzedzeniem zapisu (ib_log plików) w usłudze Azure Storage, która jest dołączona do serwera bazy danych. Podczas procesu punktu kontrolnego bazy danych strony danych z pamięci serwera bazy danych są również opróżniane do magazynu.
Magazyn zdalny Wszystkie pliki danych fizycznych i pliki dziennika bazy danych MariaDB są przechowywane w usłudze Azure Storage, która przechowuje trzy kopie danych w regionie w celu zapewnienia nadmiarowości danych, dostępności i niezawodności. Warstwa magazynu jest niezależna od serwera bazy danych. Można go odłączyć od nieudanego serwera bazy danych i ponownie dołączyć go do nowego serwera bazy danych w ciągu kilku sekund.
Usługa Azure Storage stale monitoruje błędy magazynu. Jeśli wykryje uszkodzenie bloku, automatycznie rozwiąże problem, tworząc wystąpienie nowej kopii magazynu.
Brama Brama działa jako serwer proxy bazy danych, rozsyłając wszystkie połączenia klienta z serwerem bazy danych.

Ograniczenie planowanego przestoju

Architektura usługi Azure Database for MariaDB zapewnia wysoką dostępność podczas planowanych operacji przestojów.

Diagram of elastic scaling in Azure Database for MariaDB.

Poniżej przedstawiono niektóre scenariusze planowanej konserwacji:

Scenariusz opis
Skalowanie zasobów obliczeniowych w górę lub w dół Podczas wykonywania operacji skalowania w górę lub w dół obliczeń usługa Azure Database for MariaDB aprowizuje nowy serwer bazy danych przy użyciu skalowanej konfiguracji obliczeniowej. Na starym serwerze bazy danych usługa umożliwia zakończenie aktywnych punktów kontrolnych, opróżnianie połączeń klienta i anulowanie wszelkich niezatwierdzonych transakcji. Następnie usługa zamyka stary serwer bazy danych. Odłącza magazyn od starego serwera bazy danych i dołącza magazyn do nowego serwera bazy danych. Gdy aplikacja kliencka ponawia próbę nawiązania połączenia lub spróbuje nawiązać nowe połączenie, brama kieruje żądanie połączenia do nowego serwera bazy danych.
Skalowanie magazynu w górę Skalowanie w górę magazynu jest operacją online i nie przerywa serwera bazy danych.
Nowe wdrożenie oprogramowania (Azure) Wdrożenia nowych funkcji lub poprawek błędów są automatycznie wykonywane w ramach planowanej konserwacji usługi. Aby uzyskać więcej informacji, zobacz dokumentację i sprawdź portal.
Uaktualnienia wersji pomocniczej Usługa Azure Database for MariaDB automatycznie poprawia serwery baz danych do wersji pomocniczej, którą określa platforma Azure. Automatyczne stosowanie poprawek odbywa się w ramach planowanej konserwacji usługi. Spowoduje to krótki przestój w sekundach, a serwer bazy danych zostanie automatycznie uruchomiony ponownie z nową wersją pomocniczą. Aby uzyskać więcej informacji, zobacz dokumentację i sprawdź portal.

Ograniczenie nieplanowanego przestoju

Nieplanowany przestój może 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 nieoczekiwanie przestanie działać, nowy serwer bazy danych zostanie aprowizowany automatycznie w ciągu kilku sekund. Magazyn zdalny jest automatycznie dołączany do nowego serwera bazy danych.

Aparat MariaDB wykonuje operację odzyskiwania przy użyciu plików dziennika z wyprzedzeniem zapisu i bazy danych, a następnie otwiera serwer bazy danych, aby umożliwić klientom nawiązywanie połączenia. Niezatwierdzone transakcje zostaną utracone, a aplikacja musi je ponowić.

Chociaż nie można uniknąć nieplanowanego przestoju, usługa Azure Database for MariaDB ogranicza ją przez automatyczne wykonywanie operacji odzyskiwania zarówno na serwerze bazy danych, jak i w warstwach magazynu bez konieczności interwencji człowieka.

Diagram of high availability in Azure Database for MariaDB.

Nieplanowany przestój: scenariusze awarii i odzyskiwanie usługi

Poniżej przedstawiono dwa scenariusze awarii i sposób automatycznego odzyskiwania usługi Azure Database for MariaDB:

Scenariusz Automatyczne odzyskiwanie
Błąd serwera bazy danych Jeśli serwer bazy danych nie działa z powodu podstawowej awarii sprzętowej, usługa Azure Database for MariaDB przerywa aktywne połączenia i anuluje wszelkie transakcje w locie. Usługa automatycznie wdraża nowy serwer bazy danych i dołącza zdalny magazyn danych do nowego serwera bazy danych. Po zakończeniu odzyskiwania bazy danych klienci mogą łączyć się z nowym serwerem bazy danych za pośrednictwem bramy.
Aplikacje korzystające z baz danych MariaDB 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, brama w sposób niewidoczny przekierowuje połączenie z nowo utworzonym serwerem bazy danych.
Błąd magazynu Problemy związane z magazynem, takie jak awaria dysku lub uszkodzenie bloku fizycznego, nie mają wpływu na aplikacje. Ponieważ dane są przechowywane w trzech kopiach, magazyn ocalały obsługuje kopię danych. Usługa Azure Database for MariaDB automatycznie poprawia uszkodzenia bloku. W przypadku utraty kopii danych usługa automatycznie tworzy nową kopię danych.

Poniżej przedstawiono scenariusze błędów, które wymagają wykonania akcji użytkownika w celu odzyskania:

Scenariusz Plan odzyskiwania
Błąd regionu Awaria regionu jest rzadkim zdarzeniem. Jeśli jednak potrzebujesz ochrony przed awarią regionu, możesz skonfigurować co najmniej jedną replikę do odczytu w innych regionach na potrzeby odzyskiwania po awarii. Aby uzyskać szczegółowe informacje, zobacz ten artykuł dotyczący tworzenia replik do odczytu i zarządzania nimi. Jeśli wystąpi awaria na poziomie regionu, możesz ręcznie podwyższyć poziom repliki do odczytu skonfigurowanej w innym regionie jako serwer produkcyjnej bazy danych.
Błąd logiczny/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. Ta akcja przywraca i odzyskuje dane do czasu tuż przed wystąpieniem błędu.
Jeśli chcesz przywrócić tylko podzbiór baz danych lub określonych tabel, a nie wszystkich baz danych na serwerze bazy danych, możesz przywrócić serwer bazy danych w nowym wystąpieniu, wyeksportować tabele za pośrednictwem narzędzia mysqldump, a następnie przywrócić te tabele w bazie danych.

Podsumowanie

Usługa Azure Database for MariaDB ma nieodłączne funkcje wysokiej dostępności, które pomagają chronić bazy danych przed typowymi awariami. Zapewnia ona możliwość szybkiego ponownego uruchamiania serwerów baz danych, magazynu nadmiarowego i wydajnego routingu z bramy. Aby uzyskać dodatkową ochronę danych, można skonfigurować kopie zapasowe pod kątem replikacji geograficznej i wdrożyć repliki do odczytu w innych regionach.

Następne kroki