Wysoka dostępność Azure SQL Database i SQL Managed Instance

DOTYCZY: Azure SQL Database Azure SQL Managed Instance

Celem architektury wysokiej dostępności w Azure SQL Database i SQL Managed Instance jest zagwarantowanie, że baza danych jest uruchomiona co najmniej 99,99% czasu bez obaw o wpływ operacji konserwacji i awarii. Aby uzyskać więcej informacji na temat określonej umowy SLA dla różnych warstw, zapoznaj się z umową SLA dotyczącą Azure SQL Database i umowy SLA dla Azure SQL Managed Instance.

Platforma Azure automatycznie obsługuje krytyczne zadania obsługi, takie jak stosowanie poprawek, kopie zapasowe, Windows i Azure SQL uaktualnienia oraz nieplanowane zdarzenia, takie jak awarie sprzętu, oprogramowania lub sieci. Jeśli podstawowa baza danych w Azure SQL Database zostanie poprawiona lub przełączona w tryb failover, przestój nie jest zauważalny w przypadku korzystania z logiki ponawiania prób w aplikacji. SQL Database i SQL Managed Instance mogą szybko odzyskiwać nawet w najbardziej krytycznych okolicznościach, dzięki czemu dane są zawsze dostępne.

Rozwiązanie wysokiej dostępności ma na celu zapewnienie, że zatwierdzone dane nigdy nie zostaną utracone z powodu awarii, operacje konserwacji nie wpłyną na obciążenie, a baza danych nie będzie pojedynczym punktem awarii w architekturze oprogramowania. Nie ma okien konserwacji ani przestojów, które powinny wymagać zatrzymania obciążenia podczas uaktualniania lub konserwacji bazy danych.

Istnieją dwa modele architektury wysokiej dostępności:

  • Standardowy model dostępności oparty na rozdzieleniu zasobów obliczeniowych i magazynu. Opiera się on na wysokiej dostępności i niezawodności zdalnej warstwy magazynowania. Ta architektura jest przeznaczona dla aplikacji biznesowych ukierunkowanych na budżet, które mogą tolerować pewne pogorszenie wydajności podczas działań konserwacyjnych.
  • Premium modelu dostępności opartego na klastrze procesów aparatu bazy danych. Opiera się on na tym, że zawsze istnieje kworum dostępnych węzłów aparatu bazy danych. Ta architektura jest przeznaczona dla aplikacji o krytycznym znaczeniu z wysoką wydajnością operacji we/wy, wysoką szybkością transakcji i gwarantuje minimalny wpływ na wydajność obciążenia podczas działań konserwacyjnych.

SQL Database i SQL Managed Instance działają w najnowszej stabilnej wersji aparatu bazy danych SQL Server i systemu operacyjnego Windows, a większość użytkowników nie zauważy, że uaktualnienia są wykonywane w sposób ciągły.

Podstawowa, Standardowa i Ogólnego przeznaczenia lokalnie nadmiarowa dostępność

Warstwy usług Podstawowa, Standardowa i Ogólnego przeznaczenia używają standardowej architektury dostępności zarówno dla zasobów obliczeniowych bezserwerowych, jak i aprowizowanych. Na poniższej ilustracji przedstawiono cztery różne węzły z oddzielonymi warstwami obliczeniowymi i magazynowymi.

Separation of compute and storage

Standardowy model dostępności obejmuje dwie warstwy:

  • Bezstanowa warstwa obliczeniowa, która uruchamia sqlservr.exe proces i zawiera tylko dane przejściowe i buforowane, takie jak TempDB, bazy danych modelu na dołączonym dysku SSD oraz pamięć podręczna planu, pula buforów i pula magazynu kolumn w pamięci. Ten bezstanowy węzeł jest obsługiwany przez usługę Azure Service Fabric, która inicjuje sqlservr.exe, kontroluje kondycję węzła i wykonuje przejście w tryb failover do innego węzła w razie potrzeby.
  • Warstwa danych stanowych z plikami bazy danych (mdf/.ldf), które są przechowywane w usłudze Azure Blob Storage. Usługa Azure Blob Storage ma wbudowaną funkcję dostępności i nadmiarowości danych. Gwarantuje to, że każdy rekord w pliku dziennika lub stronie w pliku danych zostanie zachowany nawet w przypadku sqlservr.exe awarii procesu.

