Přehled provozní kontinuity s flexibilním serverem Azure Database for MySQL
Flexibilní server Azure Database for MySQL umožňuje možnosti provozní kontinuity, které chrání vaše databáze v případě plánovaného a neplánovaného výpadku. Funkce, jako jsou automatizované zálohování a vysoká dostupnost, řeší různé úrovně ochrany proti chybám s různými dobami obnovení a expozicemi ztráty dat. Při návrhu návrhu aplikace na ochranu před chybami byste měli zvážit cíl doby obnovení (RTO) a cíl bodu obnovení (RPO) pro každou aplikaci. RtO je odolnost proti výpadkům a cíl bodu obnovení je odolnost proti ztrátě dat po přerušení databázové služby.
Následující tabulka ukazuje funkce, které flexibilní server Azure Database for MySQL nabízí.
| Funkce | Popis | Omezení |
|---|---|---|
| Zálohování a obnovení | Služba automaticky provádí denní zálohy vašich databázových souborů a průběžně zálohuje transakční protokoly. Zálohy je možné uchovávat po libovolnou dobu mezi 1 až 35 dny. Databázový server můžete obnovit k libovolnému bodu v čase během doby uchovávání záloh. Doba obnovení závisí na velikosti dat, která se mají obnovit + čas k provedení obnovení protokolu. Další podrobnosti najdete v tématu Zálohování a obnovení na flexibilním serveru Azure Database for MySQL. | Zálohovaná data zůstávají v rámci oblasti. |
| Místní redundantní zálohování | Zálohy služeb se automaticky a bezpečně ukládají v místním redundantním úložišti v rámci oblasti a ve stejné zóně dostupnosti. Místně redundantní zálohy replikují záložní datové soubory serveru třikrát v rámci jednoho fyzického umístění v primární oblasti. Místně redundantní úložiště záloh poskytuje alespoň 99,999999999% odolnost objektů (11 devítek) za daný rok. Další podrobnosti najdete v tématu Zálohování a obnovení na flexibilním serveru Azure Database for MySQL. | Použitelné ve všech oblastech |
| Zónově redundantní zálohování | Od poloviny prosince 2024 je možné zálohování služeb nakonfigurovat jako zónově redundantní při vytváření. Povolení redundance zón bude synchronně replikovat váš účet úložiště napříč třemi zónami dostupnosti Azure v primární oblasti. Každá zóna dostupnosti je samostatné fyzické umístění s nezávislým napájením, chlazením a sítí. ZRS nabízí odolnost prostředků úložiště nejméně 99,9999999999999 % (12 9s) za daný rok. Tato konfigurace umožní bezproblémové obnovení během zónových výpadků. | Do poloviny prosince 2024 se bude podporovat pouze úroveň výpočetních prostředků pro důležité obchodní informace. K dispozici pouze v oblastech, kde je k dispozici více zón. |
| Geograficky redundantní zálohování | Zálohy služeb je možné nakonfigurovat jako geograficky redundantní při vytváření. Povolením geografické redundance se replikují záložní datové soubory serveru v spárované oblasti primární oblasti ™za účelem zajištění regionální odolnosti. Geograficky redundantní úložiště záloh poskytuje alespoň 99,9999999999999999% stálost objektů (16 devítek) za daný rok. Další podrobnosti najdete v tématu Zálohování a obnovení na flexibilním serveru Azure Database for MySQL. | K dispozici ve všech spárovaných oblastech Azure |
| Zónově redundantní vysoká dostupnost | Službu je možné nasadit v režimu vysoké dostupnosti, který nasadí primární a pohotovostní servery ve dvou různých zónách dostupnosti v rámci oblasti. Zónově redundantní vysoká dostupnost chrání před selháními na úrovni zóny a pomáhá také snížit výpadky aplikace během plánovaných a neplánovaných výpadků. Data z primárního serveru se synchronně replikují na pohotovostní repliku. Během jakékoli události výpadku služby databázového serveru automaticky převezme pohotovostní replika. Další podrobnosti najdete v konceptech vysoké dostupnosti na flexibilním serveru Azure Database for MySQL. | Podporováno v úrovních pro obecné účely a Pro důležité obchodní informace výpočetních prostředků. K dispozici pouze v oblastech, kde je k dispozici více zón. |
| Sdílené složky Úrovně Premium | Databázové soubory jsou uložené ve vysoce odolných a spolehlivých sdílených složkách Azure Premium, které poskytují redundanci dat se třemi kopiemi repliky uloženými v zóně dostupnosti s možnostmi automatického obnovení dat. Další podrobnosti najdete ve sdílených složkách Úrovně Premium. | Data uložená v zóně dostupnosti |
Plánované zmírnění výpadků
Tady je několik scénářů plánované údržby, u nichž dochází k výpadku:
| Scénář | Proces |
|---|---|
| Škálování výpočetních prostředků (uživatel) | Při provádění operace škálování výpočetních prostředků se pomocí škálované výpočetní konfigurace zřídí nový flexibilní server. Na existujícím databázovém serveru jsou aktivní kontrolní body povolené, klientská připojení se vyprázdní, zruší se všechny nepotvrzené transakce a vypne se. Úložiště se pak připojí k novému serveru a databáze se spustí, což provede obnovení v případě potřeby před přijetím připojení klientů. |
| Nové nasazení softwaru (Azure) | Nové funkce zavedení nebo opravy chyb se automaticky stávají součástí plánované údržby služby a můžete naplánovat, kdy k těmto aktivitám dojde. Další informace najdete v dokumentaci a také na portálu . |
| Upgrady podverze (Azure) | Flexibilní server Azure Database for MySQL automaticky opravuje databázové servery na podverzi určenou Azure. Stává se to jako součást plánované údržby služby. To by v řádu sekund docházelo k krátkému výpadku a databázový server se automaticky restartuje s novou podverzi. Další informace najdete v dokumentaci a také na portálu. |
Pokud je flexibilní server nakonfigurovaný s zónově redundantní vysokou dostupností, flexibilní server nejprve provádí operace na pohotovostním serveru a potom na primárním serveru bez převzetí služeb při selhání. Další podrobnosti najdete v konceptech vysoké dostupnosti na flexibilním serveru Azure Database for MySQL.
Zmírnění dopadu neplánovaných výpadků
Neplánované výpadky můžou nastat v důsledku nepředvídatelných selhání, včetně základní chyby hardwaru, problémů se sítí a chyb softwaru. Pokud databázový server neočekávaně přestane fungovat, pokud je nakonfigurovaná vysoká dostupnost [HA], aktivuje se pohotovostní replika. Pokud ne, automaticky se zřídí nový databázový server. I když se neplánovaný výpadek nedá vyhnout, flexibilní server zmírní výpadky tím, že automaticky provádí operace obnovení na databázových serverech i vrstvách úložiště bez nutnosti zásahu člověka.
Neplánovaný výpadek: scénáře selhání a obnovení služby
Tady jsou některé neplánované scénáře selhání a proces obnovení:
| Scénář | Proces obnovení [bez vysoké dostupnosti] | Proces obnovení [HA] |
|---|---|---|
| Selhání databázového serveru | Pokud databázový server nefunguje kvůli nějaké základní chybě hardwaru, aktivní připojení se zahodí a všechny příchozí transakce se přeruší. Azure se pokusí restartovat databázový server. Pokud je to úspěšné, provede se obnovení databáze. Pokud restartování selže, pokusí se restartování databázového serveru na jiném fyzickém uzlu. Doba obnovení (RTO) závisí na různých faktorech, včetně aktivity v době selhání, například velké transakce a množství obnovení, které se má provést během procesu spouštění databázového serveru. Cíl bodu obnovení je nulový, protože u potvrzených transakcí se neočekává žádná ztráta dat. Aplikace využívající databáze MySQL musí být sestaveny způsobem, který zjišťuje a opakuje ukončená připojení a neúspěšné transakce. Při opakování aplikace se připojení směrují na nově vytvořený databázový server. Další dostupné možnosti se obnoví ze zálohy. Můžete použít obnovení k určitému bodu v čase i geografické obnovení z spárované oblasti. PITR : RTO: Varies, RPO=0sec Geografické obnovení: RTO: Liší se cíl bodu <obnovení 1 h. Repliku pro čtení můžete použít také jako řešení zotavení po havárii. Replikaci můžete zastavit, takže replika pro čtení i zápis (samostatně a pak přesměruje provoz aplikace do této databáze). RtO ve většině případů je několik minut a cíl bodu < obnovení 1 h. RtO a RPO můžou být v některých případech mnohem vyšší v závislosti na různých faktorech, mezi které patří latence mezi lokalitami, objem přenášených dat a důležité úlohy zápisu do primární databáze. |
Pokud se zjistí selhání databázového serveru nebo chyby, které se nedají obnovit, aktivuje se pohotovostní databázový server, čímž se sníží výpadek. Další podrobnosti najdete na stránce konceptů vysoké dostupnosti. Očekává se, že RTO bude 60–120 s, s RPO=0. Poznámka: Možnosti pro proces obnovení [non-HA] jsou zde také použitelné. |
| Selhání úložiště | Aplikace nevidí žádný dopad na problémy související s úložištěm, jako je selhání disku nebo poškození fyzického bloku. Vzhledem k tomu, že jsou data uložená ve třech kopiích, bude kopie dat obsluhována úložištěm pro přežití. Blokování poškození se opraví automaticky. Pokud dojde ke ztrátě kopie dat, automaticky se vytvoří nová kopie dat. Ve výjimečných nebo nejhorších případech, pokud jsou všechny kopie poškozené, můžeme použít obnovení z geografického obnovení (spárované oblasti). RPO by bylo < 1 h a RTO se liší. Repliku pro čtení můžete použít také jako řešení zotavení po havárii, jak je podrobně popsáno výše. |
Pro tento scénář jsou možnosti stejné jako pro proces obnovení [non-HA] . |
| Logické nebo uživatelské chyby | Obnovení z chyb uživatelů, jako jsou náhodné vyřazení tabulek nebo nesprávně aktualizovaná data, zahrnuje obnovení k určitému bodu v čase (PITR) obnovením a obnovením dat do doby těsně před tím, než došlo k chybě. Odstraněný prostředek flexibilního serveru můžete obnovit do pěti dnů od odstranění serveru. Podrobný průvodce obnovením odstraněného serveru najdete v části [viz zdokumentované kroky] (.. /flexible-server/how-to-restore-dropped-server.md). K ochraně prostředků serveru po nasazení před náhodným odstraněním nebo neočekávanými změnami můžou správci používat zámky správy. |
Tyto chyby uživatelů nejsou chráněny vysokou dostupností, protože všechny operace uživatelů se replikují také do pohotovostního režimu. V tomto scénáři jsou možnosti stejné jako u procesu obnovení [non-HA] |
| Selhání zóny dostupnosti | I když se jedná o vzácnou událost, pokud se chcete zotavit z selhání na úrovni zóny, můžete provést geografické obnovení z spárované oblasti. RPO by bylo <1 h a RTO se liší. Repliku pro čtení můžete použít také jako řešení zotavení po havárii vytvořením repliky v jiné zóně dostupnosti. RTO\RPO je podobné tomu, co je podrobně popsáno výše. |
Pokud jste povolili zónově redundantní vysokou dostupnost, flexibilní server provede automatické převzetí služeb při selhání do pohotovostní lokality. Další podrobnosti najdete v konceptech vysoké dostupnosti na flexibilním serveru Azure Database for MySQL. Očekává se, že RTO bude 60–120 s, s RPO=0. Další dostupné možnosti se obnoví ze zálohy. Můžete použít obnovení k určitému bodu v čase i geografické obnovení z spárované oblasti. PITR : RTO: Liší se, RPO=0 s Geografické obnovení: RTO: Liší se, RPO <1 h Poznámka: Pokud máte povolenou vysokou dostupnost se stejnou zónou, jsou možnosti stejné jako u procesu obnovení [non-HA]. |
| Selhání oblasti | I když se jedná o vzácnou událost, pokud se chcete zotavit z selhání na úrovni oblasti, můžete provést obnovení databáze vytvořením nového serveru pomocí nejnovější geograficky redundantní zálohy dostupné ve stejném předplatném, abyste získali nejnovější data. Do vybrané oblasti se nasadí nový flexibilní server. Doba potřebná k obnovení závisí na předchozím zálohování a počtu transakčních protokolů, které se mají obnovit. RPO ve většině případů bude <1 h a RTO se bude lišit. | Pro tento scénář jsou možnosti stejné jako pro proces obnovení [non-HA] . |
Požadavky a omezení
Rezidence dat oblastí
Flexibilní server Azure Database for MySQL ve výchozím nastavení nepřesunuje ani neukládá zákaznická data z oblasti, ve které jsou nasazená. Zákazníci ale můžou volitelně povolit geograficky redundantní zálohování nebo nastavit replikaci mezi oblastmi pro ukládání dat v jiné oblasti.