sql >> Databáze >  >> RDS >> Mysql

Online migrace z MySQL 5.6 Non-GTID na MySQL 5.7 s GTID

V tomto příspěvku na blogu se podíváme na to, jak provést online migraci ze samostatného nastavení MySQL 5.6 na novou replikační sadu běžící na MySQL 5.7, nasazenou a spravovanou ClusterControl.

V plánu je vytvořit replikační linku z nového clusteru běžícího na MySQL 5.7 do hlavního běžícího na MySQL 5.6 (mimo ClusterControl), který nepoužívá žádné GTID. MySQL nepodporuje míchání GTID a non-GTID v jednom replikačním řetězci. Potřebujeme tedy provést několik triků, abychom během migrace přepínali mezi režimy bez GTID a GTID.

Naši architekturu a plán migrace lze ilustrovat níže:

Nastavení se skládá ze 4 serverů s následujícím zastoupením:

  • mysql56a – starý mistr – Oracle MySQL 5.6 bez GTID
  • Slave cluster:
    • mysql57a – Nový hlavní server – Oracle MySQL 5.7 s GTID
    • mysql57b – Nový slave – Oracle MySQL 5.7 s GTID
  • cc – Server ClusterControl – Server pro nasazení/správu/monitorování pro uzly databáze.

Všichni hostitelé MySQL 5.7 běží na Debianu 10 (Buster), zatímco MySQL 5.6 běží na Debianu 9 (Stretch).

Nasazení Slave Cluster

Nejprve si připravme podřízený cluster, než nastavíme replikační odkaz ze starého hlavního serveru. Finální konfigurace slave clusteru bude spuštěna na MySQL 5.7 s povoleným GTID. Nainstalujte ClusterControl na server ClusterControl (cc):

$ wget https://severalnines.com/downloads/install-cc
$ chmod 755 install-cc
$ ./install-cc

Postupujte podle pokynů, dokud nebude instalace dokončena. Poté nastavte SSH bez hesla z ClusterControl na mysql57a a mysql57b:

$ whoami
root
$ ssh-keygen -t rsa # press Enter on all prompts
$ ssh-copy-id [email protected] # enter the target host root password
$ ssh-copy-id [email protected] # enter the target host root password

Potom se přihlaste do uživatelského rozhraní ClusterControl, vyplňte úvodní formulář a přejděte do části ClusterControl -> Deploy -> Replikace MySQL a vyplňte následující:

Poté klikněte na Pokračovat a jako dodavatele vyberte Oracle a jako poskytovatele 5.7 verze. Poté pokračujte do sekce topologie a nakonfigurujte ji, jak je uvedeno níže:

Počkejte, až se nasazení dokončí a měli byste vidět nový cluster, jak je uvedeno níže:

Náš podřízený cluster běžící na MySQL 5.7 s GTID je nyní připraven.

Příprava starého mistra

Aktuální master, který chceme replikovat, je samostatný MySQL 5.6 (binární log povolen, server-id nakonfigurované, bez GTID) a obsluhuje produkční databáze. Pro tuto migraci tedy nejsou možné prostoje. Na druhou stranu ClusterControl konfiguruje novou MySQL 5.7 s povoleným GTID, což znamená, že musíme vypnout funkci GTID uvnitř podřízeného clusteru, abychom mohli správně replikovat z tohoto samostatného hlavního serveru.

Následující řádky ukazují naši aktuální konfiguraci související s replikací pro hlavní /etc/mysql/mysql.conf.d/mysqld.cnf pod direktivou [mysqld]:

server_id=1
binlog_format=ROW
log_bin=binlog
log_slave_updates=1
relay_log=relay-bin
expire_logs_days=7
sync_binlog=1

Ověřte, že server MySQL vytváří binární protokol bez GTID:

mysql> SHOW MASTER STATUS;
+---------------+----------+--------------+------------------+-------------------+
| File          | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+---------------+----------+--------------+------------------+-------------------+
| binlog.000007 |   734310 |              |                  |                   |
+---------------+----------+--------------+------------------+-------------------+

1 row in set (0.00 sec)

U jiných značek než GTID se očekává, že Executed_Gtid_Set bude prázdná. Všimněte si, že náš nový replikační cluster MySQL 5.7 nasazený pomocí ClusterControl je nakonfigurován s povoleným GTID.

1) Vytvořte uživatele replikace, kterého bude používat mysql57a:

mysql> CREATE USER 'slave'@'192.168.10.31' IDENTIFIED BY 'slavepassword';
mysql> GRANT REPLICATION SLAVE ON *.* TO 'slave'@192.168.10.31';

