Sdílet prostřednictvím

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

  • Článek

Platí pro: Azure SQL Managed Instance

Služba Azure SQL Managed Instance 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 úrovně služeb azure SQL Managed Instance.

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 dostupná pro spravovanou instanci SQL, abyste zajistili odolnost proti chybám zón.

Kontrolní seznam pro zotavení po havárii

I když azure SQL Managed Instance 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 místní služby Azure SQL Managed Instance 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 instanci.
    • Koncové body naslouchacího procesu jen pro čtení a čtení ve vaší aplikaci připojovací řetězec, aby se aplikace automaticky připojují k jakékoli instanci, která je primární.
    • Nastavte zásadu převzetí služeb při selhání na spravovanou zákazníkem.
  • Ujistěte se, že je vytvořená geograficky sekundární instance se stejnou úrovní služby, generováním hardwaru a velikostí výpočetních prostředků jako primární instance.
  • 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í 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

K úspěšnému obnovení do jiné oblasti dat pomocí skupin převzetí služeb při selhání nebo geografického obnovení je potřeba připravit sekundární spravovanou instanci Azure SQL v jiné oblasti. V případě potřeby se tato sekundární instance může stát novou primární instancí. 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 instanci v jiné oblasti, aby se stala novou primární instancí. 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 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í.
  • Identifikujte a volitelně definujte konfiguraci skupiny zabezpečení sítě a směrovací tabulky, kterou 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.
  • Zdokumentujte konfiguraci auditování na aktuální primární instanci a nastavte ji stejně jako v sekundární instanci.

Související obsah

Další informace najdete tady: