Udostępnij za pośrednictwem

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

  • Artykuł

Dotyczy: Azure SQL Managed Instance

Usługa Azure SQL Managed Instance zapewnia wiodącą w branży gwarancję wysokiej dostępności wynoszącą 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 Managed Instance 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 staramy się zapewnić wysoką dostępność, czasami usługa Azure SQL Managed Instance powoduje awarie, 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 Managed Instance można 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 Managed Instance.

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

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, wystarczy 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 Managed Instance 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:

Przechodzenie w tryb failover (bez utraty danych) do wystąpienia pomocniczego replikowanego geograficznie

Jeśli grupy trybu failover są włączone, sprawdź, czy stan zasobu wystąpienia podstawowego i pomocniczego to Online w witrynie Azure Portal. Jeśli tak, płaszczyzna danych dla wystąpienia podstawowego i pomocniczego jest w dobrej kondycji.

Zainicjuj przejście w tryb failover grup trybu failover do regionu pomocniczego przy użyciu:

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.

Wymuszone przejście w tryb failover (potencjalna utrata danych) do wystąpienia pomocniczego replikowanego geograficznie

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:

Przywracanie geograficzne

Jeśli nie włączono grup trybu failover, możesz użyć przywracania geograficznego w celu odzyskania sprawności po awarii. Przywracanie geograficzne używa kopii zapasowych replikowanych geograficznie jako źródła. Bazę danych można przywrócić na dowolnym wystąpieniu w dowolnym regionie platformy Azure z najnowszych kopii zapasowych replikowanych geograficznie. Możesz zażądać przywrócenia geograficznego, nawet jeśli awaria wystąpienia 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.

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 nowym wystąpieniem jest prawidłowo skonfigurowana, aby można było wznowić normalne działanie 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.

Aktualizowanie parametry połączenia

  • Jeśli używasz przywracania geograficznego, upewnij się, że łączność z nowym wystąpieniem jest prawidłowo skonfigurowana, aby można było wznowić normalną funkcję aplikacji. Ponieważ odzyskana baza danych znajduje się w innym wystąpieniu, należy zaktualizować parametry połączenia aplikacji, aby wskazywała 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

Upewnij się, że reguły sieciowej grupy zabezpieczeń i tabeli tras skonfigurowane dla wystąpienia pomocniczego są zgodne z regułami skonfigurowanymi w wystąpieniu podstawowym. Przejrzyj konfigurację podsieci wspomaganej przez usługę, aby dowiedzieć się więcej.

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

Utwórz identyfikatory logowania, które muszą znajdować się w bazie danych w wystąpieniu master pomocniczym, i upewnij się, że te identyfikatory logowania mają odpowiednie uprawnienia w master bazie danych, jeśli istnieją.

Konfigurowanie alertów telemetrycznych

Upewnij się, że istniejące ustawienia reguły alertu zostały zaktualizowane w celu mapowania na nowe wystąpienie podstawowe. 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 w wystąpieniu podstawowym, ustaw ją identycznie w wystąpieniu pomocniczym. Aby uzyskać więcej informacji, zobacz Inspekcja usługi Azure SQL dla usługi Azure SQL Managed Instance.

Powiązana zawartość

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