Kontrolní seznam pro vysokou dostupnost a zotavení po havárii – Azure SQL Database

  • Článek

Platí pro: Azure SQL Database

Služba Azure SQL Database automaticky zajišťuje, aby všechny databáze byly online, v pořádku a neustále se snaží dosáhnout publikované smlouvy SLA.

Tato příručka obsahuje podrobný přehled proaktivních kroků, které můžete provést k maximalizaci dostupnosti, zajištění obnovení a přípravě na výpadky Azure. Tyto pokyny platí pro všechny nákupní modely a úrovně služeb azure SQL Database.

Kontrolní seznam k dostupnosti

Pro maximalizaci dostupnosti se doporučuje následující konfigurace:

  • Začleňte do aplikace logiku opakování pro zpracování přechodných chyb.
  • Časové intervaly údržby umožňují předvídatelné a méně rušivé události údržby.
  • Otestujte odolnost aplikace proti chybám tím, že ručně aktivujete převzetí služeb při selhání, abyste viděli odolnost v akci.

Kontrolní seznam k vysoké dostupnosti

Pro dosažení vysoké dostupnosti se doporučuje následující konfigurace:

  • Povolte zónovou redundanci, pokud je pro databázi nebo elastický fond k dispozici, abyste zajistili odolnost proti chybám zón.

Kontrolní seznam pro zotavení po havárii

I když Azure SQL Database automaticky udržuje dostupnost, existují instance, kdy i vysoká dostupnost (redundance zón) nemusí zaručit odolnost, protože dopad výpadků zahrnuje celou oblast. Výpadek regionální služby Azure SQL Database může vyžadovat zahájení zotavení po havárii.

Pokud chcete co nejlépe připravit na zotavení po havárii, postupujte podle těchto doporučení:

  • Povolte skupiny převzetí služeb při selhání pro skupinu databází.
    • Koncové body naslouchacího procesu jen pro čtení a čtení ve vaší aplikaci připojovací řetězec, aby se aplikace automaticky připojují k serveru a databázi, které jsou aktuální primární.
    • Nastavte zásadu převzetí služeb při selhání na spravovanou zákazníkem.
  • Alternativně ke skupinám převzetí služeb při selhání můžete povolit aktivní geografickou replikaci , aby měla sekundární databázi čitelnou v jiné oblasti Azure.
  • Ujistěte se, že je vytvořená geograficky sekundární databáze se stejnou úrovní služby, výpočetní úrovní (zřízenou nebo bezserverovou) a velikostí výpočetních prostředků (DTU nebo virtuálními jádry) jako primární databáze.
  • Při vertikálním navýšení kapacity vertikálně navyšte kapacitu sekundární geografické oblasti a pak vertikálně navyšte kapacitu primární lokality.
  • V případě vertikálního snižování kapacity postupujte v opačném pořadí: nejprve vertikálně snižte kapacitu primární databáze, a teprve pak vertikálně snižte kapacitu sekundární databáze.
  • Zotavení po havárii je ze své podstaty navržené tak, aby využívalo asynchronní replikaci dat mezi primární a sekundární oblastí. Pokud chcete určit prioritu dostupnosti dat před vyšší latencí potvrzení, zvažte volání sp_wait_for_database_copy_sync uložené procedury ihned po potvrzení transakce. Volání sp_wait_for_database_copy_sync blokuje volající vlákno do poslední potvrzené transakce byla přenášena a posílena v transakčním protokolu sekundární databáze.
  • Monitorujte prodlevu s ohledem na cíl bodu obnovení (RPO) pomocí replication_lag_sec sloupce zobrazení dynamické správy sys.dm_geo_replication_link_status v primární databázi. Zobrazení dynamické správy zobrazuje prodlevu v sekundách mezi transakcemi potvrzenými na primární a posílené v transakčním protokolu na sekundárním serveru. Předpokládejme například, že prodleva je v okamžiku v čase jedna sekunda, pokud je primární ovlivněn výpadkem a v tomto okamžiku se zahájí geografické převzetí služeb při selhání, transakce potvrzené v poslední sekundě budou ztraceny.
  • Pokud povolení skupin převzetí služeb při selhání nebo aktivní geografické replikace není možné, zvažte nastavení možnosti redundance úložiště zálohování na geograficky redundantní úložiště záloh, aby bylo možné použít funkci geografického obnovení.
  • Často naplánujte a proveďte postupy zotavení po havárii, abyste byli lépe připraveni v případě skutečného výpadku.

Příprava sekundární na výpadek

Pokud chcete úspěšně provést obnovení do jiné oblasti dat pomocí aktivní geografické replikace, skupin převzetí služeb při selhání nebo geografického obnovení, musíte připravit sekundární logický server Azure SQL Database v jiné oblasti. V případě potřeby se tento sekundární server může stát novým primárním serverem. Měli byste mít také zdokumentované a otestované kroky, abyste zajistili bezproblémové obnovení. Mezi tyto přípravné kroky patří:

  • V případě geografického obnovení identifikujte server v jiné oblasti, aby se stal novým primárním serverem. Obvykle se jedná o server ve spárované oblasti pro oblast, ve které se nachází vaše primární databáze. Použití serveru v oblasti spárované s primárním serverem eliminuje dodatečné náklady na provoz během operací geografického obnovení.
  • Určete, jak budete uživatele přesměrovat na nový primární server. Přesměrování uživatelů může být provedeno ruční změnou aplikace připojovací řetězec nebo záznamů DNS. Pokud jste nakonfigurovali skupiny převzetí služeb při selhání a používali naslouchací proces jen pro čtení a čtení v aplikacích připojovací řetězec, není potřeba žádná další akce – připojení se po převzetí služeb při selhání automaticky směrují na novou primární.
  • Určete a volitelně definujte pravidla brány firewall, která uživatelé potřebují pro přístup k nové primární databázi.
  • Identifikujte a volitelně vytvořte přihlášení, která musí být v master databázi na novém primárním serveru, a ujistěte se, že tato přihlášení mají příslušná oprávnění v master databázi, pokud existuje. Další informace najdete v tématu Zabezpečení služby Azure SQL Database po zotavení po havárii.
  • Identifikujte pravidla upozornění, která je potřeba aktualizovat, aby se namapovála na nový primární server.
  • Zdokumentujte konfiguraci auditování na aktuálním primárním serveru a na sekundárním serveru ji zdokumentujte.

Související obsah