Konfigurace replikace dat flexibilního serveru Azure Database for MySQL

Tento článek popisuje, jak nastavit replikaci dat do flexibilního serveru Azure Database for MySQL na flexibilním serveru Azure Database for MySQL konfigurací zdrojových serverů a serverů replik. Tento článek předpokládá, že máte zkušenosti se servery a databázemi 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.

Pokud chcete vytvořit repliku v instanci flexibilního serveru Azure Database for MySQL, replikace dat do flexibilního serveru Azure Database for MySQL synchronizuje data ze zdrojového místního serveru MySQL, ve virtuálních počítačích nebo v cloudových databázových službách. Replikaci příchozích dat je možné nakonfigurovat pomocí replikace založené na pozici souboru binárního protokolu (binlog) NEBO replikace na základě GTID. Další informace o replikaci binlogu najdete v tématu Replikace MySQL.

Před provedením kroků v tomto článku si projděte omezení a požadavky replikace příchozích dat.

Vytvoření instance flexibilního serveru Azure Database for MySQL pro použití jako repliky

1. Vytvořte novou instanci flexibilního serveru Azure Database for MySQL (například replica.mysql.database.azure.com). Projděte si rychlý start: Vytvoření instance Služby Azure Database for MySQL pomocí webu Azure Portal pro vytvoření serveru. Tento server je serverem repliky pro replikaci příchozích dat.

2. Vytvořte stejné uživatelské účty a odpovídající oprávnění.

   Uživatelské účty se nereplikují ze zdrojového serveru na server repliky. Pokud máte v plánu poskytnout uživatelům přístup k serveru repliky, musíte na této nově vytvořené instanci flexibilního serveru Azure Database for MySQL vytvořit všechny účty a odpovídající oprávnění ručně.

Konfigurace zdrojového serveru MySQL

Následující kroky připraví a nakonfigurují server MySQL hostovaný místně, na virtuálním počítači nebo v databázové službě hostované jinými poskytovateli cloudu pro replikaci příchozích dat. Tento server je "zdrojem" pro replikaci příchozích dat.

1. Než budete pokračovat, zkontrolujte požadavky na zdrojový server.

2. Požadavky na síť

   • Ujistěte se, že zdrojový server umožňuje příchozí i odchozí provoz na portu 3306 a že má veřejnou IP adresu, DNS je veřejně přístupný nebo že má plně kvalifikovaný název domény (FQDN).

   • Pokud se používá privátní přístup (integrace virtuální sítě), ujistěte se, že máte připojení mezi zdrojovým serverem a virtuální sítí, ve které je server repliky hostovaný.

   • Ujistěte se, že zajišťujeme připojení typu site-to-site k místním zdrojovým serverům pomocí ExpressRoute nebo VPN. Další informace o vytváření virtuální sítě najdete v dokumentaci k virtuální síti a zejména v článcích rychlého startu s podrobnými podrobnostmi.

   • Pokud se privátní přístup (integrace virtuální sítě) používá na serveru repliky a váš zdroj je virtuální počítač Azure, ujistěte se, že je navázáno připojení virtuální sítě k virtuální síti. Podporuje se partnerský vztah virtuálních sítí. Můžete také použít jiné metody připojení ke komunikaci mezi virtuálními sítěmi v různých oblastech, jako je připojení virtuální sítě k virtuální síti. Další informace najdete v tématu Brána VPN typu VNet-to-VNet

   • Ujistěte se, že pravidla skupiny zabezpečení sítě virtuální sítě neblokují odchozí port 3306 (příchozí taky v případě, že je mySQL spuštěný na virtuálním počítači Azure). Další podrobnosti o filtrování provozu pomocí skupin zabezpečení virtuální sítě najdete v článku Filtrování provozu sítě s použitím skupin zabezpečení sítě.

   • Nakonfigurujte pravidla brány firewall zdrojového serveru tak, aby umožňovala IP adresu serveru repliky.

3. Pokud chcete použít umístění binárního protokolu nebo replikaci dat založenou na GTID, postupujte podle příslušných kroků.

   Replikace založená na poloze protokolu přihrádky

   Spuštěním následujícího příkazu zkontrolujte, jestli je ve zdroji povolené binární protokolování:

   SHOW VARIABLES LIKE 'log_bin';
   

   Pokud se proměnná log_bin vrátí s hodnotou ON, je na vašem serveru povolené binární protokolování.

   Pokud log_bin se vrátí hodnota OFF a váš zdrojový server běží místně nebo na virtuálních počítačích, kde máte přístup ke konfiguračnímu souboru (my.cnf), můžete postupovat následovně:

   1. Na zdrojovém serveru vyhledejte konfigurační soubor MySQL (my.cnf). Příklad: /etc/my.cnf

   2. Otevřete konfigurační soubor, který chcete upravit, a vyhledejte v souboru oddíl mysqld .

   3. V části mysqld přidejte následující řádek:

      log-bin=mysql-bin.log
      

   4. Restartujte službu MySQL na zdrojovém serveru (nebo restartujte), aby se změny projevily.

   5. Po restartování serveru ověřte, že je binární protokolování povolené spuštěním stejného dotazu jako předtím:

      SHOW VARIABLES LIKE 'log_bin';
      

   Replikace založená na GTID

   Hlavní server musí být spuštěn s režimem GTID, který je povolený nastavením gtid_mode proměnné na ZAPNUTO. Je také důležité, aby byla povolena proměnná enforce_gtid_consistency, aby se zajistilo, že se protokolují pouze příkazy, které jsou bezpečné pro replikaci MYSQL GTID.

   SET @@GLOBAL.ENFORCE_GTID_CONSISTENCY = ON;
   SET @@GLOBAL.GTID_MODE = ON;
   

   Pokud je hlavním serverem jiná instance flexibilního serveru Azure Database for MySQL, můžete tyto parametry serveru aktualizovat také z portálu tak, že přejdete na stránku parametrů serveru.

4. Nakonfigurujte nastavení zdrojového serveru.

   Replikace příchozích dat vyžaduje, aby byl parametr lower_case_table_names konzistentní mezi zdrojovými servery a servery replik. Tento parametr je ve výchozím nastavení 1 na flexibilním serveru Azure Database for MySQL.

   SET GLOBAL lower_case_table_names = 1;
   

5. Vytvořte novou roli replikace a nastavte oprávnění.

   Na zdrojovém serveru, který je nakonfigurovaný s oprávněními replikace, vytvořte uživatelský účet. Můžete to provést pomocí příkazů SQL nebo nástroje, jako je MySQL Workbench. Zvažte, jestli plánujete replikaci pomocí PROTOKOLU SSL, protože při vytváření uživatele bude potřeba zadat tuto možnost. Informace o přidávání uživatelských účtů na zdrojovém serveru najdete v dokumentaci k MySQL.

   V následujících příkazech má nová vytvořená role replikace přístup ke zdroji z libovolného počítače, nejen k počítači, který je hostitelem samotného zdroje. To se provádí zadáním "syncuser@"%" v příkazu create user. Další informace o zadávání názvů účtů najdete v dokumentaci k MySQL.

   Příkaz SQL

   Replikace s využitím SSL

   Pokud chcete vyžadovat protokol SSL pro všechna uživatelská připojení, vytvořte uživatele pomocí následujícího příkazu:

   CREATE USER 'syncuser'@'%' IDENTIFIED BY 'yourpassword';
   GRANT REPLICATION SLAVE ON *.* TO ' syncuser'@'%' REQUIRE SSL;
   

   Replikace bez SSL

   Pokud pro všechna připojení není vyžadován protokol SSL, vytvořte uživatele pomocí následujícího příkazu:

   CREATE USER 'syncuser'@'%' IDENTIFIED BY 'yourpassword';
   GRANT REPLICATION SLAVE ON *.* TO ' syncuser'@'%';
   

   MySQL Workbench

   Pokud chcete vytvořit roli replikace v aplikaci MySQL Workbench, otevřete na panelu Správa panel Uživatelé a oprávnění a pak vyberte Přidat účet.

   

   Do pole Přihlašovací jméno zadejte uživatelské jméno.

   

   Vyberte panel Role pro správu a pak v seznamu globálních oprávnění vyberte Replikační slave. Pak vyberte Použít a vytvořte roli replikace.

   

6. Nastavte zdrojový server na režim jen pro čtení.

   Než začnete s výpisem databáze, musí být server umístěn v režimu jen pro čtení. V režimu jen pro čtení nebude zdroj moct zpracovat žádné transakce zápisu. V případě potřeby vyhodnoťte dopad na vaši firmu a naplánujte okno jen pro čtení v době mimo špičku.

   FLUSH TABLES WITH READ LOCK;
   SET GLOBAL read_only = ON;
   

7. Získejte název a posun souboru binárního protokolu.

   Spuštěním show master status příkazu určete aktuální název souboru binárního protokolu a posun.

   show master status;
   

   Výsledky by se měly podobat následujícímu. Nezapomeňte si poznamenat název binárního souboru pro použití v pozdějších krocích.

   

---

Výpis a obnovení zdrojového serveru

1. Určete, které databáze a tabulky chcete replikovat na flexibilní server Azure Database for MySQL, a proveďte výpis ze zdrojového serveru.

   K výpisu databází z primárního serveru můžete použít mysqldump. Podrobnosti najdete v tématu Výpis a obnovení. Není nutné vysunout knihovnu MySQL a testovací knihovnu.

2. Nastavte zdrojový server na režim čtení a zápisu.

   Po výpisu databáze změňte zdrojový server MySQL zpět na režim čtení a zápisu.

   SET GLOBAL read_only = OFF;
   UNLOCK TABLES;
   

   Poznámka:

   Než se server nastaví zpět do režimu čtení a zápisu, můžete načíst informace GTID pomocí globální proměnné GTID_EXECUTED. Použije se v pozdější fázi k nastavení GTID na serveru repliky.

3. Obnovte soubor s výpisem paměti na nový server.

   Obnovte soubor s výpisem paměti na server vytvořený na flexibilním serveru Azure Database for MySQL. Informace o obnovení souboru s výpisem paměti na server MySQL najdete v tématu Výpis a obnovení . Pokud je soubor s výpisem paměti velký, nahrajte ho do virtuálního počítače v Azure ve stejné oblasti jako server repliky. Obnovte ji z virtuálního počítače do instance flexibilního serveru Azure Database for MySQL.

Poznámka:

Pokud se chcete vyhnout nastavení databáze jen pro čtení při výpisu a obnovení, můžete použít mydumper/myloader.

Nastavení GTID na serveru repliky

1. Pokud používáte replikaci založenou na pozicích protokolu při intervalu, přeskočte tento krok.

2. Informace GTID ze souboru výpisu paměti převzaté ze zdroje se vyžadují k resetování historie GTID cílového serveru (repliky).

3. Pomocí těchto informací GTID ze zdroje spusťte resetování GTID na serveru repliky pomocí následujícího příkazu rozhraní příkazového řádku:

   az mysql flexible-server gtid reset --resource-group  <resource group> --server-name <replica server name> --gtid-set <gtid set from the source server> --subscription <subscription id>
   

Další podrobnosti najdete v tématu OBNOVENÍ GTID.

Poznámka:

Resetování GTID nejde provést na serveru s povolenou geografickou redundancí. Zakažte geografickou redundanci a proveďte resetování GTID na serveru. Možnost geografické redundance můžete znovu povolit po resetování GTID. Akce resetování GTID zneplatní všechny dostupné zálohy, a proto po opětovném povolení geografické redundance může trvat den před provedením geografického obnovení na serveru.

Propojení zdrojových serverů a serverů replik za účelem spuštění replikace příchozích dat

