Replikace dat na flexibilní server Azure Database for MySQL

  • Článek

PLATÍ PRO: Flexibilní server Azure Database for MySQL

Replikace vstupních dat umožňuje synchronizovat data z externího serveru MySQL do instance flexibilního serveru Azure Database for MySQL. Externí server může být místní, na virtuálních počítačích, jednoúčelovém serveru Azure Database for MySQL nebo v databázové službě hostované jinými poskytovateli cloudu. Replikace příchozích dat je založená na umístění souboru binárního protokolu (binlog) nebo replikaci založené na GTID. Další informace o replikaci binlogu najdete v tématu Replikace MySQL.

Poznámka:

Konfigurace replikace příchozích dat pro servery s povolenou vysokou dostupností se podporuje pouze prostřednictvím replikace založené na GTID.

Kdy použít replikaci příchozích dat

Mezi hlavní scénáře, které je potřeba zvážit použití replikace příchozích dat, patří:

  • Hybridní Synchronizace dat hronizace: Díky replikaci dat můžete udržovat synchronizovaná data mezi místními servery a flexibilním serverem Azure Database for MySQL. Tato synchronizace pomáhá vytvářet hybridní aplikace. Tato metoda je atraktivní, pokud máte existující místní databázový server, ale chcete přesunout data do oblasti blíže koncovým uživatelům.
  • Synchronizace s více cloudy: U složitých cloudových řešení použijte replikaci dat k synchronizaci dat mezi flexibilním serverem Azure Database for MySQL a různými poskytovateli cloudu, včetně virtuálních počítačů a databázových služeb hostovaných v těchto cloudech.
  • Migrace: Zákazníci můžou migrovat v minimálním čase pomocí opensourcových nástrojů, jako je MyDumper/MyLoader s replikací dat. Selektivní přímé produkční zatížení ze zdroje do cílové databáze je možné s replikací příchozích dat.

Pro scénáře migrace použijte službu Azure Database Migration Service (DMS).

Omezení a důležité informace

Data se nereplikují

Systémová databáze mysql na zdrojovém serveru se nereplikuje. Kromě toho se změny účtů a oprávnění na zdrojovém serveru nereplikují. Pokud vytvoříte účet na zdrojovém serveru a tento účet potřebuje přístup k serveru repliky, ručně vytvořte stejný účet na serveru repliky. Informace o tabulkách v systémové databázi najdete v příručce k MySQL.

Replikace příchozích dat se podporuje na serverech s podporou vysoké dostupnosti (HA).

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

Filtrovat

replicate_wild_ignore_table Parametr vytvoří filtr replikace pro tabulky na serveru repliky. Pokud chcete tento parametr upravit z webu Azure Portal, přejděte do instance flexibilního serveru Azure Database for MySQL, která se používá jako replika, a výběrem možnosti Parametry serveru zobrazte nebo upravte replicate_wild_ignore_table parametr.

Požadavky

  • Verze zdrojového serveru musí být minimálně MySQL verze 5.7.

  • Naším doporučením je mít stejnou verzi pro verze zdrojového serveru a serveru repliky. Oba musí být například MySQL verze 5.7, nebo oba musí být MySQL verze 8.0.

  • Naším doporučením je mít v každé tabulce primární klíč. Pokud máme tabulku bez primárního klíče, můžete při replikaci čelit zpomalení.

  • Zdrojový server by měl používat modul MySQL InnoDB.

  • Uživatel musí mít správná oprávnění ke konfiguraci binárního protokolování a vytvoření nových uživatelů na zdrojovém serveru.

  • Binární soubory protokolu na zdrojovém serveru by neměly být před tím, než replika tyto změny použije, vyprázdnit. Pokud je zdrojem flexibilní server Azure Database for MySQL, přečtěte si, jak nakonfigurovat binlog_expire_logs_seconds pro flexibilní server nebo jeden server.

  • Pokud má zdrojový server povolený protokol SSL, ujistěte se, že certifikát CA SSL zadaný pro doménu je součástí mysql.az_replication_change_master uložené procedury. Projděte si následující příklady a master_ssl_ca parametr.

  • Ujistěte se, že počítač, který je hostitelem zdrojového serveru, umožňuje příchozí i odchozí provoz na portu 3306.

  • Pokud používáte veřejný přístup, ujistěte se, že zdrojový server má veřejnou IP adresu, že DNS je veřejně přístupný nebo že zdrojový server má plně kvalifikovaný název domény (FQDN). Pokud máte privátní koncový bod a zakázali jste veřejný přístup, replikace příchozích dat se nepodporuje.

  • S privátním přístupem (integrace virtuální sítě) se ujistěte, že je možné přeložit název zdrojového serveru a že je přístupný z virtuální sítě, ve které je spuštěná instance flexibilního serveru Azure Database for MySQL. (Další podrobnosti najdete na stránce Překlad názvů pro prostředky ve virtuálních sítích Azure).

Generovaný neviditelný primární klíč

Pro MySQL verze 8.0 a novější je pro všechny instance flexibilního serveru Azure Database for MySQL ve výchozím nastavení povolené generované neviditelné primární klíče (GIPK ). Servery MySQL 8.0+ přidají neviditelný sloupec my_row_id do tabulek a primární klíč v daném sloupci, kde se tabulka InnoDB vytvoří bez explicitního primárního klíče. Pokud je tato funkce povolená, může mít vliv na některé případy použití replikace příchozích dat, jak je popsáno níže:

  • Replikace příchozích dat selže s chybou replikace: CHYBA 1068 (42000): Definovaný více primárních klíčů, pokud zdrojový server vytvoří primární klíč v tabulce bez primárního klíče. Pro zmírnění rizik spusťte následující příkaz SQL, přeskočte chybu replikace a restartujte replikaci dat.

    alter table <table name> drop column my_row_id, add primary key <primary key name>(<column name>);

  • Replikace příchozích dat selže s chybou replikace: CHYBA 1075 (42000): Nesprávná definice tabulky; může existovat pouze jeden automatický sloupec a musí být definován jako klíč" pokud zdrojový server přidá sloupec auto_increment jako jedinečný klíč. Pro zmírnění rizik spusťte následující příkaz SQL, nastavte "sql_generate_invisible_primary_key" jako VYPNUTO, přeskočte chybu replikace a restartujte replikaci v replikaci.

    alter table <table name> drop column my_row_id, modify <column name> int auto_increment;

  • Replikace příchozích dat selže, pokud zdrojový server spustí jakýkoli jiný SQL, který není podporován, pokud je zapnutá možnost sql_generate_invisible_primary_key. Můžete například vytvořit tabulku oddílů. V takovém scénáři je nastavit "sql_generate_invisible_primary_key" jako VYPNUTO a restartovat replikaci dat.

Další kroky