Spolehlivost v Azure Database for MySQL

Azure Database for MySQL je plně spravovaná databázová služba navržená tak, aby vám poskytla podrobnou kontrolu a flexibilitu nad funkcemi správy databáze a nastavením konfigurace. Služba poskytuje možnosti vysoké dostupnosti a zotavení po havárii 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 učinit Azure Database for MySQL odolnou vůči nejrůznějším potenciálním výpadkům a problémům, včetně přechodných chyb, výpadků zón dostupnosti, výpadků regionů a údržby služeb. 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í

Další informace o nasazení Azure Database for MySQL pro podporu požadavků na spolehlivost vašeho řešení a o tom, jak spolehlivost ovlivňuje další aspekty architektury, najdete v osvědčených postupech Architecture pro Azure Database for MySQL v Azure Well-Architected Frameworku.

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íce úrovních výpočetních prostředků: burstable, Pro obecné účely a Optimalizováno pro paměť, z nichž každá je optimalizovaná pro různé druhy úloh.

Další informace o obecné architektuře služeb a modelech nasazení najdete v tématu Co je Azure Database for MySQL?.

Fyzická architektura

  • Kompute a oddělení úložiště: Azure Database for MySQL využívá architekturu oddělení výpočetních prostředků a úložiště k zajištění 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 místně redundantním úložišti (LRS).

  • Vysoká dostupnost: Volitelně můžete na serveru povolit konfiguraci vysoké dostupnosti . Když povolíte konfiguraci vysoké dostupnosti, služba zřídí a udržuje server repliky ve vlažném záložním režimu. 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ě a umožňuje službě 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í. Existují dva typy převzetí služeb při selhání: neplánované převzetí služeb při selhání, které se používají při selhání primárního serveru, a plánované převzetí služeb při selhání, které se používají v jiných scénářích, kdy potřebujete minimalizovat výpadky aplikace během převzetí služeb při selhání.

    Další informace najdete v tématu Vysoká dostupnost 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í:

  • Když ve vaší aplikaci dojde k přechodným chybám, zkuste operaci zopakovat pomocí exponenciálního zpomalování. Zvyšte prodlevu mezi opakovanými pokusy a omezte počet pokusů. Pokud operace po maximálním počtu opakování stále selže, považuje se za selhání.
  • Pokud je to možné, použijte klientské knihovny , které automaticky zpracovávají opakování.
  • Přechodné chyby, ke kterým dochází během operací zápisu, vyžadují pečlivější pozornost. Zvažte nastavení idempotentních operací zápisu, aby se mohly bezpečně spouštět několikrát.

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.

Typ podpory pro zóny dostupnosti můžete vybrat prostřednictvím konfigurace vysoké dostupnosti. Povolení vysoké dostupnosti umožňuje nasazení standby replika serveru společně s primárním serverem. Tento model vysoké dostupnosti pomáhá zajistit, aby se během selhání nikdy neztratila potvrzená data. Podle toho, který model nasazení s vysokou dostupností zvolíte, se data synchronně potvrdí na primární i pohotovostní servery repliky. Pokud dojde k přerušení primárního serveru, server automaticky převezme služby serveru pohotovostní repliky.

