Sdílet prostřednictvím

Přehled skupin převzetí služeb při selhání a osvědčené postupy (Azure SQL Database)

  • Článek

Platí pro:Azure SQL Database

Funkce skupin pro převzetí služeb při selhání umožňuje spravovat replikaci a převzetí služeb při selhání některých nebo všech databází z logického serveru do logického serveru v jiné oblasti. Tento článek obsahuje přehled funkce skupiny pro převzetí služeb při výpadku, včetně osvědčených postupů a doporučení pro její použití se službou Azure SQL Database.

Pokud chcete tuto funkci začít používat, přečtěte si Jak konfigurovat skupinu převzetí služeb při selhání pro Azure SQL Database.

Poznámka:

Tento článek se zabývá skupinami převzetí služeb při selhání pro Azure SQL Database. Pro více informací o službě Azure SQL Managed Instance vizte Přehled a osvědčené postupy skupin převzetí služeb při selhání – Azure SQL Managed Instance.

Další informace o zotavení po havárii azure SQL Database najdete v tomto videu:

Přehled

Funkce skupin zotavení po selhání umožňuje spravovat replikaci a zotavení po selhání databází do jiné Azure oblasti. Můžete zvolit všechny nebo podmnožinu uživatelských databází na logickém serveru, které se mají replikovat na jiný logický server. Je to deklarativní abstrakce nad aktivní funkcí geografické replikace , která je navržená tak, aby zjednodušila nasazení a správu geograficky replikovaných databází ve velkém měřítku.

Informace o geografickém převzetí služeb při selhání a RTO najdete v přehledu provozní kontinuity.

Přesměrování koncového bodu

Skupiny převzetí služeb při selhání poskytují naslouchací koncové body pro čtení a zápis i jen pro čtení, které se během geografických převzetí služeb při selhání nezmění. Po geo-failoveru nemusíte měnit řetězec připojení aplikace, protože připojení se automaticky směrují na aktuální primární. Geografické převzetí při selhání přepne všechny sekundární databáze ve skupině do primární role. Po dokončení geografického převzetí se záznam DNS automaticky aktualizuje a přesměruje koncové body do nového regionu.

Snižování zátěže úloh jen pro čtení

Pokud chcete snížit provoz do primárních databází, můžete také použít sekundární databáze ve skupině převzetí služeb při selhání k přesměrování zátěže úloh jen pro čtení. Pomocí naslouchadla ve verzi jen pro čtení směrujte provoz do čitelné sekundární databáze.

Obnovení aplikace

Pokud chcete dosáhnout plné kontinuity podnikových procesů, je přidání redundance regionální databáze pouze součástí řešení. Obnovení aplikace (služby) po závažném selhání vyžaduje obnovení všech komponent, které tvoří službu a všechny závislé služby. Mezi tyto komponenty patří klientský software (například prohlížeč s vlastním JavaScriptem), webové front-endy, úložiště a DNS. Je důležité, aby všechny komponenty byly odolné vůči stejným chybám a byly k dispozici v rámci cíle doby obnovení (RTO) vaší aplikace. Proto potřebujete identifikovat všechny závislé služby a porozumět zárukám a možnostem, které poskytují. Pak musíte provést odpovídající kroky, abyste zajistili, že vaše služba bude fungovat během převzetí služeb při selhání služeb, na kterých závisí.

Zásady převzetí služeb při selhání

