Vysoká dostupnost ve službě Azure Database for MySQL

Flexibilní server Azure Database for MySQL umožňuje nakonfigurovat vysokou dostupnost pomocí automatického převzetí služeb při selhání. Toto řešení zajišťuje, že selhání nikdy nezpůsobí ztrátu potvrzených dat a že databáze není jediným bodem selhání ve vaší softwarové architektuře. Když nakonfigurujete vysokou dostupnost, flexibilní server automaticky zřídí a spravuje pohotovostní repliku. Za zřízené výpočetní prostředky a úložiště platíte jak za primární, tak sekundární repliky. K dispozici jsou dva modely architektury s vysokou dostupností:

• Zónově redundantní vysoká dostupnost Tato možnost poskytuje úplnou izolaci a redundanci infrastruktury napříč několika zónami dostupnosti. Nabízí nejvyšší úroveň dostupnosti, ale vyžaduje, abyste nakonfigurovali redundanci aplikací napříč zónami. Zvolte zónově redundantní vysokou dostupnost, pokud chcete chránit před jakýmkoli selháním infrastruktury v zóně dostupnosti a pokud je latence napříč zónou dostupnosti přijatelná. Zónově redundantní vysokou dostupnost můžete povolit jenom při vytváření serveru. Zónově redundantní vysoká dostupnost je dostupná v podmnožině oblastí Azure, kde tato oblast podporuje více zón dostupnosti a zónově redundantní sdílené složky Premium jsou k dispozici.

• Místní redundantní vysoká dostupnost Tato možnost poskytuje redundanci infrastruktury s nižší latencí sítě, protože primární a pohotovostní servery jsou ve stejné zóně dostupnosti. Nabízí vysokou dostupnost bez nutnosti konfigurovat redundanci aplikací napříč zónami. Pokud chcete dosáhnout nejvyšší úrovně dostupnosti v rámci jedné zóny dostupnosti s nejnižší latencí sítě, zvolte lokální redundantní HA. Místně redundantní vysoká dostupnost je dostupná ve všech oblastech Azure, kde můžete použít Azure Database for MySQL Flexible Server.

Architektura zónově redundantní vysoké dostupnosti (HA)

Když nasadíte server s zónově redundantní vysokou dostupností, Azure vytvoří dva servery:

• Primární server v jedné zóně dostupnosti.
• Pohotovostní server repliky v jiné zóně dostupnosti stejné oblasti Azure. Server pohotovostní repliky má stejnou konfiguraci jako primární server, včetně úrovně výpočetních prostředků, velikosti výpočetních prostředků, velikosti úložiště a konfigurace sítě.

Můžete zvolit zónu dostupnosti pro primární server i pohotovostní repliku. Umístění pohotovostních databázových serverů a pohotovostních aplikací do stejné zóny snižuje latenci. Pomůže vám také připravit se na situace zotavení po havárii a scénáře "zón mimo provoz".

Data a soubory protokolů jsou hostované v zónově redundantním úložišti (ZRS). Pohotovostní server průběžně čte a přehrává soubory protokolu z účtu úložiště primárního serveru, který chrání replikaci na úrovni úložiště.

Pokud dojde k převzetí služeb při selhání:

• Pohotovostní replika se aktivuje.
• Binární soubory protokolu primárního serveru se nadále vztahují na pohotovostní server, aby byl online až do poslední potvrzené transakce na primárním serveru.

Protokoly v ZRS jsou přístupné i v případě, že primární server není k dispozici. Tato dostupnost pomáhá zajistit, aby nedošlo ke ztrátě dat. Po aktivaci pohotovostní repliky a použití binárních protokolů převezme aktuální pohotovostní server repliky roli primárního serveru. Aktualizace DNS tak, aby klientská připojení byla při opětovném připojení klienta přímo k novému primárnímu serveru. Převzetí služeb při selhání je plně transparentní z klientské aplikace a nevyžaduje od vás žádnou akci. Řešení vysoké dostupnosti pak vrátí starý primární server, pokud je to možné, a umístí ho jako pohotovostní server.

Název databázového serveru slouží k připojení aplikací k primárnímu serveru. Řešení nezpřístupňuje informace o pohotovostní replice pro přímý přístup. Potvrzení a zápisy se potvrdí po vyprázdnění souborů protokolu na ZRS primárního serveru. Vzhledem k technologii replikace synchronizace používané v úložišti ZRS můžete očekávat 5 až 10procentní zvýšenou latenci pro zápisy a potvrzení aplikací.

Automatické zálohování, snímky i zálohy protokolů, se provádí v zónově redundantním úložišti z primárního databázového serveru.

