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 konserwacji, aby prace konserwacyjne były przewidywalne i mniej destrukcyjne.
  • Przetestuj odporność błędów aplikacji, ręcznie uruchamiając przełączenie awaryjne, aby zobaczyć tę odporność w działaniu.

Lista kontrolna wysokiej dostępności

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

  • Włącz nadmiarowość strefową, jeśli jest dostępna, dla zarządzanego wystąpienia 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 do odczytu i zapisu oraz tylko do odczytu w parametrach połączenia aplikacji, aby aplikacje automatycznie łączyły się z instancją główną.
    • Ustaw zasady trybu failover na zarządzane przez klienta.
  • Upewnij się, że lokalizacja geograficzna pomocnicza została utworzona przy użyciu tej samej warstwy usługi, generacji sprzętu i rozmiaru obliczeniowego, co lokalizacja podstawowa.
  • Podczas skalowania w górę najpierw przeprowadź skalowanie w górę sekudarnego obszaru geograficznego, a następnie 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 priorytetować dostępność danych nad większym opóźnieniem 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, aż ostatnia zatwierdzona transakcja zostanie przesłana i utrwalona w dzienniku transakcji bazy danych wtórnej.
  • 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. DMV pokazuje opóźnienie w sekundach między transakcjami zatwierdzonymi w głównym systemie a zapisanymi do dziennika transakcji w systemie zapasowym. Załóżmy na przykład, że w danym momencie opóźnienie wynosi jedną sekundę. Jeśli wystąpi awaria, która wpływa na główną lokalizację i w tym momencie zostanie zainicjowane przełączenie geograficzne, transakcje zatwierdzone w ciągu ostatniej sekundy zostaną utracone.
  • Jeśli włączenie grup awaryjnych nie jest możliwe, rozważ ustawienie opcji nadmiarowości magazynu kopii zapasowych na geograficznie nadmiarowy magazyn kopii zapasowych, aby skorzystać z funkcji przywracania geograficznego.
  • Często planuj i przeprowadzaj ćwiczenia awaryjne, aby być lepiej przygotowanym na wypadek rzeczywistej awarii.

Przygotowanie systemu zapasowego na wypadek awarii

Aby pomyślnie odzyskać dane do innego regionu z użyciem grup trybu failover lub przywracania geograficznego, należy przygotować dodatkowe wystąpienie zarządzane 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, które stanie 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ę grupy zabezpieczeń i tabeli tras, którą użytkownicy muszą mieć, aby uzyskać dostęp do nowej podstawowej bazy danych na 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ę audytu na bieżącej instancji primary i uzgodnić ją z instancją secondary.

Powiązana zawartość

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