Repliky pro čtení na flexibilním serveru Azure Database for MySQL

  • Článek

PLATÍ PRO: Flexibilní server Azure Database for MySQL

MySQL je jedním z oblíbených databázových strojů pro provozování internetových a mobilních aplikací. Mnoho našich zákazníků ji používá pro své online vzdělávací služby, služby streamování videa, digitální platební řešení, platformy elektronického obchodování, herní služby, informační portály, státní správu a zdravotnické weby. Tyto služby musí sloužit a škálovat při nárůstu provozu na webu nebo mobilní aplikaci.

Na straně aplikací se aplikace obvykle vyvíjí v Javě nebo PHP a migruje se tak, aby běžela ve službě Azure Virtual Machine Scale Sets nebo Aplikace Azure Services nebo se kontejnerizuje pro spouštění ve službě Azure Kubernetes Service (AKS). Díky škálovací sadě virtuálních počítačů, službě App Service nebo AKS jako základní infrastruktuře se škálování aplikací zjednoduší okamžitým zřizováním nových virtuálních počítačů a replikací bezstavových komponent aplikací, které budou vyhovět požadavkům, ale často je databáze kritickým bodem jako centralizovaná stavová komponenta.

Funkce repliky pro čtení umožňuje replikovat data z instance flexibilního serveru Azure Database for MySQL na server jen pro čtení. Ze zdrojového serveru můžete replikovat až na 10 replik. Repliky se aktualizují asynchronně s využitím technologie replikace na základě pozice v souboru binárního protokolu (binlog) nativní pro stroj MySQL. Další informace o replikaci binlogu najdete v přehledu replikace binlogu MySQL.

Repliky jsou nové servery, které spravujete podobně jako zdrojové instance flexibilního serveru Azure Database for MySQL. Za každou repliku pro čtení se účtují poplatky za fakturaci na základě zřízeného výpočetního výkonu ve virtuálních jádrech a úložišti v GB/měsíci. Další informace najdete na stránce s cenami.

Poznámka:

Funkce repliky pro čtení je dostupná jenom pro instance flexibilního serveru Azure Database for MySQL v cenových úrovních pro obecné účely nebo Pro důležité obchodní informace. Ujistěte se, že zdrojový server je v některé z těchto cenových úrovní.

Další informace o funkcích a problémech s replikací MySQL najdete v dokumentaci k replikaci MySQL.

Poznámka:

Tento článek obsahuje odkazy na termín slave (podřízený) , což je termín, který už Microsoft nepoužívá. Když se termín odebere ze softwaru, odebereme ho z tohoto článku.

Běžné případy použití repliky pro čtení

Funkce repliky pro čtení pomáhá zvýšit výkon a zlepšit škálování úloh náročných na čtení. Úlohy čtení je možné izolovat s replikami, zatímco úlohy zápisu je možné směrovat na zdroj.

Mezi běžné scénáře patří:

  • Škálování úloh čtení pocházejících z aplikace pomocí zjednodušeného proxy připojení, jako je ProxySQL nebo vzor založený na mikroslužbách, ke škálování dotazů na čtení přicházejících z aplikace na repliky pro čtení
  • Úlohy bi nebo analytického generování sestav můžou jako zdroj dat používat repliky pro čtení pro vytváření sestav.
  • Ve scénáři IoT nebo Manufacturing, ve kterém se telemetrické informace ingestují do databázového stroje MySQL, zatímco k vytváření sestav dat se používá více replik pro čtení

Vzhledem k tomu, že repliky jsou jen pro čtení, nezmenšují přímo zatížení kapacity zápisu na zdroj. Tato funkce není určená pro úlohy, které jsou náročné na zápis.

Funkce repliky pro čtení používá asynchronní replikaci MySQL. Tato funkce není určená pro scénáře synchronní replikace. Mezi zdrojem a replikou je měřitelné zpoždění. Data na replice se nakonec stanou konzistentními s daty ve zdroji. Tuto funkci použijte pro úlohy, kterým toto zpoždění nevadí.

Replikace mezi oblastmi

Repliku pro čtení můžete vytvořit v jiné oblasti než na zdrojovém serveru. Replikace mezi oblastmi může být užitečná ve scénářích, jako je plánování zotavení po havárii nebo přiblížení dat uživatelům. Flexibilní server Azure Database for MySQL umožňuje zřídit repliku pro čtení v libovolné podpora Azure oblastech, kde je k dispozici flexibilní server Azure Database for MySQL. Pomocí této funkce může zdrojový server mít repliku ve své spárované oblasti nebo v oblastech univerzální repliky. Seznam oblastí Azure, ve kterých je flexibilní server Azure Database for MySQL dostupný dnes, najdete tady .

