Sdílet prostřednictvím

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

  • Článek

Platí pro:Azure SQL Managed Instance

Funkce skupin převzetí služeb při selhání umožňuje spravovat replikaci a převzetí služeb při selhání všech uživatelských databází ve spravované instanci do jiné oblasti Azure. Tento článek poskytuje přehled funkce skupiny převzetí služeb při selhání a nabízí osvědčené postupy a doporučení pro její použití s Azure SQL Managed Instance.

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

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í uživatelských databází ve spravované instanci do spravované instance v jiné oblasti Azure. Skupiny failover jsou navržené tak, aby zjednodušily implementaci a řízení geograficky replikovaných databází v rozsahu.

Další informace najdete v tématu Vysoká dostupnost pro spravovanou instanci Azure SQL. Informace o geografickém převzetí služeb při selhání, RPO a RTO najdete v přehledu kontinuity podnikání.

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

Skupiny pro převzetí služeb při selhání poskytují koncové body naslouchacího procesu pro čtení i zápis 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. Geografické 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 failoveru 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 na primární databáze, můžete také použít sekundární databáze ve skupině pro převzetí služeb při selhání k odlehčení zátěže úloh, které jsou pouze pro čtení. Pomocí posluchače pro čtení směrujte pouze čtecí provoz do 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í podporují dvě zásady převzetí:

  • Spravovaná zákazníkem (doporučeno) – Zákazníci můžou provést převzetí rolí při selhání skupiny, když si všimnou neočekávaného výpadku, který ovlivňuje jednu nebo více databází ve skupině. 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 zákazníkem spravované 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 pro převzetí při selhání Jedna nebo více databází ve skupinách pro převzetí služeb při selhání je ovlivněna výpadkem a stanou se nedostupnými. Můžete zvolit převzetí odpovědnosti při selhání. Ano
Spravováno společností Microsoft Všechny skupiny převzetí služeb při selhání v regionu 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í vůči RTO (výpadku) nejméně jedné hodiny.		 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 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 na službu 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.

  • Výpadek na úrovni datacentra, zóny dostupnosti nebo oblasti způsobený přírodní katastrofou, změnami konfigurace, softwarovými chybami nebo selháním hardwarových komponent 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é Microsoftem, které může být provedeno Microsoftem pouze za extrémních okolností. Ve všech skupinách s politikou převzetí služeb při selhání spravovanou Microsoftem v dané oblasti by bylo zahájeno 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í při selhání skupiny, použijte zásady převzetí při selhání 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řepnutí nějakou dobu po uplynutí období odkladu, protože skutečný čas vynuceného přepnutí se může výrazně lišit.
  • Je v pořádku, že všechny databáze v rámci skupiny převzetí služeb při selhání se přepnou, bez ohledu na konfiguraci redundance zóny nebo stav jejich 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řesunuty v případě selhání, pokud jsou součástí skupiny pro převzetí služeb při selhání se zásadami spravovanými Microsoftem.
  • Je přípustné provést vynucené převzetí služeb při selhání databází ve skupině pro převzetí služeb při selhání bez ohledu na závislost aplikace na jiných službách nebo komponentách Azure, které používá aplikace, což může způsobit snížení výkonu nebo nedostupnost aplikace.
  • Je přijatelné připustit neznámý rozsah ztráty dat, protože přesný čas vynuceného převzetí služeb při selhání nelze řídit a současně se ignoruje stav synchronizace sekundárních databází.
  • Všechny primární a sekundární databáze ve skupině pro převzetí služeb při selhání a všechny vztahy geografické replikace mají stejnou úroveň služby, úroveň výpočetního výkonu (zajištěnou nebo bezserverovou) a velikost výpočetního výkonu (DTU nebo vCores). Pokud cíle na úrovni služby (SLO) všech databází neodpovídají, politika převzetí služeb při selhání se nakonec aktualizuje ze správy Microsoftu na správu zákazníkem prostřednictvím služby Azure SQL.

Když Microsoft vyvolá převzetí služeb při selhání, přidá se do protokolu aktivit služby Azure Monitor záznam s názvem operace Převzetí služeb při selhání skupiny Azure SQL. Položka obsahuje název skupiny převzetí služeb při selhání v části Prostředek a Událost inicioval zobrazuje jeden spojovník (-), který označuje, že převzetí služeb při selhání inicioval Microsoft. Tyto informace najdete také na protokolu aktivit nové primární instance nebo serveru v prostředí Azure Portal.