Architektura vysoké dostupnosti s místní redundancí (HA)

Když nasadíte server s HA s místní redundancí, vytvoříte dva servery ve stejné zóně.

• Primární server
• Pohotovostní server repliky, který má stejnou konfiguraci jako primární server (úroveň výpočetních prostředků, velikost výpočetních prostředků, velikost úložiště a konfigurace sítě)

Pohotovostní server poskytuje redundanci infrastruktury pomocí samostatného virtuálního počítače (výpočetních prostředků). Tato redundance snižuje dobu převzetí služeb při selhání a latenci sítě mezi aplikací a databázovým serverem kvůli kolokaci.

Data a soubory protokolů jsou hostované v místně redundantním úložišti (LRS). Pohotovostní server průběžně čte a přehrává soubory protokolu z účtu úložiště primárního serveru, který je chráněný replikací na úrovni úložiště.

Pokud dojde k převzetí služeb při selhání:

• Pohotovostní replika se aktivuje.
• Binární soubory protokolu primárního serveru se nadále vztahují na pohotovostní server, aby byl online až do poslední potvrzené transakce na primárním serveru.

Protokoly v LRS jsou přístupné i v případě, že primární server není dostupný. Tato dostupnost pomáhá zajistit, aby nedošlo ke ztrátě dat. Po aktivaci pohotovostní repliky a použití binárních protokolů převezme aktuální pohotovostní replika roli primárního serveru. Dns se aktualizuje tak, aby při opětovném připojení klienta přesměrovává připojení k nové primární síti. Převzetí služeb při selhání je plně transparentní z klientské aplikace a nevyžaduje od vás žádnou akci. Řešení vysoké dostupnosti pak vrátí starý primární server, pokud je to možné, a umístí ho jako pohotovostní server.

Název databázového serveru připojuje aplikace k primárnímu serveru. Informace o pohotovostní replice nejsou přístupné pro přímý přístup. Potvrzení a zápisy se potvrdí po vyprázdnění souborů protokolu na LRS primárního serveru. Protože primární a pohotovostní replika jsou ve stejné zóně, je mezi aplikačním serverem a databázovým serverem menší prodleva replikace a nižší latence. Místní redundantní nastavení neposkytuje vysokou dostupnost, pokud jsou závislé infrastruktury pro konkrétní zónu dostupnosti mimo provoz. Dojde k výpadkům, dokud nebudou všechny závislé služby pro danou zónu dostupnosti zase online.

Automatické zálohování, snímky i zálohy protokolů, se provádí na místně redundantním úložišti z primárního databázového serveru.

Poznámka:

Pro zónově redundantní i místní redundantní vysokou dostupnost:

• Pokud dojde k selhání, doba potřebná k převzetí role primární repliky v pohotovostním režimu závisí na době potřebné k přehrání binárního protokolu z primárního účtu úložiště do pohotovostního režimu. Pokud chcete zkrátit dobu převzetí služeb při selhání, použijte u všech tabulek primární klíče. Časy převzetí služeb při selhání obvykle trvá 60 až 120 sekund.
• Pohotovostní server není k dispozici pro operace čtení nebo zápisu. Jedná se o pasivní pohotovostní režim, který umožňuje rychlé převzetí služeb při selhání.
• Vždy použijte plně kvalifikovaný název domény (FQDN) pro připojení k primárnímu serveru. Vyhněte se použití IP adresy pro připojení. Pokud dojde k převzetí služeb při selhání, může se po přepnutí primární a pohotovostní role serveru změnit záznam DNS A. Tato změna brání aplikaci v připojení k novému primárnímu serveru, pokud se v připojovacím řetězci použije IP adresa.

Proces převzetí služeb při selhání

Během procesu převzetí služeb při selhání ve službě Azure Database for MySQL se systém automaticky přepne z primárního serveru na pohotovostní repliku. Tento přepínač zajišťuje kontinuitu a minimalizuje výpadky. Když systém zjistí selhání, podporuje pohotovostní repliku, aby se stala novým primárním serverem. Systém použije binární soubory protokolu z původního primárního serveru na pohotovostní repliku. Tento proces synchronizuje pohotovostní repliku s poslední potvrzenou transakcí a zajišťuje žádnou ztrátu dat. Tento bezproblémový přechod pomáhá udržovat vysokou dostupnost a spolehlivost databázové služby.

Poznámka:

Aby se snížila závislost doby převzetí služeb při selhání na ukládání do mezipaměti DNS, od října 2025 budou všechny nové servery vysoké dostupnosti (HA) vytvořené s veřejným přístupem nebo privátním propojením používat novou architekturu s vyhrazeným SLB pro každý HA server. Díky správě cesty přenosu dat MySQL SLB eliminuje potřebu změn DNS během přepnutí při selhání a výrazně zlepšuje výkon při přepnutí v případě selhání. Během přepnutí při selhání přesměruje provoz do aktuální primární instance pomocí pravidel pro vyrovnávání zátěže. Stávající servery s veřejným přístupem nebo privátním propojením se budou migrovat postupně, aby se minimalizoval dopad. Zákazníci, kteří upřednostňují brzkou migraci, mohou vysokou dostupnost zakázat a poté znovu aktivovat. Tato funkce není podporována pro servery používající privátní přístup s integrací virtuální sítě.

Plánováno: Vynucené převzetí služeb při selhání

Flexibilní server Azure Database for MySQL s vynuceným převzetím služeb při selhání umožňuje ruční vynucení převzetí služeb při selhání. Tato funkce umožňuje otestovat funkčnost ve scénářích aplikace a pomůže vám připravit se na výpadky.

Vynucené převzetí služeb při selhání aktivuje převzetí služeb při selhání, které aktivuje záložní repliku, aby se stala primárním serverem se stejným názvem databázového serveru, a to aktualizací záznamu DNS. Původní primární server se restartuje a přepne na pohotovostní repliku. Připojení klientů se odpojí a potřebují se znovu připojit, aby se obnovily jejich operace.

Celková doba převzetí služeb při selhání závisí na aktuální úloze a posledním kontrolním bodě. Obecně trvá 60 až 120 sekund.

Poznámka:

Během plánovaného převzetí služeb při selhání se vygeneruje událost služby Azure Resource Health. Událost představuje dobu převzetí služeb při selhání, během které server není k dispozici. V levém podokně můžete zobrazit aktivované události, které jsou vybrány ve službě Resource Health . Stav představuje uživatelem iniciované nebo ruční převzetí služeb při selhání jako Nedostupné a označené jako Plánované. Příklad : Operace převzetí služeb při selhání aktivovala autorizovaný uživatel (plánované). Pokud váš prostředek zůstane v tomto stavu po delší dobu, otevřete lístek podpory a my vám pomůžeme.

Neplánováno: Automatické převzetí služeb při selhání

K neplánovaným výpadkům služby může dojít kvůli chybám softwaru nebo chybám infrastruktury, jako jsou výpočetní prostředky, síť nebo selhání úložiště. Výpadky napájení můžou také ovlivnit dostupnost databáze. Pokud se databáze stane nedostupnou, replikace do pohotovostní repliky se zastaví a pohotovostní replika se stane primární databází. Dochází k aktualizacím DNS a klienti se znovu připojují k databázovému serveru a obnovují své operace.

Celková doba převzetí služeb při selhání je obvykle 60 až 120 sekund. V závislosti na aktivitě primárního databázového serveru však v době převzetí služeb při selhání (například velké transakce a doba obnovení) může převzetí služeb při selhání trvat déle.

Poznámka:

Událost služby Azure Resource Health se vygeneruje během neplánovaného převzetí služeb při selhání. Událost představuje čas převzetí služeb při selhání, kdy server není k dispozici. Aktivované události se zobrazí, když v levém podokně vyberete Resource Health . Automatické převzetí služeb při selhání zobrazuje stav Nedostupný a je označený jako Neplánovaný.

Například Nedostupný: Operace převzetí služeb při selhání se aktivovala automaticky (neplánovaná). Pokud váš prostředek zůstane v tomto stavu dlouho, otevřete lístek podpory a my vám pomůžeme.

Jak funguje automatické zjišťování převzetí služeb při selhání na serverech s podporou vysoké dostupnosti

Primární server a sekundární server mají dva koncové body sítě:

• Koncový bod zákazníka: Zákazníci se připojují a spouštějí dotazy na instanci pomocí tohoto koncového bodu.
• Koncový bod správy: Interně se používá pro komunikaci služeb s komponentami pro správu a pro připojení k back-endovému úložišti.

Komponenta monitorování stavu nepřetržitě provádí následující kontroly:

• Monitorování odešle příkaz ping koncovému bodu sítě pro správu uzlu. Pokud tato kontrola selže dvakrát za sebou, aktivuje automatickou operaci převzetí služeb při selhání. Tato kontrola stavu řeší scénáře, jako je nedostupnost uzlu nebo nereagovatelnost kvůli problémům s operačním systémem, problémům se sítí mezi komponentami správy a uzly a podobnými problémy.
• Monitorování spustí jednoduchý dotaz na instanci. Pokud se dotazy nespustí, aktivuje se automatické převzetí služeb při selhání. Tato kontrola stavu řeší scénáře, jako jsou chybové ukončení démona MySQL, zastavení nebo zablokování, problémy s back-endovým úložištěm a podobné problémy.

