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

Platí pro:Azure SQL Managed Instance

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 použití se službou 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 SQL do jiné oblasti Azure.

Pokud chcete začít, 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í z jedné spravované instance SQL do jiné spravované instance SQL 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 převzetí služeb při selhání poskytují naslouchací koncové body pro čtení a zápis a pouze pro čtení, které se během geografického převzetí služeb při selhání nemě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.
  • Microsoft managed – 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í Jedna nebo více databází ve skupině 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 regionu způsobuje nedostupnost databází a tým Microsoft Azure SQL služeb se rozhodne aktivovat vynucené převzetí služeb.
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.
Převzetí služeb při selhání spravované Microsoftem se může spouštět pouze za extrémních okolností. Důrazně se doporučuje zákazníkem spravovaná zásada pro převzetí při selhání.		 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í, které databáze používají. 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 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 oblasti jsou ovlivněny.
  • 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ásadu převzetí služeb při selhání spravovanou 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í. Spravované převzetí služeb při selhání Microsoftu se zahájí pro všechny skupiny převzetí služeb při selhání v oblasti, které mají nastavené zásady převzetí služeb při selhání nastavené na správu Microsoftu. Nejde ho zahájit pro jednotlivé skupiny převzetí služeb při selhání. Pokud potřebujete selektivně převzít služby při selhání skupiny převzetí služeb při selhání, použijte zásady převzetí služeb 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ř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 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í.
  • Primární a sekundární repliky ve skupině převzetí služeb při selhání mají stejnou úroveň služby, úroveň výpočetních prostředků a velikost výpočetních prostředků.

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 převzetí služeb při selhání umožňuje, aby všechny uživatelské databáze ve spravované instanci SQL mohly převzít služby při selhání jako jednotka do jiného regionu Azure, pokud se primární spravovaná instance SQL stane nedostupnou kvůli výpadku primárního regionu. 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 SQL, která funguje jako hostitel primárních databází v rámci skupiny převzetí služeb při selhání.

  • Sekundární

    Spravovaná instance SQL, která je hostitelem sekundárních databází ve skupině pro převzetí. 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 SQL ve stejné skupině pro 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 pro převzetí služeb při selhání ve spravované instanci SQL se záznam DNS CNAME pro URL naslouchacího procesu 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 pro převzetí služeb při selhání ve spravované instanci SQL se záznam DNS CNAME pro URL naslouchacího procesu 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 hodnotu True, nový primární server obsluhuje jak relace pro čtení a zápis, tak relace pouze pro čtení.

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

Skupina failover musí být nakonfigurována na primární instanci a být připojena k sekundární instanci v jiné oblasti Azure. Všechny uživatelské databáze v primární instanci se replikují do sekundární instance. Systémové databáze jako master a msdb nereplikují se.

Následující diagram znázorňuje typickou konfiguraci geograficky redundantní cloudové aplikace využívající spravovanou instanci SQL 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í ke spravované SQL instanci po přepnutí, 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 provést zadáním volitelného parametru při vytváření instance. 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 SQL 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 důvodů výkonu nasaďte obě spravované instance SQL 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 upgraduje jako první, 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, ze které si můžete vybrat v závislosti na topologii sítě a zásadách:

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. Komunikace mezi partnerskými virtuálními sítěmi nevyžaduje 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 SQL je 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 seedování se data synchronizují a replikují se pouze následné změny dat. Doba potřebnou k dokončení počátečního počátečního nasazení závisí na velikosti dat, počtu replikovaných databází, intenzitě úloh na primárních databázích a rychlosti propojení mezi virtuálními sítěmi, které jsou hostitelem primární a sekundární instance, což většinou 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ě, ale 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 zadanou počáteční rychlost, počet používaných databází, celkovou velikost dat a rychlost propojení k odhadnutí, jak dlouho trvá úvodní fáze před tím, 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 je k replikaci více databází, provede se počáteční nasazení paralelně. V kombinaci s pomalou rychlostí propojení může počáteční 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é

Počáteční fáze počátečního seedingu může trvat dny s extrémně nízkými rychlostmi nebo zaneprázdněnými spojeními. V takovém případě může dojít k časovému vypršení při pokusu o vytvoření skupiny převzetí služeb při selhání. Vytvoření skupiny převzetí služeb při selhání se po šesti dnech automaticky zruší.

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

Skupina převzetí služeb při selhání spravuje geografické převzetí služeb při selhání všech databází v primární spravované instanci SQL. 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 je databáze odstraněna na primární spravované instanci SQL, automaticky bude odstraněna i na geosekundární spravované instanci SQL.

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í při selhání zahrnuje aktualizaci záznamu DNS, takže nová klientská připojení se směrují do nového primárního serveru až po aktualizaci DNS klientské mezipaměti. 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íť. Posluchač pro čtení a zápis a posluchač pouze pro čtení nelze dosáhnout prostřednictvím veřejného koncového bodu spravované instance SQL.

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í služba pro čtení i zápis a služba pouze pro čtení nejsou dostupné prostřednictvím veřejného koncového bodu pro spravovanou instanci SQL.

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ýpadek nemusí mít vliv na jiné služby Azure v primární oblasti a jejich komponenty můžou být v této oblasti 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 přístup k součástem aplikace v případě selhání společně s databází, aby zvýšená latence mezi oblastmi neměla vliv na výkon aplikace.

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 nemusely být replikovány do geo-sekundární oblasti a v případě vynuceného přepnutí 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ž pět 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 SQL 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í jen jednu repliku a replika musí být buď replikou pro čtení, nebo určena jako replika pouze pro DR.

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í, nezapomeňte vytvořit stejné objekty v sekundární instanci. 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 shodným 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í oddělené od prostředků Azure a do sekundární instance se automaticky nereplikují žádné změny konfigurace primá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

Konfigurace primární a sekundární instance by měla být stejná. To zahrnuje velikost výpočetních prostředků, velikost úložiště a úroveň služby. Pokud potřebujete změnit konfiguraci skupiny převzetí služeb při selhání, můžete to udělat tak, že každou instanci odpovídajícím způsobem škálujete na stejnou konfiguraci. Další informace najdete v tématu Škálování instancí ve skupině 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. Informace o ochraně dat najdete v tématu Ochrana před ztrátou dat.

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í seeding: Počáteční seeding proběhne po vytvoření skupiny pro obnovu po selhání, dokud se neinicializují všechny uživatelské databáze v sekundární instanci. Převzetí služeb při selhání nejde zahájit, když je skupina převzetí služeb při selhání ve stavu Počáteční, protože uživatelské databáze se ještě nezkopírují do sekundární instance.
  • Synchronizace: Obvyklý stav skupiny pro převzetí 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 být změny dat z primárního serveru, které ještě nebyly replikovány na sekundární server. Obě převzetí služeb při selhání, automatické i ruční, mohou být zahájeny, když je skupina převzetí služeb při selhání ve stavu Synchronizační.
  • Probíhá převzetí služeb při selhání: Tento stav označuje, že probíhá převzetí služeb při selhání automaticky nebo ručně iniciované převzetí služeb při selhání. Pokud je skupina převzetí služeb při selhání v tomto stavu, není možné zahájit žádné změny skupiny převzetí služeb při selhání 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, vynucené převzetí služeb při selhání na geograficky sekundární server se zahájí 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.

Vezměte v úvahu následující skutečnosti:

  • Databáze hostované v sekundární instanci skupiny převzetí služeb při selhání se nezálohují, dokud se tato instance po převzetí služeb při selhání nestane primárním nebo dokud se skupina převzetí služeb při selhání nezařadí.
  • Jakmile se databáze změní na primární roli po převzetí služeb při selhání nebo se stane samostatnou po vyřazení skupiny převzetí služeb při selhání, automaticky se zahájí úplná záloha databáze, aby se usnadnilo obnovení k určitému bodu v čase.
  • Databázi nelze obnovit z instance do bodu v čase, kdy byla tato instance sekundární replikou ve skupině převzetí služeb při selhání. Chcete-li provést obnovení k určitému bodu v čase, je nutné obnovit databázi z instance, která byla primární během tohoto bodu v čase.
  • Pokud chcete znovu vytvořit vyřazenou skupinu převzetí služeb při selhání ve stejné dvojici spravovaných instancí SQL, je potřeba po vyřazení skupiny převzetí služeb při selhání odebrat všechny uživatelské databáze ze zamýšlené sekundární oblasti. Databáze se úplně odebere až po dokončení všech čekajících operací zálohování, včetně úplného zálohování, pokud nebyla provedena (což je operace velikosti dat). Dopřejte si čas na vyřešení sekundární instance po odstranění skupiny pro převzetí služeb při selhání s velmi velkými databázemi, protože každá databáze může mít probíhající operaci úplného zálohování.

Úplná záloha je datová operace, kterou nelze přeskočit ani odložit a její dokončení může nějakou dobu trvat. 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í replikaci a může buď zpozdit, nebo zabránit operaci přepnutí na zálohovací systém na nové instanci krátce po přepnutí.

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í, když začnete vytvářet skupinu převzetí služeb při selhání. Monitorování replikace zobrazuje 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. Další informace najdete v tématu Konfigurace skupiny převzetí služeb při selhání .

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

Provedení cvičení pomocí vynuceného přepnutí se nedoporučuje, protože tato operace neposkytuje ochranu 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 SQL.
  • Všechny dlouhotrvající transakce byly dokončeny.
  • Všechna klientská připojení k primární spravované instanci SQL byla odpojena.
  • Stav skupiny převzetí služeb při selhání je 'Synchronizuje'.

Ujistěte se, že dvě spravované instance SQL přepnuly role. Stav failover skupiny se také změnil z 'Převzetí služeb při selhání probíhá' na 'Synchronizace' před volitelným navázáním připojení k nové primární spravované instanci SQL a spuštěním úlohy čtení a zápisu.

Aby bylo možné provést bezeztrátový návrat do původních rolí spravované instance SQL, důrazně doporučujeme použít ruční plánované převzetí služeb místo vynuceného převzetí. Pokud se použije vynucený návrat:

  • Postupujte stejně jako při bezeztrátovém převzetí služeb při selhání.
  • Očekává se delší doba provádění zpětného převzetí služeb, pokud se vynucené zpětné převzetí provede krátce po dokončení počátečního vynuceného převzetí služeb, protože musí čekat na dokončení nevyřízených automatických operací zálohování na dřívější primární instanci spravované SQL.
  • Všechny nevyhrazené automatické operace zálohování u instance, která přechází z primární na sekundární roli, můžou mít vliv na dostupnost databáze v této 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

  • Last updated on