Migrazione online da MySQL 5.6 non GTID a MySQL 5.7 con GTID

In questo post del blog, esamineremo come eseguire la migrazione online dalla configurazione standalone di MySQL 5.6 a un nuovo set di replica in esecuzione su MySQL 5.7, distribuito e gestito da ClusterControl.

Il piano prevede di impostare un collegamento di replica dal nuovo cluster in esecuzione su MySQL 5.7 al master in esecuzione su MySQL 5.6 (al di fuori della fornitura ClusterControl), che non utilizza GTID. MySQL non supporta la combinazione di GTID e non GTID in un'unica catena di replica. Quindi dobbiamo fare alcuni trucchi per passare dalla modalità non GTID a GTID durante la migrazione.

La nostra architettura e il nostro piano di migrazione possono essere illustrati di seguito:

Il setup è composto da 4 server, con la seguente rappresentazione:

mysql56a - Old master - Oracle MySQL 5.6 senza GTID
Gruppo di slave:
- mysql57a - Nuovo master - Oracle MySQL 5.7 con GTID
- mysql57b - Nuovo slave - Oracle MySQL 5.7 con GTID
cc - ClusterControl Server - Server di distribuzione/gestione/monitoraggio per i nodi del database.

Tutti gli host MySQL 5.7 girano su Debian 10 (Buster), mentre MySQL 5.6 gira su Debian 9 (Stretch).

Distribuzione del cluster slave

Innanzitutto, prepariamo il cluster slave prima di impostare un collegamento di replica dal vecchio master. La configurazione finale del cluster slave verrà eseguita su MySQL 5.7, con GTID abilitato. Installare ClusterControl sul server ClusterControl (cc):

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

Segui le istruzioni fino al completamento dell'installazione. Quindi, imposta SSH senza password da ClusterControl a mysql57a e 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

Quindi, accedi all'interfaccia utente di ClusterControl, compila il modulo iniziale e vai alla sezione ClusterControl -> Deploy -> MySQL Replication e compila quanto segue:

Quindi fai clic su Continua e scegli Oracle come fornitore e 5.7 come fornitore versione. Quindi procedi alla sezione della topologia e configurala come di seguito:

Aspetta fino al completamento della distribuzione e dovresti vedere il nuovo cluster come di seguito:

Il nostro cluster slave in esecuzione su MySQL 5.7 con GTID è ora pronto.

Preparare l'Antico Maestro

L'attuale master che vogliamo replicare è un MySQL 5.6 autonomo (log binario abilitato, server-id configurato, senza GTID) e sta servendo database di produzione. Quindi i tempi di inattività non sono un'opzione per questa migrazione. D'altra parte, ClusterControl configura il nuovo MySQL 5.7 con GTID abilitato, il che significa che dobbiamo disattivare la funzionalità GTID all'interno del cluster slave per poter replicare correttamente da questo master autonomo.

Le righe seguenti mostrano la nostra attuale configurazione relativa alla replica per il master /etc/mysql/mysql.conf.d/mysqld.cnf sotto la direttiva [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

Verifica che il server MySQL stia producendo un log binario, senza 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)

Per non GTID, l'Executed_Gtid_Set dovrebbe essere vuoto. Tieni presente che il nostro nuovo cluster di replica MySQL 5.7 distribuito da ClusterControl è configurato con GTID abilitato.

1) Crea un utente di replica che deve essere utilizzato da mysql57a:

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

2) Disabilita il ripristino automatico di ClusterControl. Sotto ClusterControl UI -> seleziona il cluster -> assicurati che il cluster e il nodo di ripristino automatico siano disattivati (icone di alimentazione rosse), come mostrato nella schermata seguente:

Non vogliamo che ClusterControl ripristini il nodo durante questa configurazione di replica.

3) Ora dobbiamo creare un backup completo di mysqldump poiché questo sarà un aggiornamento della versione principale. Altri strumenti di backup non bloccanti come Percona Xtrabackup o MySQL Enterprise Backup non supportano il ripristino a una versione principale diversa. Abbiamo anche bisogno di preservare il file di log binario corrente e la posizione usando --master-data flag:

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

Nota che il comando sopra non bloccherà nessuna tabella InnoDB a causa di --single-transaction. Quindi, se hai tabelle MyISAM, le tabelle verranno bloccate durante il periodo di backup per mantenere la coerenza.

4) Copia il backup da mysql56a a mysql57a e mysql57b:

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

Preparazione del cluster slave

A questo punto configureremo il cluster slave per iniziare a replicare dal vecchio master, mysql56a senza GTID.

1) Interrompere la replica tra mysql57a e mysql57b, rimuovere tutte le credenziali relative allo slave configurate da ClusterControl e disabilitare la sola lettura su mysql57b:

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

2) Disabilita GTID su 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) Disabilita GTID su 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) Ripristina il backup di mysqldump su mysql57a:

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

5) Ripristina il backup di mysqldump su mysql57b:

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

6) Esegui lo script di aggiornamento MySQL su mysql57a (per controllare e aggiornare tutte le tabelle alla versione corrente):

$ mysql_upgrade -uroot -p

7) Esegui lo script di aggiornamento MySQL su mysql57b (per controllare e aggiornare tutte le tabelle alla versione corrente):

$ mysql_upgrade -uroot -p

Entrambi i server nel cluster slave sono ora organizzati con lo snapshot dei dati del vecchio master, mysql56a, e sono ora pronti per la replica.

Impostazione della replica per il cluster slave

1) Reimposta i log binari utilizzando RESET MASTER su mysql57a, quindi non è necessario specificare il file binario e il posizionamento del log in un secondo momento su mysql57b. Inoltre, rimuoviamo tutti i riferimenti GTID esistenti configurati in precedenza:

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

2) Su mysql57a, recupera il file binlog e la posizione dal file dump, mysql56a-fullbackup.sql:

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

3) Avvia la replica slave dal vecchio master, mysql56a al nuovo master mysql57a, specificando i valori MASTER_LOG_FILE e MASTER_LOG_POS corretti recuperati nel passaggio precedente. Su 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

Assicurati di vedere le seguenti righe:

             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes

Probabilmente devi aspettare che mysql57a raggiunga mysql56a monitorando "Seconds_Behind_Master" e assicurandoti che diventi 0.

4) A questo punto, mysql57a sta replicando i dati da mysql56a, il che significa che tutti gli utenti creati da ClusterControl sono ora mancanti dal server (perché mysql57a ora sta seguendo i dati su mysql56a). ClusterControl avrà un problema per connettersi a mysql57a e apparirà come "inattivo". Fondamentalmente significa che ClusterControl non è in grado di connettersi ai server MySQL perché mancano le sovvenzioni. Gli utenti scomparsi sono:

[email protected]
[email protected]'{tutti i nodi in un cluster particolare}'
[email protected]'{ClusterControl host}'

Tutte le credenziali sono archiviate in modo sicuro in ClusterControl e nel server di database stesso. È necessario disporre dell'accesso root per recuperare le credenziali dai file pertinenti.

Ora, ricreiamo gli utenti mancanti sul nuovo master, mysql57a:

a) Crea utente di backup (password presa da /etc/mysql/secrets-backup.cnf su 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) Creare utenti di replica, per tutti gli host DB (password presa dalla variabile repl_password all'interno di /etc/cmon.d/cmon_X.cnf sul server ClusterControl, dove X è l'ID cluster del cluster slave):

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) Creare due utenti del database cmon (uno per l'indirizzo IP e uno per il nome host) per l'utilizzo di ClusterControl (password presa dalla variabile mysql_password all'interno di /etc/cmon.d/cmon_X.cnf sul server ClusterControl, dove X è l'ID del cluster dello slave grappolo):

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) A questo punto, mysql57a dovrebbe apparire verde in ClusterControl. Ora possiamo impostare un collegamento di replica da mysql57a a mysql57b. Su 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

**Non è necessario specificare MASTER_LOG_FILE e MASTER_LOG_POS perché inizierà sempre con una posizione iniziale fissa dopo RESET MASTER al passaggio #1.

Assicurati di vedere le seguenti righe:

             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes

Controlla lo stato della replica e assicurati che mysql57b stia al passo con mysql57a e mysql57a stia al passo con mysql56a. Potrebbe essere necessario abilitare la sola lettura su mysql57b (e/o mysql57a) in seguito, per proteggersi da scritture accidentali.

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

Dall'interfaccia utente di ClusterControl, puoi vedere lo stato corrente nella sezione Panoramica:

A questo punto, il nuovo master mysql57a, 192.168.10.31 sta replicando da il vecchio host autonomo mysql56a, 192.168.10.22, mentre il nuovo slave mysql57b (sola lettura) sta replicando da mysql57a, 192.168.10.31. Tutti i nodi vengono sincronizzati con il ritardo di replica 0.

In alternativa, puoi commentare le seguenti righe all'interno dei file di configurazione di MySQL nella sezione [mysqld]:

#gtid_mode=ON
#enforce_gtid_consistency=1

Abilitazione GTID sul cluster slave

Si noti che per MySQL 5.6 e versioni successive, ClusterControl non supporta più l'implementazione non GTID su alcune delle sue funzionalità di gestione come Rebuild Replication Slave e Change Replication Master. Quindi, durante il tempo di interruzione (quando punti le applicazioni al nuovo cluster) dal server MySQL autonomo (mysql56a), si consiglia di riattivare GTID su mysql57a e mysql57b con i seguenti passaggi:

1) Assicurati di disattivare la funzione di ripristino automatico di ClusterControl:

2) Durante la finestra di manutenzione del cut-off, dobbiamo interrompere la replica dal vecchio master, mysql56a, rimuovi tutta la configurazione slave su mysql57a e abilita il GTID indietro. Su mysql57a, esegui i seguenti comandi nell'ordine corretto:

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';

A questo punto, è praticamente sicuro che la tua applicazione inizi a scrivere al nuovo master, mysql57a. Il vecchio MySQL autonomo è ora fuori dalla catena di replica e può essere spento.

3) Ripetere gli stessi passaggi per mysql57b. Ricorda di seguire i passaggi nell'ordine corretto:

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) Quindi, ripristina il master sul nuovo master, mysql57a:

mysql> RESET MASTER;

3) Quindi sul nuovo slave, mysql57b imposta il collegamento di replica utilizzando GTID su 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

Assicurati di vedere che i campi Retrieved_Gtid_Set ed Executed_Gtid_Set hanno il suo valore GTID.

4) A questo punto, abbiamo ripristinato la configurazione di replica come precedentemente configurata da ClusterControl durante la fase di distribuzione del cluster. Possiamo quindi abilitare la sola lettura sul nuovo slave, mysql57b per proteggerlo da scritture accidentali:

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

Infine, riattiva il ripristino automatico di ClusterControl per il cluster, portando le icone di alimentazione in verde. È quindi possibile disattivare il vecchio master, mysql56a. Abbiamo appena completato la nostra migrazione online da MySQL 5.6 a MySQL 5.7 con tempi di inattività minimi. I passaggi simili dovrebbero funzionare anche per la migrazione a MySQL 8.0.