Skupiny převzetí služeb při selhání podporují dvě zásady převzetí služeb při selhání:

  • Spravovaná zákazníkem (doporučeno) – Zákazníci mohou provést převzetí služeb při selhání, když zaznamenají neočekávaný výpadek, který ovlivňuje jednu nebo více databází ve skupině pro převzetí služeb při selhání. Pokud používáte nástroje příkazového řádku, jako je PowerShell, Azure CLI nebo rest API, hodnota zásad převzetí služeb při selhání pro spravovanou zákazníkem je manual.
  • Spravováno Microsoftem – V případě rozsáhlého výpadku, který ovlivní primární oblast, zahájí Microsoft převzetí služeb všech dotčených skupin, jejichž zásady převzetí jsou nakonfigurovány jako spravované Microsoftem. Převzetí služeb při selhání spravované Microsoftem se nespustí pro jednotlivé skupiny převzetí služeb při selhání ani pro podmnožinu skupin převzetí služeb při selhání v regionu. Pokud používáte nástroje příkazového řádku, jako je PowerShell, Azure CLI nebo rozhraní REST API, hodnota zásad převzetí služeb při selhání pro spravované Microsoftem je automatic.

Každá zásada převzetí služeb při selhání má jedinečnou sadu případů použití a odpovídající očekávání týkající se rozsahu převzetí služeb při selhání a ztráty dat, jak shrnuje následující tabulka:

Zásady převzetí služeb při selhání Rozsah převzetí služeb při selhání Případ použití Potenciální ztráta dat
Spravovaná zákazníkem
(Doporučeno)		 Skupiny převzetí služeb při selhání Jedna nebo více databází ve skupinách pro převzetí služeb při selhání je ovlivněno výpadkem a stanou se nedostupnými. Můžete zvolit přepnutí při selhání. Ano
Spravováno společností Microsoft Všechny skupiny převzetí služeb při selhání v oblasti Rozsáhlý výpadek v datacentru, zóně dostupnosti nebo oblasti způsobuje nedostupnost databází a tým služby Microsoft Azure SQL se rozhodne aktivovat vynucené převzetí služeb při selhání.
Tuto možnost použijte pouze v případě, že chcete delegovat odpovědnost za zotavení po havárii na Microsoft a aplikace je tolerantní k RTO (výpadku) nejméně jedné hodiny nebo více.		 Ano

Zákazníkem spravované

Ve výjimečných případech nemusí integrovaná dostupnost nebo vysoká dostupnost stačit ke zmírnění výpadku a databáze ve skupině převzetí služeb při selhání můžou být nedostupné po dobu, která není přijatelná pro smlouvu o úrovni služeb (SLA) aplikací využívajících databáze. Databáze můžou být nedostupné kvůli lokalizovaným problémům, které mají vliv jenom na několik databází, nebo můžou být na úrovni datacentra, zóny dostupnosti nebo oblasti. V každém z těchto případů můžete k obnovení provozní kontinuity zahájit vynucené převzetí služeb při selhání.

Nastavení zásad převzetí služeb při selhání na zajišťovanou zákazníkem se důrazně doporučuje, protože vám zajistí kontrolu nad tím, kdy zahájit převzetí služeb při selhání a obnovit provozní kontinuitu. Převzetí služeb můžete zahájit, když zaznamenáte neočekávaný výpadek, který ovlivňuje jednu či více databází ve skupině převzetí služeb.

Spravováno společností Microsoft

Díky zásadám selhání řízeným Microsoftem je odpovědnost za zotavení po havárii přenesena na službu Azure SQL. Aby služba Azure SQL iniciovala vynucené přepnutí při selhání, musí být splněny následující podmínky:

  • Výpadek datacentra, zóny dostupnosti nebo na úrovni oblasti způsobený přírodní katastrofou, změnami konfigurace, chybami softwaru nebo selháním hardwarových komponent, který ovlivní mnoho databází v dané oblasti.
  • Období odkladu vypršelo. Vzhledem k tomu, že ověření rozsahu a zmírnění rizik závisí na lidských akcích, nedá se období odkladu nastavit pod jednu hodinu.

Po splnění těchto podmínek služba Azure SQL zahájí vynucené převzetí služeb při selhání pro všechny skupiny převzetí služeb při selhání v oblasti, ve které jsou nastavené zásady převzetí služeb při selhání spravované Microsoftem.

Důležité