Data se ukládají v Azure Files Premium Storage. V závislosti na konfiguraci vysoké dostupnosti vašeho serveru buď používá zónově redundantní úložiště, nebo místně redundantní úložiště (LRS), které ukládá tři kopie dat v rámci zón dostupnosti nebo napříč zónami dostupnosti.

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

  • Zónově redundantní vysoká dostupnost: Redundance zón poskytuje nejvyšší úroveň odolnosti zóny nasazením primárního serveru do jedné zóny dostupnosti a pohotovostního serveru repliky v jiné zóně 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 doporučujeme zónově redundantní nasazení.

    Diagram znázorňující zónově redundantní server s primárními a pohotovostními servery v různých zónách dostupnosti

    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í, ale dopad se liší podle úloh, vybraných skladových položek a oblastí.

  • Místní redundantní vysoká dostupnost: Primární a pohotovostní 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í poskytuje vysokou dostupnost v rámci jedné zóny dostupnosti. Chrání vás před selháními na úrovni uzlu a také pomáhá snížit výpadky aplikace 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 s zónami dostupnosti se tento druh konfigurace také někdy označuje jako zónová nebo jednozónová.

    Diagram znázorňující místní redundantní server s primárními a pohotovostními servery ve stejné zóně dostupnosti

    Doporučujeme místní redundanci pro vysokou dostupnost jenom v konkrétních scénářích:

    • Pokud máte neobvykle citlivé aplikace na latenci, ověřili jste nutnost minimalizovat latenci mezi primární a sekundární replikou a plánujete odolnost zón sami pomocí jiných přístupů k architektuře.
    • Když nasadíte do oblasti, která nepodporuje zóny dostupnosti, bude tato oblast efektivně fungovat jako jedna zóna, čímž se místní redundantní vysoká dostupnost stane jedinou možností vysoké dostupnosti.

    Vzhledem k tomu, že jsou servery ve stejné zóně, může snížit latenci zápisu do aplikací, které nasadíte v této zóně.

Pokud nakonfigurujete server bez vysoké dostupnosti, spustí se na jednom serveru. Pokud tento server nebo jeho zóna zmizí, server není dostupný.

Požadavky

  • Podpora oblasti: Podpora služby Azure Database pro MySQL pro konfigurace zón dostupnosti se liší mezi jednotlivými oblastmi Azure. Úplný seznam oblastí, typy podpory zón dostupnosti a konkrétní aspekty pro jednotlivé oblasti najdete v části Azure regiony.

  • Úroveň služby: Pro vysokou dostupnost jsou vyžadovány úrovně Obecný účel nebo Optimalizováno pro paměť. Úroveň Burstable nepodporuje vysokou dostupnost (zónovou nebo lokální redundanci).

Náklady

Když povolíte vysokou dostupnost, vytvoří se pohotovostní server a fakturuje se stejným tempem jako primární server. Konfigurace zóny dostupnosti nemá vliv na náklady. Za replikaci dat v rámci zón dostupnosti ani mezi zónami dostupnosti se neúčtují žádné poplatky. 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: U všech tabulek doporučujeme používat primární klíče, protože tento přístup zkracuje dobu replikace a 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, nakonfigurujete nastavení vysoké dostupnosti.

Poznámka:

Když vyberete, které zóny dostupnosti se mají použít, ve skutečnosti vybíráte logickou zónu dostupnosti. Pokud nasadíte jiné součásti úloh v jiném Azure předplatném, můžou pro přístup ke stejné zóně fyzické dostupnosti použít jiné číslo logické zóny dostupnosti. Další informace najdete v tématu Fyzické a logické zóny dostupnosti.

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

Tato část popisuje, co očekávat, když jsou servery nakonfigurované s vysokou dostupností a podporou 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í, kde se všechna připojení a dotazy databáze zpracovávají primárním serverem 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 potvrdí 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 dopad se liší podle úloh, vybraných skladových položek a oblastí.

    • Místně redundantní: Provoz se mezi zónami nereplikuje.

    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ých aktualizací 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 očekávat, když jsou servery nakonfigurované pro vysokou dostupnost s podporou zón dostupnosti a dojde k výpadku v jedné z těchto zón.

  • 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.

    V případě selhání zóny se chování 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 tématu Jak funguje automatická detekce přepnutí služeb 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.

  • Notification: 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 ukončit všechny probíhající požadavky na servery v ovlivněné zóně. 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á.

    • Zónově redundantní: Převzetí služeb při selhání se obvykle dokončí během 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í po selhání se bývalý pohotovostní 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ě. Úplné podrobnosti 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á.

  • Zone-redundant: 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í server do původní zóny, můžete ručně zahájit plánovaný přechod na zálohu.

  • Lokálně redundantní: Jakmile je zóna v pořádku, servery v zóně jsou opět k dispozici. Zodpovídáte za všechny postupy obnovení zóny 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á.

Odolnost proti selháním v celé oblasti

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

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

