Sdílet prostřednictvím

Dostupnost prostřednictvím redundance – Azure SQL Database

Platí pro:Azure SQL DatabaseSQL databáze v prostředí Fabric

Tento článek popisuje architekturu služby Azure SQL Database a databáze SQL ve Fabric, která dosahuje dostupnosti díky místní redundanci a vysoké dostupnosti díky zónové redundanci.

Overview

Azure SQL Database a SQL databáze v prostředí Fabric běží na nejnovější stabilní verzi databázového stroje SQL Server v operačním systému Windows se všemi příslušnými opravami. SQL Database automaticky zpracovává důležité úlohy údržby, jako jsou opravy, zálohy, upgrady modulu Windows a SQL a neplánované události, jako jsou základní hardware, software nebo selhání sítě. Pokud se databáze nebo elastický fond ve službě SQL Database opraví nebo dojde k přepnutí služeb po selhání, výpadky nebudou výrazné, pokud ve své aplikaci použijete logiku opakování. SQL Database se může rychle obnovit i za nejdůležitějších okolností a zajistit tak, aby vaše data byla vždy dostupná. Většina uživatelů si nevšimne, že se upgrady provádějí nepřetržitě.

Azure SQL Database ve výchozím nastavení dosahuje dostupnosti prostřednictvím místní redundance a zajišťuje, aby vaše databáze zvládla přerušení, například:

  • Operace správy iniciované zákazníkem, které vedou ke krátkému výpadku
  • Operace údržby služeb
  • Problémy s následujícími položkami:
    • rack, kde jsou umístěny servery, které pohánějí vaši službu
    • fyzický počítač, který je hostitelem databázového stroje SQL
  • Další problémy s databázovým strojem SQL
  • Další potenciální neplánované místní výpadky

Výchozí řešení dostupnosti je navržené tak, aby se zajistilo, že se potvrzená data nikdy neztratí kvůli selháním, že operace údržby mají minimální dopad na vaši úlohu a že databáze není jediným bodem selhání ve vaší softwarové architektuře.

Pokud ale chcete minimalizovat dopad na data v případě výpadku celé zóny, můžete dosáhnout vysoké dostupnosti povolením redundance zóny. Bez redundance zón dochází k převzetí služeb při selhání místně ve stejném datovém centru, což může vést k nedostupnosti databáze, dokud se nevyřeší výpadek – jediný způsob, jak provést zotavení, je prostřednictvím řešení zotavení po havárii, jako je geografické převzetí služeb při selhání prostřednictvím aktivní geografické replikace, skupin převzetí služeb při selhání nebo geografického obnovení geograficky redundantního zálohování. Další informace najdete v přehledu kontinuity podnikových procesů.

Existují tři modely architektury dostupnosti:

  • Model vzdáleného úložiště založený na oddělení výpočetních prostředků a úložiště Model vzdáleného úložiště spoléhá na dostupnost a spolehlivost úrovně vzdáleného úložiště. Tato architektura cílí na rozpočtově orientované podnikové aplikace, které mohou tolerovat určité snížení výkonu během údržby.
  • Místní model úložiště založený na clusteru procesů databázového stroje. Model místního úložiště spoléhá na skutečnost, že vždy existuje kvorum dostupných uzlů databázového stroje. Tato architektura cílí na klíčové aplikace s vysokým výkonem vstupně-výstupních operací, vysokou rychlostí transakcí a zaručuje minimální dopad na výkon vaší úlohy během údržby.
  • Model Hyperscale , který používá distribuovaný systém vysoce dostupných komponent, jako jsou výpočetní uzly, stránkovací servery, služba protokolů a trvalé úložiště. Každá komponenta podporující databázi Hyperscale poskytuje vlastní redundanci a odolnost proti selháním. Výpočetní uzly, stránkovací servery a služba protokolu běží v Azure Service Fabric, která řídí stav jednotlivých komponent a podle potřeby provádí převzetí služeb při selhání dostupným uzlům, které jsou v pořádku. Trvalé úložiště využívá Azure Storage s nativními možnostmi vysoké dostupnosti a redundance. Další informace najdete v tématu Architektura Hyperscale.

V rámci každého ze tří modelů dostupnosti sql Database podporuje možnosti místní redundance a zónové redundance. Místní redundance zajišťuje odolnost v rámci datacentra, zatímco zónová redundance zvyšuje odolnost tím, že chrání před výpadky zóny dostupnosti v rámci oblasti.

Následující tabulka uvádí možnosti dostupnosti na základě úrovní služby:

Úroveň služby Model vysoké dostupnosti Místně redundantní dostupnost Zónově redundantní dostupnost
Obecné účely (vCore) Vzdálené úložiště Yes Yes
Kritické pro podnikání (vCore) Místní úložiště Yes Yes
Hyperscale (virtuální jádro) Hyperscale Yes Yes
Základní (DTU) Vzdálené úložiště Yes No
Standard (DTU) Vzdálené úložiště Yes No
Premium (DTU) Místní úložiště Yes Yes

Další informace o konkrétních smlouvách SLA pro různé úrovně služeb najdete v SLA pro Azure SQL Database.

Dostupnost prostřednictvím místní redundance

Místně redundantní dostupnost je založená na ukládání databáze do místně redundantního úložiště (LRS), které kopíruje data třikrát v rámci jednoho datacentra v primární oblasti a chrání vaše data v případě místního selhání, jako je například malá síť nebo selhání napájení. LRS je možnost redundance s nejnižšími náklady a nabízí nejnižší odolnost v porovnání s jinými možnostmi. Pokud dojde k rozsáhlé havárii, jako je požár nebo záplava v rámci oblasti, můžou být všechny repliky účtu úložiště využívajícího LRS ztraceny nebo neobnovitelné. Pokud chcete data dál chránit při použití možnosti místně redundantní dostupnosti, zvažte použití odolnější možnosti úložiště pro zálohy databáze. To neplatí pro databáze Hyperscale, kde se stejné úložiště používá pro datové soubory i zálohy.

Místně redundantní dostupnost je k dispozici pro všechny databáze ve všech úrovních služby a také cíl bodu obnovení (RPO), což značí, že ztráta dat je nulová.

Úrovně služby Basic, Standard a Pro obecné účely

Úrovně služeb Basic a Standard nákupního modelu založeného na DTU a úroveň služby Pro obecné účely nákupního modelu založeného na virtuálních jádrech používají model dostupnosti vzdáleného úložiště pro bezserverové i zřízené výpočetní prostředky. Následující diagram znázorňuje uzly s oddělenými výpočetními a úložnými vrstvami.

Diagram znázorňující oddělení výpočetních prostředků a úložiště

Model dostupnosti vzdáleného úložiště obsahuje dvě vrstvy:

  • Bezstavová výpočetní vrstva, která spouští proces databázového enginu a obsahuje pouze přechodná a uložená data v mezipaměti, jako jsou databáze tempdb a model na připojeném SSD disku, a mezipaměť plánu, vyrovnávací paměť a columnstore fond v paměti. Tento bezstavový uzel je provozován službou Azure Service Fabric, jež inicializuje databázový stroj, kontroluje zdraví uzlu a v případě potřeby provádí převzetí služeb při selhání do jiného uzlu.

  • Stavová datová vrstva s databázovými soubory (.mdf a .ldf) uloženými ve službě Azure Blob Storage. Azure Blob Storage má integrované funkce dostupnosti dat a redundance. Zaručuje, že každý záznam v souboru protokolu nebo stránce datového souboru se zachová i v případě, že dojde k chybovému ukončení procesu databázového stroje.

Při každém upgradu databázového stroje nebo operačního systému nebo zjištění selhání přesune Azure Service Fabric proces bezstavového databázového stroje do jiného bezstavového výpočetního uzlu s dostatečnou bezplatnou kapacitou. Data ve službě Azure Blob Storage zůstávají bez změny při přesunu a soubory dat a protokolů se připojí k nově inicializovanému procesu databázového enginu. Tento proces zaručuje vysokou dostupnost, ale při přechodu může docházet k určitému snížení výkonu, protože nový proces databázového stroje začíná studenou mezipamětí.

