Sdílet prostřednictvím

Spolehlivost ve službě Azure SQL Database

Azure SQL Database je databázový stroj PaaS (platforma jako služba), který zpracovává většinu funkcí správy databází, jako je upgrade, opravy, zálohování a monitorování bez zásahu uživatele.

Při používání Azure je spolehlivost sdílenou odpovědností. Microsoft nabízí celou řadu možností, které podporují odolnost a obnovení. Zodpovídáte za pochopení toho, jak tyto možnosti fungují ve všech službách, které používáte, a výběrem možností, které potřebujete ke splnění vašich obchodních cílů a cílů dostupnosti.

Tento článek popisuje, jak zajistit odolnost služby Azure SQL Database vůči nejrůznějším potenciálním výpadkům a problémům, včetně přechodných chyb, výpadků zón dostupnosti a výpadků oblastí. Popisuje také, jak můžete použít zálohy k obnovení z jiných typů problémů, jak zvládnout údržbu služeb a zvýrazní některé klíčové informace o smlouvě o úrovni služeb (SLA) služby Azure SQL Database.

Doporučení pro nasazení do produkčního prostředí

Informace o nasazení služby Azure SQL Database pro podporu požadavků na spolehlivost vašeho řešení a o tom, jak spolehlivost ovlivňuje další aspekty architektury, najdete v tématu Osvědčené postupy architektury pro Azure SQL Database v architektuře Azure Well-Architected Framework.

Přehled architektury spolehlivosti

SQL Database běží na nejnovější stabilním databázovém stroji SQL Serveru operačního systému Windows, včetně všech použitelných oprav.

SQL Database dosahuje redundance tím, že ve výchozím nastavení ukládá tři kopie dat do jednoho datacentra v primární oblasti. Tento přístup chrání vaše data, pokud dojde k lokalizované chybě, jako je selhání sítě v malém měřítku nebo selhání napájení, a také během následujících událostí:

  • Operace správy iniciované zákazníkem, které vedou ke krátkému výpadku

  • Operace údržby služeb

  • Problémy a výpadky datacentra, ve kterých má datacentrum následující komponenty:

    • Racky, kde běží stroje, které využívají vaši službu

    • Fyzické počítače, které hostují virtuální počítač, na kterém běží databázový stroj SQL

  • Další problémy s databázovým strojem SQL

  • Další neplánované lokalizované výpadky

SQL Database ke správě replikace databáze používá Azure Service Fabric.

Redundance se implementuje různými způsoby pro různé úrovně služeb sql Database. Další informace najdete v tématu Dostupnost prostřednictvím redundance – SQL Database.

Odolnost proti přechodným chybám

Přechodné chyby jsou krátká, přerušovaná selhání ve složkách. V distribuovaném prostředí, jako je cloud, se vyskytují často a jsou normální součástí provozu. Přechodné chyby se opravují po krátké době. Je důležité, aby vaše aplikace mohly zpracovávat přechodné chyby, obvykle opakováním ovlivněných požadavků.

Všechny aplikace hostované v cloudu by měly při komunikaci se všemi cloudovými rozhraními API, databázemi a dalšími komponentami postupovat podle pokynů pro zpracování přechodných chyb Azure. Další informace najdete v tématu Doporučení pro zpracování přechodných chyb.

SQL Database automaticky zpracovává důležité úlohy údržby, jako jsou opravy, zálohy, upgrady windows a databázový stroj SQL. Zpracovává také neplánované události, jako jsou selhání hardwaru, softwaru nebo sítě. SQL Database je navržená tak, aby se rychle zotavila z kritických selhání, což zajišťuje, že vaše data budou vždy dostupná. Většina uživatelů si nevšimne, že se upgrady provádějí nepřetržitě.

Pokud je databáze opravená nebo převezme služby při selhání, výpadek nenaruší, pokud ve své aplikaci použijete logiku opakování .

Odolnost aplikace proti přechodným chybám můžete otestovat podle pokynů v části Testování odolnosti proti chybám aplikace.

Odolnost proti chybám zóny dostupnosti

Zóny dostupnosti jsou fyzicky oddělené skupiny datacenter v rámci oblasti Azure. Když jedna zóna selže, mohou služby přejít na jednu ze zbývajících zón.

