Spolehlivost v Azure Database for MySQL

Azure Database for MySQL je plně spravovaná databázová služba, která poskytuje podrobnou kontrolu a flexibilitu nad funkcemi správy databáze a nastavením konfigurace. Služba poskytuje možnosti vysoké dostupnosti (HA) a zotavení po havárii (DR) na základě vašich požadavků.

Při použití Azure je spolehlivost sdílenou odpovědností. Microsoft poskytuje řadu funkcí pro podporu odolnosti a obnovení. Zodpovídáte za pochopení toho, jak tyto možnosti fungují ve všech službách, které používáte, a výběrem možností, které potřebujete ke splnění vašich obchodních cílů a cílů dostupnosti.

Tento článek popisuje, jak zajistit, aby byla služba Azure Database for MySQL odolná vůči různým potenciálním výpadkům a problémům, včetně přechodných poruch, výpadků zón dostupnosti, výpadků oblastí a údržby služby. Popisuje také, jak můžete použít zálohy k zotavení z jiných typů problémů a zvýrazní některé klíčové informace o smlouvě o úrovni služeb (SLA) Azure Database for MySQL.

Doporučení pro nasazení do produkčního prostředí

Azure Well-Architected Framework poskytuje doporučení týkající se spolehlivosti, zabezpečení, nákladů, provozu a výkonu. Informace o tom, jak tyto oblasti vzájemně ovlivňují a přispívají ke spolehlivému Azure Database for MySQL řešení, najdete v tématu Osvědčené postupy architektury pro Azure Database for MySQL.

Přehled architektury spolehlivosti

Tato část popisuje některé důležité aspekty fungování služby, které jsou z hlediska spolehlivosti nejrelevantní. Tato část představuje logickou architekturu, která obsahuje některé prostředky a funkce, které nasazujete a používáte. Popisuje také fyzickou architekturu, která poskytuje podrobnosti o tom, jak služba funguje v zákulisí.

Logická architektura

Při práci s Azure Database for MySQL nasadíte server, který představuje výpočetní prostředky a prostředky úložiště potřebné k podpoře databázového serveru. Na server nasadíte jednu nebo více databází .

Servery můžete nasadit ve výpočetních úrovních Burstable, Pro obecné účely a Optimalizováno pro paměť. Každá úroveň výpočetních prostředků je optimalizovaná pro různé druhy úloh.

Další informace o obecné architektuře služeb a modelech nasazení najdete v Azure Database for MySQL přehledu.

Fyzická architektura

• Oddělení výpočetních prostředků a úložiště: Azure Database for MySQL využívá architekturu oddělení výpočetních prostředků a úložiště k podpoře vysoké dostupnosti. Databázový stroj běží na virtuálním počítači. Datové soubory jsou uloženy v Azure Storage, které synchronně udržuje tři kopie dat, aby se chránily před selháním hardwaru úložiště. V závislosti na konfiguraci vysoké dostupnosti serveru je možné datové soubory ukládat v zónově redundantním úložišti (ZRS) nebo v místním redundantním úložišti (LRS).

• HA: Na serveru můžete volitelně povolit konfiguraci HA. Když povolíte konfiguraci HA, služba vytvoří a udržuje repliku serveru v režimu teplé zálohy. Změny dat na primárním serveru se synchronně replikují na pohotovostní server repliky, aby se zajistila nulová ztráta dat během selhání primárního serveru.

  Architektura odděluje výpočetní vrstvu od vrstvy úložiště, která službě umožňuje správně zpracovávat různé typy selhání. Kvůli vyšší odolnosti můžete servery rozložit mezi zóny dostupnosti.

  Server pohotovostní repliky se nasadí ve stejné konfiguraci virtuálního počítače jako primární server, včetně virtuálních jader, úložiště a nastavení sítě.

  Přepínat mezi servery můžete provedením převzetí služeb při selhání. Použijte neplánované převzetí služeb při selhání, když primární server selže, a plánované převzetí služeb při selhání použijte tehdy, když potřebujete během převzetí služeb při selhání minimalizovat dobu nedostupnosti aplikace.

  Další informace najdete v tématu ha v Azure Database for MySQL.

• Backups: Azure Database for MySQL automaticky vytváří zálohy serveru. Další informace najdete v tématu Zálohování a obnovení.

Odolnost proti přechodným chybám