Za każdym razem, gdy aparat bazy danych lub system operacyjny zostanie uaktualniony lub zostanie wykryty błąd, usługa Azure Service Fabric przeniesie proces bezstanowy sqlservr.exe do innego bezstanowego węzła obliczeniowego z wystarczającą ilością wolnej pojemności. Dane w usłudze Azure Blob Storage nie mają wpływu na przeniesienie, a pliki danych/dziennika są dołączane do nowo zainicjowanego sqlservr.exe procesu. Ten proces gwarantuje dostępność na 99,99%, ale duże obciążenie może spowodować obniżenie wydajności podczas przejścia, ponieważ nowy sqlservr.exe proces rozpoczyna się od zimnej pamięci podręcznej.

Ogólnego przeznaczenia strefowo nadmiarowa dostępność w warstwie usługi

Konfiguracja strefowo nadmiarowa dla warstwy usługi ogólnego przeznaczenia jest oferowana zarówno dla zasobów obliczeniowych bezserwerowych, jak i aprowizowanych. Ta konfiguracja korzysta z usługi Azure Strefy dostępności do replikowania baz danych w wielu lokalizacjach fizycznych w regionie świadczenia usługi Azure. Wybierając nadmiarowość strefową, możesz wprowadzić nowe i istniejące bezserwerowe, aprowizowane pojedyncze bazy danych ogólnego przeznaczenia i elastyczne pule odporne na znacznie większy zestaw awarii, w tym katastrofalne awarie centrum danych, bez żadnych zmian logiki aplikacji.

Konfiguracja strefowo nadmiarowa dla warstwy ogólnego przeznaczenia ma dwie warstwy:

  • Warstwa danych stanowych z plikami bazy danych (mdf/.ldf), które są przechowywane w magazynie strefowo nadmiarowym ZRS. Za pomocą magazynu ZRS pliki danych i dzienników są synchronicznie kopiowane w trzech fizycznie odizolowanych strefach dostępności platformy Azure.
  • Bezstanowa warstwa obliczeniowa, która uruchamia proces sqlservr.exe i zawiera tylko przejściowe i buforowane dane, takie jak TempDB, bazy danych modelu na dołączonym dysku SSD oraz pamięć podręczna planu, pula buforów i pula magazynów kolumn w pamięci. Ten bezstanowy węzeł jest obsługiwany przez usługę Azure Service Fabric, która inicjuje sqlservr.exe, kontroluje kondycję węzła i wykonuje przejście w tryb failover do innego węzła w razie potrzeby. W przypadku baz danych bezserwerowych strefowo nadmiarowych i aprowizowanych baz danych ogólnego przeznaczenia węzły o pojemności zapasowej są łatwo dostępne w innych Strefy dostępności na potrzeby trybu failover.

Wersja strefowo nadmiarowa architektury wysokiej dostępności dla warstwy usługi ogólnego przeznaczenia jest pokazana na poniższym diagramie:

Zone redundant configuration for general purpose

Ważne

W warstwie ogólnego przeznaczenia konfiguracja strefowo nadmiarowa jest ogólnie dostępna w następujących regionach: Europa Zachodnia, Europa Północna, Zachodnie stany USA 2 i Francja Środkowa. Jest to wersja zapoznawcza w następujących regionach: Wschodnie stany USA, Wschodnie stany USA 2, Azja Południowo-Wschodnia, Australia Wschodnia, Japonia Wschodnia i Południowe Zjednoczone Królestwo.

Uwaga

Konfiguracja strefowo nadmiarowa nie jest dostępna w SQL Managed Instance. W SQL Database ta funkcja jest dostępna tylko wtedy, gdy wybrano sprzęt Gen5.

Premium i Krytyczne dla działania firmy lokalnie nadmiarowa dostępność warstwy usług

Premium i warstwy usług Krytyczne dla działania firmy korzystają z modelu dostępności Premium, który integruje zasoby obliczeniowe (sqlservr.exeproces) i magazyn (lokalnie dołączony dysk SSD) w jednym węźle. Wysoka dostępność jest osiągana przez replikowanie zarówno zasobów obliczeniowych, jak i magazynu do dodatkowych węzłów tworzących klaster z trzema do czterech węzłów.

Cluster of database engine nodes