Úroveň služby Premium a Kritická pro podnikání

Úroveň služby Premium nákupního modelu založeného na DTU a úroveň služby Business Critical modelu založeného na virtuálních jádrech využívají model dostupnosti místního úložiště, který integruje výpočetní zdroje (proces databázového stroje) a úložiště (místně připojené SSD) na jednom uzlu. Vysoká dostupnost se dosahuje replikací výpočetních prostředků i úložiště do dalších uzlů.

Diagram clusteru uzlů databázového stroje

Podkladové databázové soubory (.mdf/.ldf) jsou umístěné v připojeném úložišti SSD, aby poskytovaly pro vaši úlohu velmi nízkou latenci vstupně-výstupních operací. Vysoká dostupnost se implementuje pomocí technologie podobné skupinám dostupnosti AlwaysOn SQL Serveru. Cluster obsahuje jednu primární repliku, která je přístupná pro úlohy zákazníků se čtením a zápisem, a až tři sekundární repliky (výpočetní prostředky a úložiště) obsahující kopie dat. Primární replika neustále odesílá změny do sekundárních replik v daném pořadí a zajišťuje, aby data byla spolehlivě uložena na dostatečném počtu sekundárních replik před potvrzením každé transakce. Tento proces zaručuje, že pokud z nějakého důvodu dojde k selhání primární repliky nebo čtecí sekundární repliky, vždy existuje plně synchronizovaná replika pro převzetí při selhání. Převzetí služeb při selhání je inicializováno službou Azure Service Fabric. Jakmile se sekundární replika stane novou primární replikou, vytvoří se další sekundární replika, která zajistí, že cluster bude mít dostatečný počet replik pro zachování kvóra. Po dokončení převzetí služeb při selhání se připojení Azure SQL automaticky přesměrují na novou primární repliku nebo čitelnou sekundární repliku.

Model dostupnosti místního úložiště navíc zahrnuje možnost přesměrovat připojení Azure SQL jen pro čtení na jednu ze sekundárních replik. Tato funkce se nazývá Čtení s rozložením zatížení. Poskytuje 100% dodatečné výpočetní kapacity bez dalších poplatků, aby převedla operace jen pro čtení, jako jsou analytické úlohy, z primární repliky.

Hyperskálová úroveň služby

Architektura úrovně služby Hyperscale je popsaná v architektuře distribuovaných funkcí, která obsahuje podrobný diagram.

Model dostupnosti v Hyperscale zahrnuje čtyři vrstvy:

  • Bezstavová výpočetní vrstva, která spouští procesy databázového stroje a obsahuje pouze přechodná data a data uložená v mezipaměti, jako je například neodkrývající mezipaměť RBPEX, databáze tempdb a model atd. na připojeném disku SSD, a dále pak plán mezipaměti, vyrovnávací fond a columnstore fond v paměti. Tato bezstavová vrstva zahrnuje primární výpočetní repliku a volitelně i několik sekundárních výpočetních replik, které mohou v případě selhání sloužit jako cíle převzetí služeb.

  • Bezstavová vrstva úložiště vytvořená stránkovými servery. Tato vrstva je distribuovaný úložný modul pro procesy databázového stroje běžící na výpočetních replikách. Každý stránkový server obsahuje pouze přechodná data a data uložená v mezipaměti, například pokrytí mezipaměti RBPEX na připojeném disku SSD a datové stránky uložené v mezipaměti v paměti. Každý server stránky má zdvojený server stránky v uspořádání aktivně-aktivně, aby poskytoval vyrovnávání zatížení, redundanci a vysokou dostupnost.

  • Vrstva úložiště stavového transakčního protokolu vytvořená výpočetním uzlem, který spouští proces služby protokolu, cílovou zónu transakčního protokolu a dlouhodobé úložiště transakčních protokolů. Cílová zóna a dlouhodobé úložiště používají Službu Azure Storage, která poskytuje dostupnost a redundanci transakčního protokolu a zajišťuje odolnost dat pro potvrzené transakce.

  • Stavová vrstva úložiště dat se soubory databáze (.mdf/.ndf), které jsou uložené ve službě Azure Storage a aktualizují se stránkovými servery. Tato vrstva používá funkce dostupnosti dat a redundance služby Azure Storage. Zaručuje, že každá stránka v datovém souboru se zachová i v případě, že dojde k chybě procesů v jiných vrstvách architektury Hyperscale nebo pokud výpočetní uzly selžou.