Přechodné chyby jsou krátká, přerušovaná selhání ve složkách. V distribuovaném prostředí, jako je cloud, se vyskytují často a jsou normální součástí provozu. Přechodné chyby se opravují po krátké době. Je důležité, aby vaše aplikace mohly zpracovávat přechodné chyby, obvykle opakováním ovlivněných požadavků.

Všechny aplikace hostované v cloudu by měly postupovat podle Azure pokynů pro zpracování přechodných chyb, když komunikují s libovolnými rozhraními API, databázemi a dalšími komponentami hostovanými v cloudu. Další informace najdete v tématu Doporučení pro zpracování přechodných chyb.

Vaše aplikace musí zpracovávat přechodné chyby připojení, ke kterým může dojít během údržby, operací škálování nebo přerušení sítě. Postupujte podle těchto doporučení:

Odolnost proti chybám zóny dostupnosti

zóny dostupnosti jsou fyzicky oddělené skupiny datacenter v rámci Azure oblasti. Když jedna zóna selže, mohou služby přejít na jednu ze zbývajících zón.

Vyberte typ podpory pro zóny dostupnosti v konfiguraci HA. Když povolíte vysokou dostupnost, Azure Database for MySQL nasadí server repliky v pohotovostním režimu vedle vašeho primárního serveru. Tento model HA pomáhá zajistit, aby při selhání nikdy nedošlo ke ztrátě potvrzeně zapsaných dat. Ať už zvolíte kterýkoli model nasazení vysoké dostupnosti, služba synchronně zapisuje data na primární i pohotovostní replikační server. Pokud dojde k výpadku primárního serveru, systém se automaticky přepne na záložní repliku serveru.

Služba ukládá data do Azure Files Premium Storage. V závislosti na konfiguraci vysoké dostupnosti vašeho serveru buď používá ZRS nebo LRS, které ukládají tři kopie dat v rámci zón dostupnosti nebo napříč zónami dostupnosti.

Azure Database for MySQL podporuje při použití vysoké dostupnosti dva typy konfigurace zóny dostupnosti:

• Zónově redundantní HA: Redundance mezi zónami poskytuje nejvyšší úroveň odolnosti vůči výpadku zóny tím, že primární server nasadí do jedné zóny dostupnosti a pohotovostní repliku serveru do jiné zóny dostupnosti. Server pohotovostní repliky používá podobné výpočetní prostředky, úložiště a konfiguraci sítě jako primární server. Zónově redundantní konfigurace poskytuje fyzickou izolaci celé vrstvy mezi primárními a záložními servery.

  Vyberete zóny dostupnosti pro primární a pohotovostní servery.

  Pro produkční servery používejte zónově redundantní nasazení.

  

  Diagram se skládá ze tří částí. První část obsahuje seznam klientských aplikací, jako jsou Azure virtuální počítače, Azure Kubernetes Service (AKS) a Azure App Service. V další části je označená zóna dostupnosti 1. Obsahuje primární server a dvě dílčí části, výpočetní prostředky a úložiště oddělené tečkovanou čárou. Třetí část je označená jako zóna dostupnosti 2. Zrcadlí zónu dostupnosti 1, ale obsahuje pohotovostní server. Šipky ukazují z klientských aplikací na standardní nástroj pro vyrovnávání zatížení. Jedna šipka ukazuje z nástroje pro vyrovnávání zatížení na virtuální počítač na primárním serveru v zóně dostupnosti 1. Obousměrné šipky připojují virtuální počítač a sdílenou složku Premium a jednotku SSD (Solid-State Drive). Další šipka směřuje z prémiové sdílené složky do záložního úložiště objektů blob. Šipka označená jako asynchronní replikace založená na úložišti směřuje ze zóny dostupnosti 1 do zóny dostupnosti 2.

  Operace zápisu mohou zaznamenat malý nárůst latence potvrzení, protože služba synchronně replikuje data na záložní server. V průměru můžete očekávat 5% až 10% vyšší latenci pro zápisy a potvrzení aplikací. Vliv se liší podle úloh, vybraných skladových položek a oblastí.

• Lokálně redundantní HA: Primární a záložní servery používají stejnou zónu dostupnosti. Pokud dojde k přerušení primárního serveru, ale zóna je stále v pořádku, server se automaticky přepne na pohotovostní server.

  Místně redundantní nasazení vám poskytuje HA v rámci jedné zóny dostupnosti. Chrání vás před selháními na úrovni uzlu a také pomáhá snižovat výpadky aplikací během plánovaných a neplánovaných výpadků. Nechrání se ale před výpadkem v této zóně. V oblastech, které mají zóny dostupnosti, se tento druh konfigurace také někdy označuje jako zónová nebo jednozónová.

  

  Diagram se skládá ze tří částí. První část obsahuje seznam klientských aplikací, jako jsou Azure virtuální počítače, AKS a App Service. V další části je označená zóna dostupnosti 1. Obsahuje dva samostatné oddíly pro primární server a pohotovostní server. Tečkovaná čára rozdělí oddíl každého serveru do dvou pododdílů, výpočetních prostředků a úložiště. Šipky ukazují z klientských aplikací na standardní nástroj pro vyrovnávání zatížení. Jedna šipka ukazuje z nástroje pro vyrovnávání zatížení na virtuální počítač na primárním serveru v zóně dostupnosti 1. Obousměrné šipky připojují virtuální počítač a sdílenou složku Premium a jednotku SSD (Solid-State Drive). Další šipka směřuje z prémiové sdílené složky do záložního úložiště objektů blob. Šipka označená jako „úložišťová asynchronní replikace“ směřuje z primárního serveru na záložní server. Třetí část označená jako zóna dostupnosti 2 je prázdná.

  Místně redundantní HA používejte pouze v následujících scénářích:

  • Pokud máte aplikace citlivé na neobvyklou latenci, ověříte nutnost minimalizovat latenci mezi primární a sekundární replikou a plánujete odolnost zón pomocí jiných přístupů architektury.

  • Když nasadíte do oblasti, která nepodporuje zóny dostupnosti. V tomto scénáři funguje region jako jediná zóna, takže jedinou možností HA je lokálně redundantní HA.

  Servery jsou ve stejné zóně, což může snížit latenci zápisu do aplikací, které nasazujete v této zóně.

Pokud server nakonfigurujete bez HA, poběží na jednom serveru. Pokud tento server nebo jeho zóna selže, server není k dispozici.

Požadavky

• Podpora oblastí: Azure Database for MySQL podporuje různé konfigurace zón dostupnosti v závislosti na vaší Azure oblasti. Úplný seznam oblastí, včetně typů podpory zóny dostupnosti a konkrétních aspektů pro každou oblast, najdete v Azure oblastech.

• Úroveň služby: HA vyžaduje úroveň Pro obecné účely nebo Optimalizované pro paměť. Vrstva Burstable nepodporuje HA (vysokou dostupnost) – redundanci mezi zónami ani místní redundanci.

Náklady

Když povolíte vysokou dostupnost, vytvoříte a platíte za pohotovostní server se stejnou sazbou jako primární server. Konfigurace zóny dostupnosti nemá vliv na náklady. Za replikaci dat se neúčtují žádné poplatky v rámci zón dostupnosti ani mezi zónami dostupnosti. V závislosti na objemu úložiště záloh vám může být také účtováno za úložiště záloh. Podrobné informace o cenách najdete v cenách služby Azure Database for MySQL.

Úvahy

• Primární klíče: Používejte primární klíče u všech tabulek, protože tento přístup zkracuje dobu replikace a dobu převzetí služeb při selhání.

• Omezení a známé problémy: Projděte si seznam omezení a známých problémů.

Konfigurujte podporu zón dostupnosti

Pokud chcete nakonfigurovat podporu zóny dostupnosti pro server, nakonfigurujte nastavení vysoké dostupnosti.

• Vytvořte zónově redundantní server. Informace o vytvoření serveru s povolenou vysokou dostupností a redundancí zón najdete v následujících článcích:

  • portál Azure: Správa zónově redundantní vysoké dostupnosti v Azure Database for MySQL pomocí portálu Azure.

  • Azure CLI: Správa zónově redundantní vysoké dostupnosti ve službě Azure Database for MySQL pomocí rozhraní Azure CLI.

• Vytvořte místní redundantní server. Pokud chcete vytvořit server s vysokou dostupností s místní redundancí v rámci jedné zóny dostupnosti, musíte použít Azure CLI nebo jinou metodu programového nasazení. Pokyny k Azure CLI najdete v tématu Povolení vysoké dostupnosti při vytváření serveru.

• Změňte konfiguraci zóny dostupnosti pro existující servery. Pokud máte existující server, postup, podle kterého povolíte podporu zóny dostupnosti, závisí na počáteční konfiguraci serveru.

  • Pokud chcete existující server převést na vysokou dostupnost se zónovou redundancí, musíte migrovat na nový server. Další informace naleznete v tématu Migrace z existujícího serveru na zónově redundantní server.

  • Pokud chcete změnit existující server na místně redundantní HA:

    1. Zakažte HA, pokud je povolená.

    2. Povolte vysokou dostupnost s místní redundancí. Musíte použít Azure CLI nebo jinou programovou metodu nasazení. Pokyny k Azure CLI najdete v tématu Správa zónově redundantní vysoké dostupnosti v Azure Database for MySQL pomocí Azure CLI.

• Vypněte HA. Zakázání HA odebere pohotovostní replikační server, takže váš server nebude odolný vůči výpadkům na úrovni zóny. Pokud jsou ale povolené geograficky redundantní zálohy, můžete server obnovit v jiné oblasti pomocí těchto záloh. Další informace naleznete v části Zakázat HA.

Chování, když jsou všechny zóny v pořádku

Tato část popisuje, co očekávat, když nakonfigurujete servery s podporou vysoké dostupnosti a zóny dostupnosti a všechny zóny dostupnosti jsou funkční.

• Operace napříč zónami: Klientské aplikace MySQL se připojují k primárnímu serveru pomocí plně kvalifikovaného názvu domény (FQDN) databázového serveru. Nepoužívejte IP adresu primárního serveru, protože ip adresa se může změnit, včetně během převzetí služeb při selhání.

  Azure Database for MySQL používá konfiguraci aktivní-pasivní, ve které primární server zpracovává všechna připojení a dotazy databáze v primární zóně dostupnosti. Server repliky v pohotovostním režimu během normálního provozu neobsluhuje klientský provoz.

• Replikace dat mezi zónami: Zápisy se zapisují na primárním serveru a synchronně zapisují do protokolů pohotovostního serveru pomocí ZRS. Primární server nečeká, až pohotovostní server použije protokoly, ale protože jsou protokoly v ZRS, jsou dostupné i v případě, že dojde k selhání repliky nebo zóny.

  Účinky replikace se liší v závislosti na konfiguraci zóny dostupnosti, kterou váš server používá:

  • Zónově redundantní: Vzhledem k tomu, že servery jsou v samostatných zónách, zajišťuje tento přístup nulovou ztrátu dat během selhání zóny. Tato situace se také označuje jako dosažení nulového cíle bodu obnovení (RPO) pro selhání zón.

    Replikace mezi zónami ale může představovat malou latenci navíc. V průměru můžete očekávat 5% až 10% vyšší latenci pro zápisy a potvrzení aplikací, ale vliv se liší podle úloh, vybraných skladových položek a oblastí.

  • Místně redundantní: Mezi zónami se nereplikuje žádný provoz.

  Poznámka:

  Systém replikuje všechny změny v reálném čase na pohotovostní server repliky, včetně nezamýšlených chyb uživatelů, jako je náhodné vyřazení tabulky nebo nesprávné aktualizace dat. Z důvodu okamžité replikace nemůžete k obnovení použít pohotovostní repliku. Pokud se chcete zotavit z chyb uživatelů, musíte provést obnovení k určitému bodu v čase ze zálohy. Další informace najdete v tématu Zálohování a obnovení.

Chování při selhání zóny

Tato část popisuje, co můžete očekávat, když nakonfigurujete servery s vysokou dostupností a podporou zón dostupnosti, pokud dojde k výpadku zóny dostupnosti.

• Detekce a reakce: Azure pravidelně kontroluje stav primárních i pohotovostních serverů. Pokud sledování stavu po několika příkazech ping zjistí, že hlavní server není dostupný, služba zahájí automatické převzetí služeb při selhání na záložní server. Algoritmus monitorování stavu používá více datových bodů, aby se zabránilo falešně pozitivním situacím.

  Pokud dojde k selhání zóny, chování se liší v závislosti na konfiguraci zóny dostupnosti, kterou váš server používá:

  • Zone-redundant: Azure Database for MySQL automaticky detekuje selhání zóny dostupnosti nepřetržitým monitorováním několika koncových bodů serveru. Další informace najdete v článku Jak funguje automatické zjišťování převzetí služeb při selhání na serverech s podporou HA.

    Informace o možných typech stavu vysoké dostupnosti najdete v tématu Monitorování vysoké dostupnosti. Pokud dojde k selhání zóny, Azure zahájí neplánované převzetí služeb při selhání na pohotovostní server, aniž byste museli podniknout jakékoli kroky.

  • Místní redundantní: Primární i pohotovostní servery nejsou k dispozici, pokud zóna dostupnosti, která je hostitelem místního redundantního serveru, není k dispozici. V tomto scénáři služba neposkytuje automatické převzetí služeb při selhání. Zodpovídáte za zjištění výpadku zóny a provádění akcí obnovení, jako je obnovení zónově redundantních záloh na samostatný server v jiné zóně dostupnosti nebo oblasti.

• Oznámení: Microsoft vás při výpadku zóny automaticky neoznámí. Pomocí Azure Resource Health ale můžete monitorovat stav jednotlivých prostředků a můžete nastavit výstrahy Resource Health, které vás upozorní na problémy. Můžete také použít Azure Service Health k pochopení celkového stavu služby, včetně jakýchkoli selhání zóny, a můžete nastavit upozornění služby Service Health, která vás upozorní na problémy.

  Azure Database for MySQL vygeneruje událost Azure Resource Health, když dojde k neplánovanému přechodu při selhání.

• Aktivní požadavky: Když se zóna dostupnosti stane nedostupnou, můžou se probíhající požadavky na servery v ovlivněné zóně ukončit. Aplikace musí tyto požadavky opakovat. Pokud vaši klienti zpracovávají přechodné chyby odpovídajícím způsobem opakovaným pokusem po krátké době, obvykle se vyhýbají významnému dopadu.

• Očekávaná ztráta dat: Velikost ztráty dat závisí na konfiguraci zóny dostupnosti vašeho serveru.

  • Zónově redundantní: Očekává se nulová ztráta dat při selhání zóny díky synchronní replikaci mezi primárními a záložními servery v různých zónách.

  • Místní redundantní: Data na serverech v ovlivněné zóně nejsou k dispozici, dokud se zóna neobnoví.

• Očekávaný výpadek: Velikost výpadků závisí na konfiguraci zóny dostupnosti, kterou váš server používá.

  • S redundancí napříč zónami: Převzetí služeb po selhání se obvykle dokončí za 60 až 120 sekund. Pokud vaši klienti zpracovávají přechodné chyby odpovídajícím způsobem opakovaným pokusem po krátké době, obvykle se vyhýbají významnému dopadu.

  • Místní redundantní: Servery v ovlivněné zóně nejsou dostupné, dokud se zóna dostupnosti neobnoví.

• Přerozdělování: Chování přesměrování provozu závisí na konfiguraci zóny dostupnosti, kterou váš server používá.

  • Zónově redundantní: Po přepnutí při selhání se záložní server stane novým primárním serverem a začne přijímat nová připojení. Azure po obnovení automaticky vytvoří pohotovostní server v původní primární zóně. Další informace najdete v tématu Neplánované převzetí služeb při selhání.

  • Místní redundantní: Jakmile je zóna nedostupná, váš server nebude dostupný. Pokud máte samostatný server, který jste vytvořili v jiné zóně nebo oblasti dostupnosti, zodpovídáte za přesměrování provozu na tento server.

Obnovení zóny

Chování obnovení zóny závisí na konfiguraci zóny dostupnosti, kterou váš server používá.

• Zónově redundantní: Když se zóna dostupnosti obnoví, Azure Database for MySQL automaticky znovu sestaví pohotovostní server v obnovené zóně a synchronizuje ho s aktuálním primárním serverem. Obnovená zóna pak slouží jako pohotovostní umístění. Služba nepřesune primární roli automaticky zpět do původní zóny, aby nedošlo k zbytečnému přerušení. Pokud chcete vrátit primární zpět do původní zóny, můžete ručně zahájit plánovaný přechod při selhání.

• Lokálně redundantní: Jakmile je zóna v pořádku, servery v zóně jsou opět k dispozici. Zodpovídáte za postupy obnovení zón a synchronizaci dat, které vaše úlohy vyžadují.

Testování poruch zón

Možnosti pro testování selhání zón závisí na konfiguraci zóny dostupnosti, kterou vaše instance používá.

• Zónově redundantní: Odolnost aplikace vůči převzetí služeb při selhání můžete otestovat spuštěním plánovaného převzetí služeb při selhání. Pomocí plánovaného převzetí služeb při selhání můžete simulovat neplánovaný výpadek při spuštění úloh a sledovat výpadky vaší aplikace. Spouštění simulací v neprodukčních prostředích nebo v tichém čase Další informace najdete v části Plánované převzetí služeb při selhání.

• Místně redundantní: Nemůžete simulovat úplný výpadek zóny, ale můžete simulovat stav, kdy je server nedostupný, podobně jako při výpadku zóny. Další informace najdete v následujících článcích:

  • portál Azure: Zastavte a spusťte instanci flexibilního serveru Azure Database for MySQL.

  • Azure CLI: Restartování, zastavení a spuštění flexibilního serveru Azure Database for MySQL.

