Udostępnij za pośrednictwem

Lista kontrolna dotycząca wysokiej dostępności i odzyskiwania po awarii — Azure SQL Managed Instance

  • Artykuł

Dotyczy: Azure SQL Managed Instance

Usługa Azure SQL Managed Instance 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 warstw usług usługi Azure SQL Managed Instance.

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 wystąpienia zarządzanego SQL, aby zapewnić odporność na awarie strefowe.

Lista kontrolna odzyskiwania po awarii

Mimo że usługa Azure SQL Managed Instance 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 Managed Instance 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 wystąpienia.
    • 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 wystąpieniem podstawowym.
    • Ustaw zasady trybu failover na zarządzane przez klienta.
  • Upewnij się, że wystąpienie pomocnicze geograficzne zostało utworzone przy użyciu tej samej warstwy usługi, generowania sprzętu i rozmiaru obliczeniowego co wystąpienie podstawowe.
  • 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 nie jest możliwe, rozważ ustawienie opcji nadmiarowości magazynu kopii zapasowych na geograficznie nadmiarowy magazyn kopii zapasowych 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

Aby pomyślnie odzyskać dane do innego regionu przy użyciu grup trybu failover lub przywracania geograficznego, należy przygotować pomocnicze wystąpienie zarządzane Usługi Azure SQL w innym regionie. W razie potrzeby to wystąpienie pomocnicze może stać się nowym wystąpieniem 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 wystąpienie w innym regionie, aby stać się nowym wystąpieniem podstawowym. Jeśli region podstawowy ma sparowany region, często używasz sparowanego regionu jako regionu pomocniczego. W ten sposób zwykle zmniejsza się opóźnienie operacji replikacji i 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 konfigurację sieciowej grupy zabezpieczeń i tabeli tras, którą użytkownicy muszą uzyskać do nowej podstawowej bazy danych w nowym podstawowym.
  • 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ą.
  • Udokumentować konfigurację inspekcji dla bieżącego podstawowego elementu podstawowego i uczynić ją identyczną w wystąpieniu pomocniczym.

Powiązana zawartość

Aby dowiedzieć się więcej, zapoznaj się z tematem: