Sdílet prostřednictvím

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 logiku opakování do aplikace 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 vůči chybám ručním vyvoláním přepnutí, aby se odolnost skutečně prokázala.

Kontrolní seznam pro vysokou dostupnost

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

  • Povolte zónovou redundanci tam, kde je k dispozici pro databázi nebo elastický fond, 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 pro převzetí služeb při selhání pro skupinu databází.
    • Používejte naslouchací koncové body pro čtení a zápis a jen pro čtení v připojovacím řetězci vaší aplikace, aby se aplikace automaticky připojily 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 , abyste měli čitelnou sekundární databázi 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 navýšení kapacity navyšte kapacitu sekundární lokality jako první a poté 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, dokud poslední potvrzená transakce nebyla přenesena a posílena v transakčním protokolu sekundární databáze.
  • Monitorujte prodlevu vzhledem k cíli bodu obnovení (RPO) pomocí sloupce replication_lag_sec v zobrazení dynamické správy sys.dm_geo_replication_link_status v primární databázi. Zobrazovač pohybu dat ukazuje zpoždění v sekundách mezi transakcemi potvrzenými na primárním serveru a zapsanými do transakčního protokolu na sekundárním serveru. Předpokládejme například, že prodleva je v daném okamžiku jedna sekunda, pokud je primární server ovlivněn výpadkem a v tomto okamžiku se zahájí geografické přepnutí na záložní server, transakce potvrzené v poslední sekundě budou ztraceny.
  • Pokud není možné povolit skupiny pro převzetí služeb při selhání nebo aktivní geografickou replikaci, zvažte nastavení možnosti redundance úložiště zálohování na geograficky redundantní úložiště zálohování, abyste mohli použít geografické obnovení pro Azure SQL Database.
  • Č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.

Sekundární příprava na výpadek

Pokud chcete úspěšně provést obnovení do jiného datového regionu pomocí aktivní geografické replikace, skupin pro 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. Pokud má primární oblast spárovanou oblast, je běžné použít spárovanou oblast jako sekundární oblast. Tím obvykle snížíte latenci operací replikace a 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 připojovacích řetězců aplikace nebo záznamů DNS. Pokud jste nakonfigurovali skupiny převzetí služeb při selhání a používáte naslouchací proces pro čtení a zápis a jen pro čtení v připojovacích řetězcích aplikací, není potřeba žádná další akce – připojení se po převzetí automaticky směrují na novou primární repliku.
  • 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 třeba aktualizovat, aby odpovídala novému primárnímu.
  • Zdokumentujte konfiguraci auditování na aktuálním primárním serveru a zajistěte její totožnost na sekundárním serveru.

Související obsah