Můžete vytvořit zónově redundantní jednoúčelovou databázi nebo elastický fond. Redundance zón zajišťuje odolnost databáze vůči velké sadě selhání, včetně katastrofických výpadků datacentra, bez jakýchkoli změn logiky aplikace.

Pro úroveň služby Pro obecné účely redundance zón zajišťuje, že bezstavové výpočetní komponenty i stavové komponenty úložiště dat služby SQL Database jsou odolné vůči výpadku zóny dostupnosti.

Pro úrovně služeb Premium, Pro důležité obchodní informace a Hyperscale umístí redundance zón repliky vaší databáze SQL napříč několika zónami dostupnosti Azure ve vaší primární oblasti. Aby se zabránilo jedinému bodu selhání (SPOF), řídicí okruh se také duplikuje napříč několika zónami dostupnosti.

Pokud chcete zobrazit informace o podpoře zón dostupnosti pro jiné úrovně služby, nezapomeňte na začátku této stránky vybrat příslušnou úroveň služby.

Požadavky

Úrovně služby Basic a Standard nepodporují redundanci zón.

Redundance zón je dostupná pro databáze v úrovních služby Pro důležité obchodní informace, Pro obecné účely a Hyperscale nákupního modelu založeného na virtuálních jádrech a pouze na úrovni služby Premium nákupního modelu založeného na DTU.

Pro úroveň služby Pro obecné účely:

Úrovně služeb Premium a Kritické podnikové služby.

Úroveň služby Hyperscale:

Pokud chcete zobrazit informace o podpoře zón dostupnosti pro jiné úrovně služby, nezapomeňte na začátku této stránky vybrat příslušnou úroveň služby.

Úvahy

  • Latence: Zónově redundantní databáze mají repliky v samostatných datacentrech. Přidaná latence sítě může zvýšit dobu potvrzení transakcí a potenciálně ovlivnit výkon určitých úloh zpracování online transakcí (OLTP). Většina aplikací není citlivá na tuto dodatečnou latenci.

  • master databáze: Při vytvoření databáze s zónově redundantní konfigurací na logickém serveru master se databáze přidružená k serveru také automaticky zónově redundantní. Další informace o tom, jak zkontrolovat, jestli je vaše master databáze zónově redundantní, najdete v tématu Zónově redundantní dostupnost databáze.

Pokud chcete zobrazit informace o podpoře zón dostupnosti pro jiné úrovně služby, nezapomeňte na začátku této stránky vybrat příslušnou úroveň služby.

Náklady

Pro úroveň služby Pro obecné účely se účtuje příplatek za povolení redundance zón pro službu SQL Database. Další informace najdete v tématu Ceny – SQL Database.

Úrovně služby Premium a Business Critical poskytují více replik databáze. Když povolíte redundanci zóny, repliky se distribuují mezi zóny dostupnosti. Tato distribuce znamená, že při povolování redundance zón ve vaší databázi SQL v případě, že je ve vrstvě služby Premium nebo Business Critical, nejsou spojené žádné další náklady.

Pokud povolíte více replik databáze vrstvy služby Hyperscale, můžete povolit redundanci zón. Když povolíte redundanci zóny, repliky se distribuují mezi zóny dostupnosti. Tato distribuce znamená, že při povolování redundance zón ve vaší databázi SQL v případě, že je ve vrstvě služby Hyperscale, nejsou spojené žádné další poplatky za předpokladu, že máte více replik.

Pokud chcete zobrazit informace o podpoře zón dostupnosti pro jiné úrovně služby, nezapomeňte na začátku této stránky vybrat příslušnou úroveň služby.

Konfigurujte podporu zón dostupnosti

Úrovně služby Pro obecné účely, Premium a Pro důležité obchodní informace:

Úroveň služby Hyperscale:

Pokud chcete zobrazit informace o podpoře zón dostupnosti pro jiné úrovně služby, nezapomeňte na začátku této stránky vybrat příslušnou úroveň služby.

Chování, když jsou všechny zóny v pořádku

Tato část popisuje, co očekávat, když jsou databáze nakonfigurované pro redundanci zón a všechny zóny dostupnosti jsou funkční.