Odolnost proti selháním v celé oblasti

Azure Database for MySQL podporuje repliky pro čtení mezi oblastmi, které můžete použít k zajištění rychlejšího obnovení synchronizované kopie databáze v jiné oblasti.

K zajištění obnovení mezi oblastmi můžete použít také geograficky redundantní zálohy v podporovaných oblastech. Zálohování ale obvykle zahrnuje větší výpadek a ztrátu dat než replikace. Další informace najdete v tématu Zálohování a obnovení.

Repliky pro čtení napříč regiony

Nasaďte repliky pro čtení pro ochranu databází před selháními na úrovni oblasti. Každá replika pro čtení je samostatný server Azure Database for MySQL. Když umístíte repliku pro čtení do druhé Azure oblasti, může databázový server zajistit odolnost vůči problému v celé oblasti. Můžete nasadit až 10 replik pro čtení, které můžou být volitelně v různých Azure oblastech.

Technologie fyzické replikace MySQL asynchronně aktualizuje repliky pro čtení ze zdrojového serveru v primární oblasti, což znamená, že repliky mohou mít oproti zdrojovému serveru zpoždění. Repliky pro čtení napříč oblastmi můžou volitelně obsluhovat úlohy pouze pro čtení, aby se snížila latence globálně distribuovaných aplikací a tím odlehčila zátěž čtení ze zdrojového serveru. Další informace o funkcích replik pro čtení a souvisejících aspektech najdete v části Repliky pro čtení.

Pokud vaše primární oblast selže, můžete ručně provést převzetí služeb při selhání a nastavit sekundární repliku jako primární server. Chcete-li ručně provést převzetí služeb při selhání, zastavte proces replikace, čímž povýšíte repliku pro čtení na server pro čtení i zápis. Kvůli asynchronní replikaci může převzetí při selhání vést ke ztrátě dat. Vaše aplikace se musí připojit k novému primárnímu serveru a zodpovídáte za rekonfiguraci aplikace.

Požadavky

• podpora oblasti Region: Repliky pro čtení mezi oblastmi můžete vytvořit v libovolné oblasti, která podporuje Azure Database for MySQL. Nejste omezeni pouze na spárované oblasti Azure.

• Úrovně výpočetní techniky: Úrovně výpočtů obecného účelu a optimalizované pro paměť podporují čtecí repliky. Úroveň Burstable nepodporuje repliky pro čtení.

Úvahy

• Rozdíly v konfiguraci: Když vytvoříte repliku, dědí z zdrojového serveru několik nastavení, včetně generování výpočetních prostředků, virtuálních jader a úložiště. Tyto hodnoty můžete po vytvoření repliky pro čtení přizpůsobit, ale nejlepší je použít stejné nebo vyšší hodnoty, aby se zajistilo, že replika dokáže držet krok se změnami ve zdroji.

• Monitorování prodlevy replikace: Proces asynchronní replikace vyžaduje prodlevu replikace, která se může lišit v závislosti na několika faktorech. Když je prodleva replikace velmi vysoká, může na vašem serveru docházet k problémům. Je důležité monitorovat prodlevu replikace, abyste před eskalacem mohli zmírnit problémy. Další informace najdete v tématu Monitorování replikace.

• HA: Repliky pro čtení nemohou mít povolenou HA a při převzetí služeb při selhání, kdy se stanou primárním serverem, také nemají HA. Odpovídáte za konfiguraci HA po přepnutí služeb na repliku.

Náklady

Repliky pro čtení souvisejí s náklady na výpočetní prostředky a úložiště, a také poplatky za přenos dat mezi regiony kvůli replikaci. Podrobné informace o cenách najdete v tématech Ceny Azure Database for MySQL a Ceny za šířku pásma.

Konfigurace podpory více oblastí

• Vytvoření repliky pro čtení: Informace o vytvoření repliky pro čtení najdete v následujících článcích:

  • portál Azure: Vytváření a správa replik pro čtení na flexibilním serveru Azure Database for MySQL pomocí portálu Azure

  • Azure CLI: Vytváření a správa replik pro čtení na flexibilním serveru Azure Database for MySQL pomocí Azure CLI

  Repliky můžete nakonfigurovat po vytvoření zdrojového serveru jenom v případě, že je zdrojový server spuštěný a dostupný.

