Poznámka:
Přístup k této stránce vyžaduje autorizaci. Můžete se zkusit přihlásit nebo změnit adresáře.
Přístup k této stránce vyžaduje autorizaci. Můžete zkusit změnit adresáře.
Vysoká dostupnost je klíčovou funkcí služby Azure Database for MySQL, která je navržená tak, aby minimalizovala výpadky a zajistila, že vaše aplikace zůstanou dostupné i během plánované údržby nebo neočekávaných výpadků. Tento článek se zabývá běžnými dotazy k možnostem vysoké dostupnosti, fakturaci, procesům převzetí služeb při selhání, dopadům na výkon a osvědčeným postupům, které vám pomůžou činit informovaná rozhodnutí o úlohách MySQL v Azure.
Jaké jsou SLA smlouvy pro flexibilní servery s povolenou lokální redundantní 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 vysokou dostupností mají primární a sekundární repliku. Sekundární replika může být ve stejné zóně nebo zónově 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 výpočetních prostředků a 512 GB zřízeného úložiště, má sekundární replika 4 virtuální jádra a 512 GB zřízeného úložiště.
Zónově redundantní server HA se účtuje za 8 virtuálních jader a 1 024 GB úložiště. V závislosti na svazku úložiště záloh se vám také může úč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ě jedna zóna. Je to ten, který se používá 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 dvakrát v zónově redundantní vysoké dostupnosti ve srovnání se stejnou zónou HA. Vysoká dostupnost s lokální redundancí: protože primární a pohotovostní replika jsou ve stejné zóně, latence replikace, a tím i synchronní latence zápisu, je nižší.
Pokud je pro vás latence zápisu důležitější než dostupnost, můžete zvolit Local-redundant HA. Naopak, pokud jsou pro vás dostupnost a odolnost dat klíčové i za cenu snížení výkonu zápisu, musíte zvolit zone-redundant HA. 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ů. Objem výpadků je 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 se zónově redundantní HA, můžete později povolit zónově redundantní HA nebo HA s místní redundancí na obnoveném serveru. Pokud byl zdrojový server vytvořen s lokálně redundantní vysokou dostupností, můžete na obnovený server povolit pouze lokálně redundantní vysokou dostupnost.
Můžu povolit vysokou dostupnost na serveru po vytvoření serveru?
Při vytváření serveru musí být povolená zónově redundantní vysoká dostupnost. Po vytvoření serveru můžete povolit místní redundantní vysokou dostupnost, ale než budete pokračovat, ujistěte se, že parametry serveru enforce_gtid_consistency a gtid_mode jsou nastaveny na ON.
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ázvu mysql.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ě využívá plánované převzetí služeb při selhání k optimalizaci operací 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í HA/lokálně redundantní) serveru**
Pokud vytvoříte server s povoleným režimem zónově redundantní vysoké dostupnosti, můžete změnit zónově redundantní vysokou dostupnost na místní 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 místní redundantní a zvolit Režim vysoké dostupnosti.