Terminologie a možnosti

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

    Skupina pro převzetí služeb při selhání umožňuje, aby všechny uživatelské databáze ve spravované instanci přešly při selhání jako jedna jednotka do jiné oblasti Azure, pro případ, že primární spravovaná instance přestane být dostupná kvůli výpadku primární oblasti. Vzhledem k tomu, že skupiny převzetí služeb při selhání pro službu SQL Managed Instance obsahují všechny uživatelské databáze v instanci, je možné pro instanci nakonfigurovat pouze jednu skupinu převzetí služeb při selhání.

    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.

  • Primární

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

  • Sekundární

    Spravovaná instance, 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í.

    Důležité

    Pokud databáze obsahuje objekty OLTP v paměti, primární a sekundární instance 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 instanci geografické repliky může vést k problémům s nedostatkem paměti. Pokud k tomu dojde, sekundární 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 by zase mohlo způsobit, že převzetí služeb při selhání nemusí být úspěšné. Abyste tomu předešli, ujistěte se, že úroveň služby sekundární instance odpovídá úrovni služby primární databáze. Upgrady na úrovni služby můžou být operace s velikostí dat a jejich dokončení může chvíli trvat.

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

    Přepnutí při selhání provádí úplnou synchronizaci dat mezi primární a sekundární databází předtím, než sekundární převezme 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:

    • Provádějte cvičení pro zotavení po havárii (DR) v produkčním prostředí, když 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í).

  • Vynucený přechod (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í. Provedení failoveru umožňuje vrátit repliky do jejich původních primárních a sekundárních rolí.

  • Období odkladu se ztrátou dat

    Vzhledem k tomu, že se data replikují na sekundární server pomocí asynchronní replikace, může vynucené převzetí služeb při selhání skupin se zásadami spravovanými 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í GracePeriodWithDataLossHours můžete řídit, jak dlouho služba Azure SQL čeká před zahájením vynuceného selhání, což může vést ke ztrátě dat.

  • Zóna DNS

    Jedinečné ID, které se automaticky vygeneruje při vytvoření nové spravované instance SQL. Pro tuto instanci je zřízený certifikát SAN (Multi-Domain) pro ověření připojení klienta k jakékoli instanci ve stejné zóně DNS. Dvě spravované instance ve stejné skupině převzetí služeb při selhání musí sdílet zónu DNS.

  • 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 a umožní čtení i zápis transparentně 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í ve spravované instanci SQL se záznam DNS CNAME pro naslouchací URL vytvoří jako <fog-name>.<zone_id>.database.windows.net.

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

    Záznam DNS CNAME, který směřuje na současný sekundární server. Vytvoří se automaticky při vytvoření skupiny převzetí služeb při selhání a umožňuje, aby se zátěž 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í ve spravované instanci SQL se záznam DNS CNAME pro adresu URL posluchače vytvoří jako <fog-name>.secondary.<zone_id>.database.windows.net. Ve výchozím nastavení je převzetí služeb při selhání naslouchadla jen pro čtení zakázané, aby byl zajištěn neovlivněný výkon primárního serveru, když je sekundární server offline. To ale také znamená, že se relace jen pro čtení nebudou moct připojit, dokud se sekundární server neobnoví. Pokud nemůžete tolerovat výpadky u relací pouze pro čtení a můžete používat primární server jak pro přenosy pouze pro čtení, tak pro čtení i zápis i za cenu potenciálního snížení výkonu primárního serveru, můžete povolit převzetí služeb při selhání pro posluchače pouze pro čtení konfigurací vlastnosti AllowReadOnlyFailoverToPrimary. V takovém případě se provoz pouze pro čtení automaticky přesměruje na primární server, pokud není sekundární 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 bylo vyvoláno vynucené převzetí služeb při selhání. V takovém případě, pokud je vlastnost nastavena na True, bude nový primární server obsluhovat jak relace s možností zápisu, tak relace pouze pro čtení.

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

Skupina převzetí služeb při selhání musí být nakonfigurovaná v primární instanci a připojí ji k sekundární instanci v jiné oblasti Azure. Všechny uživatelské databáze v instanci budou replikovány do sekundární instance. Systémové databáze jako master a msdb nebudou replikovány.

Následující diagram znázorňuje typickou konfiguraci geograficky redundantní cloudové aplikace využívající spravovanou instanci a skupinu převzetí služeb při selhání:

diagram skupiny převzetí služeb při selhání pro spravovanou instanci Azure SQL

Pokud vaše aplikace jako datovou vrstvu používá službu SQL Managed Instance, postupujte podle obecných pokynů a osvědčených postupů popsaných v tomto článku při navrhování provozní kontinuity.

Vytvoření instance geograficky sekundární

Aby se zajistilo nepřerušované připojení k primární spravované instanci SQL po převzetí při selhání, musí být primární i sekundární instance ve stejné zóně DNS. Zaručuje, že stejný multi-domain (SAN) certifikát lze použít k ověření klientských připojení k oběma instancím ve skupině pro failover. Jakmile je vaše aplikace připravená pro produkční nasazení, vytvořte sekundární spravovanou instanci SQL v jiné oblasti a ujistěte se, že sdílí zónu DNS s primární spravovanou instancí SQL. Můžete to udělat zadáním volitelného parametru během vytváření. Pokud používáte PowerShell nebo rozhraní REST API, název volitelného parametru je DNSZonePartner. Název odpovídajícího volitelného pole na webu Azure Portal je Primární spravovaná instance.

Důležité

První spravovaná instance vytvořená v podsíti určuje zónu DNS pro všechny následné instance ve stejné podsíti. To znamená, že dvě instance ze stejné podsítě nemůžou patřit do různých zón DNS.

Další informace o vytvoření sekundární spravované instance SQL ve stejné zóně DNS jako primární instance najdete v tématu Konfigurace skupiny převzetí služeb při selhání pro spravovanou instanci Azure SQL.

Použití spárovaných oblastí

Z výkonnostních důvodů nasaďte obě spravované instance do spárovaných oblastí. Skupiny převzetí služeb při selhání SQL Managed Instance ve spárovaných oblastech mají v porovnání s nespárovanými oblastmi lepší výkon.

Azure SQL Managed Instance se řídí osvědčeným postupem nasazení, kdy se ve stejnou dobu obvykle nenasazují spárované oblasti Azure. Není však možné předpovědět, která oblast se nejprve upgraduje, takže pořadí nasazení není zaručené. Někdy se primární instance upgraduje jako první a někdy se sekundární instance upgraduje jako první.

V situacích, kdy je spravovaná instance Azure SQL součástí skupiny pro převzetí služeb při selhání a instance ve skupině nejsou v spárovaných oblastech Azure, vyberte různé časové plány údržby pro primární a sekundární databázi. Vyberte například časové období údržby v týdnu pro vaši geografickou sekundární databázi a časové období víkendové údržby pro vaši geografickou primární databázi.

Povolte a optimalizujte tok geografické replikace mezi instancemi.

Připojení mezi podsítěmi virtuální sítě, které hostují primární a sekundární instanci, musí být vytvořeno a udržováno kvůli nepřerušovanému toku provozu geografické replikace. Existuje několik způsobů, jak zajistit připojení mezi instancemi, mezi kterými si můžete vybrat na základě topologie sítě a zásad:

Globální propojení virtuálních sítí (VNet Peering) je doporučeným způsobem, jak vytvořit připojení mezi dvěma instancemi ve skupině pro převzetí služeb při selhání. Pomocí páteřní infrastruktury Microsoftu poskytuje privátní připojení mezi partnerskými virtuálními sítěmi s nízkou latencí a velkou šířkou pásma. V komunikaci mezi partnerskými virtuálními sítěmi se nevyžaduje žádný veřejný internet, brány ani další šifrování.

Počáteční setí

Při vytváření skupiny převzetí služeb při selhání mezi spravovanými instancemi existuje počáteční fáze před zahájením replikace dat. Počáteční fáze osévání je nejdelší a nejdražší částí operace. Po dokončení počátečního seedingu se data synchronizují a replikují se pouze následné změny dat. Doba potřebná k dokončení počátečního seedingu závisí na velikosti dat, počtu replikovaných databází, intenzitě pracovního zatížení na primárních databázích a rychlosti propojení mezi virtuálními sítěmi, které hostují primární a sekundární instanci, což částečně závisí na způsobu navázání připojení. Za normálních okolností a při navázání připojení s využitím doporučeného globálního připojení virtuálních sítí je rychlost nasazení pro SQL Managed Instance až 360 GB za hodinu. Seeding se provádí pro dávku uživatelských databází paralelně – ne nutně pro všechny databáze najednou. Pokud je v instanci hostováno mnoho databází, může být zapotřebí více sad.

Pokud je rychlost propojení mezi těmito dvěma instancemi pomalejší než to, co je potřeba, je pravděpodobné, že doba potřebná k osázení bude výrazně ovlivněna. Můžete použít uvedenou počáteční rychlost, počet databází, celkovou velikost dat a rychlost připojení k odhadu, jak dlouho bude počáteční fáze trvat, než začne replikace dat. Například v případě jedné databáze o velikosti 100 GB by počáteční fáze trvala přibližně 1,2 hodiny, pokud by propojení dokázalo přenášet 84 GB za hodinu a pokud se neočkují žádné další databáze. Pokud propojení může přenášet pouze 10 GB za hodinu, může počáteční rozdělení databáze o velikosti 100 GB trvat přibližně 10 hodin. Pokud existuje více databází k replikaci, počáteční fáze se spustí paralelně a v kombinaci s pomalou rychlostí propojení může počáteční fáze trvat výrazně déle, zejména pokud paralelní počáteční dělení dat ze všech databází překročí dostupnou šířku pásma propojení.

Důležité

V případě extrémně nízké rychlosti nebo přetíženého spojení mohou počáteční fáze trvat dny, což může způsobit vypršení časového limitu pro vytvoření skupiny pro převzetí služeb při selhání. Proces vytvoření se automaticky zruší po 6 dnech.

Správa geopřevzetí do sekundární instance

Skupina pro převzetí služeb při selhání spravuje geografické převzetí všech databází na primární spravované instanci. Při vytvoření skupiny se každá databáze v instanci automaticky geograficky replikuje do sekundární instance. Nemůžete použít skupiny převzetí služeb při selhání k zahájení částečného převzetí služeb při selhání podmnožiny databází.

Důležité

Pokud dojde k vyřazení databáze v primární spravované instanci, automaticky se zahodí také na geograficky sekundární spravovanou instanci.

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

Pro úlohy čtení a zápisu použijte <fog-name>.zone_id.database.windows.net jako název serveru. Připojení se automaticky směrují na primární server. Tento název se po převzetí služeb při selhání nezmění. Geografické převzetí služeb při selhání zahrnuje aktualizaci záznamu DNS, takže nová připojení klientů se směrují na novou primární síť až po aktualizaci mezipaměti DNS klienta. Vzhledem k tomu, že sekundární instance sdílí zónu DNS s primárním serverem, klientská aplikace se k ní bude moct znovu připojit pomocí stejného certifikátu SÍTĚ SAN na straně serveru. Stávající klientská připojení je potřeba ukončit a pak znovu vytvořit, aby se směrovala na novou primární síť. Naslouchací pro čtení i zápis a naslouchací jen pro čtení nelze dosáhnout prostřednictvím veřejného koncového bodu pro spravovanou instanci.

Použijte nasloucháč pouze ke čtení (sekundární MI)

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. Pokud se chcete připojit přímo k geografické sekundární oblasti, použijte <fog-name>.secondary.<zone_id>.database.windows.net jako název serveru.

Ve vrstvě Obchodně Kritická podporuje služba SQL Managed Instance použití replik pouze pro čtení k přesměrování zpracování úloh dotazů pouze pro čtení pomocí parametru v připojovacím řetězci. Pokud jste nakonfigurovali geograficky replikovanou sekundární lokalitu, můžete se pomocí této funkce připojit k replice jen pro čtení v primárním umístění nebo v geograficky replikovaném umístění:

  • Pokud se chcete připojit k replice jen pro čtení v primárním umístění, použijte ApplicationIntent=ReadOnly a <fog-name>.<zone_id>.database.windows.net.
  • 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.<zone_id>.database.windows.net.

Naslouchací proces pro čtení i zápis a naslouchací proces jen pro čtení nelze dosáhnout prostřednictvím veřejného koncového bodu pro spravovanou instanci.

Potenciální snížení výkonu po selhání

Typická aplikace Azure používá více služeb Azure a skládá se z několika součástí. Geografické převzetí služeb při selhání skupiny se aktivuje na základě stavu samotných komponent 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é. Jakmile se primární databáze přepnou do sekundární oblasti, může se zvýšit latence mezi závislými komponentami. Zajistěte redundanci všech komponent aplikace v sekundární oblasti a zajistěte převzetí provozu součástí aplikace společně s databází, aby výkon aplikace nebyl ovlivněn vyšší latencí mezi oblastmi.

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.

Aktualizace DNS

Aktualizace DNS posluchače pro čtení a zápis proběhne okamžitě po spuštění převzetí služeb při selhání. Tato operace nezpůsobí ztrátu dat. Proces přepínání databázových rolí ale za normálních podmínek může trvat až 5 minut. Dokud se nedokončí, některé databáze v nové primární instanci budou stále jen pro čtení. Pokud se spustí převzetí služeb při selhání pomocí PowerShellu, změna role primární repliky je synchronní. Pokud se zahájí pomocí webu Azure Portal, uživatelské rozhraní indikuje stav dokončení. Pokud je inicializováno pomocí rozhraní REST API, pomocí standardního mechanismu dotazování Azure Resource Manageru monitorujte dokončení.

Důležité

Použijte ruční plánované převzetí služeb při selhání k přesunu primárního zdroje zpět na původní místo, jakmile dojde ke zmírnění výpadku, který vyvolal geografické převzetí služeb při selhání.

Úspora nákladů s neplacenou DR replikou

Náklady na licence SQL Serveru můžete ušetřit tak, že nakonfigurujete sekundární spravovanou instanci tak, aby se používala pouze pro zotavení po havárii (DR). Postup nastavení najdete v tématu Konfigurace pohotovostní repliky bez licence pro službu Azure SQL Managed Instance.

Pokud sekundární instance není použita pro úlohy čtení, Microsoft vám poskytne bezplatný počet virtuálních jader, aby odpovídaly primární instanci. Stále se vám účtují poplatky za výpočetní prostředky a úložiště používané sekundární instancí. Skupiny převzetí služeb při selhání podporují pouze jednu repliku – replika musí být buď replikou pro čtení, nebo určená pouze pro zotavení po havárii.

Povolení scénářů závislých na objektech ze systémových databází

Systémové databáze se nereplikují do sekundární instance ve skupině převzetí služeb při selhání. Pokud chcete povolit scénáře, které závisí na objektech ze systémových databází, vytvořte stejné objekty v sekundární instanci a udržujte je synchronizované s primární instancí.

Pokud například plánujete používat stejná přihlášení v sekundární instanci, nezapomeňte je vytvořit se stejným identifikátorem SID.

-- Code to create login on the secondary instance
CREATE LOGIN foo WITH PASSWORD = '<enterStrongPasswordHere>', SID = <login_sid>;

Další informace viz Replikace přihlašovacích údajů a úloh agenta.

Synchronizace vlastností instancí a instancí zásad uchovávání dat

Instance ve skupině převzetí služeb při selhání zůstávají samostatnými prostředky Azure a žádné změny konfigurace primární instance nebudou automaticky replikovány do sekundární instance. Nezapomeňte provést všechny relevantní změny v primární i sekundární instanci. Pokud například změníte redundanci úložiště zálohování nebo zásady dlouhodobého uchovávání záloh v primární instanci, nezapomeňte ji také změnit v sekundární instanci.

Škálujte instance

Můžete vertikálně navýšit nebo snížit kapacitu primární a sekundární instance na jinou velikost výpočetních prostředků v rámci stejné úrovně služby nebo na jinou úroveň služby. Při vertikálním navýšení kapacity ve stejné úrovni služby doporučujeme nejprve vertikálně navýšit kapacitu sekundární geografické oblasti a pak vertikálně navýšit kapacitu primární úrovně. Při vertikálním snížení kapacity ve stejné úrovni služby otočte pořadí: nejprve vertikálně snížit kapacitu primárního serveru a pak vertikálně snížit kapacitu sekundární úrovně. Toto doporučení se vynucuje při škálování instance na jinou úroveň služby. Posloupnost operací se vynucuje při škálování úrovně služby a virtuálních jader a úložiště.

Toto pořadí se doporučuje zejména proto, aby se během procesu upgradu nebo downgradu zabránilo problému s přetížením instance v sekundární geografické oblasti s nižší skladovou položkou, kterou by tak bylo potřeba znovu naplnit.

Důležité

  • V případě instancí ve skupině převzetí služeb se změna úrovně služby na nebo z úrovně Obecné účely nové generace nepodporuje. Než upravíte některou z replik, musíte nejprve odstranit skupinu přepnutí při selhání, a po provedení změny znovu vytvořit skupinu přepnutí při selhání.
  • Existuje známý problém, který může ovlivnit přístupnost škálované instance pomocí přidruženého naslouchacího procesu skupiny převzetí služeb při selhání.

Zabránění ztrátě důležitých dat

Kvůli vysoké latenci širokých sítí používá geografická replikace mechanismus asynchronní replikace. Asynchronní replikace činí možnost ztráty dat nevyhnutelnou, pokud primární selže. Aby bylo možné chránit důležité transakce před ztrátou dat, vývojář aplikace může okamžitě po potvrzení transakce zavolat sp_wait_for_database_copy_sync uloženou proceduru. Volání sp_wait_for_database_copy_sync blokuje volající vlákno, dokud poslední potvrzená transakce není přenesena a zapsána v transakčním protokolu sekundární databáze. Nečeká však na přehrání přenášených transakcí (znovu) na sekundárním serveru. sp_wait_for_database_copy_sync je vymezen na konkrétní odkaz geografické replikace. Tento postup může volat každý uživatel s právy k připojení k primární databázi.

Aby se zabránilo ztrátě dat během uživatelem zahájeného plánovaného geografického převzetí služeb při selhání, replikace se automaticky a dočasně přepne na synchronní a poté se provede převzetí služeb při selhání. Po dokončení geografického převzetí při selhání se replikace vrací do asynchronního režimu.

Poznámka:

sp_wait_for_database_copy_sync zabraňuje ztrátě dat po geografickém obnovení po selhání pro konkrétní transakce, ale nezaručuje úplnou synchronizaci při přístupu pro čtení. Zpoždění způsobené voláním sp_wait_for_database_copy_sync procedury může být významné a závisí na velikosti dosud nepřesílaného transakčního protokolu v primárním okamžiku volání.

Stav skupiny pro převzetí při selhání

Skupina převzetí služeb při selhání hlásí svůj stav popisující aktuální stav replikace dat:

  • Počáteční zasívání – počáteční zasívání probíhá po vytvoření skupiny pro převzetí služeb při selhání, dokud nebudou v sekundární instanci inicializovány všechny uživatelské databáze. Proces převzetí služeb při selhání nelze zahájit, když je skupina převzetí služeb při selhání ve stavu Seeding, protože uživatelské databáze nejsou ještě zkopírovány do sekundární instance.
  • Synchronizace je obvyklým stavem skupiny pro převzetí služeb při selhání. To znamená, že se změny dat v primární instanci replikují asynchronně do sekundární instance. Tento stav nezaručuje, že se data v každém okamžiku plně synchronizují. Kvůli asynchronní povaze procesu replikace mezi instancemi ve skupině převzetí služeb při selhání mohou stále probíhat změny dat z primárního serveru, které se mají replikovat na sekundární server. Automatické i ruční převzetí služeb při selhání je možné zahájit, když je skupina převzetí služeb při selhání ve stavu Synchronizace.
  • Probíhá převzetí služeb při selhání – tento stav označuje, že probíhá proces převzetí služeb při selhání automaticky nebo ručně zahájený. Pokud je skupina převzetí služeb při selhání v tomto stavu, nelze zahájit žádné její změny ani další převzetí služeb při selhání.

Obnovení provozu

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. Návrat k původnímu primárnímu serveru musí být proveden ručně.

Interoperabilita funkcí

Zálohování

Úplné zálohování se provádí v následujících scénářích:

  • Před prvotním osetím, když vytváříte skupinu pro převzetí služeb při selhání.
  • Po převzetí služeb při selhání.

Úplná záloha je operace s daty, kterou nelze přeskočit ani odložit a může trvat nějakou dobu, než se dokončí. Doba, která trvá dokončení, závisí na velikosti dat, počtu databází a intenzitě úloh v primárních databázích. Úplné zálohování může výrazně zpozdit počáteční seeding a může buď zpozdit, nebo zabránit operaci převzetí služeb při selhání na nové instanci krátce po něm.

Služba Log Replay

Databáze migrované do Azure SQL Managed Instance pomocí Log Replay Service (LRS) se nedají přidat do skupiny pro převzetí služeb při selhání, dokud nebude proveden krok přepnutí. Databáze migrovaná pomocí LRS je ve stavu obnovení, dokud migrace není dokončena, a databáze ve stavu obnovení nelze přidat do skupiny pro automatické převzetí služeb při selhání. Při pokusu o vytvoření skupiny převzetí služeb při selhání s databází v obnovovacím stavu dochází ke zpoždění při vytváření skupiny převzetí služeb při selhání, dokud se obnovení databáze nevytvoří.

Transakční replikace

Použití transakční replikace s instancemi, které jsou ve skupině převzetí služeb při selhání, je podporováno. Pokud ale nakonfigurujete replikaci před přidáním spravované instance SQL do skupiny převzetí služeb při selhání, replikace se pozastaví, jakmile začnete vytvářet skupinu převzetí služeb při selhání, a monitor replikace zobrazí stav Replicated transactions are waiting for the next log backup or for mirroring partner to catch up. Replikace se obnoví po úspěšném vytvoření skupiny převzetí služeb při selhání.

Pokud je vydavatelská nebo distribuční spravovaná instance SQL ve skupině převzetí služeb při selhání, musí správce spravované instance SQL vyčistit všechny publikace na staré primární instanci a po selhání je znovu nakonfigurovat na nové primární instanci. Projděte si průvodce transakční replikací pro kroky aktivit, které v tomto scénáři potřebujete.

Oprávnění a omezení

Před konfigurací skupiny pro převzetí služeb při selhání zkontrolujte 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. Projděte si konfiguraci skupiny převzetí služeb při selhání a dozvíte se více.

Postup zotavení po havárii

Doporučený způsob, jak provést cvičení zotavení po havárii, je použití ručního plánovaného převzetí služeb při selhání podle následujícího návodu: Testovací převzetí služeb při selhání.

Realizace testu s použitím vynuceného failoveru se nedoporučuje, protože tato operace neposkytuje ochranné opatření proti ztrátě dat. Je však možné dosáhnout bezeztrátového vynuceného převzetí služeb zajištěním splnění následujících podmínek před zahájením tohoto procesu:

  • Úloha se zastaví v primární spravované instanci.
  • Všechny dlouhotrvající transakce byly dokončeny.
  • Všechna klientská připojení k primární spravované instanci byla odpojena.
  • Stav skupiny převzetí služeb při selhání je 'Synchronizuje'.

Než volitelně navážete připojení k nové primární spravované instanci a spustíte úlohu čtení a zápisu, ujistěte se, že si dvě spravované instance vyměnily role a že stav skupiny převzetí služeb při selhání se změnil z "Probíhá převzetí služeb při selhání" na "Synchronizace".

Pokud chcete provést navrácení bezeztrátově do původních rolí spravované instance, důrazně doporučujeme použít ruční plánovaný přechod při selhání místo vynuceného přechodu při selhání. Pokud se použije vynucený návrat:

  • Postupujte stejně jako při bezeztrátovém převzetí služeb při selhání.
  • Delší doba provádění vynuceného navrácení se očekává, pokud se spustí krátce po dokončení počátečního vynuceného převzetí, protože musí čekat na dokončení nevyřízených automatických operací zálohování v bývalé primární spravované instanci.
  • Všechny nevyhrazené automatické operace zálohování u spravované instance, která přechází z primární na sekundární roli, ovlivní dostupnost databáze na tuto instanci.
  • Pomocí stavu skupiny pro převzetí služeb při selhání zjistěte, zda obě instance úspěšně změnily své role a jsou připravené přijímat klientská připojení.

Související obsah