Podstawowe pliki bazy danych (mdf/.ldf) są umieszczane w dołączonym magazynie SSD w celu zapewnienia bardzo małego opóźnienia operacji we/wy do obciążenia. Wysoka dostępność jest implementowana przy użyciu technologii podobnej do SQL Server zawsze włączonych grup dostępności. Klaster zawiera jedną replikę podstawową dostępną dla obciążeń klienta odczytu i zapisu oraz maksymalnie trzy repliki pomocnicze (obliczenia i magazyn) zawierające kopie danych. Węzeł podstawowy stale wypycha zmiany do węzłów pomocniczych i zapewnia, że dane są utrwalane do co najmniej jednej repliki pomocniczej przed zatwierdzeniem każdej transakcji. Ten proces gwarantuje, że jeśli węzeł podstawowy ulegnie awarii z jakiegokolwiek powodu, zawsze istnieje w pełni zsynchronizowany węzeł, aby przejść w tryb failover. Tryb failover jest inicjowany przez usługę Azure Service Fabric. Gdy replika pomocnicza stanie się nowym węzłem podstawowym, zostanie utworzona inna replika pomocnicza, aby upewnić się, że klaster ma wystarczającą liczbę węzłów (zestaw kworum). Po zakończeniu pracy w trybie failover połączenia Azure SQL są automatycznie przekierowywane do nowego węzła podstawowego.

W związku z dodatkową korzyścią model dostępności w warstwie Premium obejmuje możliwość przekierowywania połączeń tylko do odczytu Azure SQL z jedną z replik pomocniczych. Ta funkcja jest nazywana skalowaniem odczytu w poziomie. Zapewnia ona 100% dodatkowej pojemności obliczeniowej bez dodatkowych opłat za operacje tylko do odczytu, takie jak obciążenia analityczne, z repliki podstawowej.

Premium i Krytyczne dla działania firmy strefowo nadmiarowa dostępność warstwy usług

Domyślnie klaster węzłów dla modelu dostępności Premium jest tworzony w tym samym centrum danych. Wraz z wprowadzeniem usługi Azure Strefy dostępności SQL Database można umieścić różne repliki bazy danych Krytyczne dla działania firmy do różnych stref dostępności w tym samym regionie. Aby wyeliminować pojedynczy punkt awarii, pierścień sterowania jest również duplikowany w wielu strefach jako trzy pierścienie bramy (GW). Routing do określonego pierścienia bramy jest kontrolowany przez Azure Traffic Manager (ATM). Ponieważ konfiguracja strefowo nadmiarowa w warstwach usług Premium lub Krytyczne dla działania firmy nie tworzy dodatkowej nadmiarowości bazy danych, można ją włączyć bez dodatkowych kosztów. Wybierając konfigurację strefowo nadmiarową, można wprowadzić Premium lub Krytyczne dla działania firmy bazy danych odporne na znacznie większy zestaw awarii, w tym katastrofalne awarie centrum danych bez żadnych zmian logiki aplikacji. Możesz również przekonwertować wszystkie istniejące Premium lub Krytyczne dla działania firmy bazy danych lub pule na konfigurację strefowo nadmiarową.

Ze względu na to, że bazy danych strefowo nadmiarowe mają repliki w różnych centrach danych z pewną odległością między nimi, zwiększone opóźnienie sieci może zwiększyć czas zatwierdzania, a tym samym wpłynąć na wydajność niektórych obciążeń OLTP. Zawsze można wrócić do konfiguracji pojedynczej strefy, wyłączając ustawienie nadmiarowości strefy. Ten proces jest operacją online podobną do regularnego uaktualniania warstwy usług. Na końcu procesu baza danych lub pula jest migrowana z pierścienia strefowo nadmiarowego do pierścienia pojedynczej strefy lub odwrotnie.

Ważne

Ta funkcja nie jest dostępna w SQL Managed Instance. W SQL Database w przypadku korzystania z warstwy Krytyczne dla działania firmy konfiguracja strefowo nadmiarowa jest dostępna tylko wtedy, gdy wybrano sprzęt Gen5. Aby uzyskać aktualne informacje o regionach, w których obsługiwane są strefowo nadmiarowe bazy danych, zobacz Obsługa usług według regionów.

Wersja strefowo nadmiarowa architektury wysokiej dostępności jest pokazana na poniższym diagramie:

high availability architecture zone redundant

Warstwa usługi Hiperskala lokalnie nadmiarowa

Architektura warstwy usługi Hiperskala jest opisana w temacie Architektura funkcji rozproszonych i jest obecnie dostępna tylko dla SQL Database, a nie SQL Managed Instance.

Hyperscale functional architecture

