Migration en ligne de MySQL 5.6 non-GTID vers MySQL 5.7 avec GTID

Dans cet article de blog, nous allons examiner comment effectuer une migration en ligne de la configuration autonome de MySQL 5.6 vers un nouvel ensemble de réplication fonctionnant sur MySQL 5.7, déployé et géré par ClusterControl.

Le plan consiste à configurer un lien de réplication du nouveau cluster s'exécutant sur MySQL 5.7 vers le maître s'exécutant sur MySQL 5.6 (en dehors de la fourniture ClusterControl), qui n'utilise aucun GTID. MySQL ne prend pas en charge le mélange GTID et non-GTID dans une chaîne de réplication. Nous devons donc faire quelques astuces pour basculer entre les modes non-GTID et GTID pendant la migration.

Notre architecture et notre plan de migration peuvent être illustrés ci-dessous :

L'installation se compose de 4 serveurs, avec la représentation suivante :

mysql56a - Ancien maître - Oracle MySQL 5.6 sans GTID
Cluster esclave :
- mysql57a - Nouveau maître - Oracle MySQL 5.7 avec GTID
- mysql57b - Nouvel esclave - Oracle MySQL 5.7 avec GTID
cc - ClusterControl Server - Serveur de déploiement/gestion/surveillance des nœuds de la base de données.

Tous les hôtes MySQL 5.7 fonctionnent sur Debian 10 (Buster), tandis que MySQL 5.6 fonctionne sur Debian 9 (Stretch).

Déploiement du cluster esclave

Tout d'abord, préparons le cluster esclave avant de configurer un lien de réplication à partir de l'ancien maître. La configuration finale du cluster esclave s'exécutera sur MySQL 5.7, avec GTID activé. Installez ClusterControl sur le serveur ClusterControl (cc) :

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

Suivez les instructions jusqu'à ce que l'installation soit terminée. Ensuite, configurez SSH sans mot de passe de ClusterControl vers mysql57a et 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

Ensuite, connectez-vous à l'interface utilisateur de ClusterControl, remplissez le formulaire initial et accédez à la section ClusterControl -> Deploy -> MySQL Replication et remplissez ce qui suit :

Ensuite, cliquez sur Continuer et choisissez Oracle comme fournisseur et 5.7 comme fournisseur version. Passez ensuite à la section topologie et configurez-la comme ci-dessous :

Attendez que le déploiement se termine et vous devriez voir le nouveau cluster comme ci-dessous :

Notre cluster esclave fonctionnant sur MySQL 5.7 avec GTID est maintenant prêt.

Préparer le Vieux Maître

Le maître actuel que nous voulons répliquer est un MySQL 5.6 autonome (journaux binaires activés, ID de serveur configuré, sans GTID) et il dessert les bases de données de production. Les temps d'arrêt ne sont donc pas une option pour cette migration. D'autre part, ClusterControl configure le nouveau MySQL 5.7 avec le GTID activé, ce qui signifie que nous devons désactiver la fonctionnalité GTID à l'intérieur du cluster esclave pour pouvoir répliquer correctement à partir de ce maître autonome.

Les lignes suivantes montrent notre configuration actuelle liée à la réplication pour le maître /etc/mysql/mysql.conf.d/mysqld.cnf sous la directive [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

Vérifiez que le serveur MySQL produit un journal binaire, sans 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)

Pour les non-GTID, l'Executed_Gtid_Set devrait être vide. Notez que notre nouveau cluster de réplication MySQL 5.7 déployé par ClusterControl est configuré avec GTID activé.

1) Créez un utilisateur de réplication à utiliser par mysql57a :

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

2) Désactivez la récupération automatique de ClusterControl. Sous ClusterControl UI -> choisissez le cluster -> assurez-vous que le cluster et le nœud de récupération automatique sont désactivés (icônes d'alimentation rouges), comme indiqué dans la capture d'écran ci-dessous :

Nous ne voulons pas que ClusterControl récupère le nœud pendant cette configuration de réplication.

3) Nous devons maintenant créer une sauvegarde mysqldump complète car il s'agira d'une mise à jour majeure de la version. D'autres outils de sauvegarde non bloquants comme Percona Xtrabackup ou MySQL Enterprise Backup ne prennent pas en charge la restauration vers une version majeure différente. Nous devons également conserver le fichier journal binaire actuel et sa position à l'aide de l'indicateur --master-data :

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

Notez que la commande ci-dessus ne bloquera aucune table InnoDB à cause de --single-transaction. Donc si vous avez des tables MyISAM, les tables seront bloquées pendant la période des sauvegardes pour maintenir la cohérence.

4) Copiez la sauvegarde de mysql56a vers mysql57a et mysql57b :

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

Préparation du cluster esclave

À cette phase, nous allons configurer le cluster esclave pour commencer la réplication à partir de l'ancien maître, mysql56a sans GTID.

1) Arrêtez la réplication entre mysql57a et mysql57b, supprimez toutes les informations d'identification liées aux esclaves configurées par ClusterControl et désactivez la lecture seule sur mysql57b :

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

2) Désactiver GTID sur 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) Désactiver GTID sur 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) Restaurez la sauvegarde mysqldump sur mysql57a :

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

5) Restaurez la sauvegarde mysqldump sur mysql57b :

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

6) Exécutez le script de mise à jour MySQL sur mysql57a (pour vérifier et mettre à jour toutes les tables vers la version actuelle) :

$ mysql_upgrade -uroot -p

7) Exécutez le script de mise à niveau MySQL sur mysql57b (pour vérifier et mettre à jour toutes les tables vers la version actuelle) :

$ mysql_upgrade -uroot -p

Les deux serveurs du cluster esclave sont maintenant mis en scène avec l'instantané de données de l'ancien maître, mysql56a, et sont maintenant prêts à être répliqués.

Configuration de la réplication pour le cluster esclave

1) Réinitialisez les journaux binaires à l'aide de RESET MASTER sur mysql57a, nous n'avons donc pas à spécifier le fichier binaire et le positionnement des journaux ultérieurement sur mysql57b. De plus, nous supprimons toutes les références GTID existantes qui ont été configurées auparavant :

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

2) Sur mysql57a, récupérez le fichier binlog et sa position depuis le fichier de vidage, mysql56a-fullbackup.sql :

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

3) Démarrez la réplication esclave de l'ancien maître, mysql56a vers le nouveau maître mysql57a, en spécifiant les valeurs correctes MASTER_LOG_FILE et MASTER_LOG_POS récupérées à l'étape précédente. Sur 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

Assurez-vous de voir les lignes suivantes :

             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes

Vous devrez probablement attendre que mysql57a rattrape mysql56a en surveillant le "Seconds_Behind_Master" et en vous assurant qu'il passe à 0.

4) À ce stade, mysql57a réplique les données de mysql56a, ce qui signifie que tous les utilisateurs créés par ClusterControl sont maintenant absents du serveur (car mysql57a suit maintenant les données sur mysql56a). ClusterControl aura un problème pour se connecter à mysql57a et il apparaîtra comme "down". Cela signifie essentiellement que ClusterControl ne peut pas se connecter aux serveurs MySQL car les autorisations sont manquantes. Les utilisateurs manquants sont :

[email protected]
[email protected]'{tous les nœuds d'un cluster particulier}'
[email protected]'{Hôte ClusterControl}'

Toutes les informations d'identification sont stockées en toute sécurité dans le ClusterControl et le serveur de base de données lui-même. Vous devez disposer d'un accès root pour récupérer les informations d'identification à partir des fichiers concernés.

Maintenant, recréons les utilisateurs manquants sur le nouveau maître, mysql57a :

a) Créer un utilisateur de sauvegarde (mot de passe extrait de /etc/mysql/secrets-backup.cnf sur 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) Créez des utilisateurs de réplication, pour tous les hôtes de base de données (mot de passe extrait de la variable repl_password dans /etc/cmon.d/cmon_X.cnf sur le serveur ClusterControl, où X est l'ID de cluster du cluster esclave) :

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) Créez deux utilisateurs de base de données cmon (un pour l'adresse IP et un pour le nom d'hôte) pour l'utilisation de ClusterControl (mot de passe tiré de la variable mysql_password dans /etc/cmon.d/cmon_X.cnf sur le serveur ClusterControl, où X est l'ID de cluster de l'esclave 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) À ce stade, mysql57a devrait apparaître en vert dans ClusterControl. Maintenant, nous pouvons configurer un lien de réplication de mysql57a vers mysql57b. Sur 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

**Nous n'avons pas besoin de spécifier MASTER_LOG_FILE et MASTER_LOG_POS car il commencera toujours par une position initiale fixe après RESET MASTER à l'étape 1.

Assurez-vous de voir les lignes suivantes :

             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes

Surveillez l'état de la réplication et assurez-vous que mysql57b suit mysql57a, et mysql57a suit mysql56a. Vous devrez peut-être activer la lecture seule sur mysql57b (et/ou mysql57a) après cela, pour vous protéger contre les écritures accidentelles.

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

Depuis l'interface utilisateur de ClusterControl, vous voyez l'état actuel dans la section Présentation :

À ce stade, le nouveau maître mysql57a, 192.168.10.31 se réplique à partir de l'ancien hôte autonome mysql56a, 192.168.10.22, tandis que le nouvel esclave mysql57b (lecture seule) se réplique à partir de mysql57a, 192.168.10.31. Tous les nœuds sont synchronisés avec le décalage de réplication 0.

Alternativement, vous pouvez commenter les lignes suivantes dans les fichiers de configuration MySQL sous la section [mysqld] :

#gtid_mode=ON
#enforce_gtid_consistency=1

Activer GTID sur le cluster esclave

Notez que pour MySQL 5.6 et versions ultérieures, ClusterControl ne prend plus en charge l'implémentation non-GTID sur certaines de ses fonctionnalités de gestion telles que Rebuild Replication Slave et Change Replication Master. Ainsi, pendant l'heure limite (lorsque vous pointez des applications vers le nouveau cluster) depuis le serveur MySQL autonome (mysql56a), il est recommandé de réactiver GTID sur mysql57a et mysql57b en procédant comme suit :

1) Assurez-vous de désactiver la fonctionnalité de récupération automatique de ClusterControl :

2) Pendant la fenêtre de maintenance de coupure, nous devons arrêter la réplication de l'ancien maître, mysql56a, supprimez toute la configuration esclave sur mysql57a et réactivez le GTID. Sur mysql57a, exécutez les commandes suivantes dans le bon ordre :

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

À ce stade, il est pratiquement sûr pour votre application de commencer à écrire sur le nouveau maître, mysql57a. L'ancien MySQL autonome est maintenant hors de la chaîne de réplication et peut être arrêté.

3) Répétez les mêmes étapes pour mysql57b. N'oubliez pas de suivre les étapes dans le bon ordre :

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) Ensuite, réinitialisez le maître sur le nouveau maître, mysql57a :

mysql> RESET MASTER;

3) Ensuite, sur le nouvel esclave, mysql57b configure le lien de réplication en utilisant GTID vers 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

Assurez-vous que les champs Retrieved_Gtid_Set et Executed_Gtid_Set ont leur valeur GTID.

4) À ce stade, nous avons restauré la configuration de réplication telle qu'elle avait été configurée précédemment par ClusterControl lors de l'étape de déploiement du cluster. Nous pouvons alors activer la lecture seule sur le nouvel esclave, mysql57b pour le protéger contre les écritures accidentelles :

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

Enfin, réactivez la récupération automatique de ClusterControl pour le cluster, en faisant passer les icônes d'alimentation au vert. Vous pouvez ensuite désactiver l'ancien maître, mysql56a. Nous venons de terminer notre migration en ligne de MySQL 5.6 vers MySQL 5.7 avec un temps d'arrêt très minime. Les étapes similaires devraient également fonctionner pour la migration vers MySQL 8.0.