Repliky pro čtení ve službě Azure Database for MySQL

PLATÍ PRO: Jednoúčelový server Azure Database for MySQL

Funkce repliky pro čtení umožňuje replikovat data ze serveru Azure Database for MySQL na server jen pro čtení. Ze zdrojového serveru je můžete replikovat až na pět 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 běžné servery Azure Database for MySQL. Pro každou repliku pro čtení se vám účtuje zřízený výpočetní výkon ve virtuálních jádrech a úložišti v GB/měsíc.

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

Kdy použít repliku 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.

Častým scénářem je, že úlohy BI a analytické úlohy používají repliku pro čtení jako zdroj dat pro účely generování sestav.

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 bude 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.

Zdrojový server můžete mít v libovolné oblasti Azure Database for MySQL. Zdrojový server může mít repliku ve své spárované oblasti nebo v oblastech univerzální repliky. Následující obrázek ukazuje, které oblasti repliky jsou dostupné v závislosti na vaší zdrojové oblasti.

Oblasti univerzální repliky

Repliku pro čtení můžete vytvořit v libovolné z následujících oblastí bez ohledu na umístění zdrojového serveru. Mezi podporované oblasti univerzální repliky patří:

Spárované oblasti

Kromě oblastí univerzální repliky můžete vytvořit repliku pro čtení ve spárované oblasti Azure zdrojového serveru. Pokud pár oblastí neznáte, můžete se dozvědět víc v článku o spárovaných oblastech Azure.

Pokud pro plánování zotavení po havárii používáte repliky mezi oblastmi, doporučujeme vytvořit repliku v spárované oblasti místo jedné z ostatních oblastí. Spárované oblasti se vyhýbají souběžným aktualizacím a upřednostňují fyzickou izolaci a rezidenci dat.

Existují však omezení, která je potřeba vzít v úvahu:

• Regionální dostupnost: Azure Database for MySQL je k dispozici ve Francii – střed, Spojené arabské emiráty – sever a Německo – střed. Spárované oblasti ale nejsou k dispozici.

• Jednosměrné páry: Některé oblasti Azure jsou spárované pouze jedním směrem. Mezi tyto oblasti patří Západní Indie, Brazílie – jih a US Gov – Virginie. To znamená, že zdrojový server v Západní Indii může vytvořit repliku v Indii – jih. Zdrojový server v Indii – jih však nemůže vytvořit repliku v západní Indii. Je to proto, že sekundární oblast Západní Indie je Indie – jih, ale sekundární oblast Indie – jih není Západní Indie.

Vytvoření repliky

Když spustíte pracovní postup vytvoření repliky, vytvoří se prázdný server 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. 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.

Pro automatické zvětšování úložiště je povolená každá replika. Funkce automatického zvětšování umožňuje replikě udržovat krok s daty replikovanými do ní a zabránit přerušení replikace způsobené chybami mimo úložiště.

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í pravidla brány firewall zdrojového serveru. Poté jsou tato pravidla nezávislá na zdrojovém serveru.

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 na běžném 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@myreplica -p

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

Monitorování replikace

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 .

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í.

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í.

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.

Jakmile se rozhodnete, že chcete provést převzetí služeb 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í. Doba výpadku, na které vaše aplikace dojde, závisí na tom, kdy zjistíte problém a dokončíte kroky 1 a 2 uvedené dříve.

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 ve službě Azure Database for MySQL vypnutý. GTID se podporuje ve verzích 5.7 a 8.0 a pouze na serverech, které podporují úložiště až 16 TB (úložiště pro obecné účely v2). Další informace o GTID a o tom, jak se používá při replikaci, najdete v dokumentaci k replikaci MySQL pomocí GTID .

MySQL podporuje dva typy transakcí: transakce GTID (identifikované pomocí GTID) a anonymní transakce (nemají přidělené GTID).

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

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

Pokud je na zdrojovém serveru povolené GTID (gtid_mode = ZAPNUTO), nově vytvořené repliky budou mít také povolené GTID a budou používat replikaci GTID. Pokud chcete zajistit, aby byla replikace konzistentní, gtid_mode nelze ji po vytvoření hlavního serveru nebo serveru repliky s povoleným IDENTIFIKÁTORem GTID změnit.

Úvahy a omezení

Cenové úrovně

Repliky pro čtení jsou aktuálně k dispozici pouze v cenových úrovních Pro obecné účely a Optimalizováno pro paměť.

Restartování zdrojového serveru

Server, který má úložiště pro obecné účely verze 1, log_bin bude ve výchozím nastavení vypnutý. Tato hodnota bude při vytváření první repliky pro čtení zapnutá. Pokud zdrojový server nemá žádné existující repliky pro čtení, zdrojový server se nejprve restartuje, aby se připravil na replikaci. Zvažte restartování serveru a proveďte tuto operaci mimo špičku.

Zdrojový server, který má úložiště pro obecné účely v2, log_bin bude ve výchozím nastavení zapnutý a při přidání repliky pro čtení nevyžaduje restartování.

Nové repliky

Replika pro čtení se vytvoří jako nový server 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. Cenovou úroveň lze také změnit nezávisle, s výjimkou úrovně Basic nebo z ní.

Pravidla brány firewall a nastavení parametrů se při vytváření repliky dědí ze zdrojového serveru do 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.

GTID

GTID se podporuje na:

• MySQL verze 5.7 a 8.0
• Servery, které podporují úložiště až 16 TB. Úplný seznam oblastí, které podporují 16TB úložiště, najdete v článku věnovaném cenovým úrovním.

VE výchozím nastavení je GTID vypnuté. Po zapnutí nelze identifikátor GTID vypnout. Pokud potřebujete GTID vypnout, obraťte se na podporu.

Je-li na zdrojovém serveru GTID zapnutý, nově vytvořené repliky ho také budou mít zapnutý a používat replikaci GTID. Pokud chcete zachovat konzistenci replikace, nemůžete aktualizovat gtid_mode na zdrojovém serveru ani na serverech replik.

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 zdrojové serverové tabulky mají primární klíče. Nedostatek primárních klíčů může způsobit latenci replikace mezi zdrojem a replikami.
• Úplný seznam omezení replikace MySQL najdete v dokumentaci k MySQL.

Další kroky

• Naučte se vytvářet a spravovat repliky pro čtení pomocí webu Azure Portal.
• Naučte se vytvářet a spravovat repliky pro čtení pomocí Azure CLI a rozhraní REST API.