Sdílet prostřednictvím

Pokyny k zotavení po havárii – Azure SQL Database

  • Článek

Platí pro: Azure SQL Database

Azure SQL Database poskytuje špičkovou záruku vysoké dostupnosti minimálně 99,99 % pro podporu široké škály aplikací, včetně klíčového cíle, které musí být vždy dostupné. Azure SQL Database má také klíčové funkce provozní kontinuity, které můžete provést pro rychlé zotavení po havárii v případě regionálního výpadku. Tento článek obsahuje cenné informace ke kontrole před nasazením aplikace.

I když neustále usilujeme o zajištění vysoké dostupnosti, dochází k výpadkům služby Azure SQL Database, které způsobují nedostupnost vaší databáze, a tím ovlivní vaši aplikaci. Když naše monitorování služeb zjistí problémy, které způsobují rozsáhlé chyby připojení, chyby nebo problémy s výkonem, služba automaticky deklaruje výpadek, který vás bude informovat.

Výpadek služby

V případě výpadku služby Azure SQL Database najdete další podrobnosti týkající se výpadku na následujících místech:

  • Banner webu Azure Portal

    Pokud je vaše předplatné identifikované jako ovlivněné, na webu Azure Portal se zobrazí upozornění na výpadek problému se službou:

    Snímek obrazovky webu Azure Portal s oznámením o problému se službou Azure SQL Database

  • Nápověda a podpora a řešení potíží

    Když vytvoříte lístek podpory z nápovědy a podpory nebo podpory a řešení potíží, najdete informace o jakýchkoli problémech, které mají vliv na vaše prostředky. Pokud chcete zobrazit další informace a souhrn dopadu, vyberte Zobrazit podrobnosti o výpadku. Na stránce Nová žádost o podporu je také upozornění.

    Snímek obrazovky se stránkou Nápověda a podpora zobrazující oznámení o aktivním problému se stavem služby

  • Stav služby

    Stránka Service Health na webu Azure Portal obsahuje informace o stavu datového centra Azure globálně. Na panelu hledání na webu Azure Portal vyhledejte stav služby a pak zobrazte problémy se službou v kategorii Aktivní události . Stav jednotlivých prostředků můžete zobrazit také na stránce Stav prostředku libovolného prostředku v nabídce Nápověda . Následuje ukázkový snímek obrazovky se stránkou Service Health s informacemi o aktivním problému se službou v jihovýchodní Asii:

    Snímek obrazovky se stránkou Stavu služby na webu Azure Portal během problému se službou v jihovýchodní Asii zobrazující problém a mapu ovlivněných prostředků

  • E-mailové oznámení

    Pokud jste nastavili upozornění, odešle se e-mailové oznámení, když azure-noreply@microsoft.com výpadek služby ovlivní vaše předplatné a prostředek. Text e-mailu obvykle začíná upozorněním protokolu aktivit ... aktivoval problém se službou pro předplatné Azure.... Další informace o upozorněních na stav služby najdete v tématu Příjem upozornění protokolu aktivit na oznámeních služby Azure pomocí webu Azure Portal.

  • Metrika dostupnosti

    Na webu Azure Portal můžete monitorovat a konfigurovat upozornění na metriku dostupnosti služby Azure SQL Database.

Kdy zahájit zotavení po havárii během výpadku

V případě výpadku služby, který má vliv na prostředky aplikace, zvažte následující postupy:

  • Týmy Azure pracují usilovně na obnovení dostupnosti služeb co nejrychleji, ale v závislosti na původní příčině může někdy trvat hodiny. Pokud vaše aplikace dokáže tolerovat významné výpadky, můžete jednoduše počkat na dokončení obnovení. V takovém případě se nevyžaduje žádná akce na vaší straně. Stav jednotlivých prostředků můžete zobrazit na stránce Stav prostředku libovolného prostředku v nabídce Nápověda . Informace o výpadcích najdete na stránce Resource Health a nejnovější informace o výpadku. Po obnovení oblasti se obnoví dostupnost vaší aplikace.

  • Obnovení do jiné oblasti Azure může vyžadovat změnu aplikačních připojovací řetězec nebo použití přesměrování DNS a může vést ke ztrátě trvalých dat. Zotavení po havárii by se proto mělo provést pouze v případě, že doba trvání výpadku se blíží cíli doby obnovení vaší aplikace (RTO). Když je aplikace nasazená do produkčního prostředí, měli byste provést pravidelné monitorování stavu aplikace a potvrdit, že obnovení je zaručené pouze v případě, že dojde k dlouhodobému selhání připojení z aplikační vrstvy do databáze. V závislosti na odolnosti vaší aplikace vůči výpadkům a možné obchodní odpovědnosti se můžete rozhodnout, jestli chcete počkat, až se služba obnoví nebo zahájí zotavení po havárii sami.

Pokyny k zotavení po výpadku

Pokud se výpadek služby Azure SQL Database v oblasti po delší dobu nezmírní a ovlivňuje smlouvu o úrovni služeb vaší aplikace (SLA), zvažte následující kroky:

Převzetí služeb při selhání (bez ztráty dat) na geograficky replikovaný sekundární server

Pokud je povolená aktivní geografická replikace nebo skupiny převzetí služeb při selhání, zkontrolujte, jestli je stav primárního a sekundárního databázového prostředku online na webu Azure Portal. Pokud ano, rovina dat pro primární i sekundární databázi je v pořádku. Spuštění převzetí služeb při selhání aktivní geografické replikace nebo skupin převzetí služeb při selhání do sekundární oblasti pomocí webu Azure Portal, T-SQL, PowerShellu nebo Azure CLI

Poznámka:

