Aktywna replikacja geograficzna

Dotyczy: baza danych Azure SQL

Aktywna replikacja geograficzna to funkcja, która umożliwia tworzenie stale synchronizowanej pomocniczej pomocniczej bazy danych z możliwością odczytu dla podstawowej bazy danych. Pomocnicza baza danych z możliwością odczytu może znajdować się w tym samym regionie świadczenia usługi Azure co podstawowy lub, częściej, w innym regionie. Ta pomocnicza baza danych z możliwością odczytu jest również nazywana pomocniczą lub geograficzną repliką geograficzną.

Aktywna replikacja geograficzna jest zaprojektowana jako rozwiązanie zapewniające ciągłość działalności biznesowej, które umożliwia szybkie odzyskiwanie po awarii poszczególnych baz danych w przypadku awarii regionalnej lub awarii na dużą skalę. Po skonfigurowaniu replikacji geograficznej możesz zainicjować przejście geograficzne w tryb failover do pomocniczego obszaru geograficznego w innym regionie świadczenia usługi Azure. Geograficzne przejście w tryb failover jest inicjowane programowo przez aplikację lub ręcznie przez użytkownika.

Jeśli aplikacja wymaga stabilnego punktu końcowego połączenia i automatycznej obsługi trybu failover geograficznego oprócz replikacji geograficznej, użyj grup automatycznego trybu failover.

Na poniższym diagramie przedstawiono typową konfigurację aplikacji w chmurze geograficznie nadmiarowej przy użyciu aktywnej replikacji geograficznej.

Jeśli z jakiegoś powodu podstawowa baza danych ulegnie awarii, możesz zainicjować przejście geograficzne w tryb failover do dowolnej pomocniczej bazy danych. Po podwyższeniu poziomu pomocniczego do roli podstawowej wszystkie inne pomocnicze pliki pomocnicze są automatycznie połączone z nowym elementem podstawowym.

Replikację geograficzną można zarządzać i inicjować przechodzenie w tryb failover geograficznie przy użyciu następujących elementów:

• Azure Portal
• PowerShell: pojedyncza baza danych
• PowerShell: elastyczna pula
• Transact-SQL: pojedyncza baza danych lub elastyczna pula
• Interfejs API REST: pojedyncza baza danych

Aktywna replikacja geograficzna wykorzystuje technologię zawsze włączonej grupy dostępności do asynchronicznego replikowania dziennika transakcji wygenerowanego w repliki podstawowej do wszystkich replik geograficznych. I chociaż pomocnicza baza danych może być zawsze nieco w tyle za podstawową bazą danych, dane w pomocniczej bazie danych mają gwarancję spójności na poziomie transakcji. Innymi słowy zmiany wprowadzone przez niezatwierdzone transakcje nie są widoczne.

Nadmiarowość regionalna zapewniana przez replikację geograficzną umożliwia aplikacjom szybkie odzyskiwanie po trwałej utracie całego regionu platformy Azure lub części regionu, spowodowanych klęskami żywiołowymi, katastrofalnymi błędami ludzkimi lub złośliwymi działaniami. Cel punktu odzyskiwania replikacji geograficznej można znaleźć w temacie Omówienie ciągłości działania.

Na poniższej ilustracji przedstawiono przykład aktywnej replikacji geograficznej skonfigurowanej przy użyciu podstawowego regionu Północno-środkowe stany USA i pomocniczego obszaru geograficznego w regionie Południowo-środkowe stany USA.

Oprócz odzyskiwania po awarii aktywna replikacja geograficzna może być używana w następujących scenariuszach:

• Migracja bazy danych: możesz użyć aktywnej replikacji geograficznej, aby przeprowadzić migrację bazy danych z jednego serwera do drugiego z minimalnym przestojem.
• Uaktualnienia aplikacji: możesz utworzyć dodatkową pomocniczą kopię jako kopię powrotu po awarii podczas uaktualniania aplikacji.

Aby zapewnić pełną ciągłość działalności biznesowej, dodanie nadmiarowości regionalnej bazy danych jest tylko częścią rozwiązania. Odzyskiwanie kompleksowej aplikacji (usługi) po katastrofalnym niepowodzeniu wymaga odzyskania wszystkich składników, które składają się na usługę i wszelkie usługi zależne. Przykłady tych składników obejmują oprogramowanie klienckie (na przykład przeglądarkę z niestandardowym kodem JavaScript), frontony internetowe, magazyn i system DNS. Ważne jest, aby wszystkie składniki były odporne na te same błędy i stały się dostępne w ramach celu czasu odzyskiwania (RTO) aplikacji. W związku z tym należy zidentyfikować wszystkie usługi zależne i zrozumieć gwarancje i możliwości, które zapewniają. Następnie należy podjąć odpowiednie kroki, aby upewnić się, że funkcje usługi podczas pracy w trybie failover usług, od których zależy. Aby uzyskać więcej informacji na temat projektowania rozwiązań do odzyskiwania po awarii, zobacz Projektowanie rozwiązań w chmurze na potrzeby odzyskiwania po awarii przy użyciu aktywnej replikacji geograficznej.

• Automatyczna replikacja asynchroniczna

  Dla istniejącej bazy danych można utworzyć tylko pomocniczą bazę danych z replikacją geograficzną. Pomocnicza lokalizacja geograficzna może być tworzona na dowolnym serwerze logicznym innym niż serwer z podstawową bazą danych. Po utworzeniu replika pomocnicza geograficznie jest wypełniana danymi podstawowej bazy danych. Ten proces jest znany jako rozmieszczanie. Po utworzeniu i zainicjowaniu replikacji geograficznej pomocniczej aktualizacje podstawowej bazy danych są automatycznie i asynchronicznie replikowane do repliki pomocniczej geograficznej. Replikacja asynchroniczna oznacza, że transakcje są zatwierdzane w podstawowej bazie danych przed ich replikacją.

• Repliki pomocnicze z możliwością odczytu

  Aplikacja może uzyskać dostęp do repliki pomocniczej geograficznej w celu wykonywania zapytań tylko do odczytu przy użyciu tych samych lub różnych podmiotów zabezpieczeń używanych do uzyskiwania dostępu do podstawowej bazy danych. Aby uzyskać więcej informacji, zobacz Używanie replik tylko do odczytu do odciążania obciążeń zapytań tylko do odczytu.

  Ważne

  Replikacja geograficzna umożliwia tworzenie replik pomocniczych w tym samym regionie co podstawowy. Tych pomocniczych można użyć do spełnienia scenariuszy skalowania odczytu w poziomie w tym samym regionie. Jednak replika pomocnicza w tym samym regionie nie zapewnia dodatkowej odporności na katastrofalne awarie lub awarie na dużą skalę, dlatego nie jest odpowiednim celem trybu failover na potrzeby odzyskiwania po awarii. Nie gwarantuje również izolacji strefy dostępności. Aby uzyskać izolację strefy dostępności, użyj konfiguracji strefowo nadmiarowej warstwy usług Krytyczne dla działania firmy lub warstwy usługi Premium albo konfiguracji strefowo nadmiarowej warstwy usługi Ogólnego przeznaczenia.

• Planowana praca geograficzna w trybie failover

  Planowane przejście w tryb failover geograficznie przełącza role podstawowych i pomocniczych baz danych geograficznych po zakończeniu pełnej synchronizacji danych. Planowane przełączanie awaryjne nie powoduje utraty danych. Czas trwania planowanego przejścia w tryb failover geograficzny zależy od rozmiaru dziennika transakcji na serwerze podstawowym, który musi zostać zsynchronizowany z pomocniczym obszarem geograficznym. Planowane geograficzne przejście w tryb failover jest przeznaczone dla następujących scenariuszy:

  • Wykonywanie próbnego odzyskiwania po awarii w środowisku produkcyjnym, gdy utrata danych jest niedopuszczalna;
  • Przenieś bazę danych do innego regionu;
  • Wróć bazę danych do regionu podstawowego po wyeliminowaniu awarii (znanej jako powrót po awarii).

• Nieplanowana praca geograficzna w trybie failover

  Nieplanowane lub wymuszone przejście w tryb failover geograficzne natychmiast przełącza pomocnicze geograficznie do roli podstawowej bez żadnej synchronizacji z serwerem podstawowym. Wszystkie transakcje zatwierdzone na serwerze podstawowym, ale nie zostały jeszcze zreplikowane do pomocniczej, zostaną utracone. Ta operacja jest zaprojektowana jako metoda odzyskiwania podczas awarii, gdy podstawowy jest niedostępny, ale dostępność bazy danych musi zostać szybko przywrócona. Gdy oryginalny serwer podstawowy wróci do trybu online, zostanie automatycznie ponownie połączony, ponownie przekazany przy użyciu bieżących danych podstawowych i stanie się nowym pomocniczym obszarem geograficznym.

  Ważne

  Po zaplanowanym lub nieplanowanym trybie failover punkt końcowy połączenia dla nowych zmian podstawowych, ponieważ nowy serwer podstawowy znajduje się teraz na innym serwerze logicznym.

• Wiele czytelnych lokalizacji geograficznych

  Dla bazy podstawowej można utworzyć maksymalnie cztery pomocnicze lokalizacje geograficzne. Jeśli istnieje tylko jedna pomocnicza i kończy się niepowodzeniem, aplikacja jest narażona na większe ryzyko do momentu utworzenia nowej pomocniczej. Jeśli istnieje wiele serwerów pomocniczych, aplikacja pozostaje chroniona, nawet jeśli jeden z serwerów pomocniczych ulegnie awarii. Dodatkowe pomocnicze można również użyć do skalowania obciążeń tylko do odczytu.

  Porada

  Jeśli używasz aktywnej replikacji geograficznej do tworzenia globalnie rozproszonej aplikacji i musisz zapewnić dostęp tylko do odczytu do danych w ponad czterech regionach, możesz utworzyć pomocniczą pomocniczą (proces znany jako łańcuch), aby utworzyć dodatkowe repliki geograficzne. Opóźnienie replikacji w łańcuchowych replikach geograficznych może być wyższe niż w przypadku replik geograficznych połączonych bezpośrednio z serwerem podstawowym. Konfigurowanie topologii replikacji geograficznej jest obsługiwane tylko programowo, a nie z Azure Portal.

• Replikacja geograficzna baz danych w elastycznej puli

  Każda pomocnicza lokalizacja geograficzna może być pojedynczą bazą danych lub bazą danych w elastycznej puli. Wybór elastycznej puli dla każdej pomocniczej bazy danych z replikacją geograficzną jest oddzielny i nie zależy od konfiguracji żadnej innej repliki w topologii (podstawowej lub pomocniczej). Każda elastyczna pula jest zawarta na jednym serwerze logicznym. Ponieważ nazwy baz danych na serwerze logicznym muszą być unikatowe, wiele serwerów geograficznych tego samego podstawowego nigdy nie może współużytkować elastycznej puli.

• Sterowany przez użytkownika tryb geo-failover i powrót po awarii

  Pomocnicze geograficznie pomocnicze, które zakończyło wstępne rozmieszczanie, można jawnie przełączyć na rolę podstawową (przełączenie w tryb failover) w dowolnym momencie przez aplikację lub użytkownika. Podczas awarii, w której serwer podstawowy jest niedostępny, można użyć tylko nieplanowanego geograficznego trybu failover. Natychmiast podwyższa to poziom pomocniczego obszaru geograficznego, aby był nowym podstawowym elementem. Gdy awaria zostanie złagodzone, system automatycznie utworzy odzyskaną podstawową pomocniczą lokalizację geograficzną i przywróci ją do nowej podstawowej bazy danych. Ze względu na asynchroniczną naturę replikacji geograficznej ostatnie transakcje mogą zostać utracone podczas nieplanowanych trybów geograficznych trybu failover, jeśli podstawowy tryb failover zakończy się niepowodzeniem, zanim te transakcje zostaną zreplikowane do pomocniczego obszaru geograficznego. W przypadku przełączenia w tryb failover serwera podstawowego z wieloma serwerami geograficznymi system automatycznie ponownie konfiguruje relacje replikacji i łączy pozostałe pomocnicze lokalizacje geograficzne z nowo podwyższonym poziomem podstawowym bez konieczności interwencji użytkownika. Po wystąpieniu awarii, która spowodowała ograniczenie geograficznego trybu failover, może być pożądane zwrócenie podstawowego do oryginalnego regionu. Aby to zrobić, wywołaj planowane przejście w tryb failover geograficznego.

Aby upewnić się, że aplikacja może natychmiast uzyskać dostęp do nowego podstawowego po przejściu w tryb failover geograficznie, sprawdź, czy uwierzytelnianie i dostęp sieciowy do serwera pomocniczego są prawidłowo skonfigurowane. Aby uzyskać szczegółowe informacje, zobacz SQL Database zabezpieczenia po odzyskiwaniu po awarii. Sprawdź również, czy zasady przechowywania kopii zapasowych w pomocniczej bazie danych są zgodne z zasadami podstawowymi. To ustawienie nie jest częścią bazy danych i nie jest replikowane z bazy danych podstawowej. Domyślnie pomocnicza lokalizacja geograficzna jest skonfigurowana z domyślnym okresem przechowywania pitr w ciągu siedmiu dni. Aby uzyskać szczegółowe informacje, zobacz SQL Database automatycznych kopii zapasowych.

Zarówno podstawowa, jak i pomocnicza lokalizacja geograficzna muszą mieć tę samą warstwę usługi. Zdecydowanie zaleca się też skonfigurowanie pomocniczej lokalizacji geograficznej przy użyciu tej samej nadmiarowości magazynu kopii zapasowych i rozmiaru obliczeniowego (jednostki DTU lub rdzenie wirtualne) jako lokalizacji podstawowej. Jeśli lokalizacja podstawowa będzie silnie obciążona operacjami zapisu, pomocnicza lokalizacja geograficzna o mniejszym rozmiarze obliczeniowym może nie być w stanie nadążyć. Spowoduje to opóźnienie replikacji w pomocniczej lokalizacji geograficznej i może w końcu spowodować niedostępność tej lokalizacji. Aby ograniczyć te czynniki ryzyka, aktywna replikacja geograficzna zmniejszy (ograniczy) szybkość rejestrowania transakcji w lokalizacji podstawowej, jeśli będzie to konieczne, aby umożliwić nadrobienie zaległości w lokalizacjach pomocniczych.

Kolejną konsekwencją niedopasowanej konfiguracji pomocniczej lokalizacji geograficznej jest to, że po przejściu w tryb failover wydajność aplikacji może spaść z powodu niewystarczającej wydajności obliczeniowej nowej lokalizacji podstawowej. W takim przypadku konieczne będzie skalowanie bazy danych w górę, aby mieć wystarczające zasoby, co może zająć dużo czasu i będzie wymagać przejścia w tryb failover o wysokiej dostępności na końcu procesu skalowania w górę, co może przerwać obciążenia aplikacji.

Jeśli zdecydujesz się utworzyć pomocniczą lokalizację geograficzną z mniejszym rozmiarem obliczeniowym, należy monitorować szybkość operacji we/wy rejestrowania w lokalizacji podstawowej. Pozwoli to oszacować minimalny rozmiar obliczeniowy pomocniczej lokalizacji geograficznej wymagany do utrzymania obciążenia replikacji. Jeśli na przykład podstawowa baza danych to P6 (1000 DTU), a jej operacje we/wy dziennika są utrzymywane na poziomie 50%, pomocnicza lokalizacja geograficzna musi być co najmniej P4 (500 DTU). Aby pobrać dane we/wy dziennika historycznego, użyj widoku sys.resource_stats . Aby pobrać ostatnie dane we/wy dziennika z większą szczegółowością, która lepiej odzwierciedla krótkoterminowe skoki, użyj widoku sys.dm_db_resource_stats .

Domyślnie nadmiarowość magazynu kopii zapasowych pomocniczego obszaru geograficznego jest taka sama jak w przypadku podstawowej bazy danych. Możesz skonfigurować pomocniczą lokalizację geograficzną z inną nadmiarowością magazynu kopii zapasowych. Kopie zapasowe są zawsze wykonywane w podstawowej bazie danych. Jeśli pomocnicza jest skonfigurowana z inną nadmiarowością magazynu kopii zapasowej, po przejściu do trybu failover geograficznego po podwyższeniu poziomu geograficznego do warstwy podstawowej nowe kopie zapasowe będą przechowywane i rozliczane zgodnie z typem magazynu (RA-GRS, ZRS, LRS) wybranym w nowej podstawowej (poprzedniej pomocniczej).

Aby utworzyć pomocniczą geograficzną w subskrypcji innej niż subskrypcja podstawowego (niezależnie od tego, czy jest to ta sama dzierżawa usługi Azure Active Directory, czy nie), wykonaj kroki opisane w tej sekcji.

1. Dodaj adres IP maszyny klienckiej wykonującej poniższe polecenia języka T-SQL do zapór serwera zarówno serwerów podstawowych, jak i pomocniczych. Ten adres IP można potwierdzić, wykonując następujące zapytanie podczas nawiązywania połączenia z serwerem podstawowym z tej samej maszyny klienckiej.

   SQL Kopiuj

   select client_net_address from sys.dm_exec_connections where session_id = @@SPID;
   

   Aby uzyskać więcej informacji, zobacz Konfigurowanie zapory.

