Omówienie zagadnień dotyczących ciągłości działalności biznesowej zapewnianej przez usługę Azure SQL Database

Artykuł
2025-04-09

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.
Katastrofa naturalna wyłącza centrum danych, strefę dostępności lub region.
Rzadkie centrum danych, strefa dostępności lub awaria całego regionu spowodowane zmianą konfiguracji, usterką oprogramowania lub awarią sprzętu.

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, zobacz:

Wysoka 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 Platforma jako usługa (PaaS), usługa Azure SQL Database zapewnia dostępność jako funkcję standardową z wiodącym w branży wskaźnikiem dostępności SLA wynoszącym 99,99%.

Aby zapewnić wysoką dostępność w środowisku chmury Azure, włącz strefową nadmiarowość. W przypadku nadmiarowości strefowej, korzystając ze stref dostępności platformy Azure, baza danych lub elastyczna pula zapewnia odporność 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, zdolności i wysokiej dostępności w pozostałych strefach, jeśli w jednej ze stref wystąpi awaria.

Dzięki włączeniu nadmiarowości strefowej dla bazy danych lub elastycznej puli, jest ona odporna na awarie sprzętu w strefie i oprogramowania, a proces odzyskiwania jest przejrzysty 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ć funkcje odzyskiwania po awarii w celu szybkiego odzyskania bazy danych z katastrofalnej awarii regionalnej. Opcje odzyskiwania po awarii w bazie danych 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 awaryjne, oprócz zapewnienia ciągłej synchronizacji między podstawową a pomocniczą bazą danych, umożliwiają również zarządzanie replikacją i przełączaniem awaryjnym niektórych lub wszystkich baz danych na serwerze logicznym do pomocniczego serwera logicznego 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 awaryjnego przełączania
Ciągła synchronizacja danych między głównym i zapasowym	Tak	Tak
Jednoczesne przełączanie na tryb fail-over wielu baz danych	Nie.	Tak
Parametry połączenia pozostają niezmienione po przejściu w tryb failover	Nie.	Tak
Obsługuje skalowanie odczytów	Tak	Tak
Wiele replik	Tak	Nie.
Może znajdować się w tym samym regionie co podstawowy	Tak	Nie.

Czas Odzyskiwania (RTO) i Punkt Odzyskiwania (RPO)

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. Istnieją dwa typowe sposoby kwantyfikacji wymagań biznesowych związanych z odzyskiwaniem po awarii:

Cel czasu odzyskiwania (RTO): czas wymagany do pełnego odzyskania aplikacji po nieplanowanym zdarzeniu zakłócających działanie.
Cel punktu odzyskiwania (RPO) : czas utraty danych, który może być tolerowany z powodu nieplanowanego zdarzenia powodującego zakłócenia.

W poniższej tabeli porównujemy RPO i RTO każdej z opcji ciągłości działania:

Opcja ciągłości działania	RTO (Czas przestoju)	RPO (utrata danych)
Wysoka dostępność (przy użyciu redundancji strefowej)	Zazwyczaj mniej niż 30 sekund	0
Odzyskiwanie po awarii (używanie grup trybu failover z zasadami trybu failover zarządzanymi przez klienta lub aktywną replikacją geograficzną)	Zazwyczaj mniej niż 60 sekund	Równe lub większe niż 0 (zależy od zmian danych przed zdarzeniem zakłócającymi, które nie zostały zreplikowane)
Odzyskiwanie po awarii (korzystanie z przywracania geograficznego)	Zazwyczaj minuty lub godziny zależne od replikacji usługi Azure Storage	Zazwyczaj minuty lub godziny zależne od rozmiaru kopii zapasowej bazy danych

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 Azure SQL Database obejmuje architekturę dostępności, która gwarantuje automatyczne odzyskiwanie po tych awariach z maksymalnie 99,99% umową SLA 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 poziomy usług z wyjątkiem podstawowej 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).
Rzadka awaria centrum danych lub strefy dostępności, prawdopodobnie spowodowana przez zdarzenie klęski żywiołowej, zmianę konfiguracji, usterkę oprogramowania lub awarię sprzętu.	Aby zmniejszyć ryzyko awarii na poziomie centrum danych lub strefy dostępności, włącz nadmiarowość stref dla bazy danych lub elastycznej puli, aby wykorzystać Azure Availability Zones i zapewnić nadmiarowość w wielu fizycznych strefach na terenie regionu Azure. Włączenie redundancji strefowej zapewnia, że baza danych lub elastyczna pula jest odporna na awarie strefowe, z gwarancją wysokiej dostępności SLA na poziomie do 99.995%.
Rzadka awaria regionalna wpływająca 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, korzystając z jednej z opcji: — opcje ciągłej synchronizacji danych, takie jak grupy awaryjne (zalecane) lub geograficzna replikacja aktywna, które umożliwiają tworzenie replik w regionie pomocniczym na potrzeby mechanizmu failover. — Ustawianie nadmiarowości magazynu kopii zapasowych na geograficznie nadmiarowy magazyn kopii zapasowych w celu korzystania z przywracania geograficznego.

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, przywracanie aplikacji online po awarii lub odzyskiwaniu zajmuje dodatkowy czas i prawdopodobnie wymaga również rozwiązywania problemów, co może opóźnić RTO. Postępuj zgodnie z listą kontrolną przygotowania systemu zapasowego na wypadek 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. Aby uzyskać informacje dotyczące czasu odzyskiwania, zobacz RTO i RPO.

Jeśli maksymalny obsługiwany okres przechowywania kopii zapasowych dla przywracania do punktu w czasie nie jest wystarczający dla Twojej aplikacji, możesz wydłużyć okres ten, konfigurując politykę przechowywania długoterminowego (LTR). Aby uzyskać więcej informacji, zobacz Długoterminowe przechowywanie.

Uaktualnianie aplikacji przy minimalnych przestojach

Czasami aplikacja musi zostać przełączona w tryb offline z powodu konserwacji, takiej jak aktualizacja. Można zarządzać stopniowymi uaktualnieniami aplikacji w chmurze przy użyciu aktywnej replikacji geograficznej usługi SQL Database. Replikacja geograficzna może również podać ścieżkę 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, przejrzyj replikę zapasową nie wymagającą licencji.

Następny krok

Lista kontrolna wysokiej dostępności i odzyskiwania po awarii

Udostępnij za pośrednictwem