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 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í na logickém serveru na logický server v jiné oblasti. Tento článek obsahuje přehled funkce skupiny převzetí služeb při selhání s osvědčenými postupy a doporučeními pro jeho použití se službou Azure SQL Database.

Pokud chcete začít používat tuto funkci, přečtěte si téma Konfigurace skupiny převzetí služeb při selhání.

Poznámka:

Tento článek se zabývá skupinami převzetí služeb při selhání pro Azure SQL Database. Informace o službě Azure SQL Managed Instance najdete v tématu Skupiny převzetí služeb při selhání ve službě Azure SQL Managed Instance.

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

Přehled

Funkce skupin převzetí služeb při selhání umožňuje spravovat replikaci a převzetí služeb při selhání databází do jiné oblasti Azure. 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í koncové body naslouchacího procesu jen pro čtení a jen pro čtení, které se během geografických převzetí služeb při selhání nezmění. Po geografickém převzetí služeb při selhání nemusíte měnit připojovací řetězec aplikace, protože připojení se automaticky směrují na aktuální primární server. Geograficky převzetí služeb při selhání přepne všechny sekundární databáze ve skupině na primární roli. Po dokončení geografického převzetí služeb při selhání se záznam DNS automaticky aktualizuje a přesměruje koncové body do nové oblasti.

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í naslouchacího procesu jen pro čtení směrujte provoz jen pro čtení do sekundární databáze, která je čitelná.

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 můžou provést převzetí služeb při selhání skupiny, když si všimnou neočekávaného výpadku, který má vliv na jednu nebo více databází ve skupině 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ý má vliv na primární oblast, zahájí Microsoft převzetí služeb při selhání všech ovlivněných skupin převzetí služeb při selhání, které mají nakonfigurované zásady převzetí služeb při selhání 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 oblasti. 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í Na jednu nebo více databází ve skupinách převzetí služeb při selhání má vliv výpadek a stát se nedostupným. Můžete zvolit převzetí služeb 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 do Microsoftu a aplikace je tolerantní k rto (výpadku) nejméně jedné hodiny nebo více.		 Ano

Spravovaná zákazníkem

Ve výjimečných případech není integrovaná dostupnost nebo vysoká dostupnost dostatečná pro 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 spravovanou zákazníkem se důrazně doporučuje, protože vám zajistí kontrolu nad tím, kdy se má zahájit převzetí služeb při selhání a obnovit provozní kontinuitu. Převzetí služeb při selhání můžete zahájit, když zjistíte neočekávaný výpadek, který má vliv na jednu nebo více databází ve skupině převzetí služeb při selhání.

Spravováno společností Microsoft

Díky zásadám převzetí služeb při selhání spravovaným Microsoftem se odpovědnost za zotavení po havárii deleguje do služby Azure SQL. Aby služba Azure SQL iniciovala vynucené převzetí služeb při selhání, musí být splněny následující podmínky:

  • Na datacentra, zónu dostupnosti nebo výpadek na úrovni oblasti způsobené přírodní událostí havárie, změnami konfigurace, chybami softwaru nebo selháním hardwarových komponent a mnoha databází v dané oblasti dojde k ovlivnění.
  • 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.

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ě převzetí služeb při selhání převzaly služby při selhání bez ohledu na konfiguraci redundance zóny 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í to mít vliv na výpadek, budou se i nadále převzít služby při selhání, pokud jsou součástí skupiny převzetí služeb při selhání se zásadami převzetí služeb při selhání spravované Microsoftem.
  • Je přijatelné mít vynucené převzetí služeb při selhání databází ve skupině převzetí služeb při selhání bez zohlednění závislosti aplikace na jiných službách nebo komponentách Azure používaných aplikací, 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ý čas vynuceného převzetí služeb při selhání nelze řídit a ignoruje stav synchronizace sekundárních databází.
  • Všechny primární a sekundární databáze ve skupině převzetí služeb při selhání mají stejnou úroveň služby, výpočetní úroveň (zřízenou nebo bezserverovou) a velikost výpočetních prostředků (DTU nebo virtuální jádra). Pokud cíl na úrovni služby (SLO) všech databází ve skupině převzetí služeb při selhání neodpovídá, zásady převzetí služeb při selhání se nakonec aktualizují ze služby Microsoft Managed na zákazníky spravované službou Azure SQL.

Když Microsoft aktivuje převzetí služeb při selhání, přidá se do protokolu aktivit služby Azure Monitor položka pro název operace Převzetí služeb při selhání skupiny převzetí služeb při selhání Azure SQL. Položka obsahuje název skupiny převzetí služeb při selhání v části Prostředek a událost iniciovaná jedním spojovníkem (-), který označuje, že převzetí služeb při selhání inicioval Microsoft. Tyto informace najdete také na stránce protokolu aktivit nového primárního serveru nebo instance na webu Azure Portal.