2. master W bazie danych na serwerze podstawowym utwórz identyfikator logowania uwierzytelniania SQL dedykowany do aktywnej konfiguracji replikacji geograficznej. Dostosuj nazwę logowania i hasło zgodnie z potrzebami.

   SQL Kopiuj

   create login geodrsetup with password = 'ComplexPassword01';
   

3. W tej samej bazie danych utwórz użytkownika na potrzeby logowania i dodaj go do dbmanager roli:

   SQL Kopiuj

   create user geodrsetup for login geodrsetup;
   alter role dbmanager add member geodrsetup;
   

4. Zanotuj wartość identyfikatora SID nowego identyfikatora logowania. Uzyskaj wartość identyfikatora SID przy użyciu następującego zapytania.

   SQL Kopiuj

   select sid from sys.sql_logins where name = 'geodrsetup';
   

5. Połącz się z podstawową bazą danych (a nie master bazą danych) i utwórz użytkownika dla tego samego identyfikatora logowania.

   SQL Kopiuj

   create user geodrsetup for login geodrsetup;
   

6. W tej samej bazie danych dodaj użytkownika do db_owner roli.

   SQL Kopiuj

   alter role db_owner add member geodrsetup;
   

7. master W bazie danych na serwerze pomocniczym utwórz to samo logowanie co na serwerze podstawowym, używając tej samej nazwy, hasła i identyfikatora SID. Zastąp wartość szesnastkowego identyfikatora SID w poniższym przykładowym poleceniu wartością uzyskaną w kroku 4.

   SQL Kopiuj

   create login geodrsetup with password = 'ComplexPassword01', sid=0x010600000000006400000000000000001C98F52B95D9C84BBBA8578FACE37C3E;
   

8. W tej samej bazie danych utwórz użytkownika na potrzeby logowania i dodaj go do dbmanager roli.

   SQL Kopiuj

   create user geodrsetup for login geodrsetup;
   alter role dbmanager add member geodrsetup;
   

9. Nawiąż połączenie z bazą master danych na serwerze podstawowym przy użyciu nowego geodrsetup identyfikatora logowania i zainicjuj tworzenie pomocnicze na serwerze pomocniczym. Dostosuj nazwę bazy danych i nazwę serwera pomocniczego zgodnie z potrzebami. Po wykonaniu polecenia można monitorować tworzenie pomocnicze geograficznie, wysyłając zapytanie do widoku sys.dm_geo_replication_link_status w podstawowej bazie danych oraz widok sys.dm_operation_status w master bazie danych na serwerze podstawowym . Czas potrzebny do utworzenia pomocniczego obszaru geograficznego zależy od rozmiaru podstawowej bazy danych.

   SQL Kopiuj

   alter database [dbrep] add secondary on server [servername];
   

10. Po pomyślnym utworzeniu pomocniczego obszaru geograficznego można usunąć użytkowników, identyfikatory logowania i reguły zapory utworzone przez tę procedurę.

W przypadku korzystania z dostępu do sieci publicznej do nawiązywania połączenia z bazą danych zalecamy używanie reguł zapory ip na poziomie bazy danych dla replikowanych geograficznie baz danych. Te reguły są replikowane z bazą danych, co gwarantuje, że wszystkie pomocnicze lokalizacje geograficzne mają te same reguły zapory IP co podstawowa. Takie podejście eliminuje potrzebę ręcznego konfigurowania i utrzymywania reguł zapory na serwerach hostujących podstawowe i pomocnicze bazy danych. Podobnie użycie użytkowników zawartej bazy danych w celu uzyskania dostępu do danych zapewnia, że zarówno podstawowe, jak i pomocnicze bazy danych zawsze mają te same poświadczenia uwierzytelniania. W ten sposób po przejściu w tryb failover geograficznym nie ma żadnych zakłóceń z powodu niezgodności poświadczeń uwierzytelniania. Jeśli używasz identyfikatorów logowania i użytkowników (a nie zawartych użytkowników), musisz wykonać dodatkowe kroki, aby upewnić się, że te same identyfikatory logowania istnieją dla pomocniczej bazy danych. Aby uzyskać szczegółowe informacje na temat konfiguracji, zobacz How to configure logins and users (Jak skonfigurować identyfikatory logowania i użytkowników).