Model dostępności w warstwie Hiperskala obejmuje cztery warstwy:

  • Bezstanowa warstwa obliczeniowa, która uruchamia sqlservr.exe procesy i zawiera tylko przejściowe i buforowane dane, takie jak niewskładnikowa pamięć podręczna RBPEX, baza danych TempDB, baza danych modelu itp. na dołączonym dysku SSD oraz pamięć podręczna planu, pula buforów i pula magazynu kolumn w pamięci. Ta warstwa bezstanowa zawiera podstawową replikę obliczeniową i opcjonalnie wiele pomocniczych replik obliczeniowych, które mogą służyć jako obiekty docelowe trybu failover.
  • Warstwa magazynu bezstanowego utworzona przez serwery stron. Ta warstwa jest rozproszonym aparatem magazynu dla sqlservr.exe procesów uruchomionych w replikach obliczeniowych. Każdy serwer stron zawiera tylko dane przejściowe i buforowane, takie jak pokrycie pamięci podręcznej RBPEX na dołączonym dysku SSD i strony danych buforowane w pamięci. Każdy serwer stron ma sparowany serwer stron w konfiguracji aktywne-aktywne w celu zapewnienia równoważenia obciążenia, nadmiarowości i wysokiej dostępności.
  • Warstwa magazynu dziennika transakcji stanowych utworzona przez węzeł obliczeniowy z uruchomionym procesem usługi Dziennik, strefą docelową dziennika transakcji i długoterminowego magazynu dziennika transakcji. Strefa docelowa i długoterminowy magazyn korzystają z usługi Azure Storage, która zapewnia dostępność i nadmiarowość dziennika transakcji, zapewniając trwałość danych dla zatwierdzonych transakcji.
  • Warstwa magazynu danych stanowych z plikami bazy danych (mdf/.ndf), które są przechowywane w usłudze Azure Storage i są aktualizowane przez serwery stron. Ta warstwa używa funkcji dostępności danych i nadmiarowości platformy Azure Storage. Gwarantuje to, że każda strona w pliku danych zostanie zachowana, nawet jeśli procesy w innych warstwach architektury hiperskala uległy awarii lub jeśli węzły obliczeniowe kończą się niepowodzeniem.

Węzły obliczeniowe we wszystkich warstwach hiperskala są uruchamiane na platformie Azure Service Fabric, co steruje kondycją każdego węzła i wykonuje przejścia w tryb failover do dostępnych węzłów w dobrej kondycji w razie potrzeby.

Aby uzyskać więcej informacji na temat wysokiej dostępności w warstwie Hiperskala, zobacz Wysoka dostępność bazy danych w warstwie Hiperskala.

Dostępność strefowo nadmiarowa warstwy usługi Hiperskala (wersja zapoznawcza)

Nadmiarowość strefy dla warstwy usługi Azure SQL Database Hiperskala jest teraz dostępna w publicznej wersji zapoznawczej. Włączenie tej konfiguracji zapewnia odporność na poziomie strefy przez replikację między Strefy dostępności dla wszystkich warstw hiperskala. Wybierając strefową nadmiarowość, można zapewnić odporność baz danych w warstwie Hiperskala na znacznie większy zestaw awarii, w tym katastrofalne awarie centrum danych bez żadnych zmian logiki aplikacji.

Rozważ następujące ograniczenia:

  • Obecnie obsługiwane są tylko następujące regiony platformy Azure: Południowe Zjednoczone Królestwo, Brazylia Południowa, Zachodnie stany USA 2, Japonia Wschodnia, Europa Północna, Azja Południowo-Wschodnia, Kanada Środkowa, Środkowe stany USA, Południowo-środkowe stany USA, Francja Środkowa, Australia Wschodnia, Niemcy Zachodnie, Azja Wschodnia, Korea Środkowa, Norwegia Wschodnia i Zachodnie stany USA 3.
  • Konfigurację strefowo nadmiarową można określić tylko podczas tworzenia bazy danych. Tego ustawienia nie można zmodyfikować po aprowizacji zasobu. Użyj funkcji kopiowania bazy danych, przywracania do punktu w czasie lub utwórz replikę geograficzną , aby zaktualizować konfigurację strefowo nadmiarową dla istniejącej bazy danych w warstwie Hiperskala. W przypadku korzystania z jednej z tych opcji aktualizacji, jeśli docelowa baza danych znajduje się w innym regionie niż źródło lub jeśli nadmiarowość magazynu kopii zapasowej bazy danych różni się od źródłowej bazy danych, operacja kopiowania będzie rozmiarem operacji na danych. Ponadto w przypadku korzystania z jednej z tych opcji aktualizacji docelowa baza danych nie będzie mieć historycznych danych kopii zapasowej ze źródłowej bazy danych na potrzeby przywracania do punktu w czasie.
  • Nazwane repliki nie są obsługiwane.
  • Obsługiwana jest tylko kopia zapasowa strefowo nadmiarowa .
  • Obsługiwany jest tylko sprzęt gen5.
  • Przywracanie geograficzne nie jest obecnie obsługiwane.
  • Nadmiarowość strefy nie może być obecnie określona podczas migrowania istniejącej bazy danych z innej warstwy usługi Azure SQL Database do warstwy Hiperskala.

