Suite de l’épisode précédent … Cette fois nous voulons migrer notre socle Debian 10 / MariaDB 10.3 / Galera-3 vers le socle Debian 11 / MariaDB 10.5 / Galera-4, avec un minimum de temps d’indisponibilité. Nous pouvons le faire en mettant en place une réplication standard MySQL entre les 2 clusters, pour les maintenir synchronisés jusqu’à la date de bascule sur le nouvel environnement.
| Disclaimer : attention on va simplement montrer le principe de superposer une réplication logique par dessus une réplication synchrone Galera, pour maintenir en phase deux clusters disjoints. On utilisera directement les IP plutôt que des noms DNS, etc… le but n’est pas de faire une procédure de migration nette et sans bavures, mais bien de démontrer un concept pour montrer que c’est possible. Donc à adapter selon vos besoins et contraintes… |
La cible attendue :
…et ma config LXC au départ :
root@ubuntu20:~# lxc list +----------+---------+-----------------------+-----------------------------------------------+-----------+-----------+ | NAME | STATE | IPV4 | IPV6 | TYPE | SNAPSHOTS | +----------+---------+-----------------------+-----------------------------------------------+-----------+-----------+ | galera1 | RUNNING | 10.186.157.38 (eth0) | fd42:a4e7:fd78:5160:216:3eff:fe16:1ebf (eth0) | CONTAINER | 0 | +----------+---------+-----------------------+-----------------------------------------------+-----------+-----------+ | galera2 | RUNNING | 10.186.157.242 (eth0) | fd42:a4e7:fd78:5160:216:3eff:fee3:1939 (eth0) | CONTAINER | 0 | +----------+---------+-----------------------+-----------------------------------------------+-----------+-----------+ | galera3 | RUNNING | 10.186.157.196 (eth0) | fd42:a4e7:fd78:5160:216:3eff:fe4f:893e (eth0) | CONTAINER | 0 | +----------+---------+-----------------------+-----------------------------------------------+-----------+-----------+ | galera4 | RUNNING | 10.186.157.206 (eth0) | fd42:a4e7:fd78:5160:216:3eff:fe0d:ef85 (eth0) | CONTAINER | 0 | +----------+---------+-----------------------+-----------------------------------------------+-----------+-----------+ | galera5 | RUNNING | 10.186.157.207 (eth0) | fd42:a4e7:fd78:5160:216:3eff:fe9c:5a7c (eth0) | CONTAINER | 0 | +----------+---------+-----------------------+-----------------------------------------------+-----------+-----------+ | galera6 | RUNNING | 10.186.157.208 (eth0) | fd42:a4e7:fd78:5160:216:3eff:fe22:ab44 (eth0) | CONTAINER | 0 | +----------+---------+-----------------------+-----------------------------------------------+-----------+-----------+ | galerarb | STOPPED | | | CONTAINER | 0 | +----------+---------+-----------------------+-----------------------------------------------+-----------+-----------+
Nous partons du principe que nous avons déjà configuré un cluster vierge en MariaDB 10.5/Galera-4. Il faudra penser à affecter des @@server_id différents pour les 3 noeuds cible, qui pourront être redémarrés un à un.
Autre remarque, nous n’utiliserons pas l’arbitre dans ce type de migration. A noter qu’un arbitre serait nécessaire dans le cas d’un rolling upgrade in-place en migrant les noeuds un par un, mais il y a plusieurs contraintes, il faut suivre le chemin de migration de MariaDB (éviter de sauter de version) dans ce cas, et on n’aura pas de retour arrière si ça se passe mal une fois la migration terminée.
Création de l’utilisateur de réplication
Il sera utilisé par galera4 pour se connecter à galera1 et recopier les log binaires dans ses relaylogs locaux.
MariaDB [(none)]> create user 'repl'@'10.186.157.206' identified by '********' ; Query OK, 0 rows affected (0.009 sec) MariaDB [(none)]> grant replication slave on *.* to 'repl'@'10.186.157.206' ; Query OK, 0 rows affected (0.008 sec) MariaDB [(none)]> flush privileges ; Query OK, 0 rows affected (0.008 sec) MariaDB [(none)]> show grants for 'repl'@'10.186.157.206' ; +------------------------------------------------------------------------------------------------------------------------------+ | Grants for repl@10.186.157.206 | +------------------------------------------------------------------------------------------------------------------------------+ | GRANT REPLICATION SLAVE ON *.* TO `repl`@`10.186.157.206` IDENTIFIED BY PASSWORD '*64ABE8A05EC109FED93AF1865B498359DC3B80E8' | +------------------------------------------------------------------------------------------------------------------------------+ 1 row in set (0.002 sec)
Eventuellement un test de connexion depuis galera4 pour éviter les surprises:
root@galera4:~# mysql --user=repl --host=10.186.157.38 \ --port=3306 --password --execute='select version();' Enter password: +--------------------------------------------+ | version() | +--------------------------------------------+ | 10.3.34-MariaDB-1:10.3.34+maria~buster-log | +--------------------------------------------+
OK
Synchronisation entre les 2 clusters
Evidemment ici la base sakila nous permet d’utiliser mysqldump pour faire la synchro. Nous allons injecter directement le dump dans le noeud galera4 du second cluster, le tout sera automatiquement répliqué sur les 2 autres noeuds galera5 et galera6.
root@galera1:/mariabackup# mysqldump --user=root \ --socket=/var/run/mysqld/mysqld.sock \ --password --flush-logs --single-transaction \ --master-data=2 sakila | gzip > sakila.UPGRADE-105.dmp.gz Enter password:
Puis transfert vers galera4…dans mon cas avec lxd:
root@ubuntu20:~# lxc file pull galera1/mariabackup/sakila.UPGRADE-105.dmp.gz . root@ubuntu20:~# lxc file push sakila.UPGRADE-105.dmp.gz galera4/mariabackup/sakila.UPGRADE-105.dmp.gz
A noter que je choisis ici de ne sauvegarder que la base sakila. Je n’ai pas d’autre base métier sur mon cluster en 10.3. S’il y en avait d’autres, il faudrait les ajouter dans le dump.
On n’utilisera pas non plus un binlog_do_db / replicate_do_db pour filtrer en amont ou en aval dans les binlogs, car en raison de l’ambigüité liée au contexte de la mise à jour, on ne veut pas prendre le risque de rater une mise à jour qui ne se ferait pas dans le contexte de la base. Peut être un article bientôt pour expliquer ce phénomène…
Avant de recharger, on va noter le binlog et la position qui ont été renseignées au début du dump. En mettant 2 à –master-data, la commande reste en commentaires dans le dump, on choisit de l’appliquer une fois le dump intégré:
root@galera4:/mariabackup# gzip -d sakila.UPGRADE-105.dmp.gz root@galera4:/mariabackup# grep -i "change master" sakila.UPGRADE-105.dmp -- CHANGE MASTER TO MASTER_LOG_FILE='mariadb-bin.000051', MASTER_LOG_POS=389;
OK nous n’avons pas demandé à mysqldump de préciser l’ordre de création de la base, donc il faut la recréer à la main, et charger le backup. En fonction de la taille de celui-ci, cela peut prendre un certain temps:
MariaDB [(none)]> create database sakila ; Query OK, 1 row affected (0.013 sec)
root@galera4:/mariabackup# time mysql sakila < sakila.UPGRADE-105.dmp real 0m4.861s user 0m0.188s sys 0m0.033s
Enfin on passe le CHANGE MASTER TO et on peut démarrer les slaves :
MariaDB [(none)]> CHANGE MASTER TO
-> MASTER_HOST="10.186.157.38",
-> MASTER_PORT=3306,
-> MASTER_USER="repl",
-> MASTER_PASSWORD="******",
-> MASTER_LOG_FILE="mariadb-bin.000051",
-> MASTER_LOG_POS=389;
MariaDB [(none)]> start slave;
Query OK, 0 rows affected (0.001 sec)
MariaDB [(none)]> show slave status \G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 10.186.157.38
Master_User: repl
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mariadb-bin.000051
Read_Master_Log_Pos: 734
Relay_Log_File: mysqld-relay-bin.000002
Relay_Log_Pos: 902
Relay_Master_Log_File: mariadb-bin.000051
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 734
Relay_Log_Space: 1212
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Master_Server_Id: 1
Master_SSL_Crl:
Master_SSL_Crlpath:
Using_Gtid: No
Gtid_IO_Pos:
Replicate_Do_Domain_Ids:
Replicate_Ignore_Domain_Ids:
Parallel_Mode: optimistic
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates
Slave_DDL_Groups: 1
Slave_Non_Transactional_Groups: 0
Slave_Transactional_Groups: 1
1 row in set (0.000 sec)
OK tout est bon à priori. On peut injecter un peu de données depuis galera1 pour valider le bon fonctionnement de la réplication sur les autres noeuds du nouveau cluster :
MariaDB [(none)]> use sakila ; Reading table information for completion of table and column names You can turn off this feature to get a quicker startup with -A Database changed MariaDB [sakila]> create table test(a int); Query OK, 0 rows affected (0.015 sec) MariaDB [sakila]> insert into test values (1) ; Query OK, 1 row affected (0.006 sec)
Et vérifier sur les 3 noeuds en 10.5:
-- Sur galera4, 5 ou 6
root@ubuntu20:~# for srv in galera4 galera5 galera6
> do
> lxc exec ${srv} -- mysql --execute="select * from sakila.test ;"
> done
+------+
| a |
+------+
| 1 |
+------+
+------+
| a |
+------+
| 1 |
+------+
+------+
| a |
+------+
| 1 |
+------+
Donc à partir de là, nous avons deux clusters différents qui sont maintenus synchrones l’un avec l’autre, noter qu’il n’y a eu besoin d’aucune interruption de service (je n’ai pas changé le @@server_id sur galera1) pour mettre en place la réplication.
La bascule sur la nouvelle version consistera donc à simplement stopper les applications, laisser les transactions se répliquer sur le cluster en 10.5, et une fois le master et le slave en phase, stopper les slaves et basculer les applications sur le nouveau cluster.
Bon week-end à toutes et tous !
~David
Continuez votre lecture sur le blog :
- Restauration point-in-time avec MariaDB Galera Cluster et mariabackup (David Baffaleuf) [MySQL]
- Réplication MySQL : Resynchronisation d’un Slave MySQL (Capdata team) [MySQL]
- default_password_lifetime à 360 jours entre la 5.7.4 et 5.7.10 (David Baffaleuf) [MySQL]
- Comparatif des gestionnaires de VIP dans un cluster Patroni : épisode 1 (KEEPALIVED) (David Baffaleuf) [ContainerPostgreSQL]
- Migration PostgreSQL via SLONY-I ou comment réduire le temps de coupure (Capdata team) [PostgreSQL]