• Zastavení replikace: Informace o zastavení replikace najdete v tématu Zastavení replikace na server repliky.

• Odstranění repliky pro čtení: Informace o tom, jak odstranit repliku pro čtení, najdete v tématu Odstranění serveru repliky.

Chování, když jsou všechny oblasti v pořádku

Tato část popisuje, co očekávat při konfiguraci serveru s replikou pro čtení v jiné oblasti a všechny oblasti jsou funkční:

• Směrování provozu mezi oblastmi: Během normálních operací by vaše aplikace měla směrovat provoz pro čtení i zápis do zdrojového serveru v primární oblasti. Volitelně můžete směrovat požadavky na čtení na čtecí repliku.

• Replikace dat mezi oblastmi: Repliky čtení mezi oblastmi používají asynchronní replikaci k minimalizaci dopadu na výkon zdrojového serveru. Prodleva replikace závisí na několika faktorech, včetně zatížení zápisu a latence mezi zdrojovým serverem a replikami. Prodleva replikace je obvykle nejméně několik minut, ale může být mnohem delší. Další informace najdete v tématu Monitor replication a podrobné pokyny najdete v tématu Monitor replikace na portálu Azure.

Chování při selhání oblasti

Tato část popisuje, co očekávat, když nakonfigurujete server pro podporu replik pro čtení mezi oblastmi a dojde k výpadku v primární oblasti.

• Detekce a reakce: Jste zodpovědní za detekci výpadku v primárním regionu a ruční spuštění převzetí služeb při selhání. Tato akce může vést ke ztrátě nereplicitovaných dat.

  Důležité

  Zodpovídáte za aktivaci převzetí při selhání. Azure se na repliky pro čtení automaticky nepřepne, ani v případě výpadku oblasti.

  Převzetí služeb při selhání vyžaduje provedení následujících kroků:

  1. Zastavení replikace Tento postup je nevratný a server už nelze znovu změnit na repliku. Výsledkem procesu je ztráta dat. Další informace o dopadech této akce najdete v tématu Zastavení replikace.

  2. Překonfigurujte aplikaci tak, aby používala nový primární server.

  Další informace najdete v tématu záložní režim.

• Notification: Microsoft vás při výpadku oblasti automaticky neoznámí. Můžete ale použít Azure Service Health, abyste porozuměli celkovému stavu služby, včetně jakýchkoli selhání oblastí, a můžete nastavit upozornění služby Služba Health, která vás upozorní na problémy.

• Aktivní požadavky: Všechna aktivní připojení ke zdrojové oblasti se zahodí, pokud zdrojový server není k dispozici. Aplikace musí po dokončení procesu znovu navázat připojení k novému primárnímu serveru.

• Očekávaná ztráta dat: Během výpadku oblasti v datovém centru musíte provést přepnutí na zálohu, které zastaví replikaci. Výsledkem tohoto procesu je trvalá ztráta neplicitovaných dat.

  Velikost ztráty dat závisí na prodlevě replikace v době výpadku. Prodleva replikace je obvykle nejméně několik minut, ale může být mnohem delší. Další informace najdete v tématu Monitorování replikace.

• Očekávaný výpadek: Zastavení replikace se obvykle dokončí během dvou minut po aktivaci akce. Zodpovídáte za překonfigurování aplikací pro připojení k novému primárnímu serveru. Doba, kterou potřebujete k provedení překonfigurování, také přispívá k celkové době výpadku.

• Přesměrování provozu: Zodpovídáte za překonfigurování aplikací pro připojení k novému primárnímu serveru.

  Poznámka:

  Po převzetí služeb při selhání repliky pro čtení se stane primárním serverem, server nemá povolenou vysokou dostupnost. HA musíte povolit ručně nebo ji zahrnout do automatizace.

Obnovení oblasti

Jakmile se region zotaví, jste zodpovědní za činnosti spojené s navrácením provozu, aby bylo možné obnovit provoz v primárním regionu. Microsoft nepřesune primární server automaticky. V primární oblasti můžete vytvořit novou read replica a pak provést další proces převzetí služeb při selhání k obnovení operací v primární oblasti. V závislosti na tom, jestli vaše aplikace dokáže tolerovat výpadek nebo ztrátu dat, zvažte jeden z následujících přístupů:

• Převezměte aplikaci do offline režimu a počkejte, až replikace dožene všechny změny. Tento přístup vyžaduje výpadek aplikace, který je přibližně stejný jako prodleva replikace.

• Proveďte failover a akceptujte ztrátu nereplikovaných dat.

