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

Funkce repliky pro čtení umožňuje replikovat data ze serveru Azure Database for MariaDB na server jen pro čtení. Ze zdrojového serveru je můžete replikovat až na pět replik. Repliky se aktualizují asynchronně pomocí technologie replikace na základě pozice souboru binárního protokolu (binlog) modulu MariaDB s globálním ID transakce (GTID). Další informace o replikaci protokolu binlog najdete v přehledu replikace protokolu binlog.

Repliky jsou nové servery, které spravujete podobně jako běžné Azure Database for MariaDB servery. Za každou repliku pro čtení se vám budou účtovat zřízené výpočetní prostředky ve virtuálních jaderch a úložišti v GB/měsíc.

Další informace o replikaci GTID najdete v dokumentaci k replikaci MariaDB.

Kdy použít repliku pro čtení

Funkce repliky pro čtení pomáhá zlepšit výkon a škálovat úlohy náročné na čtení. Úlohy čtení je možné izolovat na repliky, zatímco úlohy zápisu je možné směrovat do primární lokality.

Běžným scénářem je, že úlohy BI a analytické úlohy používají repliku pro čtení jako zdroj dat pro vytváření sestav.

Protože repliky jsou jen pro čtení, nesníží přímo zatížení primární kapacity zápisu. Tato funkce není určená pro úlohy, které jsou náročné na zápis.

Funkce repliky pro čtení používá asynchronní replikaci. Tato funkce není určena pro scénáře synchronní replikace. Mezi zdrojem a replikou bude měřitelné zpoždění. Data v replice se nakonec stanou konzistentní s daty v primární replice. Tuto funkci použijte pro úlohy, u které se toto zpoždění může pojmout.

Replikace mezi oblastmi

Repliku pro čtení můžete vytvořit v jiné oblasti než zdrojový server. Replikace mezi oblastmi může být užitečná pro scénáře, jako je plánování zotavení po havárii nebo přibližování dat uživatelům.

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

Oblasti univerzální repliky

Repliku pro čtení můžete vytvořit v kterékoli z následujících oblastí bez ohledu na to, kde se nachází váš zdrojový server. Mezi podporované oblasti univerzální repliky patří:

Austrálie – východ, Austrálie – jihovýchod, Brazílie – jih, Kanada – střed, Kanada – východ, USA – střed, Východní Asie, USA – východ, USA – východ 2, Japonsko – východ, Japonsko – západ, Korea – střed, Jižní Korea – jih, USA – středosever, Severní Evropa, USA – středojih, Jihovýchodní Asie, Velká Británie – jih, Velká Británie – západ, Západní Evropa, USA – západ, USA – západ 2, USA – středozápad.

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áme, další informace najdete v článku Spárované oblasti Azure.

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

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

• Regionální dostupnost: Azure Database for MariaDB ve Francii – střed, Spojeném království – 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 v jednom směru. Mezi tyto oblasti patří Indie – západ, Brazílie – jih a US Gov – Virginie. To znamená, že zdrojový server v Indie – západ může vytvořit repliku v Indie – jih. Zdrojový server v Indie – jih nemůže vytvořit repliku v Indie – západ. Je to proto Indie – západ že sekundární oblast Indie – jih, ale Indie – jih sekundární oblast není Indie – západ.

Vytvoření repliky

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

Když spustíte pracovní postup vytvoření repliky, vytvoří se Azure Database for MariaDB serveru. Nový server se vyplní daty, která byla na zdrojovém serveru. Čas vytvoření závisí na množství dat ve zdroji a čase od posledního týdenního úplného zálohování. Čas může být v rozsahu od několika minut až po několik hodin.

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

Připojení k replice

Při vytváření replika dědí pravidla brány firewall zdrojového serveru. Potom 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 pouze pomocí uživatelských účtů, které jsou k dispozici 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 Azure Database for MariaDB serveru. Pro server 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.mariadb.database.azure.com -u myadmin@myreplica -p

Po zobrazení výzvy zadejte heslo pro uživatelský účet.

Monitorování replikace

Azure Database for MariaDB poskytuje metriku Prodleva replikace v sekundách v Azure Monitor. Tato metrika je dostupná jenom pro repliky.

Tato metrika se počítá pomocí seconds_behind_master metriky dostupné v příkazu SHOW SLAVE STATUS MariaDB.