K otestování a implementaci plánu zotavení po havárii použijte zásady převzetí služeb při selhání spravované zákazníkem. Nespoléhejte se na převzetí služeb při selhání spravované společností Microsoft, které může být provedeno společností Microsoft pouze za extrémních okolností. U všech skupin převzetí služeb při selhání v oblasti, ve které jsou nastavené zásady převzetí služeb při selhání spravované Microsoftem, se zahájí převzetí služeb při selhání. Nejde ho zahájit pro jednotlivé skupiny převzetí služeb při selhání. Pokud potřebujete možnost selektivního převzetí řízení nad skupinou při selhání, použijte zásady pro převzetí řízení spravované zákazníkem.

Zásady převzetí služeb při selhání nastavte na spravované Microsoftem jenom v těchto případech:

  • Chcete delegovat odpovědnost za zotavení po havárii do služby Azure SQL.
  • Aplikace je tolerantní vůči nedostupnosti vaší databáze nejméně po dobu jedné hodiny nebo více.
  • Je přijatelné aktivovat vynucené převzetí služeb při selhání po uplynutí období odkladu, protože skutečný čas vynuceného převzetí služeb při selhání se může výrazně lišit.
  • Je přijatelné, aby všechny databáze ve skupině pro případ selhání přešly do režimu vysoké dostupnosti bez ohledu na konfiguraci zónové redundance nebo stavu dostupnosti. Přestože databáze nakonfigurované pro redundanci zón jsou odolné vůči zónovým selháním a nemusí být ovlivněny výpadkem, budou stále převedeny v případě selhání, pokud jsou součástí skupiny převzetí služeb při selhání se zásadami spravovanými Microsoftem.
  • Je možné vynutit přepnutí databází ve skupině převzetí služeb při selhání bez ohledu na závislost aplikace na jiných službách nebo komponentách Azure, což může způsobit snížení výkonu nebo nedostupnost aplikace.
  • Je přijatelné, aby došlo k neznámé ztrátě dat, protože přesný okamžik vynuceného přepnutí nelze řídit a nezohledňuje stav synchronizace sekundárních databází.
  • Všechny primární a sekundární databáze ve skupině převzetí služeb a všechny relace geografické replikace mají stejnou úroveň služby, výpočetní úroveň (předem alokovanou nebo bezserverovou) a velikost výpočetních prostředků (DTU nebo virtuální jádra). Pokud úroveň služby (SLO) všech databází neodpovídají, zásady failoveru budou nakonec aktualizovány ze služby spravované Microsoftem na spravované zákazníkem ve službě Azure SQL.

Když společnost Microsoft aktivuje převzetí služeb při selhání, přidá se do protokolu aktivit Azure Monitor položka pro název operace Převzetí služeb při selhání skupiny pro převzetí služeb při selhání Azure SQL. Položka obsahuje název skupiny pro převzetí služeb při selhání v části Prostředek, a text Událost iniciovaná zobrazuje jeden spojovník (-) k označení, že převzetí inicioval Microsoft. Tyto informace najdete také na stránce Protokol aktivit nového primárního serveru či instance na Azure Portálu.

Terminologie a možnosti

  • Skupina převzetí služeb při selhání (SPS)

    Skupina převzetí služeb při selhání je pojmenovaná skupina databází spravovaných jedním logickým serverem v Azure , která může převzít služby při selhání jako jednotka do jiné oblasti Azure v případě, že všechny nebo některé primární databáze nebudou kvůli výpadku v primární oblasti nedostupné.

    Důležité

    Název skupiny pro převzetí služeb při selhání musí být globálně jedinečný v rámci domény .database.windows.net.

  • Servery

    Některé nebo všechny uživatelské databáze na logickém serveru mohou být umístěny ve skupině pro převzetí služeb při selhání. Server také podporuje více skupin převzetí služeb při selhání na jednom serveru.

  • Primární

    Logický server, který je hostitelem primárních databází ve skupině převzetí služeb při selhání.

  • Sekundární

    Sekundární databáze ve skupině pro převzetí služeb při selhání jsou hostovány logickým serverem. Sekundární oblast nemůže být ve stejné oblasti Azure jako primární.

  • Převzetí služeb při selhání (bez ztráty dat)

    Převzetí služeb při selhání provádí úplnou synchronizaci dat mezi primární a sekundární databází, než sekundární přepne na primární roli. Tím se zaručuje žádná ztráta dat. Převzetí služeb při selhání je možné pouze tehdy, když je primární systém přístupný. Převzetí služeb při selhání se používá v následujících scénářích:

    • Provozujte cvičné zotavení po havárii (DR) v produkčním prostředí, pokud není přijatelná ztráta dat.
    • Přemístění úlohy do jiné oblasti
    • Po zmírnění výpadku vraťte pracovní zátěž do primární oblasti (navrácení služeb po obnovení).

  • Vynucené přepnutí při selhání (potenciální ztráta dat)

    Vynucené převzetí služeb při selhání okamžitě přepne sekundární roli na primární roli, aniž by čekalo na nedávné změny, které se rozšíří z primární role. Výsledkem této operace může být potenciální ztráta dat. Vynucené převzetí služeb při selhání se používá jako metoda obnovení během výpadků, když primární server není přístupný. Po zmírnění výpadku se starý primární server automaticky znovu připojí a stane se novou sekundární. K převzetí služeb při selhání může dojít, aby se repliky vrátily do svých původních primárních a sekundárních rolí.

  • Období odkladu se ztrátou dat

    Vzhledem k tomu, že se data replikují do sekundární lokace pomocí asynchronní replikace, může vynucené převzetí služeb při selhání skupin se zásadami převzetí spravovanými společností Microsoft způsobit ztrátu dat. Zásady převzetí služeb při selhání můžete přizpůsobit tak, aby odrážely odolnost vaší aplikace vůči ztrátě dat. Konfigurací GracePeriodWithDataLossHours můžete řídit, jak dlouho služba Azure SQL čeká před zahájením vynuceného převzetí služeb při selhání, což může vést ke ztrátě dat.

  • Přidání jednotlivých databází do skupiny převzetí služeb

    Do stejné skupiny převzetí služeb při selhání můžete umístit několik samostatných databází na stejný logický server. Pokud do skupiny převzetí služeb při selhání přidáte jednu databázi, automaticky vytvoří sekundární databázi se stejnou edicí a velikostí výpočetních prostředků na sekundárním serveru, který jste zadali při vytvoření skupiny převzetí služeb při selhání. Pokud přidáte databázi, která už má sekundární databázi na sekundárním serveru, skupina zdědí propojení pro geografickou replikaci. Když přidáte databázi, která už má sekundární databázi na serveru, který není součástí skupiny převzetí služeb při selhání, vytvoří se na sekundárním serveru nová sekundární databáze.

    Důležité

    • Ujistěte se, že sekundární logický server nemá databázi se stejným názvem, pokud se nejedná o existující sekundární databázi.
    • Pokud databáze obsahuje objekty OLTP v paměti, primární databáze a sekundární databáze geografické repliky musí mít odpovídající úrovně služby, protože objekty OLTP v paměti se nacházejí v paměti. Nižší úroveň služby v databázi geografické repliky může vést k problémům s nedostatkem paměti. Pokud k tomu dojde, geografická replika může selhat obnovit databázi, což způsobí nedostupnost sekundární databáze spolu s objekty OLTP v paměti v sekundární geografické oblasti. To může také způsobit, že převzetí služeb při selhání nebude úspěšné. Abyste tomu předešli, ujistěte se, že úroveň služby sekundární databáze odpovídá úrovni služby primární databáze. Aktualizace na úrovni služby mohou zahrnovat operace týkající se velikosti dat a jejich dokončení může chvíli trvat.

  • Přidání databází z elastického fondu do skupiny převzetí služeb při selhání

    Do elastického fondu můžete umístit všechny nebo několik databází do té stejné skupiny převzetí služeb při selhání. Pokud je primární databáze v elastickém fondu, sekundární se automaticky vytvoří v elastickém fondu se stejným názvem (sekundární fond). Musíte zajistit, aby sekundární server obsahoval elastický fond se stejným přesným názvem a dostatečnou volnou kapacitou pro hostování sekundárních databází, které budou vytvořeny skupinou převzetí služeb při selhání. Pokud do fondu přidáte databázi, která už má sekundární databázi ve sekundárním fondu, skupina zdědí tento odkaz geografické replikace. Když přidáte databázi, která už má sekundární databázi na serveru, který není součástí skupiny převzetí služeb při selhání, vytvoří se v sekundárním fondu nová sekundární databáze.

  • Naslouchací proces pro čtení i zápis pro skupinu převzetí služeb při selhání

    Záznam CNAME DNS, který odkazuje na aktuální primární záznam. Vytvoří se automaticky při vytvoření skupiny převzetí služeb při selhání a umožní úloze pro čtení a zápis transparentně se znovu připojit k primárnímu serveru, když se primární server změní po převzetí služeb. Při vytvoření skupiny převzetí služeb při selhání na serveru se záznam DNS CNAME pro adresu URL naslouchacího procesu vytvoří jako <fog-name>.database.windows.net. Po selhání se záznam DNS automaticky aktualizuje, aby se naslouchač přesměroval na nový primární.

  • Naslouchací jen pro čtení pro skupinu převzetí služeb při selhání

    Záznam CNAME DNS, který odkazuje na aktuální sekundární server. Vytvoří se automaticky při vytvoření skupiny převzetí služeb při selhání a umožňuje, aby se úloha SQL jen pro čtení transparentně připojila k sekundárnímu serveru, když se sekundární server po převzetí služeb při selhání změní. Při vytvoření skupiny převzetí služeb při selhání na serveru se záznam DNS CNAME pro adresu URL posluchače vytvoří jako <fog-name>.secondary.database.windows.net. Ve výchozím nastavení je převzetí služeb při selhání naslouchacího procesu jen pro čtení zakázané, protože zajišťuje, že výkon primárního serveru nebude ovlivněn, když je sekundární server offline. To ale také znamená, že se relace jen pro čtení nebudou moct připojit, dokud se druhý server neobnoví. Pokud nemůžete tolerovat výpadky relací jen pro čtení a můžete použít primární server pro přenosy jen pro čtení i zápis na úkor potenciálního snížení výkonu primárního serveru, můžete povolit přepnutí pro naslouchací proces jen pro čtení konfigurací vlastnosti AllowReadOnlyFailoverToPrimary. V takovém případě se provoz ve stavu pouze pro čtení automaticky přesměruje na primární systém, pokud sekundární není k dispozici.

    Poznámka:

    Tato AllowReadOnlyFailoverToPrimary vlastnost se projeví jenom v případě, že je povolena zásada převzetí služeb při selhání spravovaná Microsoftem a vynucené převzetí služeb při selhání bylo spuštěno. V takovém případě, pokud je vlastnost nastavena na True, bude nový primární server obsluhovat jak relace pro čtení a zápis, tak relace pouze pro čtení.

  • Více skupin převzetí služeb při selhání

    Pro stejnou dvojici serverů můžete nakonfigurovat více skupin převzetí služeb při selhání, abyste mohli řídit rozsah geografických převzetí služeb při selhání. Každá skupina selhává samostatně. Pokud je vaše aplikace pro jednotlivé databáze nasazená ve více oblastech a používá elastické fondy, můžete pomocí této funkce kombinovat primární a sekundární databáze v jednotlivých fondech. Tímto způsobem můžete snížit dopad výpadku jenom na některé databáze tenantů.

Architektura skupiny převzetí služeb při selhání

Skupina pro převzetí služeb při selhání ve službě Azure SQL Database může obsahovat jednu nebo více databází, které obvykle používá stejná aplikace. Na primárním serveru musí být nakonfigurovaná skupina převzetí služeb při selhání, která ji připojí k sekundárnímu serveru v jiné oblasti Azure. Skupina převzetí služeb při selhání může zahrnovat všechny nebo pouze některé databáze na primárním serveru. Následující diagram znázorňuje typickou konfiguraci geograficky redundantní cloudové aplikace, která využívá více databází v rámci skupiny pro převzetí služeb při selhání.

Diagram znázorňuje typickou konfiguraci geograficky redundantní cloudové aplikace využívající více databází a skupiny převzetí služeb při selhání.

Při navrhování služby s ohledem na kontinuitu podnikových procesů postupujte podle obecných pokynů a osvědčených postupů popsaných v tomto článku. Při konfiguraci skupiny převzetí služeb při selhání se ujistěte, že na sekundárním serveru je správně nastaveno ověřování a síťový přístup, aby fungovaly po geografickém failoveru, když se sekundární server stane novým primárním serverem. Podrobnosti najdete v tématu Konfigurace a správa zabezpečení služby Azure SQL Database pro geografické obnovení nebo převzetí služeb při selhání. Další informace najdete v tématu Návrh globálně dostupných služeb pomocí služby Azure SQL Database a geografického obnovení pro službu Azure SQL Database.

