Lista kontrolna wysokiej dostępności i odzyskiwania po awarii w usłudze Azure SQL Database

  • Artykuł

Dotyczy:Azure SQL Database

Usługa Azure SQL Database automatycznie zapewnia, że wszystkie bazy danych są w trybie online, w dobrej kondycji i stale dążą do osiągnięcia opublikowanej umowy SLA.

Ten przewodnik zawiera szczegółowy przegląd proaktywnych kroków, które można wykonać, aby zmaksymalizować dostępność, zapewnić odzyskiwanie i przygotować się do awarii platformy Azure. Te wskazówki dotyczą wszystkich modeli zakupów i warstw usług usługi usługi Azure SQL Database.

Lista kontrolna dotycząca dostępności

Poniżej przedstawiono zalecane konfiguracje w celu zmaksymalizowania dostępności:

  • Uwzględnij logikę ponawiania prób w aplikacji, aby obsługiwać błędy przejściowe.
  • Użyj okien obsługi, aby zapewnić przewidywalne i mniej destrukcyjne zdarzenia konserwacji.
  • Przetestuj odporność błędów aplikacji, ręcznie wyzwalając tryb failover, aby zobaczyć odporność w działaniu.

Lista kontrolna wysokiej dostępności

Poniżej przedstawiono zalecaną konfigurację, aby uzyskać wysoką dostępność:

  • Włącz nadmiarowość strefy, jeśli jest dostępna dla bazy danych lub elastycznej puli, aby zapewnić odporność na awarie strefowe.

Lista kontrolna odzyskiwania po awarii

Mimo że usługa Azure SQL Database automatycznie utrzymuje dostępność, istnieją wystąpienia, gdy nawet wysoka dostępność (nadmiarowość strefy) może nie zagwarantować odporności, ponieważ awaria obejmuje cały region. Regionalna awaria usługi Azure SQL Database może wymagać zainicjowania odzyskiwania po awarii.

Aby najlepiej przygotować się do odzyskiwania po awarii, wykonaj następujące zalecenia:

  • Włącz grupy trybu failover dla grupy baz danych.
    • Użyj punktów końcowych odbiornika do odczytu i zapisu i tylko do odczytu w aplikacji parametry połączenia, aby aplikacje automatycznie łączyły się z dowolnym serwerem i bazą danych.
    • Ustaw zasady trybu failover na zarządzane przez klienta.
  • Alternatywnie dla grup trybu failover można włączyć aktywną replikację geograficzną, aby mieć pomocniczą bazę danych z możliwością odczytu w innym regionie świadczenia usługi Azure.
  • Upewnij się, że pomocnicza baza danych geograficznie jest tworzona z tą samą warstwą usługi, warstwą obliczeniową (aprowizowaną lub bezserwerową) oraz rozmiarem obliczeniowym (jednostki DTU lub rdzeniami wirtualnymi) jako podstawową bazą danych.
  • Podczas skalowania w górę najpierw przeprowadź skalowanie w górę pomocniczego obszaru geograficznego, a następnie przeprowadź skalowanie w górę podstawowego.
  • Odwróć tę kolejność podczas skalowania w dół: najpierw przeprowadź skalowanie w dół podstawowego, a następnie pomocniczego obszaru geograficznego.
  • Odzyskiwanie po awarii z natury jest przeznaczone do korzystania z asynchronicznej replikacji danych między regionem podstawowym i pomocniczym. Aby określić priorytety dostępności danych w przypadku większego opóźnienia zatwierdzenia, rozważ wywołanie procedury składowanej sp_wait_for_database_copy_sync natychmiast po zatwierdzeniu transakcji. Wywołanie sp_wait_for_database_copy_sync blokuje wątek wywołujący do czasu przesyłania ostatniej zatwierdzonej transakcji i wzmacniania zabezpieczeń w dzienniku transakcji pomocniczej bazy danych.
  • Monitoruj opóźnienie w odniesieniu do celu punktu odzyskiwania (RPO) przy użyciu replication_lag_sec kolumny sys.dm_geo_replication_link_status dynamiczny widok zarządzania (DMV) w podstawowej bazie danych. Widok DMV pokazuje opóźnienie w sekundach między transakcjami zatwierdzonymi na serwerze podstawowym i wzmocnionym do dziennika transakcji w pomocniczym dzienniku. Załóżmy na przykład, że opóźnienie jest jedną sekundą w danym momencie, jeśli awaria ma wpływ na podstawową awarię, a przejście geograficzne w tryb failover zostanie zainicjowane w tym momencie, transakcje zatwierdzone w ciągu ostatniej sekundy zostaną utracone.
  • Jeśli włączenie grup trybu failover lub aktywnej replikacji geograficznej nie jest możliwe, rozważ ustawienie opcji nadmiarowości magazynu kopii zapasowej na magazyn kopii zapasowych geograficznie nadmiarowej w celu korzystania z funkcji przywracania geograficznego.
  • Często planuj i wykonuj próbne odzyskiwanie po awarii , aby lepiej przygotować się w przypadku rzeczywistej awarii.

Przygotowywanie pomocniczej awarii

W przypadku pomyślnego odzyskiwania do innego regionu danych przy użyciu aktywnej replikacji geograficznej, grup trybu failover lub przywracania geograficznego należy przygotować pomocniczy serwer logiczny usługi Azure SQL Database w innym regionie. W razie potrzeby ten serwer pomocniczy może stać się nowym serwerem podstawowym. Należy również mieć dobrze zdefiniowane kroki udokumentowane i przetestowane, aby zapewnić bezproblemowe odzyskiwanie. Te kroki przygotowania obejmują:

  • W przypadku przywracania geograficznego zidentyfikuj serwer w innym regionie, aby stał się nowym serwerem podstawowym. Jest to zazwyczaj serwer w sparowanym regionie dla regionu, w którym znajduje się podstawowa baza danych. Użycie serwera w tym samym regionie eliminuje dodatkowy koszt ruchu podczas operacji przywracania geograficznego.
  • Określ sposób przekierowywania użytkowników do nowego serwera podstawowego. Przekierowywanie użytkowników można wykonać przez ręczne zmianę parametry połączenia aplikacji lub wpisów DNS. Jeśli skonfigurowano grupy trybu failover i używasz odbiornika tylko do odczytu i zapisu w aplikacji parametry połączenia, nie są potrzebne żadne dalsze działania — połączenia są automatycznie kierowane do nowego podstawowego po przejściu w tryb failover.
  • Zidentyfikuj i opcjonalnie zdefiniuj reguły zapory wymagane dla użytkowników w celu uzyskania dostępu do nowej podstawowej bazy danych.
  • Zidentyfikuj i opcjonalnie utwórz identyfikatory logowania, które muszą znajdować się w master bazie danych na nowym serwerze podstawowym, i upewnij się, że te identyfikatory logowania mają odpowiednie uprawnienia w master bazie danych, jeśli istnieją. Aby uzyskać więcej informacji, zobacz Zabezpieczenia usługi Azure SQL Database po odzyskiwaniu po awarii.
  • Zidentyfikuj reguły alertów, które należy zaktualizować w celu mapowania na nowy element podstawowy.
  • Udokumentowanie konfiguracji inspekcji dla bieżącego podstawowego.

Powiązana zawartość