Výpočetní uzly ve všech vrstvách Hyperscale běží v Azure Service Fabric, které řídí stav každého uzlu a podle potřeby provádí převzetí služeb při selhání dostupným uzlům, které jsou v pořádku.

Další informace o vysoké dostupnosti v Hyperscale najdete v tématu Vysoká dostupnost databáze v Hyperscale.

Vysoká dostupnost prostřednictvím zónové redundance

Pro zónově redundantní nasazení používá Azure SQL Database počet zón dostupnosti Azure v dané oblasti, dvě nebo více běžně tři. Výpočetní a úložné komponenty zahrnují dvě nebo tři zóny, které azure SQL vybral pro zajištění optimální odolnosti, v samostatných fyzických umístěních s nezávislým napájením, chlazením a sítěmi. Azure SQL automaticky vybere počet zón na základě regionální dostupnosti a optimalizace služeb. Vaše nasazení nebude používat méně zón, než je nutné pro odolnost.

Dostupnost se zónovou redundancí je k dispozici pro databáze v úrovních služeb Business Critical, General Purpose a Hyperscale nákupního modelu založeného na virtuálních jádrech a pouze v úrovni služby Premium nákupního modelu založeného na DTU – úrovně služeb Basic a Standard nepodporují zónovou redundanci.

Zatímco každá úroveň služby implementuje zónovou redundanci odlišně, všechny implementace zajišťují cíl bodu obnovení (RPO) s nulovou ztrátou potvrzených dat při převzetí služeb při selhání, pokud jedna zóna dostupnosti v rámci oblasti Azure přestane být k dispozici.

Azure SQL automaticky optimalizuje umístění zóny pro vaše nasazení. Všechny konfigurace zón dostupnosti, které používají dvě nebo tři zóny, poskytují stejné záruky smlouvy SLA s vysokou dostupností a odolností.

Úroveň služby pro obecné účely

Konfigurace zónové redundance pro úroveň služby Obecného použití je nabízena jak pro bezserverové, tak i zřízené výpočetní kapacity pro databáze v nákupním modelu virtuálních jader. Tato konfigurace využívá zóny dostupnosti Azure k replikaci databází napříč několika fyzickými umístěními v rámci oblasti Azure. Výběrem zónově redundance můžete vytvořit novou a stávající bezserverovou a zřízenou jednoúčelovou databázi a elastické fondy odolné vůči mnohem větší sadě selhání, včetně katastrofických výpadků datacentra bez jakýchkoli změn logiky aplikace.

Zónově redundantní konfigurace pro úroveň Pro obecné účely má dvě vrstvy:

  • Stavová datová vrstva se soubory databáze (.mdf/.ldf), které jsou uložené v ZRS (zónově redundantní úložiště). Pomocí ZRS se soubory dat a protokolů synchronně kopírují napříč několika zónami dostupnosti Azure v primární oblasti. Jedná se o dvě nebo tři zóny, které vybere Azure SQL pro zajištění optimální odolnosti.
  • Bezstavová výpočetní vrstva, která spouští proces sqlservr.exe a obsahuje pouze přechodná data a data uložená v mezipaměti, jako jsou databáze tempdb a model na připojeném SSD, a plán mezipaměti, fond vyrovnávací paměti a fond columnstore v paměti. Tento bezstavový uzel provozuje Azure Service Fabric, který inicializuje sqlservr.exe, řídí stav uzlu a v případě potřeby provádí převzetí služeb při selhání do jiného uzlu. Pro zónově redundantní bezserverové a zřízené databáze obecného účelu jsou uzly s volnou kapacitou snadno dostupné v jiných zónách dostupnosti pro případ převzetí služeb při selhání.

Zónově redundantní verze architektury vysoké dostupnosti pro úroveň služby Pro obecné účely je znázorněna následujícími diagramy v oblasti se dvěma zónami nebo třemi zónami:

Oblast se dvěma zónami Oblast se třemi zónami
Diagram zónově redundantní konfigurace pro obecné účely v oblasti se dvěma zónami Diagram zónově redundantní konfigurace pro obecné účely v oblasti se třemi zónami

  • Při zřizování výpočetních prostředků napříč dvěma zónami dostupnosti:

    • Zálohování a úložiště se stále synchronizují mezi třemi zónami dostupnosti v dané oblasti.
    • Zónově redundantní úložiště se jako vždy synchronizuje napříč třemi zónami dostupnosti.

  • Při zřizování výpočetních prostředků napříč třemi zónami dostupnosti:

    • Zálohování a úložiště se synchronizují mezi třemi zónami dostupnosti v dané oblasti.

  • Všechny oblasti Azure, které mají zónu dostupnosti, podporují zónově redundantní obecné databáze.

  • Pro zónově redundantní dostupnost je ve vybraných oblastech aktuálně možné zvolit jiné časové období údržby než výchozí. Další informace najdete v tématu Dostupnost okna údržby v jednotlivých oblastech pro Azure SQL Database.

  • Zónová redundance není dostupná pro úrovně služby Basic a Standard v nákupním modelu DTU.

Úrovně služeb Premium a Renatní pro podnikání

Pokud je pro úroveň služby Premium nebo Business Critical povolená redundance zón, repliky se umístí do různých dostupnostních zón ve stejném regionu. Aby se zabránilo jedinému bodu selhání, řídicí prstenec je také duplikován napříč několika zónami jako tři přístupové prstence (GW). Směrování na konkrétní okruh brány řídí Azure Traffic Manager. Vzhledem k tomu, že zónově redundantní konfigurace v úrovních služeb Premium nebo Business Critical používá své stávající repliky k umístění do různých zón dostupnosti, můžete ji povolit bez dalších poplatků. Výběrem zónově redundantní konfigurace můžete vytvořit Premium nebo Business Critical databáze a elastické fondy, které jsou odolné vůči mnohem větší sadě selhání, včetně katastrofických výpadků datacentra, aniž by bylo potřeba cokoliv měnit v logice aplikace. Na zónově redundantní konfiguraci můžete také převést všechny existující databáze Premium nebo Business Critical, nebo elastické fondy.

Zónově redundantní verze architektury vysoké dostupnosti pro úroveň služby Pro důležité obchodní informace je znázorněna následujícími diagramy v oblasti se dvěma zónami nebo třemi zónami:

Oblast se dvěma zónami Oblast se třemi zónami
Diagram zónově redundantní konfigurace pro úroveň služby Pro důležité obchodní informace v oblasti se dvěma zónami Diagram zónově redundantní konfigurace pro úroveň služby Pro důležité obchodní informace v oblasti se třemi zónami

  • Při zřizování výpočetních prostředků napříč dvěma zónami dostupnosti:

    • Pro úložiště pro důležité obchodní informace se místně redundantní úložiště dostupnosti pro soubory dat a protokolů synchronizuje mezi dvěma zónami dostupnosti.
    • V případě jiných úrovní se zálohování a úložiště synchronizují napříč třemi zónami dostupnosti v dané oblasti.
    • Zónově redundantní úložiště se jako vždy synchronizuje napříč třemi zónami dostupnosti.

  • Při zřizování výpočetních prostředků napříč třemi zónami dostupnosti:

    • Pro úložiště pro důležité obchodní informace se místně redundantní úložiště dostupnosti pro soubory dat a protokolů synchronizuje napříč třemi zónami dostupnosti.
    • V případě jiných úrovní se zálohování a úložiště synchronizují napříč třemi zónami dostupnosti v dané oblasti.