Podstawową bazę danych można skalować w górę lub w dół do innego rozmiaru obliczeniowego (w tej samej warstwie usługi) bez odłączania żadnych serwerów geograficznych. Podczas skalowania w górę zalecamy najpierw skalowanie w górę pomocniczego, a następnie podstawowego obszaru geograficznego. Odwróć tę kolejność podczas skalowania w dół: najpierw przeprowadź skalowanie w dół podstawowego, a następnie pomocniczego obszaru geograficznego.

Ze względu na duże opóźnienie sieci rozległe replikacja geograficzna używa mechanizmu replikacji asynchronicznej. Replikacja asynchroniczna sprawia, że utrata danych jest nieunikniona w przypadku awarii podstawowej. Aby chronić krytyczne transakcje przed utratą danych, deweloper aplikacji może wywołać procedurę składowaną sp_wait_for_database_copy_sync bezpośrednio po zatwierdzeniu transakcji. Wywołanie sp_wait_for_database_copy_sync blokuje wątek wywołujący do momentu przesłania ostatniej zatwierdzonej transakcji i wzmocnionej w dzienniku transakcji pomocniczej bazy danych. Jednak nie czeka na ponowne odtworzenie przesyłanych transakcji (ponownego odtworzenia) w pomocniczej. sp_wait_for_database_copy_sync jest ograniczona do określonego łącza replikacji geograficznej. Każdy użytkownik z prawami połączenia do podstawowej bazy danych może wywołać tę procedurę.

Aby monitorować opóźnienie względem celu punktu odzyskiwania, użyj kolumny replication_lag_sec sys.dm_geo_replication_link_status w podstawowej bazie danych. Pokazuje opóźnienie w sekundach między transakcjami zatwierdzonymi na serwerze podstawowym i wzmocnionym do dziennika transakcji w pomocniczej. Jeśli na przykład opóźnienie wynosi jedną sekundę, oznacza to, że w przypadku awarii podstawowej w tej chwili nastąpi awaria, a zainicjowano przejście geograficzne w tryb failover, transakcje zatwierdzone w ciągu ostatniej sekundy zostaną utracone.

Aby zmierzyć opóźnienie w odniesieniu do zmian w podstawowej bazie danych, które zostały wzmocnione w pomocniczej lokalizacji geograficznej, porównaj last_commit czas na pomocniczym obszarze geograficznym z tą samą wartością na podstawowej.

Jak wspomniano wcześniej, aktywna replikacja geograficzna może być również zarządzana programowo przy użyciu języka T-SQL, Azure PowerShell i interfejsu API REST. W poniższych tabelach opisano zestaw dostępnych poleceń. Aktywna replikacja geograficzna obejmuje zestaw interfejsów API usługi Azure Resource Manager do zarządzania, w tym interfejs API REST usługi Azure SQL Database i Azure PowerShell poleceń cmdlet. Te interfejsy API obsługują kontrolę dostępu opartą na rolach platformy Azure (Azure RBAC). Aby uzyskać więcej informacji na temat implementowania ról dostępu, zobacz Kontrola dostępu oparta na rolach (RBAC) platformy Azure.

• Aby uzyskać przykładowe skrypty, zobacz:
  • Konfigurowanie i przechodzenie w tryb failover pojedynczej bazy danych przy użyciu aktywnej replikacji geograficznej.
  • Konfigurowanie i przełączanie bazy danych w tryb failover w puli przy użyciu aktywnej replikacji geograficznej.
• SQL Database obsługuje również grupy automatycznego trybu failover. Aby uzyskać więcej informacji, zobacz używanie grup automatycznego trybu failover.
• Aby zapoznać się z omówieniem ciągłości działania i scenariuszami, zobacz Omówienie ciągłości działania.
• Aby dowiedzieć się więcej o usłudze Azure SQL Database Hyperscale Geo-replica, zobacz Hiperskala Geo-replica
• Aby dowiedzieć się więcej o automatycznych kopiach zapasowych usługi Azure SQL Database, zobacz SQL Database automatyczne kopie zapasowe.
• Aby dowiedzieć się więcej na temat używania automatycznych kopii zapasowych na potrzeby odzyskiwania, zobacz Przywracanie bazy danych z kopii zapasowych zainicjowanych przez usługę.
• Aby dowiedzieć się więcej o wymaganiach dotyczących uwierzytelniania dla nowego serwera podstawowego i bazy danych, zobacz SQL Database zabezpieczenia po odzyskiwaniu po awarii.