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 umożliwiają szybkie odzyskiwanie 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ąpi alert dotyczący awarii problemu z usługą:
Pomoc i obsługa technicznai rozwiązywanie problemów
Podczas tworzenia biletu pomocy technicznej na stronie Pomoc i obsługa techniczna i rozwiązywanie 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.
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 | Metoda | 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 niejest 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ć 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 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żyj 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 i w bazie danych są zgodne z regułami skonfigurowanymi na serwerze podstawowym i podstawowej bazie danych. Aby uzyskać więcej informacji, zobacz Jak skonfigurować zaporę Ustawienia (Azure SQL Database).
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 usługi Azure SQL Database 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 jest wymagana do uzyskania dostępu do bazy danych, należy włączyć inspekcję po odzyskaniu bazy danych. Aby uzyskać więcej informacji, zobacz Inspekcja usługi Azure SQL Dla usługi Azure SQL Database.
Następne kroki
- Zapoznaj się z umową SLA dotyczącą usługi Azure SQL Database
- Aby dowiedzieć się więcej na temat automatycznych kopii zapasowych usługi Azure SQL Database, zobacz Automatyczne kopie zapasowe usługi SQL Database
- Aby dowiedzieć się więcej na temat scenariuszy projektowania i odzyskiwania ciągłości działania, zobacz Scenariusze ciągłości działania
- Aby dowiedzieć się więcej o korzystaniu z automatycznych kopii zapasowych na potrzeby odzyskiwania, zobacz Przywracanie bazy danych z kopii zapasowych zainicjowanych przez usługę
- Dowiedz się więcej o aktywnej replikacji geograficznej
- Dowiedz się więcej o grupach trybu failover
- Dowiedz się więcej na temat przywracania geograficznego
- Dowiedz się więcej na temat strefowo nadmiarowych baz danych
Opinia
Dostępne już wkrótce: W 2024 r. będziemy stopniowo wycofywać zgłoszenia z serwisu GitHub jako mechanizm przesyłania opinii na temat zawartości i zastępować go nowym systemem opinii. Aby uzyskać więcej informacji, sprawdź: https://aka.ms/ContentUserFeedback.
Prześlij i wyświetl opinię dla