Použití spárovaných oblastí

Při vytváření skupiny převzetí služeb při selhání mezi primárním a sekundárním serverem použijte spárované oblasti, protože tyto skupiny mají ve spárovaných oblastech lepší výkon ve srovnání s nepárovanými oblastmi.

Azure SQL Database obecně neaktualizuje spárované oblasti současně podle postupů bezpečného nasazení. Není ale možné předpovědět, která oblast se nejprve upgraduje, takže pořadí nasazení není zaručené. Někdy se váš primární server upgraduje jako první a někdy jako druhý.

Pokud máte nakonfigurovanou geografickou replikaci nebo skupiny pro převzetí služeb při selhání pro databáze, které nejsou v souladu s párováním oblastí Azure, použijte pro primární a sekundární databáze odlišné harmonogramy údržby. Můžete například vybrat časové období údržby v týdnu pro sekundární databázi a časové období víkendové údržby pro primární databázi.

Počáteční seeding

Při přidávání databází nebo elastických fondů do skupiny převzetí služeb při selhání dochází k počáteční fázi před zahájením replikace dat. Počáteční fáze seedingu je nejdelší a nejnákladnější operace. Po dokončení počátečního seedování se data synchronizují a pak se replikují pouze následné změny dat. Doba potřebná k dokončení počátečního osazení závisí na velikosti vašich dat, počtu replikovaných databází, zatížení primárních databází a rychlosti síťového propojení mezi primární a sekundární databází. Za normálních okolností je možná rychlost přenosu až 500 GB za hodinu pro SQL databázi. Nasezení se provádí pro všechny databáze paralelně.

Počet databází ve skupině převzetí služeb při selhání

Počet databází ve skupině převzetí služeb při selhání přímo ovlivňuje dobu trvání jak běžných, tak i vynucených operací převzetí služeb při selhání.

  • Během převzetí při selhání (označovaném také jako plánované převzetí při selhání) zajistíme, že všechny primární databáze budou plně synchronizovány se sekundárními databázemi a dosáhnou připraveného stavu. Aby se zabránilo zahlcení řídicí roviny, jsou databáze připravené v dávkách. Proto důrazně doporučujeme omezit počet databází ve skupině převzetí služeb při selhání.
  • V případě vynuceného převzetí služeb při selhání je přípravná fáze urychlena, protože synchronizace dat se neinicializuje. Pokud chcete dosáhnout rychlejších a předvídatelných dob převzetí služeb při selhání, může být užitečné zachovat počet databází ve skupině převzetí služeb při selhání na nižší počet.

K převzetí více databází při selhání využijte více skupin převzetí služeb.

Jednu nebo více skupin převzetí služeb při selhání je možné vytvořit mezi dvěma servery v různých oblastech (primární a sekundární servery). Každá skupina může obsahovat jednu nebo několik databází obnovených jako jednotku pro případ, že všechny nebo některé primární databáze nebudou kvůli výpadku v primární oblasti nedostupné. Vytvoření skupiny převzetí služeb při selhání vytvoří geograficky sekundární databáze, které mají stejný cíl služby jako primární databáze. Pokud do skupiny převzetí služeb při selhání přidáte existující vztah geografické replikace, ujistěte se, že je sekundární instance nakonfigurovaná se stejnou úrovní služby a výpočetní kapacitou jako primární.

Použijte posluchače pro čtení a zápis (primární)

Pro úlohy čtení i zápisu použijte v připojovacím řetězci <fog-name>.database.windows.net jako název serveru. Připojení se automaticky směrují na primární server. Tento název se po přepnutí na záložní systém nezmění. Všimněte si, že převzetí služeb při selhání zahrnuje aktualizaci záznamu DNS, aby se připojení klientů přesměrovala na nový primární pouze po aktualizaci DNS mezipaměti klienta. Hodnota TTL (Time to Live) primárního a sekundárního záznamu naslouchacího serveru DNS je 30 sekund.

Použijte posluchač pouze pro čtení (sekundární)

Pokud máte logicky izolované úlohy jen pro čtení, které jsou odolné vůči latenci dat, můžete je spustit v sekundární geografické oblasti. Pro relace jen pro čtení použijte v připojovacím řetězci <fog-name>.secondary.database.windows.net jako název serveru. Připojení jsou automaticky směrována na sekundární geografický uzel. Doporučuje se také označit záměr čtení ve připojovacím řetězci pomocí ApplicationIntent=ReadOnly.

V úrovních služeb Premium, Business Critical a Hyperscale podporuje SQL Database použití replik jen pro čtení k odlehčení pracovního zatížení dotazů jen pro čtení pomocí parametru ApplicationIntent=ReadOnly v připojovacím řetězci. Pokud jste nakonfigurovali geografickou sekundární oblast, můžete se pomocí této funkce připojit k replice jen pro čtení v primárním umístění nebo v sekundárním geografickém umístění:

Pokud se chcete připojit k replice jen pro čtení v sekundárním umístění, použijte ApplicationIntent=ReadOnly a <fog-name>.secondary.database.windows.net.

Potenciální snížení výkonu po přepnutí

Typická aplikace Azure používá více služeb Azure a skládá se z několika součástí. Převzetí služeb při selhání skupiny se aktivuje na základě stavu samotné databázové služby Azure SQL. Výpadky nemusí mít vliv na ostatní služby Azure v primární oblasti a jejich součásti můžou být v tomto regionu stále dostupné. Po přepnutí primárních databází do sekundární oblasti (DR) se může zvýšit latence mezi závislými součástmi. Abyste se vyhnuli dopadu vyšší latence na výkon aplikace, zajistěte redundanci všech komponent aplikace v regionu zotavení po havárii, postupujte podle těchto pokynů pro zabezpečení sítě a proveďte orchestraci geografického převzetí služeb při selhání relevantních součástí aplikace společně s databází.

Potenciální ztráta dat po vynuceném přepnutí

Pokud dojde k výpadku v primární oblasti, nedávné transakce se možná nereplikovaly do geosekundární oblasti a v případě nuceného převzetí služeb může dojít ke ztrátě dat.

Důležité