Ważne

Co najmniej 1 replika obliczeniowa o wysokiej dostępności i użycie strefowo nadmiarowego magazynu kopii zapasowych jest wymagane do włączenia konfiguracji strefowo nadmiarowej dla warstwy Hiperskala.

Tworzenie strefowo nadmiarowej bazy danych w warstwie Hiperskala

Użyj Azure PowerShell lub interfejsu wiersza polecenia platformy Azure, aby utworzyć strefowo nadmiarową bazę danych w warstwie Hiperskala. Upewnij się, że masz najnowszą wersję interfejsu API, aby zapewnić obsługę najnowszych zmian.

-ZoneRedundant Określ parametr, aby włączyć nadmiarowość strefy dla bazy danych w warstwie Hiperskala przy użyciu Azure PowerShell. Należy określić bazę danych z co najmniej 1 repliką o wysokiej dostępności i strefowo nadmiarowym magazynem kopii zapasowych.

Aby włączyć nadmiarowość stref przy użyciu programu Azure PowerShell, użyj następującego przykładowego polecenia:

New-AzSqlDatabase -ResourceGroupName "ResourceGroup01" -ServerName "Server01" -DatabaseName "Database01" `
    -Edition "Hyperscale" -HighAvailabilityReplicaCount 1 -ZoneRedundant -BackupStorageRedundancy Zone

Tworzenie strefowo nadmiarowej bazy danych w warstwie Hiperskala przez utworzenie repliki geograficznej

Aby utworzyć istniejącą strefę bazy danych w warstwie Hiperskala, użyj Azure PowerShell lub interfejsu wiersza polecenia platformy Azure, aby utworzyć strefowo nadmiarową bazę danych w warstwie Hiperskala przy użyciu aktywnej replikacji geograficznej. Replika geograficzna może znajdować się w tym samym lub innym regionie co istniejąca baza danych w warstwie Hiperskala.

-ZoneRedundant Określ parametr, aby włączyć nadmiarowość strefy dla pomocniczej bazy danych w warstwie Hiperskala. Należy określić pomocniczą bazę danych z co najmniej 1 repliką o wysokiej dostępności i strefowo nadmiarowym magazynem kopii zapasowych.

Aby utworzyć strefowo nadmiarową bazę danych przy użyciu Azure PowerShell, użyj następującego przykładowego polecenia:

New-AzSqlDatabaseSecondary -ResourceGroupName "myResourceGroup" -ServerName $sourceserver -DatabaseName "databaseName" -PartnerResourceGroupName "myPartnerResourceGroup" -PartnerServerName $targetserver -PartnerDatabaseName "zoneRedundantCopyOfMySampleDatabase” -ZoneRedundant -BackupStorageRedundancy Zone -HighAvailabilityReplicaCount 1

Tworzenie strefowo nadmiarowej bazy danych w warstwie Hiperskala przez utworzenie kopii bazy danych

Aby utworzyć istniejącą strefę bazy danych w warstwie Hiperskala, użyj Azure PowerShell lub interfejsu wiersza polecenia platformy Azure, aby utworzyć strefowo nadmiarową bazę danych w warstwie Hiperskala przy użyciu kopii bazy danych. Kopia bazy danych może znajdować się w tym samym lub innym regionie co istniejąca baza danych w warstwie Hiperskala.

Określ parametr, -ZoneRedundant aby włączyć nadmiarowość strefy dla kopii bazy danych w warstwie Hiperskala. Należy określić kopię bazy danych co najmniej 1 replikę o wysokiej dostępności i strefowo nadmiarowy magazyn kopii zapasowych.

Aby utworzyć strefowo nadmiarową bazę danych przy użyciu Azure PowerShell, użyj następującego przykładowego polecenia:

New-AzSqlDatabaseCopy -ResourceGroupName "myResourceGroup" -ServerName $sourceserver -DatabaseName "databaseName" -CopyResourceGroupName "myCopyResourceGroup" -CopyServerName $copyserver -CopyDatabaseName "zoneRedundantCopyOfMySampleDatabase” -ZoneRedundant -BackupStorageRedundancy Zone 

Przyspieszone odzyskiwanie bazy danych (ADR)

Przyspieszone odzyskiwanie bazy danych (ADR) to nowa funkcja aparatu bazy danych, która znacznie poprawia dostępność bazy danych, zwłaszcza w przypadku długotrwałych transakcji. Reguła ADR jest obecnie dostępna dla usługi Azure SQL Database, Azure SQL Managed Instance i Azure Synapse Analytics.

Testowanie odporności błędów aplikacji

Wysoka dostępność to podstawowa część usługi SQL Database i platformy SQL Managed Instance, która działa w sposób przejrzysty dla aplikacji bazy danych. Jednak wiemy, że można sprawdzić, jak automatyczne operacje trybu failover inicjowane podczas planowanych lub nieplanowanych zdarzeń wpływają na aplikację przed wdrożeniem jej w środowisku produkcyjnym. Możesz ręcznie wyzwolić tryb failover, wywołując specjalny interfejs API w celu ponownego uruchomienia bazy danych, elastycznej puli lub wystąpienia zarządzanego. W przypadku strefowo nadmiarowej bezserwerowej lub aprowizowanej Ogólnego przeznaczenia bazy danych lub elastycznej puli wywołanie interfejsu API spowodowałoby przekierowanie połączeń klienta do nowej bazy podstawowej w strefie dostępności innej niż strefa dostępności starego podstawowego. Dlatego oprócz testowania wpływu trybu failover na istniejące sesje bazy danych możesz również sprawdzić, czy zmienia on kompleksową wydajność ze względu na zmiany opóźnienia sieci. Ponieważ operacja ponownego uruchamiania jest natrętna i duża ich liczba może przeciążyć platformę, tylko jedno wywołanie trybu failover jest dozwolone co 15 minut dla każdej bazy danych, elastycznej puli lub wystąpienia zarządzanego.

Tryb failover można zainicjować przy użyciu programu PowerShell, interfejsu API REST lub interfejsu wiersza polecenia platformy Azure:

Typ wdrożenia PowerShell Interfejs API REST Interfejs wiersza polecenia platformy Azure
baza danych Invoke-AzSqlDatabaseFailover Tryb failover bazy danych polecenie az rest może służyć do wywoływania wywołania interfejsu API REST z interfejsu wiersza polecenia platformy Azure
Pula elastyczna Invoke-AzSqlElasticPoolFailover Tryb failover elastycznej puli polecenie az rest może służyć do wywoływania wywołania interfejsu API REST z interfejsu wiersza polecenia platformy Azure
Wystąpienie zarządzane Invoke-AzSqlInstanceFailover Wystąpienia zarządzane — tryb failover polecenie az sql mi failover może służyć do wywoływania wywołania interfejsu API REST z interfejsu wiersza polecenia platformy Azure

Ważne

Polecenie trybu failover nie jest dostępne dla czytelnych replik pomocniczych baz danych w warstwie Hiperskala.

Podsumowanie

Azure SQL Database i Azure SQL Managed Instance oferują wbudowane rozwiązanie o wysokiej dostępności, które jest głęboko zintegrowane z platformą Azure. Jest on zależny od Service Fabric na potrzeby wykrywania i odzyskiwania awarii, w usłudze Azure Blob Storage na potrzeby ochrony danych oraz od Strefy dostępności w celu zapewnienia wyższej odporności na uszkodzenia (jak wspomniano wcześniej w dokumencie, nie dotyczy jeszcze Azure SQL Managed Instance). Ponadto SQL Database i SQL Managed Instance korzystać z technologii zawsze włączonej grupy dostępności z wystąpienia SQL Server na potrzeby replikacji i trybu failover. Połączenie tych technologii pozwala aplikacjom w pełni wykorzystać zalety modelu magazynu mieszanego i obsługiwać najbardziej wymagające umowy SLA.

Następne kroki