Nezapomeňte, že také zodpovídáte za překonfigurování aplikací pro připojení k novému primárnímu serveru podle potřeby.

Testování selhání regionů

Pravidelně testujte postupy při převzetí služeb při selhání repliky pro čtení, abyste si ověřili, že vaše procesy jsou platné a že funkce splňují požadavky na cílovou dobu obnovení (RTO) a cíl bodu obnovení (RPO).

Read repliku můžete kdykoli převést na primární server, a to i v případě, že jsou všechny oblasti funkční. Tyto testy doporučujeme provést v neprodukčním prostředí, protože může způsobit ztrátu dat a vyžaduje ruční navrácení služeb po obnovení.

V rámci vaší strategie obnovy po havárii pravidelně provádějte úplná cvičení obnovy. Mezi tyto postupy patří ověření dat, testování funkčnosti aplikace a zdokumentované postupy vrácení zpět.

Zálohování a obnovení

Azure Database for MySQL automaticky zálohuje vaše data, takže je můžete obnovit k libovolnému bodu v čase během doby uchovávání záloh. Tato ochrana pomáhá vyhnout se náhodnému poškození a odstranění dat. Microsoft plně spravuje zálohy bez přerušení dostupnosti serveru. Zálohy zahrnují úplné zálohy i zálohy transakčních protokolů.

• Úložiště záloh: Pokud server nakonfigurujete se zónově redundantní vysokou dostupností, systém ukládá zálohy do úložiště ZRS. Pro servery nakonfigurované bez HA nebo s místně redundantní HA systém ukládá zálohy do LRS.

  V oblastech Azure, které jsou spárované, můžete při vytváření serveru nakonfigurovat geograficky redundantní úložiště (GRS) pro zálohy. Tento přístup replikuje zálohy do Azure spárované oblasti pro dodatečnou ochranu před selháními oblastí. Systém replikuje zálohy asynchronně.

  Výchozí doba uchovávání záloh je 7 dnů, ale uchovávání můžete prodloužit až o 35 dnů. Všechny zálohy jsou šifrované.

• Obnovení: Obnovení k určitému bodu v čase (PITR) umožňuje obnovit databázi v libovolném okamžiku během doby uchovávání záloh. Proces obnovení vytvoří nový databázový server s novým uživatelským názvem serveru. Nový server můžete použít as-is nebo z něj kopírovat data.

  Když obnovíte geograficky redundantní zálohu, vytvoříte nový server ve spárované oblasti. V některých oblastech můžete pomocí univerzálního Geo-Restore obnovit geograficky redundantní zálohu do oblasti, která není spárovanou oblastí vaší primární oblasti.

  Pomocí této funkce se můžete zotavit z náhodných úprav dat, chyb aplikace nebo testovacích scénářů.

U většiny řešení byste se neměli spoléhat výhradně na zálohy. Místo toho využijte další funkce popsané v tomto průvodci k podpoře vašich požadavků na odolnost. Zálohy ale chrání před některými riziky, která jiné přístupy nechrání. Další informace najdete v tématu Co jsou redundance, replikace a zálohování?.

Další informace najdete v tématu Backup a obnovení v Azure Database for MySQL.

Odolnost vůči údržbě služeb

Azure Database for MySQL automaticky zpracovává důležité úlohy údržby, včetně oprav základního hardwaru, operačního systému a databázového stroje. Tato služba zahrnuje aktualizace zabezpečení, aktualizace softwaru a upgrady menší verze jako součást plánované údržby. Další informace najdete v tématu Plánovaná údržba v Azure Database for MySQL.

Pokud chcete zajistit, aby váš server zůstal během údržby dostupný, postupujte podle těchto doporučení:

Smlouva o úrovni služeb

Smlouva o úrovni služeb (SLA) pro služby Azure popisuje očekávanou dostupnost každé služby a podmínky, které musí vaše řešení splnit, aby bylo dosaženo očekávané dostupnosti. Další informace najdete v tématu SLA pro online služby.

Azure Database for MySQL poskytuje různé smlouvy SLA dostupnosti na základě konfigurace serveru:

• Servery nakonfigurované se zónově redundantním nastavením vysoké dostupnosti.
• Servery nakonfigurované s místní redundantní vysokou dostupností
• Servery nakonfigurované bez HA

Související obsah

• spolehlivost Azure
• Osvědčené postupy pro Architektura pro Azure Database for MySQL
• Přehled kontinuity podnikových procesů s Azure Database for MySQL