Pro úroveň služby Pro obecné účely:

  • Směrování provozu mezi zónami: Požadavky se směrují do uzlu, na kterém běží výpočetní vrstva databáze SQL. Pokud je povolená redundance zóny, může se tento uzel nacházet v jakékoli zóně dostupnosti.

  • Replikace dat mezi zónami: Soubory dat a protokolů se synchronně replikují napříč zónami dostupnosti pomocí ZRS. Operace zápisu se nepovažují za dokončené, dokud se data úspěšně nereplikují napříč všemi zónami dostupnosti. Tato synchronní replikace zajišťuje silnou konzistenci a nulovou ztrátu dat během selhání zóny. Může ale způsobit mírně vyšší latenci zápisu v porovnání s místně redundantním úložištěm (LRS).

Úrovně služeb Premium a Kritické podnikové služby.

  • Směrování provozu mezi zónami: Repliky se distribuují napříč zónami dostupnosti a jedna z těchto replik je určená jako primární replika. Požadavky se směrují na primární repliku vaší databáze.

  • Replikace dat mezi zónami: Primární replika neustále odesílá změny do sekundárních replik postupně, aby se zajistilo, že se data uchovávají na dostatečném počtu sekundárních replik před potvrzením každé transakce. Tento proces zaručuje, že pokud primární nebo čitelný sekundární replika z nějakého důvodu nebudou k dispozici, bude plně synchronizovaná replika vždy dostupná pro převzetí služeb při selhání. Pokud je povolená redundance zón, tyto repliky se nacházejí v různých zónách dostupnosti. Proces ale může mít za následek mírně vyšší latenci zápisu kvůli latenci sítě při procházení zón.

Úroveň služby Hyperscale:

  • Směrování provozu mezi zónami: Repliky databáze se distribuují napříč zónami dostupnosti a jedna z těchto replik je určená jako primární replika. Požadavky se směrují na primární repliku vaší databáze.

  • Replikace dat mezi zónami: Replika primární databáze odesílá změny prostřednictvím zónově redundantní služby protokolu, která replikuje všechny změny synchronně napříč zónami dostupnosti. Stránkové servery se nacházejí v každé zóně dostupnosti a ukládají stav databáze. Tento proces zaručuje, že pokud primární nebo čitelná sekundární replika z nějakého důvodu nebudou k dispozici, bude plně synchronizovaná replika vždy dostupná pro převzetí služeb při selhání. Tento proces ale může mít za následek mírně vyšší latenci zápisu v porovnání s LRS.

Pokud chcete zobrazit informace o podpoře zón dostupnosti pro jiné úrovně služby, nezapomeňte na začátku této stránky vybrat příslušnou úroveň služby.

Chování při selhání zóny

Tato část popisuje, co očekávat, když jsou databáze nakonfigurované pro redundanci zón a dojde k výpadku zóny dostupnosti.

  • Detekce a odpověď: SQL Database zodpovídá za detekci selhání v zóně dostupnosti a odpovídá na ně. Nemusíte dělat nic, abyste zahájili převzetí zóny.
  • Oznámení: Microsoft vás automaticky neoznámí, když je zóna mimo provoz. Azure Service Health ale můžete použít k pochopení celkového stavu služby, včetně jakýchkoli selhání zón, a můžete nastavit upozornění služby Service Health , která vás upozorní na problémy.
  • Aktivní požadavky: Když zóna dostupnosti přejde do režimu offline, všechny požadavky, které se zpracovávají v vadné zóně dostupnosti, se ukončí a musí se opakovat. Další informace o tom, jak zajistit odolnost aplikací vůči těmto typům problémů, najdete v pokynech k odolnosti proti přechodným chybám .

  • Přesměrování provozu: Pro úroveň služby Pro obecné účely služba SQL Database přesune databázový stroj do jiného bezstavového výpočetního uzlu, který je v jiné zóně dostupnosti a má dostatečnou bezplatnou kapacitu. Po dokončení převzetí služeb při selhání se nová připojení automaticky přesměrují na nový primární výpočetní uzel.

    Další informace najdete v tématu Úroveň služby Pro obecné účely.

  • Přesměrování provozu: Pro úrovně služeb Premium a Pro důležité obchodní informace vybere služba SQL Database repliku v jiné zóně dostupnosti, aby se stala primární replikou. Jakmile se sekundární replika stane novou primární replikou, vytvoří se další sekundární replika, aby se zajistilo, že cluster má dostatečný počet replik pro zachování kvora. Po dokončení převzetí služeb při selhání se nová připojení automaticky přesměrují na novou primární repliku (nebo čitelnou sekundární repliku na základě připojovacího řetězce).

    Další informace najdete v části Úrovně služeb Premium a Business Critical.

  • Přesměrování provozu: Pokud došlo ke ztrátě primární repliky kvůli výpadku zóny, podporuje SQL Database u úrovně služby Hyperscale jednu z replik s vysokou dostupností v jiné zóně jako novou primární.

    Další informace najdete v tématu Úroveň služby Hyperscale.

  • Očekávaný výpadek: Během převzetí služeb při selhání zóny dostupnosti může dojít k malému výpadku. Výpadek je obvykle kratší než 30 sekund, což by vaše aplikace měla tolerovat, pokud se bude postupovat podle pokynů k odolnosti vůči přechodným chybám .

  • Očekávaná ztráta dat: Během převzetí služeb při selhání zóny dostupnosti se neočekává žádná ztráta dat.

Pokud chcete zobrazit informace o podpoře zón dostupnosti pro jiné úrovně služby, nezapomeňte na začátku této stránky vybrat příslušnou úroveň služby.

Obnovení zóny

Když se zóna dostupnosti obnoví, Azure Service Fabric automaticky vytvoří repliky databáze v obnovené zóně dostupnosti, odebere všechny dočasné repliky vytvořené v jiných zónách dostupnosti a obnoví normální směrování provozu do vaší databáze. Aby nedošlo k přerušení, primární replika po obnovení zóny automaticky nevrátí původní zónu.

Testování poruch zón

Platforma SQL Database spravuje postupy směrování provozu, převzetí služeb při selhání a obnovení zón pro zónově redundantní databáze. Vzhledem k tomu, že je tato funkce plně spravována, nemusíte zahajovat ani ověřovat procesy selhání zóny dostupnosti. Můžete ověřit, jak vaše aplikace zpracovává selhání a převzetí služeb při selhání, podle procesu popsaného v Testování odolnosti aplikace proti chybám.

Odolnost proti selháním v celé oblasti

Tato část obsahuje přehled dvou souvisejících, ale samostatných funkcí, které je možné použít pro geografickou replikaci služby SQL Database ve více oblastech:

Aktivní geografická replikace

Aktivní geografická replikace vytvoří nepřetržitě synchronizovanou sekundární databázi (která se někdy označuje jako geografická sekundární nebo geografická replika) v jakékoli oblasti pro jednu primární databázi. Aktivní geografická replikace může ve stejné oblasti vytvářet sekundární databáze, ale tato konfigurace neposkytuje ochranu před výpadkem oblasti. Pokud k dosažení geografické redundance použijete aktivní geografickou replikaci, vyhledáte sekundární databázi v jiné oblasti s primární databází.

Požadavky

Při použití aktivní geografické replikace zvažte následující požadavky:

  • Podpora oblastí:Aktivní geografická replikace je možné povolit ve všech oblastech Azure a nevyžaduje použití párů oblastí Azure.

    Návod

    SQL Database se řídí bezpečným postupem nasazení, kdy Se Azure snaží nenasazovat aktualizace do spárovaných oblastí současně. Pokud nakonfigurujete aktivní geografickou replikaci tak, aby používala nepopisované oblasti, nastavte pro servery v každé oblasti různá časová období údržby. Tento přístup pomáhá snížit pravděpodobnost, že obě oblasti mají problémy s připojením způsobené údržbou najednou.

  • Konfigurace: Primární i sekundární geografická oblast musí mít stejnou úroveň služby a měla by mít stejnou výpočetní úroveň, velikost výpočetních prostředků a redundanci úložiště zálohování.

  • Brána firewall: Primární i geograficky sekundární by měly mít stejná pravidla brány firewall pro IP adresy.

  • Předplatná Azure: Aktivní geografická replikace se podporuje pro databáze napříč různými předplatnými Azure.