Převzetí služeb při selhání vyžaduje úplnou synchronizaci dat před přepnutím rolí a nemá za následek ztrátu dat. V závislosti na typu výpadku služby neexistuje žádná záruka, že převzetí služeb při selhání bez ztráty dat bude úspěšné, ale stojí za to vyzkoušet jako první možnost obnovení.

K zahájení převzetí služeb při selhání použijte následující odkazy:

Technologie metoda Kroky
Aktivní geografická replikace PowerShell Převzetí služeb při selhání do sekundární geografické replikace přes PowerShell
T-SQL Převzetí služeb při selhání sekundární geografické replikace přes T-SQL
Skupiny převzetí služeb při selhání Azure CLI Převzetí služeb při selhání na sekundární server přes Azure CLI
portál Azure Převzetí služeb při selhání na sekundární server prostřednictvím webu Azure Portal
PowerShell Převzetí služeb při selhání na sekundární server přes PowerShell

Vynucené převzetí služeb při selhání (potenciální ztráta dat) na geograficky replikovaný sekundární server

Pokud převzetí služeb při selhání neproběhne úspěšně a dojde k chybám nebo pokud primární databáze není online, pečlivě zvažte vynucené převzetí služeb při selhání s potenciální ztrátou dat do sekundární oblasti.

K zahájení vynuceného převzetí služeb při selhání použijte následující odkazy:

Technologie metoda Kroky
Aktivní geografická replikace Azure CLI Vynucené převzetí služeb při selhání sekundární geografické replikace prostřednictvím Azure CLI
portál Azure Vynucené převzetí služeb při selhání sekundární geografické replikace prostřednictvím webu Azure Portal
PowerShell Vynucené převzetí služeb při selhání sekundární geografické replikace přes PowerShell
T-SQL Vynucené převzetí služeb při selhání sekundární geografické replikace přes T-SQL
Skupiny převzetí služeb při selhání portál Azure Vynucené převzetí služeb při selhání na sekundární server přes Azure Portal , ale zvolte Vynucené převzetí služeb při selhání.
Azure CLI Vynucené převzetí služeb při selhání sekundárního serveru přes Azure CLI , ale použijte --allow-data-loss
PowerShell Vynucené převzetí služeb při selhání na sekundární server přes PowerShell , ale použijte -AllowDataLoss

Geografické obnovení

Pokud jste nepovolili aktivní geografickou replikaci nebo skupiny převzetí služeb při selhání, můžete k zotavení z výpadku použít geografické obnovení. Geografické obnovení používá jako zdroj geograficky replikované zálohy. Databázi můžete obnovit na libovolném logickém serveru v libovolné oblasti Azure z nejnovějších geograficky replikovaných záloh. Geografické obnovení můžete požádat, i když došlo k výpadku databáze nebo celé oblasti, která je nepřístupná.

Další informace o geografických obnoveních prostřednictvím Azure CLI, webu Azure Portal, PowerShellu nebo rozhraní REST API najdete v tématu geografické obnovení služby Azure SQL Database.

Konfigurace databáze po obnovení

Pokud k zotavení z výpadku používáte geografické převzetí služeb při selhání nebo geografické obnovení, musíte se ujistit, že je správně nakonfigurované připojení k nové databázi, aby bylo možné obnovit normální funkci aplikace. Toto je kontrolní seznam úkolů, které vám pomůžou připravit obnovenou produkční databázi.

Důležité

Doporučujeme provést pravidelné postupy strategie zotavení po havárii , abyste ověřili odolnost aplikace a také všechny provozní aspekty postupu obnovení. Ostatní vrstvy infrastruktury aplikací můžou vyžadovat změnu konfigurace. Další informace o krocích odolné architektury najdete v kontrolním seznamu azure SQL Database s vysokou dostupností a zotavením po havárii.

Aktualizace připojovací řetězec

  • Pokud používáte aktivní geografickou replikaci nebo geografické obnovení, musíte se ujistit, že je připojení k novým databázím správně nakonfigurované, aby bylo možné obnovit normální funkci aplikace. Vzhledem k tomu, že obnovená databáze se nachází na jiném serveru, musíte aktualizovat připojovací řetězec aplikace tak, aby odkazovala na tento server. Další informace o změně připojovací řetězec najdete v příslušném vývojovém jazyce pro knihovnu připojení.
  • Pokud k zotavení ze výpadku používáte skupiny převzetí služeb při selhání a používáte naslouchací procesy jen pro čtení a čtení ve vaší aplikaci připojovací řetězec, není potřeba žádná další akce, protože připojení se automaticky přesměrují na nový primární server.

Konfigurace pravidel brány firewall

Musíte se ujistit, že pravidla brány firewall nakonfigurovaná na sekundárním serveru a databázi odpovídají pravidlům nakonfigurovaným na primárním serveru a primární databázi. Další informace naleznete v tématu Postupy: Konfigurace nastavení brány firewall.

Konfigurace přihlášení a uživatelů databáze

Vytvořte přihlašovací jména, která musí být v master databázi na novém primárním serveru, a zajistěte, aby tato přihlášení měla příslušná oprávnění v master databázi( pokud existuje). Další informace najdete v tématu Zabezpečení po zotavení po havárii.

Nastavení upozornění telemetrie

Musíte zajistit, aby se vaše stávající nastavení pravidla upozornění aktualizovalo tak, aby se mapuje na novou primární databázi a jiný server. Další informace o pravidlech upozornění databáze najdete v tématu Příjem oznámení o upozorněních a sledování stavu služby.

Povolení auditování

Pokud jste na primárním serveru nakonfigurovali auditování, nastavte ho stejně jako na sekundárním serveru. Další informace najdete v tématu Auditování.

Související obsah

Další informace najdete tady: