Sdílet prostřednictvím


Repliky pro čtení ve službě 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 zákazníků používá Azure Database for MySQL pro celou řadu aplikací, včetně online vzdělávání, streamování videa, digitálních plateb, elektronického obchodování, her, informačních portálů, vládních a zdravotnických webů. Tyto služby musí být schopné obsluhovat a škálovat s rostoucím provozem na webu nebo mobilní aplikaci.

Vývojáři na straně aplikací obvykle používají Javu nebo PHP. Migrují aplikaci tak, aby běžela ve službě Azure Virtual Machine Scale Sets, Azure App Services nebo ji kontejnerizovala tak, aby běžela 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ší tím, že okamžitě zřídí nové virtuální počítače a replikuje bezstavové komponenty aplikací tak, aby vyhovovaly požadavkům. Databáze se ale často stává 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ě pomocí technologie replikace na základě pozice souboru (binlog) nativního binárního protokolu (binlog) modulu MySQL. Další informace o replikaci binlogu najdete v přehledu replikace binlogu MySQL.

Repliky spravujete jako nové servery stejně 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 za měsíc. Další informace najdete v tématu ceny.

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 otrok, termín, který už Microsoft nepoužívá. Když odebereme termín ze softwaru, odebereme ho z tohoto článku.

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

Funkce repliky pro čtení pomáhá zlepšit výkon a škálovat úlohy náročné na čtení. Úlohy čtení můžete izolovat do replik a současně směrovat úlohy zápisu do zdroje.

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

  • Škálování úloh čtení přicházejících z aplikace pomocí jednoduchého proxy připojení, jako je ProxySQL nebo pomocí vzoru založeného na mikroslužbách pro horizontální navýšení kapacity dotazů pro čtení přicházejících z aplikace na repliky pro čtení
  • Použití replik pro čtení jako zdroje dat pro úlohy generování sestav BI nebo analytických sestav
  • Ingestování telemetrických informací do databázového stroje MySQL při použití více replik pro čtení pro generování sestav dat ve scénářích IoT nebo Manufacturing

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ých podporovaných oblastech Azure , 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 dnes k dispozici flexibilní server Azure Database for MySQL, najdete tady .

Vytvoření repliky

Při spuštění pracovního postupu vytvoření repliky vytvoříte prázdnou instanci flexibilního serveru Azure Database for MySQL. Nový server obsahuje data, 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í vytvoříte se stejnou konfigurací serveru jako zdroj. Konfiguraci serveru repliky můžete po vytvoření změnit. Vždy vytvoříte server repliky ve stejné skupině prostředků a předplatném jako zdrojový server. Pokud chcete vytvořit server repliky v jiné skupině prostředků nebo jiném předplatném, můžete po vytvoření přesunout server repliky . Udržujte konfiguraci serveru repliky na stejných nebo větších hodnotách, než je zdroj, aby se zajistilo, že replika dokáže držet krok se zdrojem.

Zjistěte, jak vytvořit repliku pro čtení na webu Azure Portal.

Připojení k replice

Když vytvoříte repliku, zdědí metodu připojení zdrojového serveru. Nemůžete změnit metodu připojení repliky. Pokud například zdrojový server používá privátní přístup (integrace virtuální sítě), replika nemůže používat veřejný přístup (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ů dostupných 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. Azure Monitor tuto metriku seconds_behind_master vypočítá pomocí metriky v příkazu MySQL SHOW SLAVE STATUS . Nastavte upozornění, které vás upozorní, když prodleva replikace překročí nepřijatelnou prahovou hodnotu pro vaši úlohu.

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ž metriku dostupnou SLAVE_IO_RUNNINGREPLICA STATUS/REPLICA_IO_RUNNINGSHOW SLAVESTATUS'/'SHOWv příkazu MySQL nepoužívá. Tato hodnota se vždy zobrazí jako Ne a neznačí stav replikace. Informace o správném stavu replikace najdete v metrikách replikace – Stav repliky IO a Stav SQL repliky na stránce Monitorování.

Zastavení replikace

Replikaci mezi zdrojovým serverem a serverem repliky můžete zastavit. Když zastavíte replikaci mezi zdrojovým serverem a replikou pro čtení, stane se server repliky samostatným serverem. Samostatný server obsahuje data, která byla k dispozici na serveru repliky při spuštění příkazu zastavit replikaci. Samostatný server nesynchronizuje žádná chybějící data ze zdrojového serveru.

Když zastavíte replikaci na server repliky, server repliky ztratí všechna propojení s předchozím zdrojovým serverem a dalšími servery repliky. Mezi zdrojovým serverem a servery repliky neexistuje automatizované převzetí služeb při selhání.

Důležité

Samostatný server nemůžete převést zpět na server repliky. Před zastavením replikace repliky pro čtení se ujistěte, že server repliky obsahuje všechna potřebná data.

Další informace najdete v tématu zastavení replikace 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í škálují úlohy náročné na čtení a neposkytují vysokou dostupnost serveru. Ruční převzetí služeb při selhání zastavíte replikaci repliky pro čtení tak, že ji přenesete do režimu čtení i zápisu do režimu online.

Vzhledem k tomu, že replikace je asynchronní, mezi zdrojem a replikou je prodleva. Mnoho faktorů ovlivňuje prodlevu, například zatížení na zdrojovém serveru a latenci mezi datovými centry. Ve většině případů se prodleva repliky pohybuje mezi několika sekundy až několik minut. Skutečnou prodlevu replikace můžete sledovat pomocí metriky Prodleva repliky , která je k dispozici pro každou repliku. Tato metrika zobrazuje čas od poslední přehrání transakce. Doporučujeme určit průměrnou prodlevu sledováním prodlevy repliky v průběhu času. Můžete nastavit upozornění na prodlevu repliky, takže pokud se nachází mimo očekávaný rozsah, můžete provést akci.

Návod

Pokud převezmete služby při selhání repliky, prodleva v okamžiku zrušení propojení repliky ze zdroje označuje, kolik dat se ztratí.

Po rozhodnutí o převzetí služeb při selhání repliky:

  1. Zastavení replikace do repliky

    Aby server repliky mohl přijímat zápisy, musíte zastavit replikaci. Tento proces odpoje server repliky ze zdroje. Po zahájení zastavení replikace proces back-endu obvykle trvá přibližně dvě 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.

Když vaše aplikace úspěšně zpracuje čtení a zápisy, dokončíte převzetí služeb při selhání. Velikost výpadků, které vaše aplikace má, závisí na tom, kdy zjistíte problém a dokončíte kroky 1 a 2.

Globální identifikátor transakce (GTID)

Globální identifikátor transakce (GTID) je jedinečný identifikátor, který zdrojový server vytvoří s každou potvrzenou transakcí. Flexibilní server Azure Database for MySQL ve výchozím nastavení vypne GTID. Verze 5.7 a 8.0 podporují GTID. Další informace o GTID a o tom, jak se replikace používá, najdete v dokumentaci k MySQL s KÓDEM GTID .

Ke konfiguraci GTID použijte 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 je možné provést pouze v jednom kroku ve vzestupném pořadí (např. OFF ->OFF_PERMISSIVEON_PERMISSIVE> -)>ON 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. Před povolením replikace GTID nastavte hodnotu ON . 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í.

Poznámka:

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

Po povolení GTID ho nemůžete vypnout. Pokud potřebujete VYPNOUT GTID, obraťte se na podporu.

Identifikátory GTID můžete změnit z jedné hodnoty na druhý krok postupně ve vzestupném pořadí. Pokud gtid_mode je například aktuálně nastavená OFF_PERMISSIVE, můžete ho změnit na ON_PERMISSIVE , ale ne na ON.

Pokud chcete zachovat konzistenci replikace, nemůžete ji aktualizovat pro primární server nebo server repliky.

Nastavte enforce_gtid_consistency na hodnotu před nastavením gtid_modeON.ON

Pokud chcete povolit GTID a nakonfigurovat chování konzistence, aktualizujte gtid_mode parametry serveru a enforce_gtid_consistency serveru. Použití konfigurace parametrů serveru na flexibilním serveru Azure Database for MySQL pomocí webu Azure Portal nebo konfigurace parametrů serveru na flexibilním serveru Azure Database for MySQL pomocí Azure CLI

Pokud zdrojový server povolí GTID (gtid_mode = ON), nově vytvořené repliky také povolí GTID a použijí replikaci GTID. Pokud chcete zajistit konzistenci replikace, nemůžete po vytvoření primárního serveru nebo serveru repliky s povoleným IDENTIFIKÁTORem GTID změnit gtid_mode .

Ú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 závisí na oblasti, ve které běží server repliky.
Výpadky nebo restartování zdrojového serveru Při vytváření repliky pro čtení není potřeba žádné restartování ani výpadek. Tato operace je online operace.
Nové repliky Repliku pro čtení vytvoříte jako novou instanci flexibilního serveru Azure Database for MySQL. Existující server nejde vytvořit jako repliku. Repliku jiné repliky pro čtení nemůžete vytvořit.
Konfigurace repliky Repliku vytvoříte pomocí stejné konfigurace serveru jako zdroj. Po vytvoření repliky můžete 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ů můžete také změnit nezávisle.

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 vytvář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 nemůžete znovu převést na repliku.
Odstraněné zdrojové servery Když odstraníte zdrojový server, replikace se zastaví na všechny repliky 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 předchozích parametrů na zdrojovém serveru, odstraňte servery replik, aktualizujte hodnotu parametru na 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 replikě pro čtení, zajistěte, aby hodnoty parametrů, které nastavujete na replice pro čtení, byly konzistentní s hodnotami zdrojového serveru.
Přidání sloupce AUTO_INCREMENT primárního klíče do existující tabulky na zdrojovém serveru Po vytvoření repliky pro čtení nedoporučujeme měnit tabulku AUTO_INCREMENT , protože tato akce přeruší replikaci. Pokud chcete přidat sloupec automatického přírůstku po vytvoření serveru repliky, zvažte tyto přístupy:
– Vytvořte novou tabulku se stejným schématem jako tabulka, kterou chcete upravit. V nové tabulce upravte sloupec pomocí AUTO_INCREMENTa potom obnovte data z původní tabulky. Přetáhněte starou tabulku a přejmenujte ji ve zdroji; tento přístup nevyžaduje odstranění serveru repliky, ale při vytvoření zálohovací tabulky může vzniknout velké náklady na vložení.
– Znovu vytvořte repliku 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 se repliky přestanou synchronizovat. Toto omezení je způsobené technologií replikace 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 vést k latenci replikace mezi zdrojem a replikami.
– Úplný seznam omezení replikace MySQL najdete v dokumentaci k MySQL.