Úvahy

  • Aktivní geografická replikace je navržena tak, aby poskytovala převzetí funkcí při selhání jedné databáze. Pokud potřebujete převzít služby při selhání více databází, zvažte místo toho použití skupin převzetí služeb při selhání.

  • Vzhledem k tomu, že geografická replikace je asynchronní, může dojít ke ztrátě dat, když dojde k převzetí služeb při selhání. Pokud potřebujete během převzetí služeb při selhání eliminovat ztrátu dat z asynchronní replikace, nakonfigurujte aplikaci tak, aby blokovala volající vlákno, dokud se nepřenese a nezpevní poslední potvrzená transakce v transakčním protokolu sekundární databáze. Tento přístup vyžaduje vlastní vývoj a snižuje výkon vaší aplikace. Další informace naleznete v tématu Prevence ztráty důležitých dat.

  • Další informace o omezeních a aspektech najdete v tématu Aktivní geografická replikace.

Náklady

Sekundární databáze se účtují jako samostatné databáze.

Pokud pro žádné úlohy čtení nebo zápisu nepoužíváte sekundární databázi, zvažte, jestli ji můžete určit jako pohotovostní repliku , abyste snížili náklady.

Konfigurace podpory více oblastí

Chování, když jsou všechny oblasti v pořádku

Tato část popisuje, co očekávat, když je databáze nakonfigurovaná tak, aby používala aktivní geografickou replikaci a všechny oblasti jsou funkční.

  • Směrování provozu mezi oblastmi: Aplikace musí být nakonfigurovaná tak, aby odesílala požadavky na čtení i zápis do primární databáze. Volitelně můžete posílat požadavky jen pro čtení do sekundární databáze, což pomáhá snížit dopad úloh jen pro čtení na primární databázi.

  • Replikace dat mezi oblastmi: Replikace mezi primární a sekundární databází probíhá asynchronně, což znamená, že mezi okamžikem, kdy se na primární databázi použije změna a kdy se replikuje do sekundární databáze, může dojít ke zpoždění.

    Při provádění failoveru se rozhodnete, jak zvládnout možnost ztráty dat.

Chování při selhání oblasti

Tato část popisuje, co očekávat, když je databáze nakonfigurovaná tak, aby používala aktivní geografickou replikaci, a v primární oblasti došlo k výpadku:

  • Detekce a odpověď: Zodpovídáte za zjištění výpadku databáze nebo oblasti a za aktivaci převzetí služeb při selhání.
  • Oznámení: Microsoft vás automaticky neoznámí, když je oblast mimo provoz. Můžete ale použít Azure Service Health k pochopení celkového stavu služby, včetně všech selhání oblastí, a můžete nastavit upozornění služby Health, která vás upozorní na problémy.

  • Aktivní požadavky: Všechny aktivní žádosti během převzetí služeb při selhání se ukončí a je nutné je opakovat.

  • Očekávaná ztráta dat: Pokud je vaše primární databáze dostupná, můžete případně provést přepnutí bez ztráty dat. Proces failoveru synchronizuje data mezi primární a sekundární databází před změnou rolí.

    Pokud vaše primární databáze není dostupná, možná budete muset provést vynucené převzetí služeb při selhání, což vede ke ztrátě dat. Velikost ztráty dat můžete odhadnout monitorováním prodlevy replikace. Další informace najdete v tématu Monitorování služby SQL Database s metrikami a upozorněními.

  • Očekávaný výpadek: Během převzetí služeb při selhání je obvykle až 60 sekund výpadků. Ujistěte se, že vaše aplikace zpracovává přechodné chyby , aby se mohly zotavit z krátkých období výpadků. Také to, jak rychle překonfigurujete aplikaci tak, aby se připojila k nové primární databázi, ovlivňuje výpadky, které máte.

  • Přesměrování provozu: Zodpovídáte za překonfigurování aplikace tak, aby odesílala požadavky do nové primární databáze. Pokud potřebujete transparentní převzetí služeb při selhání, zvažte použití skupin převzetí služeb při selhání.

Obnovení oblasti

Po obnovení primární oblasti můžete ručně provést návrat do primární oblasti provedením nového převzetí služeb při selhání.

Testování selhání regionů

