obnovení Azure SQL Database nebo převzetí služeb při selhání sekundárním

  • Článek
  • 5 min ke čtení

PLATÍ PRO: Azure SQL Database

Azure SQL Database nabízí následující možnosti pro zotavení po výpadku:

Další informace o scénářích kontinuity podnikových aplikací a funkcích, které tyto scénáře podporují, najdete v tématu Kontinuita podnikových aplikací.

Poznámka

pokud používáte redundantní Premium zóny nebo databáze Pro důležité obchodní informace nebo fondy, proces obnovení je automatizovaný a zbytek tohoto materiálu se nepoužije.

U primárních i sekundárních databází je potřeba, aby měly stejnou úroveň služby. Také se důrazně doporučuje vytvořit sekundární databázi se stejnou výpočetní velikostí (DTU nebo virtuální jádra) jako primární. Další informace najdete v tématu upgrade nebo downgrading jako primární databáze.

Pomocí jedné nebo několika skupin převzetí služeb při selhání můžete spravovat převzetí služeb při selhání více databází. Pokud přidáte existující relaci geografické replikace do skupiny převzetí služeb při selhání, ujistěte se, že je geograficky sekundární nakonfigurovaná se stejnou úrovní služeb a výpočetní velikostí jako primární. Další informace najdete v tématu použití skupin automatického převzetí služeb při selhání k zajištění transparentního a koordinovaného převzetí služeb při selhání více databází.

Příprava na případ výpadku

V případě úspěchu s obnovením do jiné oblasti dat pomocí skupin pro převzetí služeb při selhání nebo geograficky redundantního zálohování je potřeba připravit server v jiném výpadku datového centra, aby se stal novým primárním serverem, pokud by to bylo nutné, a měly by se dobře definovat popsané a testované kroky, aby se zajistilo hladké obnovení. Tyto přípravné kroky zahrnují:

  • Identifikujte Server v jiné oblasti, který se stane novým primárním serverem. V případě geografického obnovení se jedná o server v spárované oblasti pro oblast, ve které se nachází vaše databáze. Tím se eliminují dodatečné náklady na provoz během geografického obnovení.
  • Identifikujte a volitelně definujte pravidla brány firewall IP na úrovni serveru potřebná pro uživatele, kteří budou mít přístup k nové primární databázi.
  • Určete, jak budete přesměrovat uživatele na nový primární server, například změnou připojovacích řetězců nebo změnou položek DNS.
  • Identifikujte a volitelně Vytvořte přihlašovací údaje, které se musí nacházet v hlavní databázi na novém primárním serveru, a ujistěte se, že tato přihlášení mají v hlavní databázi příslušná oprávnění, pokud existují. další informace najdete v tématu SQL Database security po zotavení po havárii .
  • Identifikujte pravidla výstrah, která je potřeba aktualizovat, aby se namapovala na novou primární databázi.
  • Dokumentuje konfiguraci auditování v aktuální primární databázi.
  • Provedení postupu zotavení po havárii. Chcete-li simulovat výpadek geografického obnovení, můžete zdrojovou databázi odstranit nebo přejmenovat a způsobit tak selhání připojení aplikace. Chcete-li simulovat výpadky pomocí skupin převzetí služeb při selhání, můžete zakázat webovou aplikaci nebo virtuální počítač připojený k databázi nebo převzetí služeb při selhání databáze a způsobit tak selhání připojení aplikace.

Kdy spustit obnovení

Operace obnovení má vliv na aplikaci. vyžaduje změnu připojovacího řetězce SQL nebo přesměrování pomocí DNS a může způsobit trvalou ztrátu dat. Proto by měl být proveden pouze v případě výpadku, který je pravděpodobně naposledy delší než cíl doby obnovení vaší aplikace. Když se aplikace nasadí do produkčního prostředí, měli byste pravidelně monitorovat stav aplikace a pomocí následujících datových bodů vyhodnotit, že se obnovení opravňuje:

  1. Trvalá Chyba připojení z aplikační vrstvy k databázi.
  2. Azure Portal zobrazuje výstrahu týkající se incidentu v oblasti s rozsáhlým dopadem.

