Udostępnij za pośrednictwem


Wskazówki dotyczące odzyskiwania po awarii — Azure SQL Database

Dotyczy: Azure SQL Database

Usługa Azure SQL Database zapewnia wiodącą w branży gwarancję wysokiej dostępności co najmniej 99,99%, aby obsługiwać szeroką gamę aplikacji, w tym misję krytyczną, która zawsze musi być dostępna. Usługa Azure SQL Database ma również kluczowe możliwości ciągłości działania, które można wykonać w celu szybkiego odzyskiwania po awarii w przypadku awarii regionalnej. Ten artykuł zawiera cenne informacje, które należy przejrzeć przed wdrożeniem aplikacji.

Mimo że stale dążymy do zapewnienia wysokiej dostępności, czasami występują przerwy w działaniu usługi Azure SQL Database, które powodują niedostępność bazy danych, a tym samym wpływają na twoją aplikację. Gdy nasze monitorowanie usługi wykryje problemy, które powodują powszechne błędy łączności, błędy lub problemy z wydajnością, usługa automatycznie deklaruje awarię, aby informować Użytkownika.

Awaria usługi

W przypadku awarii usługi Azure SQL Database możesz znaleźć dodatkowe szczegóły związane z awarią w następujących miejscach:

  • Baner witryny Azure Portal

    Jeśli twoja subskrypcja zostanie zidentyfikowana jako wpłynęła, w powiadomieniach w witrynie Azure Portal występuje alert dotyczący awarii usługi:

    Zrzut ekranu przedstawiający witrynę Azure Portal z powiadomieniem o problemie z usługą Azure SQL Database.

  • Pomoc i obsługa techniczna i rozwiązywanie problemów

    Podczas tworzenia biletu pomocy technicznej z poziomu pomocy i pomocy technicznej lub pomocy technicznej i rozwiązywania problemów znajdują się informacje o wszelkich problemach wpływających na zasoby. Wybierz pozycję Wyświetl szczegóły awarii, aby uzyskać więcej informacji i podsumowanie wpływu. Na stronie Nowy wniosek o pomoc techniczną znajduje się również alert.

    Zrzut ekranu przedstawiający stronę Pomoc i obsługa techniczna z powiadomieniem o aktywnym problemie z kondycją usługi.

  • Kondycja usługi

    Strona Kondycja usługi w witrynie Azure Portal zawiera informacje o stanie centrum danych platformy Azure globalnie. Wyszukaj ciąg "service health" na pasku wyszukiwania w witrynie Azure Portal, a następnie wyświetl pozycję Problemy z usługą w kategorii Aktywne zdarzenia . Kondycję poszczególnych zasobów można również wyświetlić na stronie Kondycja zasobu dowolnego zasobu w menu Pomoc . Poniżej przedstawiono przykładowy zrzut ekranu przedstawiający stronę Kondycja usługi z informacjami na temat aktywnego problemu z usługą w Azji Południowo-Wschodniej:

    Zrzut ekranu przedstawiający stronę usługi Service Health w witrynie Azure Portal podczas problemu z usługą w Azji Południowo-Wschodniej z wyświetlonym problemem i mapą zasobów, których dotyczy problem.

  • Powiadomienie e-mail

    Jeśli skonfigurowano alerty, powiadomienie e-mail jest wysyłane, azure-noreply@microsoft.com gdy awaria usługi ma wpływ na subskrypcję i zasób. Treść wiadomości e-mail zwykle zaczyna się od "Alert dziennika aktywności ... został wyzwolony przez problem z usługą dla subskrypcji platformy Azure...". Aby uzyskać więcej informacji na temat alertów dotyczących kondycji usługi, zobacz Odbieranie alertów dziennika aktywności w powiadomieniach usługi platformy Azure przy użyciu witryny Azure Portal.

  • Metryka dostępności

    Możesz monitorować i konfigurować alerty metryki dostępności usługi Azure SQL Database w witrynie Azure Portal.

Kiedy należy zainicjować odzyskiwanie po awarii podczas awarii