Nastavte upozornění, které vás informuje, když prodleva replikace dosáhne hodnoty, která není pro vaši úlohu přijatelná.

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 v replice dostupná v době spuštění příkazu zastavení replikace. Samostatný server se zdrojovým serverem nezachytí.

Pokud se rozhodnete zastavit replikaci na repliku, přijdete o všechna propojení s předchozím zdrojem a dalšími replikami. Mezi zdrojem a jeho replikou neexistuje žádné automatické 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ým serverem a serverem repliky neexistuje žádné automatické převzetí služeb při selhání.

Vzhledem k tomu, že replikace je asynchronní, mezi zdrojem a replikou je prodleva. Na prodlevu může mít vliv řada faktorů, jako je například zatížení běžící na zdrojovém serveru a latence mezi datovými cechy. 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í metriky Replica Lag(Prodleva repliky), která je k dispozici pro každou repliku. Tato metrika zobrazuje čas od poslední znovu přehráné transakce. Doporučujeme zjistit průměrnou prodlevu tím, že v časovém období pozorujte prodlevu repliky. Můžete nastavit upozornění na prodlevu repliky, takže pokud se dostane mimo očekávaný rozsah, můžete provést akci.

Až se rozhodli, že chcete provést převzetí služeb při selhání do repliky,

1. Zastavte replikaci do repliky.

   Tento krok je nezbytný, aby server repliky mohl přijímat zápisy. V rámci tohoto procesu se server repliky od primárního serveru odpořadí. Po zahájení zastavení replikace trvá proces back-endu obvykle přibližně 2 minuty. Informace o důsledcích této akce najdete v části zastavení replikace tohoto článku.

2. Nasílání aplikace na (bývalou) repliku.

   Každý server má jedinečný připojovací řetězec. Aktualizujte svou aplikaci tak, aby odkazovala na (bývalé) repliku místo na primární.

Po úspěšném zpracování čtení a zápisu vaší aplikace jste dokončili převzetí služeb při selhání. Množství prostojů, na kterých bude prostředí aplikace záviset při zjištění problému a dokončení kroků 1 a 2 výše.

Důležité informace a omezení

Cenové úrovně

Repliky čtení jsou v tuto chvíli dostupné jenom v Pro obecné účely a paměťově optimalizované cenové úrovně.

Restart zdrojového serveru

Když vytvoříte repliku pro zdroj, který nemá žádné existující repliky, zdroj se nejdřív restartuje, aby se připravil pro replikaci. Vezměte v úvahu a udělejte tyto operace v době mimo špičku.

Nové repliky

Replika pro čtení je vytvořená jako nový server Azure Database for MariaDB. Existující server nelze vytvořit do repliky. Nelze vytvořit repliku jiné repliky pro čtení.

Konfigurace repliky

Replika je vytvořena pomocí stejné konfigurace serveru jako primární. Po vytvoření repliky se dá 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ě, doba uchování zálohy a verze stroje MariaDB. Cenová úroveň se dá změnit také nezávisle, s výjimkou nebo z úrovně Basic.

Pravidla brány firewall a nastavení parametrů se při vytvoření repliky dědí ze zdrojového serveru do repliky. Pak jsou pravidla repliky nezávislá.

Zastavené repliky

Pokud zastavíte replikaci mezi zdrojovým serverem a replikou pro čtení, zastavená replika se stane samostatným serverem, který přijímá čtení i zápis. Samostatný server se nedá znovu vytvořit do repliky.

Odstraněné zdrojové a samostatné servery

Po odstranění zdrojového serveru se replikace zastaví na všechny repliky čtení. Tyto repliky se automaticky změní na samostatné servery a můžou přijímat operace čtení i zápisu. 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 pouze pomocí uživatelských účtů, které jsou k dispozici 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čené na zdrojovém serveru i na serverech repliky:

• innodb_file_per_table
• log_bin_trust_function_creators

event_schedulerParametr je uzamčen na serverech repliky.

Pokud chcete na zdrojovém serveru aktualizovat jeden z výše uvedených parametrů, odstraňte prosím servery repliky, aktualizujte hodnotu parametru na primárním a znovu vytvořte repliky.

Jiné

• Vytvoření repliky repliky není podporováno.
• Tabulky v paměti můžou způsobit, že se repliky nesynchronizují. Toto je omezení technologie MariaDB pro replikaci.
• Zajistěte, aby tabulky zdrojového serveru měly primární klíče. Nedostatek primárních klíčů může způsobit latenci replikace mezi zdrojem a replikami.

Další kroky

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