2) Zakažte automatické obnovení ClusterControl. V uživatelském rozhraní ClusterControl -> vyberte cluster -> ujistěte se, že cluster a uzel automatického obnovení jsou VYPNUTY (červené ikony napájení), jak je znázorněno na obrázku níže:

Nechceme, aby ClusterControl obnovoval uzel během této konfigurace replikace.

3) Nyní musíme vytvořit úplnou zálohu mysqldump, protože se bude jednat o hlavní aktualizaci verze. Jiné neblokující zálohovací nástroje jako Percona Xtrabackup nebo MySQL Enterprise Backup nepodporují obnovení do jiné hlavní verze. Také musíme zachovat aktuální binární soubor protokolu a pozici pomocí --master-data flag:

$ mysqldump -u root -p --single-transaction --master-data=2 --all-databases > mysql56a-fullbackup.sql

Všimněte si, že výše uvedený příkaz nebude blokovat žádné tabulky InnoDB kvůli --single-transaction. Pokud tedy máte tabulky MyISAM, budou tabulky během zálohování zablokovány, aby byla zachována konzistence.

4) Zkopírujte zálohu z mysql56a do mysql57a a mysql57b:

$ scp mysql56a-fullbackup.sql [email protected]:~
$ scp mysql56a-fullbackup.sql [email protected]:~

Příprava Slave Cluster

V této fázi nakonfigurujeme podřízený cluster tak, aby se začal replikovat ze starého hlavního serveru, mysql56a bez GTID.

1) Zastavte replikaci mezi mysql57a a mysql57b, odstraňte všechna pověření související s podřízenými zařízeními nakonfigurovaná pomocí ClusterControl a zakažte pouze pro čtení na mysql57b:

mysql> STOP SLAVE;
mysql> RESET SLAVE ALL;
mysql> SET GLOBAL super_read_only = 0;
mysql> SET GLOBAL read_only = 0;

2) Zakázat GTID na mysql57a:

mysql> SET GLOBAL gtid_mode = 'ON_PERMISSIVE';
mysql> SET GLOBAL gtid_mode = 'OFF_PERMISSIVE';
mysql> SET GLOBAL gtid_mode = 'OFF';
mysql> SET GLOBAL enforce_gtid_consistency = 'OFF';

3) Zakázat GTID na mysql57b:

mysql> SET GLOBAL gtid_mode = 'ON_PERMISSIVE';
mysql> SET GLOBAL gtid_mode = 'OFF_PERMISSIVE';
mysql> SET GLOBAL gtid_mode = 'OFF';
mysql> SET GLOBAL enforce_gtid_consistency = 'OFF';

4) Obnovte zálohu mysqldump na mysql57a:

$ mysql -uroot -p < mysql56a-fullbackup.sql

5) Obnovte zálohu mysqldump na mysql57b:

$ mysql -uroot -p < mysql56a-fullbackup.sql

6) Spusťte skript pro upgrade MySQL na mysql57a (pro kontrolu a aktualizaci všech tabulek na aktuální verzi):

$ mysql_upgrade -uroot -p

7) Spusťte skript pro upgrade MySQL na mysql57b (pro kontrolu a aktualizaci všech tabulek na aktuální verzi):

$ mysql_upgrade -uroot -p

Oba servery na podřízeném clusteru jsou nyní připraveny se snímkem dat ze starého hlavního serveru, mysql56a, a jsou nyní připraveny k replikaci.

Nastavení replikace pro Slave Cluster

1) Resetujte binární protokoly pomocí RESET MASTER na mysql57a, takže později na mysql57b nemusíme specifikovat umístění binárního souboru a protokolu. Také odstraňujeme všechny existující reference GTID, které byly nakonfigurovány dříve:

mysql> RESET MASTER;
mysql> SET @@global.gtid_purged='';

2) Na mysql57a načtěte soubor binlog a pozici ze souboru výpisu, mysql56a-fullbackup.sql:

$ head -100 mysql56a-fullbackup.sql | grep LOG_POS
-- CHANGE MASTER TO MASTER_LOG_FILE='binlog.000007', MASTER_LOG_POS=4677987;

3) Spusťte replikaci slave ze starého hlavního serveru, mysql56a na nový master mysql57a, zadáním správných hodnot MASTER_LOG_FILE a MASTER_LOG_POS získaných v předchozím kroku. Na mysql57a:

mysql> CHANGE MASTER TO MASTER_HOST = '192.168.10.22', MASTER_USER = 'slave', MASTER_PASSWORD = 'slavepassword', MASTER_LOG_FILE='binlog.000007', MASTER_LOG_POS=4677987;
mysql> START SLAVE;
mysql> SHOW SLAVE STATUS\G

Ujistěte se, že vidíte následující řádky:

             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes

Pravděpodobně budete muset počkat, až mysql57a dohoní mysql56a sledováním "Seconds_Behind_Master" a ujistěte se, že se změní na 0.

4) V tuto chvíli mysql57a replikuje data z mysql56a, což znamená, že všichni uživatelé vytvoření ClusterControl nyní na serveru chybí (protože mysql57a nyní sleduje data na mysql56a). ClusterControl bude mít problém se připojit k mysql57a a zobrazí se jako "dole". V podstatě to znamená, že ClusterControl se nemůže připojit k serverům MySQL, protože chybí granty. Chybějící uživatelé jsou:

Všechny přihlašovací údaje jsou bezpečně uloženy v ClusterControl a na samotném databázovém serveru. Abyste mohli získat přihlašovací údaje zpět z příslušných souborů, musíte mít přístup root.

Nyní znovu vytvoříme chybějící uživatele na novém masteru, mysql57a:

a) Vytvořte záložního uživatele (heslo převzato z /etc/mysql/secrets-backup.cnf na mysql57a):

mysql> CREATE USER [email protected] IDENTIFIED BY '[email protected]!65%JlNB1z';
mysql> GRANT RELOAD, LOCK TABLES, PROCESS, SUPER, REPLICATION CLIENT ON *.* TO [email protected];

b) Vytvořte uživatele replikace pro všechny hostitele DB (heslo převzato z proměnné repl_password v /etc/cmon.d/cmon_X.cnf na serveru ClusterControl, kde X je ID klastru podřízeného klastru):

mysql> CREATE USER 'rpl_user'@'192.168.10.31' IDENTIFIED BY '68n61F+bdsW1}[email protected]}x5J';
mysql> GRANT REPLICATION SLAVE ON *.* TO 'rpl_user'@'192.168.10.31';
mysql> CREATE USER 'rpl_user'@'192.168.10.32' IDENTIFIED BY '68n61F+bdsW1}[email protected]}x5J';
mysql> GRANT REPLICATION SLAVE ON *.* TO 'rpl_user'@'192.168.10.32';

c) Vytvořte dva uživatele databáze cmon (jeden pro IP adresu a jeden pro název hostitele) pro použití ClusterControl (heslo převzato z proměnné mysql_password uvnitř /etc/cmon.d/cmon_X.cnf na serveru ClusterControl, kde X je ID clusteru podřízeného zařízení cluster):

mysql> CREATE USER [email protected]'192.168.10.19' IDENTIFIED BY 'My&Passw0rd90';
mysql> GRANT ALL PRIVILEGES ON *.* TO [email protected]'192.168.10.19' WITH GRANT OPTION;
mysql> CREATE USER [email protected]'cc.local' IDENTIFIED BY 'My&Passw0rd90';
mysql> GRANT ALL PRIVILEGES ON *.* TO [email protected]'cc.local' WITH GRANT OPTION;

5) V tomto okamžiku by se měl mysql57a v ClusterControl zobrazit zeleně. Nyní můžeme nastavit replikační odkaz z mysql57a na mysql57b. Na mysql57b:

mysql> RESET MASTER;
mysql> SET @@global.gtid_purged='';
mysql> CHANGE MASTER TO MASTER_HOST = '192.168.10.31', MASTER_USER = 'rpl_user', MASTER_PASSWORD = '68n61F+bdsW1}[email protected]}x5J';
mysql> START SLAVE;
mysql> SHOW SLAVE STATUS\G

**Nemusíme specifikovat MASTER_LOG_FILE a MASTER_LOG_POS, protože po RESET MASTER v kroku č. 1 bude vždy začínat s pevnou počáteční pozicí.

Ujistěte se, že vidíte následující řádky:

             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes

Monitorujte stav replikace a ujistěte se, že mysql57b drží krok s mysql57a a mysql57a drží krok s mysql56a. Možná budete muset povolit pouze čtení na mysql57b (a/nebo mysql57a), abyste se chránili před náhodnými zápisy. 

mysql> SET GLOBAL super_read_only = 1;
mysql> SET GLOBAL read_only = 1;

V uživatelském rozhraní ClusterControl vidíte aktuální stav v části Přehled:

V tuto chvíli se nový hlavní mysql57a, 192.168.10.31 replikuje z starý samostatný hostitel mysql56a, 192.168.10.22, zatímco nový podřízený mysql57b (pouze pro čtení) se replikuje z mysql57a, 192.168.10.31. Všechny uzly jsou synchronizovány se zpožděním replikace 0.

Případně můžete zakomentovat následující řádky v konfiguračních souborech MySQL v sekci [mysqld]:

#gtid_mode=ON
#enforce_gtid_consistency=1

Povolení GTID na Slave Cluster

Všimněte si, že pro MySQL 5.6 a novější ClusterControl již nepodporuje implementaci bez GTID u některých svých funkcí správy, jako je Rebuild Replication Slave a Change Replication Master. Takže během doby ukončení (když nasměrujete aplikace na nový cluster) ze samostatného serveru MySQL (mysql56a) se doporučuje povolit zpět GTID na mysql57a a mysql57b pomocí následujících kroků:

1) Ujistěte se, že jste vypnuli funkci automatického obnovení ClusterControl:

2) Během období údržby musíme zastavit replikaci ze starého hlavního serveru, mysql56a, odstraňte veškerou konfiguraci slave na mysql57a a povolte zpět GTID. Na mysql57a spusťte následující příkazy ve správném pořadí:

mysql> SHOW SLAVE STATUS\G # Make sure you see "Slave has read all relay log"
mysql> STOP SLAVE;
mysql> RESET SLAVE ALL;
mysql> SET GLOBAL super_read_only = 0;
mysql> SET GLOBAL read_only = 0;
mysql> SET GLOBAL gtid_mode = 'OFF_PERMISSIVE';
mysql> SET GLOBAL gtid_mode = 'ON_PERMISSIVE';
mysql> SET GLOBAL enforce_gtid_consistency = 'ON';
mysql> SET GLOBAL gtid_mode = 'ON';

V tuto chvíli je pro vaši aplikaci prakticky bezpečné začít zapisovat do nového hlavního serveru, mysql57a. Stará samostatná MySQL je nyní mimo replikační řetězec a lze ji vypnout.

3) Opakujte stejné kroky pro mysql57b. Nezapomeňte postupovat podle kroků ve správném pořadí:

mysql> SHOW SLAVE STATUS\G # Make sure you see "Slave has read all relay log"
mysql> STOP SLAVE;
mysql> RESET SLAVE ALL;
mysql> SET GLOBAL super_read_only = 0;
mysql> SET GLOBAL read_only = 0;
mysql> SET GLOBAL gtid_mode = 'OFF_PERMISSIVE';
mysql> SET GLOBAL gtid_mode = 'ON_PERMISSIVE';
mysql> SET GLOBAL enforce_gtid_consistency = 'ON';
mysql> SET GLOBAL gtid_mode = 'ON';

4) Poté resetujte master na novém masteru, mysql57a:

mysql> RESET MASTER;

3) Poté na novém slave mysql57b nastavte replikační odkaz pomocí GTID na mysql57a:

mysql> RESET MASTER;
mysql> CHANGE MASTER TO MASTER_HOST = '192.168.10.31', MASTER_USER = 'rpl_user', MASTER_PASSWORD = '68n61F+bdsW1}[email protected]}x5J', MASTER_AUTO_POSITION = 1;
mysql> START SLAVE;
mysql> SHOW SLAVE STATUS\G

Ujistěte se, že vidíte, že pole Retrieved_Gtid_Set a Executed_Gtid_Set mají hodnotu GTID.

4) V tomto okamžiku jsme obnovili konfiguraci replikace tak, jak byla dříve nakonfigurována ClusterControl během fáze nasazení clusteru. Poté můžeme na novém podřízeném zařízení mysql57b povolit pouze pro čtení, abychom jej chránili před náhodnými zápisy:

mysql> SET GLOBAL super_read_only = 1;
mysql> SET GLOBAL read_only = 1;

Nakonec znovu povolte automatické obnovení ClusterControl pro cluster přepnutím ikon napájení na zelenou. Poté můžete vyřadit z provozu starého mistra, mysql56a. Právě jsme dokončili naši online migraci z MySQL 5.6 na MySQL 5.7 s velmi minimálními výpadky. Podobné kroky by měly fungovat i pro migraci na MySQL 8.0.


  1. Proč mi Oracle DECODE dává jinou hodnotu než NVL?

  2. Uspořádejte uzly TreeView přetažením

  3. Zkontrolujte, zda tabulka obsahuje cizí klíč na serveru SQL pomocí OBJECTPROPERTY()

  4. Syntaxe MySQL pro Join Update