Při konfiguraci databází Premium nebo Business Critical s zónovou redundancí zvažte následující skutečnosti:

Hyperskálová úroveň služby

Pro databáze ve vrstvě služby Hyperscale je možné nakonfigurovat zónovou redundanci. Další informace najdete v tématu Vytvoření zónově redundantní databáze Hyperscale.

Povolení této konfigurace zajišťuje odolnost na úrovni zóny prostřednictvím replikace napříč Zóny dostupnosti pro všechny vrstvy Hyperscale. Výběrem zónově redundance můžete zajistit odolnost databází Hyperscale vůči mnohem větší sadě selhání, včetně katastrofických výpadků datacentra, bez jakýchkoli změn logiky aplikace.

Zónově redundantní dostupnost se podporuje v samostatných databázích Hyperscale i v elastických fondech Hyperscale. Další informace najdete v tématu Přehled elastických fondů Hyperscale ve službě Azure SQL Database.

Následující diagramy znázorňují základní architekturu zónově redundantních databází Hyperscale v oblasti se dvěma zónami nebo třemi zónami:

Oblast se dvěma zónami Oblast se třemi zónami
Diagram znázorňující základní architekturu dvou zónově redundantních databází Hyperscale Diagram znázorňující základní architekturu tří zónově redundantních databází Hyperscale

  • Při zřizování výpočetních prostředků napříč dvěma zónami dostupnosti:

    • Zálohování a úložiště se synchronizují mezi třemi zónami dostupnosti v dané oblasti.
    • Zónově redundantní úložiště se jako vždy synchronizuje napříč třemi zónami dostupnosti.

  • Při zřizování výpočetních prostředků napříč třemi zónami dostupnosti:

    • Zálohování a úložiště se synchronizují mezi třemi zónami dostupnosti v dané oblasti.

Berte v úvahu následující omezení:

  • Všechny oblasti Azure, které mají zónu dostupnosti, podporují zónově redundantní databázi Hyperscale.

  • Zónově redundantní konfiguraci je možné zadat pouze během vytváření databáze. Toto nastavení nelze po zřízení prostředku změnit. Pomocí kopírování databáze, obnovení k určitému bodu v čase nebo vytvoření geografické repliky aktualizujte zónově redundantní konfiguraci pro existující databázi Hyperscale. Pokud používáte jednu z těchto možností aktualizace, a pokud je cílová databáze v jiné oblasti než zdrojová, nebo pokud se redundance úložiště zálohování databáze cíle liší od zdrojové databáze, bude operace kopírování probíhat jako operace o velikosti dat.

  • Pro zónově redundantní dostupnost je ve vybraných oblastech aktuálně možné zvolit jiné časové období údržby než výchozí. Další informace najdete v tématu Dostupnost okna údržby v jednotlivých oblastech pro Azure SQL Database.

  • Při migraci databáze na Hyperscale pomocí webu Azure Portal aktuálně není možné určit redundanci zón. Redundanci zón je ale možné zadat pomocí Azure PowerShellu, Azure CLI nebo rozhraní REST API při migraci existující databáze z jiné úrovně služby Azure SQL Database na Hyperscale. Tady je příklad s Azure CLI:

    az sql db update --resource-group "myRG" --server "myServer" --name "myDB" --edition Hyperscale --zone-redundant true`

  • K povolení zónově redundantní nebo geograficky zónově redundantní úložiště zálohování pro Hyperscale se vyžaduje alespoň jedna výpočetní replika s vysokou dostupností.

Redundantní dostupnost zón databáze

V Azure SQL Database je server logický konstruktor, který funguje jako centrální bod správy pro kolekci databází. Na úrovni serveru můžete spravovat přihlášení, metodu ověřování, pravidla brány firewall, pravidla auditování, zásady detekce hrozeb a skupiny převzetí služeb při selhání. Data související s některými z těchto funkcí, jako jsou přihlášení a pravidla brány firewall, jsou uložená v master databázi. Podobně se data některých zobrazení dynamické správy, například sys.resource_stats, ukládají také do master databáze.

Při vytvoření databáze s zónově redundantní konfigurací na logickém serveru master se databáze přidružená k serveru automaticky vytvoří i zónově redundantní. Tím se zajistí, že v zónovém výpadku zůstanou aplikace používající databázi nedotčené, protože funkce závislé na master databázi, jako jsou přihlášení a pravidla brány firewall, jsou stále dostupné. Způsob, jak udělat databázi zónově redundantní, je asynchronní proces, který bude na pozadí chvíli trvat, než se dokončí.

Pokud žádná z databází na serveru není zónově redundantní nebo když vytváříte prázdný server, master databáze přidružená k serveru není zónově redundantní. Pokud chcete migrovat službu Azure SQL Database tak, aby používala redundanci zón, postupujte podle kroků v tématu Migrace služby Azure SQL Database do podpory zón dostupnosti.

Pokud chcete zkontrolovat ZoneRedundant vlastnost master databáze, použijte Azure PowerShell nebo Azure CLI nebo kroky rozhraní REST API v části Ověření stavu zóny dostupnosti služby Azure SQL Database.

Testování odolnosti proti chybám aplikace

Vysoká dostupnost je základní součástí platformy SQL Database, která transparentně funguje pro vaši databázovou aplikaci. Uvědomujeme si však, že možná budete chtít otestovat, jak by operace automatického převzetí služeb při selhání zahájené během plánovaných nebo neplánovaných událostí ovlivnily aplikaci před jejím nasazením do produkčního prostředí. Převzetí služeb při selhání můžete ručně aktivovat voláním speciálního rozhraní API pro restartování databáze nebo elastického fondu. V případě zónově redundantní bezserverové databáze nebo zřízené databáze pro obecné účely nebo elastického fondu by volání rozhraní API vedlo k přesměrování připojení klientů k nové primární zóně dostupnosti, která se liší od zóny dostupnosti původní primární. Kromě testování toho, jak převzetí služeb při selhání ovlivní stávající relace databáze, můžete také ověřit, jestli dojde ke změně výkonu end-to-end vlivem změn latence sítě. Vzhledem k tomu, že operace restartování je rušivá a velký počet z nich může natížit platformu, je pro každou databázi nebo elastický fond povolený každých 15 minut pouze jedno volání převzetí služeb při selhání.

Další informace o vysoké dostupnosti a zotavení po havárii služby Azure SQL Database najdete v kontrolním seznamu Vysoká dostupnost a zotavení po havárii – Azure SQL Database.

Převzetí služeb při selhání je možné zahájit pomocí PowerShellu, rozhraní REST API nebo Azure CLI:

Typ nasazení PowerShell REST API Azure CLI Portál (Preview)
Database Invoke-AzSqlDatabaseFailover Přepnutí databáze az rest se může použít k vyvolání volání rozhraní REST API z Azure CLI. Nastavení > Údržba > Restart
Elastický fond Invoke-AzSqlElasticPoolFailover Převzetí služeb při selhání elastického fondu az rest se může použít k vyvolání volání rozhraní REST API z Azure CLI. Nastavení > Údržba > Restart

Important

Příkaz převzetí služeb při selhání není k dispozici pro čitelné sekundární repliky databází Hyperscale.

Conclusion

Azure SQL Database nabízí integrované řešení s vysokou dostupností, které je hluboce integrované s platformou Azure. Je závislý na Service Fabric pro detekci a obnovení selhání, na úložišti objektů Blob v Azure pro ochranu dat a na Zónách Dostupnosti kvůli vyšší odolnosti proti chybám. Kromě toho SQL Database používá technologii skupiny dostupnosti Always On ze SQL Serveru k synchronizaci dat a zotavení po selhání. Kombinace těchto technologií umožňuje aplikacím plně realizovat výhody modelu smíšeného úložiště a podporuje nejnáročnější smlouvy SLA.

Další krok

Migrace služby Azure SQL Database do podpory zón dostupnosti

Související obsah

  • Last updated on