Omówienie zagadnień dotyczących ciągłości działalności biznesowej zapewnianej przez usługę Azure SQL Database
Dotyczy: 
Baza danych SQL Usługi Azure SQL Database w sieci szkieletowej
Ten artykuł zawiera omówienie możliwości ciągłości działania i odzyskiwania po awarii usługi Azure SQL Database, opisujących opcje i zalecenia dotyczące odzyskiwania po zdarzeniach powodujących zakłócenia, które mogą prowadzić do utraty danych lub spowodowania niedostępności bazy danych i aplikacji. Dowiedz się, co zrobić, gdy błąd użytkownika lub aplikacji wpływa na integralność danych, strefę dostępności platformy Azure lub region ma awarię lub aplikacja wymaga konserwacji.
Omówienie
Ciągłość działalności biznesowej w usłudze Azure SQL Database odnosi się do mechanizmów, zasad i procedur, które umożliwiają firmie kontynuowanie działania w obliczu zakłóceń, zapewniając dostępność, wysoką dostępność i odzyskiwanie po awarii.
W większości przypadków usługa SQL Database obsługuje destrukcyjne zdarzenia, które mogą wystąpić w środowisku chmury i utrzymuje uruchomione aplikacje i procesy biznesowe. Istnieją jednak pewne zakłócenia, w których środki zaradcze mogą zająć trochę czasu, takie jak:
- Użytkownik przypadkowo usuwa lub aktualizuje wiersz w tabeli.
- Złośliwy atakujący pomyślnie usuwa dane lub usuwa bazę danych.
- Katastrofalne zdarzenie klęski żywiołowej wyłącza centrum danych lub strefę dostępności lub region.
- Rzadkie awarie centrum danych, strefy dostępności lub całego regionu spowodowane przez zmianę konfiguracji, usterkę oprogramowania lub awarię składnika sprzętowego.
Dostępność
Usługa Azure SQL Database zapewnia podstawową odporność i niezawodność, która chroni ją przed awariami oprogramowania lub sprzętu. Kopie zapasowe bazy danych są zautomatyzowane w celu ochrony danych przed uszkodzeniem lub przypadkowym usunięciem. Jako usługa jako platforma jako usługa (PaaS) usługa Azure SQL Database zapewnia dostępność jako gotowej funkcji z wiodącą w branży umową SLA dostępności na 99,99%.
Wysoka dostępność
Aby zapewnić wysoką dostępność w środowisku chmury platformy Azure, włącz nadmiarowość strefy, aby baza danych lub elastyczna pula korzystała ze stref dostępności, aby zapewnić odporność bazy danych lub elastycznej puli na awarie strefowe. Wiele regionów platformy Azure zapewnia strefy dostępności, które są oddzielnymi grupami centrów danych w regionie, w którym znajdują się niezależne zasilanie, chłodzenie i infrastruktura sieciowa. Strefy dostępności są przeznaczone do świadczenia usług regionalnych, pojemności i wysokiej dostępności w pozostałych strefach, jeśli jedna strefa wystąpi awaria. Dzięki włączeniu nadmiarowości strefy baza danych lub elastyczna pula jest odporna na awarie sprzętu strefowego i oprogramowania, a odzyskiwanie jest niewidoczne dla aplikacji. Po włączeniu wysokiej dostępności usługa Azure SQL Database może zapewnić umowę SLA o wyższej dostępności na poziomie 99,995%.
Odzyskiwanie po awarii
Aby uzyskać większą dostępność i nadmiarowość w różnych regionach, możesz włączyć możliwości odzyskiwania po awarii, aby szybko odzyskać bazę danych z katastrofalnego awarii regionalnej. Opcje odzyskiwania po awarii w usłudze Azure SQL Database to:
- Aktywna replikacja geograficzna umożliwia utworzenie stale synchronizowanej pomocniczej bazy danych z możliwością odczytu w dowolnym regionie podstawowej bazy danych.
- Grupy trybu failover, oprócz zapewnienia ciągłej synchronizacji między podstawową i pomocniczą bazą danych, umożliwiają również zarządzanie replikacją i trybem failover niektórych lub wszystkich baz danych na serwerze logicznym na pomocniczym serwerze logicznym w innym regionie. Grupy trybu failover udostępniają punkty końcowe odbiornika tylko do odczytu i zapisu, które pozostają niezmienione, dlatego aktualizowanie parametry połączenia aplikacji po przejściu w tryb failover nie jest konieczne.
- Przywracanie geograficzne umożliwia odzyskanie po awarii regionalnej przez przywrócenie z replikacji geograficznej kopii zapasowych, gdy nie można uzyskać dostępu do bazy danych w regionie podstawowym, tworząc nową bazę danych na dowolnym istniejącym serwerze w dowolnym regionie świadczenia usługi Azure.
W poniższej tabeli porównaliśmy aktywne grupy replikacji geograficznej i trybu failover, dwie opcje odzyskiwania po awarii dla usługi Azure SQL Database:
| Aktywna replikacja geograficzna | Grupy trybu failover | |
|---|---|---|
| Ciągła synchronizacja danych między podstawowym i pomocniczym | Tak | Tak |
| Przechodzenie w tryb failover wielu baz danych jednocześnie | Nie. | Tak |
| Parametry połączenia pozostają niezmienione po przejściu w tryb failover | Nie. | Tak |
| Obsługuje skalę odczytu | Tak | Tak |
| Wiele replik | Tak | Nie. |
| Może znajdować się w tym samym regionie co podstawowy | Tak | Nie. |
Funkcje zapewniające ciągłość działalności biznesowej
Z perspektywy bazy danych istnieją cztery główne potencjalne scenariusze zakłóceń. W poniższej tabeli wymieniono funkcje ciągłości działania usługi SQL Database, których można użyć w celu ograniczenia potencjalnego scenariusza zakłóceń w działalności biznesowej:
| Scenariusz zakłóceń biznesowych | Funkcja ciągłości działania |
|---|---|
| Lokalne awarie sprzętu lub oprogramowania wpływające na węzeł bazy danych. | Aby wyeliminować lokalne awarie sprzętu i oprogramowania, usługa SQL Database zawiera architekturę dostępności, która gwarantuje automatyczne odzyskiwanie po tych awariach z umową SLA gwarantującą maksymalnie 99,99% dostępności. |
| Uszkodzenie lub usunięcie danych zwykle spowodowane przez usterkę aplikacji lub błąd ludzki. Takie błędy są specyficzne dla aplikacji i zwykle nie są wykrywane przez usługę bazy danych. | Aby chronić firmę przed utratą danych, usługa SQL Database automatycznie tworzy pełne kopie zapasowe bazy danych co tydzień, różnicowe kopie zapasowe baz danych co 12 lub 24 godziny, a kopie zapasowe dziennika transakcji co 5– 10 minut. Domyślnie kopie zapasowe są przechowywane w magazynie geograficznie nadmiarowym przez siedem dni dla wszystkich warstw usług. Wszystkie warstwy usług z wyjątkiem Podstawowa obsługują konfigurowalny okres przechowywania kopii zapasowych dla przywracania do punktu w czasie (PITR) do 35 dni. Możesz przywrócić usuniętą bazę danych do punktu, w którym została usunięta, jeśli serwer nie został usunięty, lub jeśli skonfigurowano długoterminowe przechowywanie (LTR). |
| Rzadkie awarie centrum danych lub strefy dostępności, prawdopodobnie spowodowane przez zdarzenie klęski żywiołowej, zmianę konfiguracji, usterkę oprogramowania lub awarię składnika sprzętowego. | Aby ograniczyć awarię na poziomie centrum danych lub strefy dostępności, włącz nadmiarowość stref dla bazy danych lub elastycznej puli, aby korzystać z usługi Azure Strefy dostępności i zapewnić nadmiarowość w wielu strefach fizycznych w regionie świadczenia usługi Azure. Włączenie nadmiarowości strefy zapewnia odporność bazy danych lub elastycznej puli na awarie strefowe z umową SLA o wysokiej dostępności do 99,995%. |
| Rzadka awaria regionalna wpływając na wszystkie strefy dostępności i składające się z niej centra danych, prawdopodobnie spowodowane katastrofalnym zdarzeniem klęski żywiołowej. | Aby wyeliminować awarię całego regionu, włącz odzyskiwanie po awarii przy użyciu jednej z opcji: — opcje ciągłej synchronizacji danych, takie jak grupy trybu failover (zalecane) lub aktywna replikacja geograficzna, które umożliwiają tworzenie replik w regionie pomocniczym na potrzeby trybu failover. — Ustawianie nadmiarowości magazynu kopii zapasowych na geograficznie nadmiarowy magazyn kopii zapasowych w celu korzystania z przywracania geograficznego. |
Cel czasu odzyskiwania i cel punktu odzyskiwania
Podczas opracowywania planu ciągłości działania należy zrozumieć maksymalny dopuszczalny czas przed pełnym odzyskaniem aplikacji po wystąpieniu zdarzenia powodującego zakłócenia. Czas wymagany do pełnego odzyskania aplikacji jest znany jako cel czasu odzyskiwania (RTO). Zapoznaj się również z maksymalnym okresem ostatnich aktualizacji danych (interwał czasu), który aplikacja może tolerować utratę podczas odzyskiwania po nieplanowanym zdarzeniu zakłócającym działanie. Potencjalna utrata danych jest znana jako cel punktu odzyskiwania (RPO).
W poniższej tabeli porównaliśmy cel punktu odzyskiwania i cel czasu odzyskiwania dla każdej opcji ciągłości działania:
Listy kontrolne ciągłości działalności biznesowej
Aby zapoznać się z zaleceniami wstępnymi w celu zmaksymalizowania dostępności i osiągnięcia wyższej ciągłości działania, zapoznaj się z tematem:
- Lista kontrolna dotycząca dostępności
- Lista kontrolna wysokiej dostępności
- Lista kontrolna odzyskiwania po awarii
Przygotowanie do awarii regionu
Niezależnie od tego, które funkcje ciągłości działania są używane, należy przygotować pomocniczą bazę danych w innym regionie. Jeśli nie przygotujesz się prawidłowo, przełączenie aplikacji do trybu online po przejściu w tryb failover lub odzyskiwaniu zajmuje dodatkowy czas, a prawdopodobnie wymaga również rozwiązywania problemów, co może opóźnić cel czasu odzyskiwania. Postępuj zgodnie z listą kontrolną przygotowania pomocniczego do awarii regionu.
Przywracanie bazy danych w tym samym regionie świadczenia usługi Azure
Automatyczne kopie zapasowe bazy danych umożliwiają przywrócenie bazy danych do punktu w czasie w przeszłości. Dzięki temu można odzyskać dane po uszkodzeniach danych spowodowanych błędami ludzkimi. Przywracanie do punktu w czasie (PITR) umożliwia utworzenie nowej bazy danych na tym samym serwerze, który reprezentuje stan danych przed uszkodzeniem zdarzenia. W przypadku większości baz danych operacje przywracania trwa mniej niż 12 godzin. Odzyskanie bardzo dużej lub bardzo aktywnej bazy danych może potrwać dłużej. Aby uzyskać więcej informacji, zobacz czas odzyskiwania bazy danych.
Jeśli maksymalny obsługiwany okres przechowywania kopii zapasowych dla przywracania do punktu w czasie nie jest wystarczający dla aplikacji, możesz ją rozszerzyć, konfigurując zasady przechowywania długoterminowego (LTR) dla baz danych. Aby uzyskać więcej informacji, zobacz Długoterminowe przechowywanie kopii zapasowych.
Uaktualnianie aplikacji przy minimalnych przestojach
Czasami aplikacja musi zostać przełączony w tryb offline z powodu konserwacji, takiej jak uaktualnienie aplikacji. Zarządzanie uaktualnieniami aplikacji opisuje sposób używania aktywnej replikacji geograficznej w celu umożliwienia uaktualniania stopniowego aplikacji w chmurze w celu zminimalizowania przestojów podczas uaktualniania i zapewnienia ścieżki odzyskiwania, jeśli coś pójdzie nie tak.
Oszczędzanie na kosztach dzięki repliki rezerwowej
Jeśli replika pomocnicza jest używana tylko do odzyskiwania po awarii (DR) i nie ma żadnych obciążeń odczytu lub zapisu, możesz zaoszczędzić na kosztach licencjonowania, określając bazę danych na potrzeby rezerwowania podczas konfigurowania nowej aktywnej relacji replikacji geograficznej.
Aby dowiedzieć się więcej, zapoznaj się z bezpłatną repliką rezerwową bez licencji .
Następne kroki
Aby zapoznać się z zagadnieniami dotyczącymi projektowania aplikacji, zobacz Projektowanie aplikacji na potrzeby odzyskiwania po awarii w chmurze i strategii odzyskiwania po awarii elastycznej puli.
Zapoznaj się ze wskazówkami dotyczącymi odzyskiwania po awarii usługi Azure SQL Database i listą kontrolną wysokiej dostępności i odzyskiwania po awarii usługi Azure SQL Database.