Vytvoření repliky

Pokud zdrojový server nemá žádné existující servery repliky, zdroj se nejprve restartuje, aby se připravil na replikaci.

Při spuštění pracovního postupu vytvoření repliky se vytvoří prázdná instance flexibilního serveru Azure Database for MySQL. Nový server je vyplněný daty, která byla na zdrojovém serveru. Doba vytvoření závisí na množství dat na zdroji a času od posledního týdenního úplného zálohování. Tato doba se může pohybovat od několika minut až po několik hodin.

Poznámka:

Repliky pro čtení se vytvářejí se stejnou konfigurací serveru jako zdroj. Konfiguraci serveru repliky je možné po vytvoření změnit. Server repliky se vždy vytvoří ve stejné skupině prostředků a stejném předplatném jako zdrojový server. Pokud chcete vytvořit server repliky do jiné skupiny prostředků nebo jiného předplatného, můžete po vytvoření přesunout server repliky. Doporučujeme zachovat konfiguraci serveru repliky na stejné nebo větší hodnoty než zdroj, aby se zajistilo, že replika bude schopná držet krok se zdrojem.

Přečtěte si, jak vytvořit repliku pro čtení na webu Azure Portal.

Připojení k replice

Při vytváření replika dědí metodu připojení zdrojového serveru. Nemůžete změnit metodu připojení repliky. Pokud má například zdrojový server privátní přístup (integrace virtuální sítě), replika nemůže být ve veřejném přístupu (povolené IP adresy).

Replika dědí účet správce ze zdrojového serveru. Všechny uživatelské účty na zdrojovém serveru se replikují do replik pro čtení. K replice pro čtení se můžete připojit jenom pomocí uživatelských účtů, které jsou dostupné na zdrojovém serveru.

K replice se můžete připojit pomocí názvu hostitele a platného uživatelského účtu, stejně jako u běžné instance flexibilního serveru Azure Database for MySQL. Pro server s názvem myreplica s uživatelským jménem správce myadmin se můžete připojit k replice pomocí rozhraní příkazového řádku mysql:

mysql -h myreplica.mysql.database.azure.com -u myadmin -p

Na příkazovém řádku zadejte heslo k uživatelskému účtu.

Monitorování replikace

Flexibilní server Azure Database for MySQL poskytuje prodlevu replikace v sekundách ve službě Azure Monitor. Tato metrika je dostupná jenom pro repliky. Tato metrika se počítá pomocí seconds_behind_master metriky dostupné v příkazu MySQL SHOW SLAVE STATUS . Nastavte upozornění, které vás informuje, když prodleva replikace dosáhne hodnoty, která není pro vaši úlohu přijatelná.

Pokud se zobrazí zvýšená prodleva replikace, projděte si řešení potíží s latencí replikace a seznamte se s možnými příčinami .

Důležité

Replika pro čtení používá technologii replikace na základě úložiště, která už nepoužívá metriku SLAVE_IO_RUNNING/REPLICA_IO_RUNNING, která je k dispozici v příkazu SHOW SLAVE STATUS/SHOW REPLICA STATUS. Tato hodnota se vždy zobrazí jako Ne a neskazuje na stav replikace. Informace o správném stavu replikace najdete v metrikách replikace – Stav V/V repliky a Stav SQL repliky v okně Monitorování.

Zastavení replikace

Replikaci mezi zdrojem a replikou můžete zastavit. Po zastavení replikace mezi zdrojovým serverem a replikou pro čtení se replika stane samostatným serverem. Data na samostatném serveru jsou data, která byla k dispozici na replice v době spuštění příkazu zastavení replikace. Samostatný server se nedohodí se zdrojovým serverem.

Když se rozhodnete zastavit replikaci na repliku, ztratí všechna propojení s předchozím zdrojem a dalšími replikami. Mezi zdrojem a jeho replikou neexistuje automatizované převzetí služeb při selhání.

Důležité

Samostatný server nelze znovu vytvořit do repliky. Než zastavíte replikaci repliky pro čtení, ujistěte se, že replika obsahuje všechna všechna data, která potřebujete.

Zjistěte, jak zastavit replikaci do repliky.

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

Mezi zdrojovými a replikovými servery neexistuje automatizované převzetí služeb při selhání.

Repliky pro čtení jsou určené pro škálování úloh náročných na čtení a nejsou navržené tak, aby splňovaly požadavky na vysokou dostupnost serveru. Zastavení replikace na replice pro čtení, aby byla v režimu zápisu pro čtení online, je způsob, jakým se provádí toto ruční převzetí služeb při selhání.

Vzhledem k tomu, že replikace je asynchronní, mezi zdrojem a replikou je prodleva. Prodleva může být ovlivněna mnoha faktory, jako je například to, jak je zatížení spuštěné na zdrojovém serveru a latence mezi datovými centry. Ve většině případů je prodleva repliky v rozsahu od několika sekund do několika minut. Skutečnou prodlevu replikace můžete sledovat pomocí prodlevy repliky metriky, která je k dispozici pro každou repliku. Tato metrika zobrazuje čas od poslední přehrání transakce. Doporučujeme zjistit, co je vaše průměrná prodleva, a to sledováním prodlevy repliky v určitém časovém období. Můžete nastavit upozornění na prodlevu repliky, takže pokud se nachází mimo očekávaný rozsah, můžete provést akci.

Tip

Pokud dojde k převzetí služeb při selhání repliky, prodleva v okamžiku odpojení repliky od zdroje označuje, kolik dat se ztratí.

Po rozhodnutí, že chcete převzít služby při selhání repliky:

  1. Zastavení replikace do repliky
    Tento krok je nezbytný k tomu, aby server repliky mohl přijímat zápisy. V rámci tohoto procesu se server repliky odpoje ze zdroje. Po zahájení zastavení replikace proces back-endu obvykle trvá přibližně 2 minuty. Informace o dopadech této akce najdete v části Zastavení replikace tohoto článku.

  2. Nasměrování aplikace na (bývalou) repliku
    Každý server má jedinečný připojovací řetězec. Místo zdroje aktualizujte aplikaci tak, aby odkazovat na (bývalou) repliku.

Po úspěšném zpracování čtení a zápisů aplikace jste dokončili převzetí služeb při selhání. Objem výpadků, na kterém vaše aplikace dochází, závisí na tom, kdy zjistíte problém a dokončíte kroky 1 a 2 výše.

Globální identifikátor transakce (GTID)

Globální identifikátor transakce (GTID) je jedinečný identifikátor vytvořený s každou potvrzenou transakcí na zdrojovém serveru a ve výchozím nastavení je vypnutý na flexibilním serveru Azure Database for MySQL. GTID se podporuje ve verzích 5.7 a 8.0. Další informace o GTID a o tom, jak se používá při replikaci, najdete v dokumentaci k replikaci MySQL pomocí GTID .

Pro konfiguraci GTID jsou k dispozici následující parametry serveru:

Parametr serveru Popis Výchozí hodnota Hodnoty
gtid_mode Označuje, zda jsou identifikátory GTID použity k identifikaci transakcí. Změny mezi režimy lze provést pouze v jednom kroku ve vzestupném pořadí (např. OFF -OFF_PERMISSIVE> -ON>ON_PERMISSIVE>) OFF* OFF: Nové i replikační transakce musí být anonymní.
OFF_PERMISSIVE: Nové transakce jsou anonymní. Replikované transakce můžou být anonymní nebo transakce GTID.
ON_PERMISSIVE: Nové transakce jsou transakce GTID. Replikované transakce můžou být anonymní nebo transakce GTID.
ON: Nové i replikované transakce musí být transakce GTID.
enforce_gtid_consistency Vynucuje konzistenci GTID povolením provádění pouze těch příkazů, které lze protokolovat transakčním bezpečným způsobem. Tato hodnota musí být nastavená na ON před povolením replikace GTID. OFF* OFF: Všechny transakce mohou narušit konzistenci GTID.
ON: Žádná transakce nesmí narušit konzistenci GTID.
WARN: Všechny transakce mohou narušit konzistenci GTID, ale vygeneruje se upozornění.

Pro instance flexibilního serveru Azure Database for MySQL, které mají povolenou funkci vysoké dostupnosti, je výchozí hodnota nastavená na ONhodnotu .

Poznámka:

  • Po zapnutí nelze identifikátor GTID vypnout. Pokud potřebujete GTID vypnout, kontaktujte prosím podporu.
  • Identifikátory GTID můžete změnit z jedné hodnoty na druhý krok postupně ve vzestupném pořadí. Pokud je například gtid_mode aktuálně nastavená na OFF_PERMISSIVE, je možné změnit ON_PERMISSIVE, ale ne na ZAPNUTO.
  • Pokud chcete zachovat konzistenci replikace, nemůžete ji aktualizovat pro hlavní server nebo server repliky.
  • Před nastavením gtid_mode=ON doporučujeme nastavit enforce_gtid_consistency na ZAPNUTO.

Pokud chcete povolit GTID a nakonfigurovat chování konzistence, aktualizujte gtid_mode parametry serveru enforce_gtid_consistency pomocí webu Azure Portal nebo Azure CLI.

Pokud je na zdrojovém serveru povolené GTID (gtid_mode = ZAPNUTO), mají nově vytvořené repliky také povolené GTID a používají replikaci GTID. Abyste měli jistotu, že je replikace konzistentní, gtid_mode po vytvoření hlavního serveru nebo serveru repliky s povoleným GTID není možné změnit.