Elastické fondy s 800 nebo méně DTU nebo 8 nebo méně virtuálními jádry a více než 250 databázemi mohou narazit na problémy, včetně plánovaných delších geografických převzetí služeb a snížení výkonu. K těmto problémům dochází spíše u pracovních zátěží náročných na zápis, pokud jsou geografické repliky značně oddělené podle geografie nebo pokud se pro každou databázi používá více sekundárních geografických replik. Příznakem těchto problémů je nárůst prodlevy geografické replikace v průběhu času, což může potenciálně vést k rozsáhlejší ztrátě dat při výpadku. Tuto prodlevu je možné monitorovat pomocí sys.dm_geo_replication_link_status. Pokud se tyto problémy vyskytnou, je možné je zmírnit zvětšením fondu o více jednotek DTU nebo vCores nebo snížením počtu georeplikovaných databází ve fondu.

Návrat po obnovení

Pokud jsou skupiny převzetí služeb při selhání nakonfigurované pomocí zásad převzetí služeb při selhání spravované Microsoftem, zahájí se vynucené převzetí služeb při selhání na geograficky sekundární server během scénáře havárie podle definovaného období odkladu. Navrácení na původní primární server musí být zahájeno ručně.

Oprávnění a omezení

Projděte si průvodce konfigurací skupiny převzetí služeb při selhání pro seznam oprávnění a omezení.

Programová správa skupin převzetí služeb při selhání

Skupiny převzetí služeb při selhání je možné spravovat také programově pomocí Azure PowerShellu, Azure CLI a rozhraní REST API. Další informace najdete v tématu Konfigurace skupiny převzetí služeb při selhání pro službu Azure SQL Database.

Povolení vysoké dostupnosti (redundance zón)

Dostupnost prostřednictvím redundance zvyšuje odolnost tím, že chrání před výpadky zóny dostupnosti v rámci oblasti.

Při vytváření skupiny převzetí služeb při selhání, která obsahuje jednu nebo více databází, není možné povolit vysokou dostupnost sekundárních databází bez ohledu na nastavení vysoké dostupnosti primárních databází.

Zónová redundance s databázemi bez hyperškálování

Sekundární databáze, které jsou vytvořené prostřednictvím skupiny převzetí služeb při selhání, nebudou mít ve výchozím nastavení povolenou vysokou dostupnost. Po vytvoření skupiny převzetí služeb při selhání povolte vysokou dostupnost databází, které tato skupina obsahuje. Toto chování platí také v případě, že nejprve vytvoříte aktivní geo-replikaci a poté případně přidáte databáze do skupiny pro převzetí služeb při selhání.

Zónová redundance a hyperškálování

Sekundární databáze vytvořené prostřednictvím skupiny převzetí služeb při selhání dědí nastavení vysoké dostupnosti příslušných primárních databází. Proto pokud má primární databáze povolenou vysokou dostupnost, bude mít sekundární databáze také povolenou. Naopak pokud primární databáze nemá povolenou vysokou dostupnost, sekundární databáze ji nebude mít ani povolenou.

Regionální podpora zón dostupnosti

Ve scénáři, kdy je v primární databázi povolená vysoká dostupnost a přidaná sekundární databáze je v oblasti, která ještě nepodporuje zóny dostupnosti, pracovní postup selže s chybovou zprávou s kódem 45122: "Operace vytvoření nebo aktualizace skupiny převzetí služeb při selhání byla úspěšně dokončena; Některé databáze však nelze přidat nebo odebrat ze skupiny převzetí služeb při selhání. Zřizování zónově redundantní databáze nebo fondu se pro aktuální požadavek nepodporuje." Chcete-li tento problém vyřešit, použijte aktivní geografické replikace, kde povolíte nebo zakážete vysokou dostupnost při vytváření sekundární databáze. Tyto databáze pak můžete případně přidat do skupiny převzetí služeb při selhání.

Související obsah