Koncepce vysoké dostupnosti flexibilního serveru Azure Database for MySQL
PLATÍ PRO: 
Flexibilní server Azure Database for MySQL
Flexibilní server Azure Database for MySQL umožňuje konfigurovat vysokou dostupnost pomocí automatického převzetí služeb při selhání. Řešení vysoké dostupnosti je navržené tak, aby se zajistilo, že potvrzená data se nikdy neztratí z důvodu selhání a že databáze nebude v rámci softwarové architektury kritický prvek způsobující selhání. Pokud je nakonfigurovaná vysoká dostupnost, flexibilní server automaticky zřídí a spravuje pohotovostní repliku. Za zřízené výpočetní prostředky a úložiště se vám účtuje jak primární, tak sekundární replika. K dispozici jsou dva modely architektury pro vysokou dostupnost:
Zónově redundantní vysoká dostupnost. Tato možnost je upřednostňovaná pro úplnou izolaci a redundanci infrastruktury napříč několika zónami dostupnosti. Poskytuje nejvyšší úroveň dostupnosti, ale vyžaduje, abyste nakonfigurovali redundanci aplikace napříč zónami. Zónově redundantní vysoká dostupnost je upřednostňovaná, pokud chcete dosáhnout nejvyšší úrovně dostupnosti proti selhání infrastruktury v zóně dostupnosti a kdy je latence napříč zónou dostupnosti přijatelná. Je možné ho povolit pouze 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.
Stejná zóna ha. Tato možnost je upřednostňovaná pro redundanci infrastruktury s nižší latencí sítě, protože primární a pohotovostní servery budou ve stejné zóně dostupnosti. Poskytuje vysokou dostupnost bez nutnosti konfigurovat redundanci aplikací napříč zónami. Vysoká dostupnost se stejnou zónou se upřednostňuje, pokud chcete dosáhnout nejvyšší úrovně dostupnosti v rámci jedné zóny dostupnosti s nejnižší latencí sítě. Vysoká dostupnost se stejnou zónou je dostupná ve všech oblastech Azure, kde můžete použít flexibilní server Azure Database for MySQL.
Zónově redundantní architektura vysoké dostupnosti
Když nasadíte server se zónově redundantní vysokou dostupností, vytvoří se dva servery:
- Primární server v jedné zóně dostupnosti.
- 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ě) v jiné zóně dostupnosti stejné oblasti Azure.
Můžete zvolit zónu dostupnosti pro primární a pohotovostní repliku. Umístění pohotovostních databázových serverů a pohotovostních aplikací do stejné zóny snižuje latenci. Umožňuje také lépe 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 čte a přehrává soubory protokolu nepřetržitě 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 je aktivována.
- 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. DNS se aktualizuje, aby se připojení klientů při opětovném připojení klienta směrovala na novou primární. 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. 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 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 se stejnou zónou
Když nasadíte server se stejnou zónou ha, vytvoří se ve stejné zóně dva servery:
- 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 nabízí 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 čte a přehrává soubory protokolu nepřetržitě 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 je aktivována.
- 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 slouží k připojení aplikací 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. Nastavení stejné zóny 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 stejnou zónu ha:
- 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. Proto doporučujeme používat primární klíče pro všechny tabulky, abyste zkrátili dobu převzetí služeb při selhání. Časy převzetí služeb při selhání jsou obvykle mezi 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 zabrání aplikaci v připojení k novému primárnímu serveru, pokud se v připojovací řetězec použije IP adresa.
Proces převzetí služeb při selhání
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 vám umožní 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 do záložní repliky. Klientská připojení jsou odpojena a pro obnovení jejich provozu je potřeba je znovu připojit.
Celková doba převzetí služeb při selhání závisí na aktuální úloze a posledním kontrolním bodě. Obecně se očekává, že bude trvat 60 až 120 sekund.
Poznámka:
Událost služby Azure Resource Health se generuje v případě plánovaného převzetí služeb při selhání představující dobu převzetí služeb při selhání, během které server nebyl k dispozici. Aktivované události se dají zobrazit po kliknutí na Resource Health v levém podokně. Uživatelem zahájené/ Ruční převzetí služeb při selhání je reprezentováno stavem Nedostupné a označeno 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í
Neplánované výpadky služby můžou být způsobené chybami softwaru nebo infrastruktury, jako jsou chyby výpočetních prostředků, sítě nebo úložiště nebo výpadky napájení, které ovlivňují dostupnost databáze. Pokud databáze přestane být dostupná, replikace na pohotovostní repliku se přeruší a pohotovostní replika se aktivuje jako primární databáze. Dns se aktualizuje a klienti se znovu připojí k databázovému serveru a obnoví jejich operace.
Celková doba převzetí služeb při selhání se očekává v rozmezí 60 až 120 sekund. V závislosti na aktivitě primárního databázového serveru v době převzetí služeb při selhání (jako jsou velké transakce a doba obnovení) ale může převzetí služeb při selhání trvat déle.
Poznámka:
Událost služby Azure Resource Health se generuje v případě neplánovaného převzetí služeb při selhání, což představuje dobu převzetí služeb při selhání, během které byl server nedostupný. Aktivované události se dají zobrazit po kliknutí na Resource Health v levém podokně. Automatické převzetí služeb při selhání je reprezentováno stavem Nedostupné a označeno jako Neplánované. Příklad – Nedostupné: Automaticky se aktivovala operace převzetí služeb při selhání (neplánovaná). Pokud váš prostředek zůstane v tomto stavu po delší dobu, 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ík se připojí a spustí dotaz 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 do koncového bodu sítě pro správu uzlů. Pokud tato kontrola selže dvakrát nepřetržitě, aktivuje automatickou operaci převzetí služeb při selhání. Scénář, jako je uzel, není k dispozici nebo nereaguje kvůli problému s operačním systémem, problém se sítí mezi komponentami pro správu a uzly atd. bude vyřešen touto kontrolou stavu.
- Monitorování také spustí jednoduchý dotaz na instanci. Pokud se dotazy nespustí, aktivuje se automatické převzetí služeb při selhání. Tyto kontroly stavu řeší scénáře, jako je chyba démon MySQL, zastavení nebo zablokování, problém s back-endovým úložištěm atd..
Poznámka:
Pokud mezi aplikací a koncovým bodem sítě zákazníka (privátním nebo veřejným přístupem) dojde k nějakému problému se sítí, a to buď v síťové cestě, v koncovém bodu nebo v případě problémů s DNS na straně klienta, kontrola stavu tento scénář nemonitoruje. Pokud používáte privátní přístup, ujistěte se, že pravidla skupiny zabezpečení sítě 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 síťový provoz povolený na portu 3306 (pokud síťová cesta obsahuje jiné brány firewall). Musí se také postarat o překlad DNS ze strany klientské aplikace.
Monitorování vysoké dostupnosti
Stav vysoké dostupnosti umístěný v podokně Vysoká dostupnost serveru na portálu se dá použít k určení stavu konfigurace vysoké dostupnosti serveru.
| Stav | Popis |
|---|---|
| NotEnabled | Vysoká dostupnost není povolená. |
| Replikace dat | Pohotovostní server probíhá při synchronizaci s primárním serverem v době zřizování serveru vysoké dostupnosti nebo při povolení možnosti vysoké dostupnosti. |
| Převzetí služeb při selhání | Databázový server probíhá v procesu převzetí služeb při selhání z primárního do pohotovostního režimu. |
| Zdravý | Je povolená možnost ha. |
| Odebránístandby | Když je možnost ha zakázaná a proces odstranění probíhá. |
K monitorování stavu serveru vysoké dostupnosti můžete použít také následující metriky.
| Zobrazovaný název metriky | Metrika | Unit | Popis |
|---|---|---|---|
| Stav vstupně-výstupních operací vysoké dostupnosti | ha_io_running | State | Stav vstupně-výstupních operací vysoké dostupnosti označuje 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 | State | Stav HA SQL označuje stav replikace vysoké dostupnosti. Hodnota metriky je 1, pokud je vlákno SQL spuštěné a 0, pokud ne. |
| Prodleva replikace vysoké dostupnosti | replication_lag | 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í
Tady je několik aspektů, které je potřeba vzít v úvahu při použití vysoké dostupnosti:
- Zónově redundantní vysokou dostupnost lze nastavit pouze při vytvoření flexibilního serveru.
- Vysoká dostupnost není podporována ve vrstvě výpočetních prostředků s možností nárazového využití.
- Restartováním primárního databázového serveru za účelem převzetí změn statických parametrů se restartuje také pohotovostní replika.
- Režim GTID se zapne, protože řešení vysoké dostupnosti používá GTID. Zkontrolujte, jestli má vaše úloha omezení nebo omezení replikace pomocí identifikátorů GTID.
Poznámka:
Pokud po vytvoření serveru povolíte stejnou zónu vysoké dostupnosti, musíte před povolením vysoké dostupnosti zajistit, aby parametry serveru enforce_gtid_consistency a gtid_mode byly nastaveny na ZAPNUTO.
Poznámka:
Automatické zvětšování úložiště je ve výchozím nastavení povolené pro server s vysokou dostupností a nedá se zakázat.
Nejčastější dotazy
Jaké jsou smlouvy SLA pro flexibilní server se stejnou zónou a zónově redundantní vysokou dostupností?
Informace o sla pro flexibilní server Azure Database for MySQL najdete ve sla pro Azure Database for MySQL.
Jak se mi účtují servery s vysokou dostupností (HA)? Servery s podporou vysoké dostupnosti mají primární a sekundární repliku. Sekundární replika může být ve stejné zóně nebo zóně redundantní. Za zřízené výpočetní prostředky a úložiště se vám účtuje jak primární, tak sekundární replika. Pokud máte například primární se 4 virtuálními jádry pro výpočetní prostředky a 512 GB zřízeného úložiště, bude mít sekundární replika také 4 virtuální jádra a 512 GB zřízeného úložiště. Za zónově redundantní server s vysokou dostupností se bude účtovat 8 virtuálních jader a 1 024 GB úložiště. V závislosti na svazku úložiště zálohování se může také účtovat úložiště zálohování.
Můžu pro operace čtení nebo zápisu použít pohotovostní repliku?
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í.Dojde ke ztrátě dat, když dojde k převzetí služeb při selhání?
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 roli primárního serveru.Musím po převzetí služeb při selhání provést nějakou akci?
Převzetí služeb při selhání je plně transparentní z klientské aplikace. Nemusíte nic dělat. Aplikace by pro svá připojení měly používat logiku opakování.Co se stane, když pro svoji pohotovostní repliku nevyberem konkrétní zónu? Můžu zónu později změnit?
Pokud nevyberete zónu, vybere se náhodně. Bude to ten, který se použije pro primární server. Pokud chcete zónu později změnit, můžete nastavit vysokou dostupnost na Zakázáno v podokně Vysoká dostupnost a pak ji nastavit zpět na Zónově redundantní a zvolit zónu.Je replikace mezi primární a pohotovostní replikou synchronní?
Replikace mezi primárním a pohotovostním režimem je podobná polosynchronnímu režimu v MySQL. Když je transakce potvrzena, nemusí se nutně potvrdit do pohotovostního režimu. Pokud ale primární server není dostupný, pohotovostní režim replikuje všechny změny dat z primárního serveru, aby se zajistilo, že nedojde ke ztrátě dat.Existuje převzetí služeb při selhání pohotovostní repliky pro všechna neplánovaná selhání?
Pokud dojde k selhání databáze nebo uzlu, virtuální počítač flexibilního serveru se restartuje na stejném uzlu. Zároveň se aktivuje automatické převzetí služeb při selhání. Pokud je restartování virtuálního počítače s flexibilním serverem úspěšné před dokončením převzetí služeb při selhání, operace převzetí služeb při selhání se zruší. Určení serveru, který se má použít jako primární replika, závisí na procesu, který se dokončí jako první.Má při použití vysoké dostupnosti vliv na výkon?
V případě zónově redundantní vysoké dostupnosti sice nemá žádný velký dopad na výkon úloh čtení napříč zónami dostupnosti, ale může docházet až ke 40procentnímu poklesu latence dotazů na zápis. Zvýšení latence zápisu je způsobené synchronní replikací napříč zónou dostupnosti. Dopad latence zápisu je obecně dvakrát v zónově redundantní vysoké dostupnosti ve srovnání se stejnou zónou HA. Pro stejnou zónu ha, protože primární a pohotovostní replika je ve stejné zóně, latence replikace a následně synchronní latence zápisu je nižší. Pokud je latence zápisu pro vás v porovnání s dostupností důležitější, můžete zvolit vysokou dostupnost se stejnou zónou, ale pokud je dostupnost a odolnost vašich dat důležitější, musíte zvolit zónově redundantní vysokou dostupnost. Pokud chcete změřit přesný dopad poklesu latence v nastavení vysoké dostupnosti, doporučujeme provést testování výkonu pro vaši úlohu a přijmout informované rozhodnutí.Jak dochází k údržbě serveru vysoké dostupnosti?
Plánované události, jako je škálování výpočetních prostředků a upgradů podverze, probíhají nejprve v původní pohotovostní instanci a následně aktivují plánovanou operaci převzetí služeb při selhání a potom pracují s původní primární instancí. Časové období plánované údržby pro servery s vysokou dostupností můžete nastavit stejně jako u flexibilních serverů. Velikost výpadku bude stejná jako výpadek instance flexibilního serveru Azure Database for MySQL, když je zakázaná vysoká dostupnost.Můžu provést obnovení k určitému bodu v čase (PITR) serveru s vysokou dostupností?
Pro instanci flexibilního serveru Azure Database for MySQL s podporou vysoké dostupnosti můžete provést obnovení k určitému bodu obnovení do nové instance flexibilního serveru Azure Database for MySQL, která má zakázanou vysokou dostupnost. Pokud byl zdrojový server vytvořen s zónově redundantní vysokou dostupností, můžete na obnoveném serveru později povolit zónově redundantní vysokou dostupnost nebo stejnou zónu HA. Pokud byl zdrojový server vytvořen se stejnou zónou HA, můžete na obnoveném serveru povolit pouze vysokou dostupnost se stejnou zónou.Můžu povolit vysokou dostupnost na serveru po vytvoření serveru?
Při vytváření serveru je potřeba povolit zónově redundantní vysokou dostupnost. Vysokou dostupnost se stejnou zónou můžete povolit po vytvoření serveru. Před povolením stejné zóny se ujistěte, že jsou parametry serveru enforce_gtid_consistency a gtid_mode nastaveny na zapnuto.Můžu vysokou dostupnost serveru po vytvoření zakázat?
Vysokou dostupnost na serveru můžete po vytvoření zakázat. Fakturace se okamžitě zastaví.Jak můžu zmírnit výpadky?
Musíte být schopni zmírnit výpadky aplikace i v případě, že nepoužíváte vysokou dostupnost. Výpadek služby, jako jsou plánované opravy, upgrady podverze nebo operace iniciované zákazníkem, jako je škálování výpočetních prostředků, je možné provádět během plánovaných časových období údržby. Pokud chcete zmírnit dopad aplikace na úlohy údržby iniciované platformou Azure, můžete je naplánovat na den v týdnu a čas, který minimalizuje dopad na aplikaci.Můžu pro server s podporou vysoké dostupnosti použít repliku pro čtení?
Ano, repliky pro čtení jsou podporované pro servery s vysokou dostupností.Můžu pro servery s vysokou dostupností použít replikaci příchozích dat?
Podpora replikace příchozích dat pro server s podporou vysoké dostupnosti je dostupná pouze prostřednictvím replikace založené na GTID. Uložená procedura pro replikaci pomocí GTID je k dispozici na všech serverech s podporou vysoké dostupnosti podle názvumysql.az_replication_with_gtid.Pokud chcete snížit výpadky, můžu převzít služby při selhání na pohotovostní server během restartování serveru nebo při vertikálním navýšení nebo snížení kapacity?
Flexibilní server Azure Database for MySQL v současné době má nastavené plánované převzetí služeb při selhání, aby se přihlásil k operacím vysoké dostupnosti, včetně vertikálního navýšení/snížení kapacity, a plánované údržby, aby se snížil výpadek. Když se tyto operace spustily, nejprve by fungovaly v původní pohotovostní instanci, následně aktivovaly plánovanou operaci převzetí služeb při selhání a potom fungovaly s původní primární instancí.Můžeme změnit režim dostupnosti (zónově redundantní vysoká dostupnost nebo stejná zóna) serveru
, pokud vytvoříte server s povoleným režimem zónově redundantní vysoké dostupnosti, pak můžete změnit zónově redundantní vysokou dostupnost na stejnou zónu a naopak. Pokud chcete změnit režim dostupnosti, můžete nastavit vysokou dostupnost na Zakázáno v podokně Vysoká dostupnost a pak ho nastavit zpět na Zónově redundantní nebo stejnou zónu a zvolit Režim vysoké dostupnosti.
Další kroky
- Přečtěte si o kontinuitě podnikových procesů.
- Přečtěte si o zónově redundantní vysoké dostupnosti.
- Přečtěte si o zálohování a obnovení.