Výpadek oblasti můžete simulovat tak, že kdykoli spustíte ruční převedení na záložní systém. Můžete aktivovat přepnutí (bez ztráty dat) nebo vynucené přepnutí.

Skupiny převzetí služeb při selhání

Skupiny převzetí služeb při selhání vycházejí z aktivní geografické replikace. Se skupinami převzetí služeb při selhání můžete provádět následující operace:

  • Replikujte sadu databází z jednoho logického serveru napříč libovolnou kombinací oblastí Azure.

  • Proveďte převzetí služeb při selhání databází jako skupina.

  • Použijte koncové body připojení, které automaticky směrují připojení k primárnímu serveru.

Požadavky

  • Podpora oblastí: Skupiny dostupnosti je možné vytvořit ve všech oblastech Azure a nevyžadují použití párů oblastí Azure.

    Návod

    Pokud nakonfigurujete skupinu převzetí služeb při selhání s nepairovanými oblastmi, zvažte nastavení různých časových intervalů údržby pro servery v každé oblasti. Tento přístup pomáhá snížit pravděpodobnost, že obě oblasti mají problémy s připojením způsobené údržbou najednou.

  • Konfigurace: Sekundární databáze ve skupině převzetí služeb při selhání by měly mít stejnou úroveň služby, výpočetní úroveň, velikost výpočetních prostředků, pravidla brány firewall IP adres a redundanci úložiště zálohování jako primární databáze.

Úvahy

  • Redundance zón: Pokud je pro úroveň služby Hyperscale povolená redundance primární databáze, sekundární databáze mají povolenou redundanci zón automaticky.
  • Redundance zón: Sekundární databáze nemají ve výchozím nastavení povolenou redundanci zón, ale můžete ji povolit později.

  • Možná ztráta dat: Vzhledem k tomu, že geografická replikace je asynchronní, může při selhání dojít ke ztrátě dat. Pokud potřebujete eliminovat ztrátu dat z asynchronní replikace během převzetí služeb při selhání, můžete nakonfigurovat aplikaci tak, aby blokovala volající vlákno, dokud se nepřenese a nezpevní poslední potvrzená transakce v transakčním protokolu sekundární databáze. Tento přístup vyžaduje vlastní vývoj a snižuje výkon vaší aplikace. Další informace naleznete v tématu Prevence ztráty důležitých dat.

  • Další informace o omezeních a aspektech najdete v tématu Skupiny převzetí služeb při selhání.

Náklady

Sekundární databáze se účtují jako samostatné databáze.

Pokud pro žádné úlohy čtení nebo zápisu nepoužíváte sekundární databázi, zvažte, jestli ji můžete určit jako pohotovostní repliku , abyste snížili náklady.

Konfigurace podpory více oblastí

  • Povolení skupin převzetí služeb při selhání: Skupinu převzetí služeb při selhání nakonfigurujete na logickém serveru. Do skupiny převzetí služeb při selhání můžete přidat všechny databáze na logickém serveru nebo můžete vybrat podmnožinu databází, které chcete přidat.

    Při vytváření skupiny převzetí služeb při selhání vyberete zásadu převzetí služeb při selhání, která určuje, kdo je zodpovědný za zjištění výpadku a provedení převzetí služeb při selhání. Můžete nakonfigurovat převzetí služeb při selhání spravované zákazníkem, což se doporučuje nebo převzetí služeb při selhání spravované Microsoftem.

    Důležité

    Převzetí služeb při selhání iniciované Microsoftem se pravděpodobně objeví po významném zpoždění a provádí se na základě nejlepšího úsilí. Převzetí služeb při selhání databází může nastat v jiném okamžiku, než dojde k převzetí služeb při selhání jiných služeb Azure. Další informace najdete v tématu Konfigurace skupiny převzetí služeb při selhání pro SLUŽBU SQL Database.

    Po nakonfigurování skupiny převzetí služeb při selhání může počáteční krok nějakou dobu trvat.

  • Zakázání skupin převzetí služeb při selhání: Jednotlivé databáze můžete odebrat ze skupiny převzetí služeb při selhání, odebrat celou skupinu převzetí služeb při selhání nebo přesunout databázi do jiné skupiny převzetí služeb při selhání.

Chování, když jsou všechny oblasti v pořádku