W przypadku awarii usługi wpływającej na zasoby aplikacji należy wziąć pod uwagę następujące kursy działania:

  • Zespoły platformy Azure pracują pilnie, aby jak najszybciej przywrócić dostępność usługi, ale w zależności od głównej przyczyny może czasami potrwać kilka godzin. Jeśli aplikacja może tolerować znaczne przestoje, możesz po prostu poczekać na zakończenie odzyskiwania. W takim przypadku nie jest wymagana żadna akcja w Twojej części. Wyświetl kondycję poszczególnych zasobów na stronie Kondycja zasobu dowolnego zasobu w menu Pomoc . Zapoznaj się ze stroną Kondycja zasobu , aby uzyskać aktualizacje i najnowsze informacje dotyczące awarii. Po odzyskaniu regionu dostępność aplikacji zostanie przywrócona.

  • Odzyskiwanie do innego regionu platformy Azure może wymagać zmiany parametry połączenia aplikacji lub przekierowania DNS i może spowodować trwałą utratę danych. W związku z tym odzyskiwanie po awarii powinno być wykonywane tylko wtedy, gdy czas trwania awarii zbliża się do celu czasu odzyskiwania aplikacji (RTO). Po wdrożeniu aplikacji w środowisku produkcyjnym należy regularnie monitorować kondycję aplikacji i potwierdzić, że odzyskiwanie jest uzasadnione tylko wtedy, gdy występuje długotrwała awaria łączności z warstwy aplikacji do bazy danych. W zależności od tolerancji aplikacji na przestoje i możliwej odpowiedzialności biznesowej możesz zdecydować, czy chcesz poczekać na odzyskanie usługi lub samodzielnie zainicjować odzyskiwanie po awarii.

Wskazówki dotyczące odzyskiwania w przypadku niedostępności

Jeśli awaria usługi Azure SQL Database w regionie nie została usunięta przez dłuższy czas i ma wpływ na umowę dotyczącą poziomu usług (SLA) aplikacji, rozważ następujące kroki:

Tryb failover (bez utraty danych) na serwerze pomocniczym replikowanym geograficznie

Jeśli włączono aktywne grupy replikacji geograficznej lub trybu failover, sprawdź, czy stan zasobu podstawowej i pomocniczej bazy danych to Online w witrynie Azure Portal. Jeśli tak, płaszczyzna danych dla podstawowej i pomocniczej bazy danych jest w dobrej kondycji. Zainicjuj przejście w tryb failover aktywnych grup replikacji geograficznej lub trybu failover do regionu pomocniczego przy użyciu witryny Azure Portal, języka T-SQL, programu PowerShell lub interfejsu wiersza polecenia platformy Azure.

Uwaga

Przejście w tryb failover wymaga pełnej synchronizacji danych przed przełączeniem ról i nie powoduje utraty danych. W zależności od typu awarii usługi nie ma gwarancji, że przejście w tryb failover bez utraty danych powiedzie się, ale warto spróbować jako pierwsza opcja odzyskiwania.

Aby zainicjować tryb failover, użyj następujących linków:

Technologia Method Kroki
Aktywna replikacja geograficzna PowerShell Przechodzenie w tryb failover do replikacji geograficznej pomocniczej za pomocą programu PowerShell
T-SQL Przechodzenie w tryb failover do replikacji geograficznej pomocniczej za pośrednictwem języka T-SQL
Grupy trybu failover Interfejs wiersza polecenia platformy Azure Przechodzenie w tryb failover na serwer pomocniczy za pośrednictwem interfejsu wiersza polecenia platformy Azure
Azure Portal Przechodzenie w tryb failover na serwer pomocniczy za pośrednictwem witryny Azure Portal
PowerShell Przechodzenie w tryb failover na serwer pomocniczy za pośrednictwem programu PowerShell

Wymuszone przejście w tryb failover (potencjalna utrata danych) na serwer pomocniczy z replikacją geograficzną

Jeśli tryb failover nie zostanie ukończony bezpiecznie i wystąpią błędy lub stan podstawowej bazy danych nie jest w trybie online, należy uważnie rozważyć wymuszone przejście w tryb failover z potencjalnymi utratą danych do regionu pomocniczego.

Aby zainicjować wymuszone przejście w tryb failover, użyj następujących linków:

Technologia Method Kroki
Aktywna replikacja geograficzna Interfejs wiersza polecenia platformy Azure Wymuszone przejście w tryb failover do pomocniczej replikacji geograficznej za pośrednictwem interfejsu wiersza polecenia platformy Azure
Azure Portal Wymuszone przejście w tryb failover do pomocniczej replikacji geograficznej za pośrednictwem witryny Azure Portal
PowerShell Wymuszone przejście w tryb failover do pomocniczej replikacji geograficznej za pośrednictwem programu PowerShell
T-SQL Wymuszone przejście w tryb failover do pomocniczej replikacji geograficznej za pośrednictwem języka T-SQL
Grupy trybu failover Azure Portal Wymuszone przejście w tryb failover na serwer pomocniczy za pośrednictwem witryny Azure Portal , ale wybierz pozycję Wymuszone przejście w tryb failover.
Interfejs wiersza polecenia platformy Azure Wymuszone przejście w tryb failover na serwer pomocniczy za pośrednictwem interfejsu wiersza polecenia platformy Azure, ale użyj polecenia --allow-data-loss
PowerShell Wymuszone przejście w tryb failover na serwer pomocniczy za pomocą programu PowerShell , ale użyj polecenia -AllowDataLoss

Przywracanie geograficzne

Jeśli nie włączono aktywnej replikacji geograficznej lub grup trybu failover, możesz użyć przywracania geograficznego do odzyskania po awarii. Przywracanie geograficzne używa kopii zapasowych replikowanych geograficznie jako źródła. Bazę danych można przywrócić na dowolnym serwerze logicznym w dowolnym regionie platformy Azure z najnowszych kopii zapasowych replikowanych geograficznie. Możesz zażądać przywrócenia geograficznego, nawet jeśli awaria bazy danych lub całego regionu jest niedostępna.

Aby uzyskać więcej informacji na temat przywracania geograficznego za pośrednictwem interfejsu wiersza polecenia platformy Azure, witryny Azure Portal, programu PowerShell lub interfejsu API REST, zobacz przywracanie geograficzne usługi Azure SQL Database.

Konfigurowanie bazy danych po odzyskaniu

Jeśli używasz trybu geograficznego trybu failover lub przywracania geograficznego w celu odzyskania sprawności po awarii, upewnij się, że łączność z nową bazą danych jest prawidłowo skonfigurowana, aby można było wznowić normalną funkcję aplikacji. Jest to lista kontrolna zadań, które umożliwiają przygotowanie do produkcji odzyskanej bazy danych.

Ważne

Zaleca się przeprowadzenie okresowych próbnych strategii odzyskiwania po awarii w celu zweryfikowania tolerancji aplikacji, a także wszystkich aspektów operacyjnych procedury odzyskiwania. Inne warstwy infrastruktury aplikacji mogą wymagać ponownej konfiguracji. Aby uzyskać więcej informacji na temat kroków architektury odpornej, zapoznaj się z listą kontrolną wysokiej dostępności i odzyskiwania po awarii usługi Azure SQL Database.

Aktualizowanie parametry połączenia

  • Jeśli używasz aktywnej replikacji geograficznej lub przywracania geograficznego, upewnij się, że łączność z nowymi bazami danych jest prawidłowo skonfigurowana, aby można było wznowić normalną funkcję aplikacji. Ponieważ odzyskana baza danych znajduje się na innym serwerze, należy zaktualizować parametry połączenia aplikacji, aby wskazać ten serwer. Aby uzyskać więcej informacji na temat zmiany parametry połączenia, zobacz odpowiedni język programowania dla biblioteki połączeń.
  • Jeśli używasz grup trybu failover do odzyskania sprawności po awarii i używasz odbiorników odczytu i zapisu i tylko do odczytu w aplikacji parametry połączenia, żadne dalsze działania nie są potrzebne, ponieważ połączenia są automatycznie kierowane do nowego podstawowego.

Konfigurowanie reguł zapory

Należy upewnić się, że reguły zapory skonfigurowane na serwerze pomocniczym i bazie danych są zgodne z regułami skonfigurowanymi na serwerze podstawowym i podstawowej bazie danych. Aby uzyskać więcej informacji, zobacz How to: Configure Firewall Settings (Instrukcje: konfigurowanie ustawień zapory).

Konfigurowanie identyfikatorów logowania i użytkowników bazy danych

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 po odzyskiwaniu po awarii.

Konfigurowanie alertów telemetrycznych

Należy upewnić się, że istniejące ustawienia reguły alertu zostały zaktualizowane, aby zamapować na nową podstawową bazę danych i inny serwer. Aby uzyskać więcej informacji na temat reguł alertów bazy danych, zobacz Otrzymywanie powiadomień o alertach i śledzenie kondycji usługi.

Włączanie przeprowadzania inspekcji

Jeśli inspekcja została skonfigurowana na serwerze podstawowym, ustaw ją tak samo na serwerze pomocniczym. Aby uzyskać więcej informacji, zobacz Inspekcja.

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