Poznámka:

Kontrola stavu nemonitoruje síťové problémy mezi aplikací a koncovým bodem sítě zákazníka (privátní nebo veřejný přístup). K těmto problémům může dojít v síťové cestě, v koncovém bodu nebo v problémech s DNS na straně klienta. Pokud používáte privátní přístup, ujistěte se, že pravidla NSG pro virtuální síť neblokují komunikaci s koncovým bodem sítě zákazníka instance na portu 3306. Pro veřejný přístup se ujistěte, že jsou nastavená pravidla brány firewall a že je povolený síťový provoz na portu 3306 (pokud síťová cesta obsahuje jiné brány firewall). Musíte se také postarat o překlad DNS ze strany klientské aplikace.

Monitorování vysoké dostupnosti

Pokud chcete zkontrolovat stav konfigurace vysoké dostupnosti serveru, použijte stav vysoké dostupnosti v podokně vysoké dostupnosti serveru na portálu.

Stav	Popis
NotEnabled	vysoká dostupnost není povolená.
Replikace dat	Pohotovostní server se během zřizování serveru s vysokou dostupností synchronizuje s primárním serverem nebo když povolíte možnost vysoké dostupnosti.
Převzetí služeb při selhání	Databázový server přebírá služby při selhání z primárního do pohotovostního režimu.
Zdravý	Možnost vysoké dostupnosti je povolená.
Odebránístandby	Proces odstranění probíhá, když zakážete možnost vysoké dostupnosti.

Pokud chcete monitorovat stav serveru s vysokou dostupností, použijte následující metriky.

Zobrazovaný název metriky	Metrika	Jednotka	Popis
Stav vysoké dostupnosti IO	ha_io_running	Stát	Stav vysoké dostupnosti IO zobrazuje stav replikace vysoké dostupnosti. Hodnota metriky je 1, pokud je spuštěné vstupně-výstupní vlákno a 0, pokud ne.
Stav SQL vysoké dostupnosti	ha_sql_running	Stát	Stav SQL vysoké dostupnosti zobrazuje stav replikace vysoké dostupnosti. Hodnota metriky je 1, pokud je vlákno SQL spuštěné a 0, pokud ne.
Prodleva replikace vysoké dostupnosti	zpoždění replikace	Sekundy	Prodleva replikace je počet sekund, po které je pohotovostní režim za sebou při přehrání transakcí přijatých na primárním serveru.

Omezení

Při používání vysoké dostupnosti mějte na paměti následující aspekty:

• Zónově redundantní vysokou dostupnost můžete nakonfigurovat pouze při vytváření serveru.

• Nárazová úroveň výpočetních prostředků nepodporuje vysokou dostupnost.

• Restartováním primárního databázového serveru, aby se použily změny statických parametrů, restartuje se také pohotovostní replika.

• Řešení zapne režim GTID, protože používá GTID. Zkontrolujte, jestli má vaše úloha omezení nebo omezení replikace pomocí identifikátorů GTID.

Poznámka:

Automatické zvětšování úložiště je ve výchozím nastavení povolené pro nakonfigurovaný server s vysokou dostupností a nedá se zakázat.

Kontroly stavu

Při konfiguraci vysoké dostupnosti (HA) pro Azure Database for MySQL hrají kontroly stavu zásadní roli při zachování spolehlivosti a výkonu vaší databáze. Tyto kontroly nepřetržitě monitorují stav a stav primárních i pohotovostních replik a zajišťují, že okamžitě detekují všechny problémy. Sledováním různých metrik, jako je odezva serveru, prodleva replikace a využití prostředků, pomáhají kontroly stavu zajistit, aby se procesy převzetí služeb při selhání mohly bez problémů spouštět, minimalizovat výpadky a bránit ztrátě dat. Správně nakonfigurované kontroly stavu jsou nezbytné pro dosažení požadované úrovně dostupnosti a odolnosti v nastavení databáze.

Monitorování stavu

Stav nastavení vysoké dostupnosti můžete monitorovat prostřednictvím webu Azure Portal. Mezi klíčové metriky, které se mají sledovat, patří:

• Odezva serveru: Označuje, jestli je primární server dostupný.
• Prodleva replikace: Měří zpoždění mezi primárními a pohotovostními replikami a zajišťuje konzistenci dat.
• Využití prostředků: Monitoruje využití procesoru, paměti a úložiště, aby se zabránilo kritickým bodům.

Související obsah

• vysoká dostupnost
• Provozní kontinuita
• Zónově redundantní vysoká dostupnost
• zálohování a obnovení