Tato část popisuje, co očekávat, když je databáze nakonfigurovaná ve skupině pro převzetí služeb při selhání (failover group) a všechny oblasti jsou funkční.

  • Směrování provozu mezi oblastmi: Pro úlohy jen pro čtení a čtení poskytují skupiny převzetí služeb při selhání dva koncové body naslouchacího procesu, kde můžete připojit aplikace. Koncové body naslouchacího procesu skupiny převzetí služeb při selhání použijte k minimalizaci výpadků během převzetí služeb při selhání. Během normálních operací dojde k následujícímu chování směrování:

    • Koncový bod naslouchacího procesu pro čtení i zápis směruje všechny požadavky na primární databáze.

    • Koncový bod naslouchacího procesu jen pro čtení směruje všechny požadavky do čitelné sekundární databáze.

  • Replikace dat mezi oblastmi: Geografická replikace mezi primární a sekundární databází probíhá asynchronně. Tato latence znamená, že mezi změnou použitou v primární databázi a replikací do sekundární databáze může dojít ke zpoždění.

    Při provádění failoveru se rozhodnete, jak zvládnout možnost ztráty dat.

Chování při selhání oblasti

Tato část popisuje, co očekávat, když je databáze nakonfigurovaná v rámci skupiny pro převzetí služeb při selhání a v primární oblasti dojde k výpadku:

  • Detekce a odpověď závisí na zásadách převzetí služeb při selhání, které používáte.

    • Převzetí služeb při selhání iniciované zákazníkem: Zodpovídáte za zjištění výpadku databáze nebo oblasti a za aktivaci převzetí služeb při selhání.

    • Převzetí služeb při selhání iniciované Microsoftem: Microsoft aktivuje převzetí služeb při selhání pro všechny skupiny převzetí služeb při selhání v ovlivněné oblasti. Microsoft očekává, že tento typ převzetí služeb při selhání provede pouze v výjimečných situacích. U většiny řešení se nespoléhejte na převzetí služeb při selhání spravovaném Microsoftem. Další informace najdete v tématu Zásady převzetí služeb při selhání – spravované Microsoftem.

  • Oznámení: Microsoft vás automaticky neoznámí, když je oblast mimo provoz. Můžete ale použít Azure Service Health k pochopení celkového stavu služby, včetně všech selhání oblastí, a můžete nastavit upozornění služby Health, která vás upozorní na problémy.

  • Aktivní požadavky: Všechny aktivní žádosti během převzetí služeb při selhání se ukončí a je nutné je opakovat.

  • Očekávaná ztráta dat: Ztráta dat závisí na zásadách převzetí služeb při selhání, které používáte.

    • Převzetí služeb při selhání iniciované zákazníkem: Pokud je vaše primární databáze dostupná, můžete volitelně provést převzetí služeb při selhání bez ztráty dat. Proces failoveru synchronizuje data mezi primární a sekundární databází před změnou rolí.

      Pokud vaše primární databáze není dostupná, možná budete muset provést vynucené převzetí služeb při selhání, což vede ke ztrátě dat. Velikost ztráty dat můžete odhadnout monitorováním prodlevy replikace. Další informace najdete v tématu Monitorování služby SQL Database s metrikami a upozorněními.

    • Převzetí služeb při selhání iniciované Microsoftem: Převzetí služeb při selhání spravované Microsoftem se aktivuje pouze v výjimečných situacích. Vynucená převzetí služeb při selhání spravovaná Microsoftem znamenají, že lze očekávat určitou ztrátu dat. Nemůžete řídit množství ztráty dat, ke které může dojít.

  • Očekávaný výpadek: Výpadek závisí na zásadách převzetí služeb při selhání, které používáte.

    • Převzetí služeb při selhání iniciované zákazníkem: Během převzetí služeb při selhání je obvykle až 60 sekund výpadků. Ujistěte se, že vaše aplikace zpracovává přechodné chyby , aby se mohly zotavit z krátkých období výpadků.

    • Převzetí služeb při selhání iniciované Microsoftem: Můžete zadat období odkladu , které určuje, jak dlouho má Microsoft čekat před zahájením převzetí služeb při selhání. Minimální období odkladu je jedna hodina. Doba odezvy Microsoftu ale bude pravděpodobně minimálně několik hodin.

  • Přesměrování provozu: Během převzetí služeb při selhání sql Database aktualizuje koncové body naslouchacího procesu jen pro čtení a pro čtení, aby podle potřeby směrovat provoz do nových primárních a sekundárních databází.

    Pokud nová sekundární databáze (dříve primární databáze) není dostupná, koncový bod naslouchacího procesu jen pro čtení se nemůže připojit, dokud nebude k dispozici nová sekundární databáze.