1. Nastavte zdrojový server.

   Všechny funkce replikace příchozích dat se provádějí uloženými procedurami. Všechny postupy najdete v uložených procedurách replikace příchozích dat. Uložené procedury je možné spustit v prostředí MySQL nebo MySQL Workbench.

   Pokud chcete propojit dva servery a spustit replikaci, přihlaste se k cílovému serveru repliky ve službě Azure Database for MySQL a nastavte externí instanci jako zdrojový server. To se provádí pomocí mysql.az_replication_change_master nebo mysql.az_replication_change_master_with_gtid uložené procedury na serveru Azure Database for MySQL.

   CALL mysql.az_replication_change_master('<master_host>', '<master_user>', '<master_password>', <master_port>, '<master_log_file>', <master_log_pos>, '<master_ssl_ca>');
   

   CALL mysql.az_replication_change_master_with_gtid('<master_host>', '<master_user>', '<master_password>', <master_port>,'<master_ssl_ca>');
   

   • master_host: název hostitele zdrojového serveru
   • master_user: uživatelské jméno zdrojového serveru
   • master_password: heslo pro zdrojový server
   • master_port: číslo portu, na kterém zdrojový server naslouchá připojení. (3306 je výchozí port, na kterém MySQL naslouchá)
   • master_log_file: Spuštění názvu binárního souboru protokolu show master status
   • master_log_pos: Pozice binárního protokolu od spuštění show master status
   • master_ssl_ca: Kontext certifikátu certifikační autority. Pokud nepoužíváte SSL, předejte prázdný řetězec.

   Tento parametr se doporučuje předat jako proměnnou. Další informace najdete v následujících příkladech.

   Poznámka:

   • Pokud je zdrojový server hostovaný na virtuálním počítači Azure, nastavte možnost "Povolit přístup ke službám Azure" na "ZAPNUTO", aby mezi sebou mohly komunikovat zdrojové servery a servery repliky. Toto nastavení lze změnit z možností zabezpečení připojení. Další informace najdete v tématu Správa pravidel brány firewall pro flexibilní server Azure Database for MySQL pomocí webu Azure Portal.
   • Pokud jste k výpisu databáze použili mydumper/myloader, můžete získat master_log_file a master_log_pos ze souboru /backup/metadata .

   Příklady

   Replikace s využitím SSL

   Proměnná @cert se vytvoří spuštěním následujících příkazů MySQL:

   SET @cert = '-----BEGIN CERTIFICATE-----
   PLACE YOUR PUBLIC KEY CERTIFICATE'`S CONTEXT HERE
   -----END CERTIFICATE-----'
   

   Replikace s protokolem SSL se nastavuje mezi zdrojovým serverem hostovaným v doméně "companya.com" a serverem repliky hostovaným na flexibilním serveru Azure Database for MySQL. Tato uložená procedura se spouští na replice.

   CALL mysql.az_replication_change_master('master.companya.com', 'syncuser', 'P@ssword!', 3306, 'mysql-bin.000002', 120, @cert);
   

   CALL mysql.az_replication_change_master_with_gtid('master.companya.com', 'syncuser', 'P@ssword!', 3306, @cert);
   

   Replikace bez SSL

   Replikace bez SSL je nastavená mezi zdrojovým serverem hostovaným v doméně "companya.com" a serverem repliky hostovaným na flexibilním serveru Azure Database for MySQL. Tato uložená procedura se spouští na replice.

   CALL mysql.az_replication_change_master('master.companya.com', 'syncuser', 'P@ssword!', 3306, 'mysql-bin.000002', 120, '');
   

   CALL mysql.az_replication_change_master_with_gtid('master.companya.com', 'syncuser', 'P@ssword!', 3306, '');
   

2. Spusťte replikaci.

   Zavolejte uloženou proceduru mysql.az_replication_start , aby se spustila replikace.

   CALL mysql.az_replication_start;
   

3. Zkontrolujte stav replikace.

   Stav replikace zobrazíte voláním show slave status příkazu na serveru repliky.

   show slave status;
   

   Informace o správném stavu replikace najdete v metrikách replikace – Stav V/V repliky a Stav SQL repliky na stránce monitorování.

   Pokud je hodnota Seconds_Behind_Master 0, replikace funguje dobře. Seconds_Behind_Master označuje, jak pozdě je replika. Pokud hodnota není 0, znamená to, že replika zpracovává aktualizace.

Další užitečné uložené procedury pro operace replikace příchozích dat

Zastavení replikace

Pokud chcete zastavit replikaci mezi zdrojovým serverem a serverem repliky, použijte následující uloženou proceduru:

CALL mysql.az_replication_stop;

Odebrání vztahu replikace

Pokud chcete odebrat vztah mezi zdrojovým serverem a serverem repliky, použijte následující uloženou proceduru:

CALL mysql.az_replication_remove_master;

Chyba přeskočení replikace

Pokud chcete přeskočit chybu replikace a povolit replikaci pokračovat, použijte následující uloženou proceduru:

CALL mysql.az_replication_skip_counter;

SHOW BINLOG EVENTS [IN 'log_name'] [FROM pos][LIMIT [offset,] row_count]

Další krok

Replikace dat do flexibilního serveru Azure Database for MySQL