Repliky pro čtení můžete nasadit pro ochranu databází před selháním 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ž deset replik pro čtení, které můžou být volitelně v různých Azure oblastech. Technologie fyzické replikace MySQL aktualizuje repliky pro čtení asynchronně ze zdrojového serveru v primární oblasti, což může vést k jejich zaostávání za zdrojem. 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 a aspektech čtení replik najdete v tématu Repliky pro čtení.

Diagram zobrazující repliku čtení v druhé Azure oblasti s aplikací, která směruje provoz pro čtení a zápis na zdrojový server.

Pokud vaše primární oblast selže, můžete ručně provést převzetí funkcí, aby se sekundární replika stala primárním serverem. Toto provedete zastavením replikace, čímž se replika pro čtení změní 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 pak musí připojit k novému primárnímu serveru a zodpovídáte za rekonfiguraci této aplikace.

Diagram zobrazující repliku pro čtení v druhém regionu Azure, která se v důsledku převzetí služeb stala primárním serverem. Aplikace teď směruje provoz pro čtení a zápis do nyní primárního regionu.

Poznámka:

Tato část shrnuje některé důležité informace o tom, jak repliky pro čtení můžou podporovat odolnost proti selháním v celé oblasti. Repliky pro čtení můžete také použít ke zlepšení výkonu a podpoře geograficky distribuovaných uživatelských bází ve velkém měřítku. Další informace viz Read replicas.

Požadavky

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

  • Ú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ě. Hodnoty můžete přizpůsobit v replice určené pro čtení po jejím vytvoření. Nejlepší je ale použít stejné nebo větší hodnoty, aby se zajistilo, že replika dokáže držet krok se změnami ve zdroji.

  • Monitorování prodlevy replikace: Asynchronní proces replikace vyžaduje prodlevu replikace, která se může lišit v závislosti na řadě faktorů. 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.

  • Vysoká dostupnost: Repliky pro čtení nemohou mít povolenou vysokou dostupnost a když se převzetí služeb při selhání stane primárním serverem, nebudou mít také vysokou dostupnost. Jste zodpovědní za konfiguraci vysoké dostupnosti po přepnutí 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í

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

Tato část popisuje, co očekávat, když je server nakonfigurovaný s replikou pro čtení v jiné oblasti a všechny oblasti jsou funkční:

  • Směrování provozu mezi oblastmi: V normálních operacích by vaše aplikace měla směrovat provoz pro čtení a 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 pro čtení mezi oblastmi používají asynchronní replikaci k minimalizaci dopadu na výkon zdrojového serveru. Prodleva replikace závisí na řadě faktorů, 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ž je server nakonfigurovaný s replikou pro čtení v jiné oblasti a v primární oblasti došlo k výpadku:

  • Detekce a odezva: Zodpovídáte za detekci výpadku v primární oblasti a ruční spuštění přepnutí při selhání. Tato akce může vést ke ztrátě jakýchkoli nereplikovaných dat.

    Důležité

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

    Převzetí služeb při selhání vyžaduje:

    1. Zastavení replikace Jedná se o nevratnou proceduru a server nemůže být znovu převeden do repliky. Výsledkem procesu je ztráta dat. Další podrobnosti o dopadech této akce najdete v tématu Zastavení replikace.
    2. Překonfigurujte aplikaci tak, aby používala novou primární instanci.

    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 všech 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 2 minut od aktivace. Zodpovídáte za změnu konfigurace aplikací pro připojení k novému primárnímu serveru a doba potřebnou k provedení rekonfigurace také přispívá k celkovému 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řevodu čtecí repliky na primární server, server nemá povolenou vysokou dostupnost. Vysokou dostupnost musíte povolit ručně nebo ji zahrnout do automatizace.

Obnovení oblasti

Když se region obnoví, nesete odpovědnost za všechny aktivity k navrácení provozu v primární oblasti. 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ý se přibližně rovná prodlevě replikace.
  • Proveďte převzetí služeb při selhání a přijměte ztrátu všech 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řevzetí služeb při selhání replik pro čtení, abyste měli jistotu, že vaše procesy jsou platné a že schopnosti splňují požadavky RTO a 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í. Doporučujeme provést tyto testy v neprodukčním prostředí, protože může dojít ke ztrátě dat a vyžaduje ruční obnovení zpět.