Obnovení oblasti

V případě potřeby jste odpovědní za přesměrování zpět do primárního regionu. Navrácení do primární oblasti můžete provést ručně prostřednictvím zákaznicky spravovaného převzetí služeb při selhání.

I když Microsoft inicioval původní převzetí při selhání, zodpovídáte za vrácení do původní oblasti, pokud se rozhodnete.

Testování selhání regionů

Výpadek oblasti můžete simulovat tak, že kdykoli spustíte ruční převedení na záložní systém. Můžete aktivovat přepnutí (bez ztráty dat) nebo vynucené přepnutí.

Zálohování a obnovení

Zálohujte databáze, které chrání před různými riziky, včetně ztráty dat. Zálohy je možné obnovit, aby se zotavily z náhodné ztráty dat, poškození nebo jiných problémů. Zálohy se liší od redundance zón, aktivní geografické replikace nebo skupin převzetí služeb při selhání a mají různé účely. Další informace najdete v tématu Redundance, replikace a zálohování.

SQL Database poskytuje automatické zálohy vašich databází. Další informace o frekvenci zálohování, která může ovlivnit ztrátu dat, pokud potřebujete provést obnovení ze zálohy, najdete v tématu Automatizované zálohy ve službě SQL Database.

Úložiště zálohování

Můžete zvolit ukládání automatizovaných záloh do LRS nebo ZRS. Pokud používáte spárovanou oblast, můžete zvolit replikaci automatizovaných záloh do spárované oblasti pomocí geograficky redundantního úložiště. Tato funkce umožňuje geografické obnovení záloh do spárované oblasti. Další informace naleznete v tématu Automatizované zálohování ve službě SQL Database.

Pokud používáte nepárovanou oblast, nebo pokud potřebujete replikovat zálohy do jiné než spárované oblasti, zvažte export databáze a uložení exportovaného souboru do účtu úložiště, který k replikaci používá replikaci objektů blob do účtu úložiště v jiné oblasti. Další informace naleznete v tématu Export databáze.

Odolnost vůči údržbě služeb

Když SQL Database provádí údržbu vašich databází a elastických fondů, může automaticky převzít služby při selhání databáze, aby používala sekundární repliku. Když dojde k převzetí služeb při selhání, můžou klientské aplikace pozorovat krátké přerušení připojení. Vaše klientské aplikace by měly postupovat podle pokynů k odolnosti a přechodným chybám , aby se minimalizovaly účinky.

SQL Database umožňuje zadat časové období údržby, které se obvykle používá pro upgrady služeb a další operace údržby. Konfigurace časového období údržby vám může pomoct minimalizovat vedlejší účinky, jako jsou automatické převzetí služeb při selhání, během pracovní doby. Můžete také obdržet předběžné oznámení o plánované údržbě.

Platforma automaticky udržuje brány používané ke zpracování připojení ke službě SQL Database. Upgrady nebo operace údržby můžou také způsobit krátké přerušení připojení, které můžou klienti opakovat.

Další informace naleznete v tématu Časové období údržby ve službě SQL Database.

Smlouva o úrovni služeb

Smlouva o úrovni služeb (SLA) pro služby Azure popisuje očekávanou dostupnost každé služby a podmínky, které musí vaše řešení splnit, aby bylo dosaženo očekávané dostupnosti. Další informace najdete v tématu Smlouvy SLA pro online služby.

Smlouva o úrovni služeb (SLA) pro SLUŽBU SQL Database popisuje očekávanou dostupnost služby a očekávanou dobu obnovení a dobu obnovení pro aktivní geografickou replikaci.

Když nasadíte zonálně redundantní databázi nebo elastický fond a použijete podporovanou úroveň služby, SLA dostupnosti bude vyšší.

Související obsah

  • Last updated on