Terminologie a možnosti

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

    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 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ě 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í

    Logický server, který je hostitelem sekundárních databází ve skupině převzetí služeb při selhání. 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í předtím, 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 v případech, kdy je primární přístupný. Převzetí služeb při selhání se používá v následujících scénářích:

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

  • Vynucené převzetí služeb 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í. Převzetí služeb při selhání je možné provést, aby se navrácení služeb po obnovení vrátily repliky do 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í pomocí asynchronní replikace, může vynucené převzetí služeb při selhání skupin se zásadami převzetí služeb při selhání spravované Microsoftem 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í GracePeriodWithDataLossHoursmůž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í jednoúčelových databází do skupiny převzetí služeb při selhání

    Do stejné skupiny převzetí služeb při selhání můžete umístit několik jednoúčelový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, zdědí toto propojení geografické replikace skupina. 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 zase způsobit neúspěšné převzetí služeb při selhá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. Upgrady na úrovni služby můžou být operace s velikostí dat a dokončení může chvíli trvat.

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

    Do stejné skupiny převzetí služeb při selhání můžete umístit všechny nebo několik databází do elastického fondu. 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 bezplatnou 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 v sekundárním fondu, zdědí toto propojení geografické replikace skupina. 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í úlohu čtení i zápisu transparentně znovu připojit k primárnímu serveru, když se primární změny 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 naslouchacího procesu vytvoří jako <fog-name>.database.windows.net. Po převzetí služeb při selhání se záznam DNS automaticky aktualizuje, aby se naslouchací proces přesměrovává na nový primární server.

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

    Záznam CNAME DNS, který odkazuje na aktuální sekundární. Vytvoří se automaticky při vytvoření skupiny převzetí služeb při selhání a umožní, aby se úloha SQL jen pro čtení transparentně připojila k sekundárnímu serveru, když se sekundární změny 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 naslouchacího procesu 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 sekundární neobnoví. Pokud nemůžete tolerovat výpadky relací jen pro čtení a můžete primární přenosy jen pro čtení i pro zápis pro čtení použít na úkor potenciálního snížení výkonu primárního serveru, můžete povolit převzetí služeb při selhání pro naslouchací AllowReadOnlyFailoverToPrimary proces jen pro čtení konfigurací vlastnosti. V takovém případě se provoz jen pro čtení automaticky přesměruje na primární, pokud sekundární není k dispozici.

    Poznámka:

    Tato AllowReadOnlyFailoverToPrimary vlastnost se projeví jenom v případě, že je povolená zásada převzetí služeb při selhání spravovaná Microsoftem a aktivovala se vynucené převzetí služeb při selhání. V takovém případě, pokud je vlastnost nastavena na True, bude nová primární obsluhovat relace jen pro čtení a zápis i jen 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 převezme služby při selhání nezávisle. 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 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 některé databáze na primárním serveru. Následující diagram znázorňuje typickou konfiguraci geograficky redundantní cloudové aplikace využívající více databází ve skupině převzetí služeb při selhání:

Diagram shows a typical configuration of a geo-redundant cloud application using multiple databases and a failover group.

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 je po geografickém převzetí služeb při selhání správně nastavený přístup k ověřování a síťovému přístupu na sekundárním serveru, když se stane novou primární oblastí. Podrobnosti najdete v tématu Zabezpečení služby SQL Database po zotavení po havárii. Další informace najdete v tématu Návrh cloudových řešení pro zotavení po havárii.

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 jako skupiny převzetí služeb při selhání ve spárovaných oblastech lepší výkon v porovnání s nezaplacený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 se upgraduje za druhé.

Pokud máte nakonfigurovanou geografickou replikaci nebo skupiny 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 různé plány časových intervalů ú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í 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í existuje počáteční počáteční počáteční fáze před zahájením replikace dat. Počáteční fáze počátečního 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řebnou k dokončení počátečního počátečního odsazení závisí na velikosti 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 počátečního nastavení až 500 GB za hodinu pro službu SQL Database. Počáteční dělení se provádí pro všechny databáze paralelně.

Použití více skupin převzetí služeb při selhání k převzetí služeb při selhání více databází

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 se stejným cílem 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í geografická oblast nakonfigurovaná se stejnou úrovní služby a velikostí výpočetních prostředků jako primární.

Použití naslouchacího procesu pro čtení i 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í iony se automaticky směrují na primární. Tento název se po převzetí služeb při selhání 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 novou primární server až po aktualizaci mezipaměti DNS klienta. Hodnota TTL (Time to Live) primárního a sekundárního záznamu DNS naslouchacího procesu je 30 sekund.

Použití naslouchacího procesu jen 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í iony se automaticky směrují na geografickou sekundární oblast. Doporučuje se také označit záměr čtení v připojovací řetězec pomocí ApplicationIntent=ReadOnly.

V úrovních služeb Premium, Pro důležité obchodní informace a Hyperscale podporuje SQL Database použití replik jen pro čtení k přesměrování zpracování úloh dotazů jen pro čtení pomocí ApplicationIntent=ReadOnly parametru v připojovací řetězec. 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řevzetí služeb při selhání

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řevzetí služeb při selhání

Pokud dojde k výpadku v primární oblasti, nedávné transakce se nemusí replikovat do sekundární geografické oblasti a v případě vynuceného převzetí služeb při selhání 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ází může narazit na problémy, včetně delších plánovaných geografických převzetí služeb při selhání 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.

Navrácení služeb 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í služeb po obnovení do původního primárního serveru musí být inicializováno ručně.

Oprávnění a omezení

Projděte si průvodce konfigurací skupiny převzetí služeb při selhání a seznamem 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í.

Související obsah