V rámci strategie obnovy po havárii pravidelně provádějte kompletní cvičení obnovy. Tyto postupy by měly zahrnovat 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 provádí zálohy, které poskytují možnosti obnovení k určitému bodu v čase a pomáhají chránit vás před náhodným poškozením a odstraněním dat. Microsoft plně spravuje zálohy, nepřerušujte dostupnost serveru a zahrňte úplné zálohy i zálohy transakčních protokolů.

  • Úložiště zálohování: Pokud je server nakonfigurovaný s zónově redundantní vysokou dostupností, zálohy se ukládají v zónově redundantním úložišti (ZRS). Pro servery nakonfigurované bez funkce vysoké dostupnosti nebo s lokálně redundantní vysokou dostupností se zálohy ukládají v místně redundantním úložišti (LRS).

    V oblastech Azure, které mají dvojice, můžete nakonfigurovat geograficky redundantní úložiště zálohování (GRS) při vytváření serveru, aby replikovalo zálohy do Azure spárované oblasti a poskytovalo dodatečnou ochranu před selháním oblasti. Zálohy se replikují asynchronně.

    Výchozí doba uchovávání záloh je 7 dnů a možnost prodloužit uchovávání až na 35 dnů. Všechny zálohy jsou šifrované.

  • Obnovení: Obnovení k určitému bodu v čase umožňuje obnovit databázi v libovolném okamžiku v rámci doby uchovávání záloh. Proces obnovení vytvoří nový databázový server s novým uživatelským názvem serveru, ze kterého pak můžete použít as-is nebo zkopí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.

    Tato funkce je užitečná pro zotavení z náhodných úprav dat, chyb aplikací 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í:

  • Vyhněte se operacím správy během období údržby: Během údržby neprovádějte operace správy serverů, protože tyto operace můžou ovlivnit spolehlivost vašeho serveru.

  • Použijte údržbu téměř nulového výpadku: Pokud má váš server povolenou vysokou dostupnost a splňuje další kritéria způsobilosti, operace údržby se často dokončí do 10 až 30 sekund. Pokud máte povolenou vysokou dostupnost, operace údržby obvykle používají kumulativní aktualizace k minimalizaci výpadků. Pravidelné činnosti údržby, jako jsou upgrady minoritních verzí, probíhají nejprve na záložní replice. Aby se snížil výpadek, je pohotovostní režim povýšen na primární, aby úlohy mohly zůstat zapnuté, zatímco úlohy údržby se použijí na zbývajícím uzlu. Toto sekvencování platí bez ohledu na to, zda váš server používá zónově nebo místně redundantní dostupnost. Další informace najdete v tématu Údržba téměř nulového výpadku.

  • Konfigurace vlastních časových období údržby: Plán údržby můžete nakonfigurovat tak, aby byl spravovaný systémem, nebo můžete definovat vlastní časové období údržby, abyste minimalizovali dopad na vaše obchodní operace. Můžete také přeplánovat operace plánované údržby. Naplánujte údržbu během období s nízkou aktivitou, abyste minimalizovali obchodní dopad. Další informace najdete v tématu Spravování nastavení plánované údržby pro Azure Database for MySQL.

  • Implementace logiky opakování: Zajistěte, aby vaše aplikace zvládly krátké přerušení připojení, ke kterým může dojít při restartování údržby. Pokud chcete, aby vaše aplikace byly odolné vůči těmto typům problémů, přečtěte si pokyny k odolnosti proti přechodným chybám .

  • Povolte virtuální kanárovou údržbu na vývojových a testovacích serverech: Virtuální canární údržba nabízí přednostní přístup k aktualizacím. Když ji povolíte na vývojových a testovacích serverech, můžete ověřit, že vaše úloha nebude ovlivněná nadcházejícími aktualizacemi, než se dostanou k vašim produkčním serverům. Další informace viz Virtuální kanárová údržba.

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é s zónově redundantní vysokou dostupností
  • Servery nakonfigurované s vysokou dostupností pomocí místní redundance.
  • Servery nakonfigurované bez vysoké dostupnosti

Související obsah

  • Last updated on