Úvahy a omezení

Scénář Omezení nebo důležité informace
Replika na serveru v cenové úrovni s možností nárazového škálování Nepodporováno
Ceny Náklady na provoz serveru repliky jsou založené na oblasti, ve které je server repliky spuštěný.
Restartování zdrojového serveru Když vytvoříte repliku pro zdroj, který nemá žádné existující repliky, zdroj se nejprve restartuje, aby se připravil na replikaci. Vezměte to v úvahu a proveďte tyto operace během období mimo špičku.
Nové repliky Replika pro čtení se vytvoří jako nová instance flexibilního serveru Azure Database for MySQL. Existující server nejde vytvořit do repliky. Repliku jiné repliky pro čtení nemůžete vytvořit.
Konfigurace repliky Replika se vytvoří pomocí stejné konfigurace serveru jako zdroj. Po vytvoření repliky je možné změnit několik nastavení nezávisle na zdrojovém serveru: generování výpočetních prostředků, virtuální jádra, úložiště a doba uchovávání záloh. Úroveň výpočetních prostředků je také možné změnit nezávisle na sobě.

DŮLEŽITÉ – Před aktualizací konfigurace zdrojového serveru na nové hodnoty aktualizujte konfiguraci repliky na stejné nebo vyšší hodnoty. Tato akce zajistí, že replika bude moct udržovat krok se všemi změnami na zdrojovém serveru.
Metoda připojení a nastavení parametrů se dědí ze zdrojového serveru do repliky při vytvoření repliky. Poté jsou pravidla repliky nezávislá.
Zastavené repliky Pokud zastavíte replikaci mezi zdrojovým serverem a replikou pro čtení, stane se zastavená replika samostatným serverem, který přijímá čtení i zápisy. Samostatný server nelze znovu vytvořit do repliky.
Odstraněný zdrojový a samostatný server Po odstranění zdrojového serveru se replikace zastaví do všech replik pro čtení. Tyto repliky se automaticky stanou samostatnými servery a můžou přijímat čtení i zápisy. Samotný zdrojový server se odstraní.
Uživatelské účty Uživatelé na zdrojovém serveru se replikují do replik pro čtení. K replice pro čtení se můžete připojit jenom pomocí uživatelských účtů dostupných na zdrojovém serveru.
Parametry serveru Aby se při použití replik pro čtení zabránilo přerušení synchronizace dat a možné ztrátě nebo poškození dat, některé parametry serveru neumožňují aktualizaci.
Následující parametry serveru jsou uzamčeny na zdrojovém i replikovacím serveru:
- innodb_file_per_table
- log_bin_trust_function_creators
Parametr event_scheduler je uzamčen na serverech repliky.
Pokud chcete aktualizovat jeden z výše uvedených parametrů na zdrojovém serveru, odstraňte servery replik, aktualizujte hodnotu parametru ve zdroji a znovu vytvořte repliky.
Parametry na úrovni relace Při konfiguraci parametrů na úrovni relace, jako je například "foreign_keys_checks" na replice pro čtení, zajistěte, aby hodnoty parametrů nastavené na replice pro čtení byly konzistentní se zdrojovým serverem.
Přidání sloupce primárního klíče AUTO_INCREMENT do existující tabulky na zdrojovém serveru Nedoporučujeme měnit tabulku s AUTO_INCREMENT po vytvoření repliky pro čtení, protože přeruší replikaci. Pokud ale chcete přidat sloupec automatického přírůstku po vytvoření serveru repliky, doporučujeme tyto dva přístupy:
– Vytvořte novou tabulku se stejným schématem tabulky, kterou chcete upravit. V nové tabulce upravte sloupec AUTO_INCREMENT a potom z původní tabulky obnovte data. Zahoďte starou tabulku a přejmenujte ji ve zdroji, nemusíme odstranit server repliky, ale pro vytvoření zálohované tabulky může být potřeba velké náklady na vložení.
- Další rychlejší metodou je opětovné vytvoření repliky po přidání všech sloupců automatického přírůstku.
Jiný důvod – Vytvoření repliky repliky se nepodporuje.
– Tabulky v paměti můžou způsobit, že repliky přestanou být synchronizované. Jedná se o omezení replikační technologie MySQL. Další informace najdete v referenční dokumentaci k MySQL.
– Ujistěte se, že tabulky zdrojového serveru mají primární klíče. Nedostatek primárních klíčů může způsobit latenci replikace mezi zdrojem a replikami.
– Projděte si úplný seznam omezení replikace MySQL v dokumentaci k MySQL.

Další kroky