Poznámka

Pokud používáte skupiny převzetí služeb při selhání a zvolíte automatické převzetí služeb při selhání, proces obnovení je automatizovaný a transparentní pro aplikaci.

V závislosti na vaší tolerance vaší aplikace na výpadky a možné obchodní odpovědnosti můžete zvážit následující možnosti obnovení.

K získání nejnovějšího geograficky replikovaného bodu obnovení použijte databázi Get obnovitelné databáze (LastAvailableBackupDate).

Počkat na obnovení služby

Azure Teams funguje usilovně k tomu, aby co nejrychleji obnovil dostupnost služby, ale v závislosti na hlavní příčině může trvat hodiny nebo dny. Pokud vaše aplikace může tolerovat významné výpadky, můžete jednoduše počkat na dokončení obnovení. V takovém případě není nutná žádná akce s vaší částí. Aktuální stav služby můžete zobrazit na našem řídicím panelu Azure Service Health. Po obnovení této oblasti se obnoví dostupnost vaší aplikace.

Převzetí služeb při selhání geograficky replikovaným sekundárním serverem ve skupině převzetí služeb při selhání

Pokud by výpadky vaší aplikace mohly vést k obchodním zodpovědnostem, měli byste používat skupiny převzetí služeb při selhání. Umožňuje aplikaci rychle obnovit dostupnost v jiné oblasti v případě výpadku. Kurz najdete v tématu implementace geograficky distribuované databáze.

Chcete-li obnovit dostupnost databází, je třeba zahájit převzetí služeb při selhání sekundárním serverem pomocí jedné z podporovaných metod.

Pro převzetí služeb při selhání geograficky replikovanou sekundární databází použijte jedno z následujících pokynů:

Obnovení pomocí geografického obnovení

Pokud výpadek vaší aplikace nevede k obchodním zodpovědnostem, můžete použít geografickou obnovu jako metodu pro obnovení databází aplikace. Vytvoří kopii databáze z poslední geograficky redundantní zálohy.

Konfigurace databáze po obnovení

Pokud k zotavení z výpadku používáte geografické obnovení, musíte zajistit, aby připojení k novým databázím bylo správně nakonfigurováno, aby bylo možné obnovit normální funkci aplikace. Toto je kontrolní seznam úkolů pro přípravu obnovené databáze.

Aktualizace připojovacích řetězců

Vzhledem k tomu, že se obnovená databáze nachází na jiném serveru, musíte aktualizovat připojovací řetězec aplikace tak, aby odkazoval na tento server.

Další informace o změně připojovacích řetězců najdete v příslušném vývojovém jazyce pro knihovnu připojení.

Konfigurace pravidel brány firewall

Je nutné zajistit, aby pravidla brány firewall nakonfigurovaná na serveru a v databázi odpovídala nastavením nakonfigurovaným na primárním serveru a primární databázi. další informace najdete v tématu postup: konfigurace Nastavení brány Firewall (Azure SQL Database).

Konfigurace přihlašovacích údajů a uživatelů databáze

Musíte zajistit, aby všechny přihlašovací údaje, které vaše aplikace používá, existovaly na serveru, který je hostitelem obnovené databáze. Další informace najdete v tématu Konfigurace zabezpečení pro geografickou replikaci.

Poznámka

Během postupu zotavení po havárii byste měli nakonfigurovat a otestovat pravidla brány firewall serveru a přihlášení (a jejich oprávnění). Tyto objekty na úrovni serveru a jejich konfigurace nemusí být k dispozici během výpadku.

Nastavení výstrah telemetrie

Musíte zajistit, aby byla stávající nastavení pravidla upozornění aktualizována tak, aby se namapovala na obnovenou databázi a na jiný server.

Další informace o pravidlech upozornění databáze najdete v tématu příjem oznámení o výstrahách a sledování Service Health.

Povolit auditování

Pokud je pro přístup k databázi vyžadováno auditování, je nutné povolit auditování po obnovení databáze. Další informace najdete v tématu auditování databáze.

Další kroky