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:
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.
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:
Powiadomienie e-mail
Jeśli skonfigurowano alerty, powiadomienie e-mail jest wysyłane,
azure-noreply@microsoft.comgdy 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:
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.
Powiązana zawartość
Aby dowiedzieć się więcej, zapoznaj się z tematem:
- Scenariusze ciągłości.
- Automatyczne kopie zapasowe
- Przywracanie bazy danych z kopii zapasowych zainicjowanych przez usługę.
- Aby dowiedzieć się więcej o szybszych opcjach odzyskiwania, zobacz Aktywne replikacje geograficzne i grupy trybu failover.
- Przejrzyj wskazówki dotyczące odzyskiwania po awarii oraz listę kontrolną wysokiej dostępności i odzyskiwania po awarii.