Mysql migration master slave

De BlaxWiki
Révision datée du 16 juillet 2021 à 07:29 par 127.0.0.1 (discussion)
Aller à la navigationAller à la recherche

Nous avons un mysql master / slave en 5.7, le but est de migrer ce master / slave sur un nouveau master / slave mysql en 8.0


##### Migration serveur MYSQL 7 --> 8.0
mysqlprod1 (ancien master) et mysqlprod2 (ancien slave)
mysqlprod1b (new master) et mysqlprod2b (new slave)

Phase de migration :

- executer : SET GLOBAL innodb_fast_shutdown = 0; sur mysqlprod1 et mysqlprod2
- Stopper mysql sur mysqlprod1 puis mysqlprod1
- sur mysqlprod1B (futur master)
  * rsync de /var/lib/mysql depuis mysqlprod1 (ancien master) vers le futur master :   rsync -e ssh -av --delete root@192.168.35.193:/var/lib/mysql/ /var/lib/mysql 
  * supprimer le fichier /var/lib/mysql/auto.cnf
  * Démarrer le service mysqld
  * Vérifier dans les logs/journalctl que le processus automatique d'upgrade s'est bien déroulé et qu'il n'y a pas d'erreur critique
  * si tout est OK, ouvrir une nouvelle session ssh et se connecter a mysql et faire :
    SET SESSION interactive_timeout = 600  
    RESET MASTER;
    FLUSH TABLES WITH READ LOCK;
    SHOW MASTER STATUS;
                sans fermer cette session, stopper le service mysqld
  * rsync de /var/lib/mysql depuis mysqlprod2B (futur master) vers mysqlprod1B (futur slave) :  rsync -e ssh -av --delete /var/lib/mysql root@192.168.35.228:/var/lib/mysql/
  * Démarrer le service mysqld
                
- sur mysqlprod2B (futur slave)
  * supprimer le fichier /var/lib/mysql/auto.cnf
  * Démarrer le service mysqld
  * Vérifier dans les logs/journalctl qu'il n'y a pas d'erreur critique
  * Ouvrir une session mysql et faire les commandes suivantes avec les valeurs récupérée précédement sur le futur master  :
    CHANGE MASTER TO MASTER_HOST='192.168.35.229', MASTER_USER='user-repl', MASTER_PASSWORD='<<MOT DE PASSE>>', MASTER_LOG_FILE='<<VALEUR RECUPEREE>>', MASTER_LOG_POS=<<VALEUR RECUPEREE>>; 
    START SLAVE; 
  * Vérifier que la réplication fonctionne bien avec : SHOW SLAVE STATUS\G

- si tout semble OK sur les 2 serveurs :
- mettre en place la VIP 192.168.35.241 sur mysqlprod2b (nouveau master)
- mettre en place la VIP 192.168.35.194 sur mysqlprod1b (nouveau slave)

##### Rollback rapide si aucune donnée importante n'a été écrite sur les nouveaux serveurs
# Principalement dans le cas de problème pour la mise en place des nouveaux serveurs
- Remettre la VIP 192.168.35.241 sur mysqlprod2 (master)
- Remettre la VIP 192.168.35.194 sur mysqlprod1 (slave)
- Démarrer le service mysqld sur mysqlprod2 et mysqlprod1

##### Rollback en réimportant les données mysql8.0 vers les anciens serveurs
# D'après la documentation MySQL il n'y a pas de solution supportée de downgrade de MySQL8.0 vers 5.7, cependant un export des bases non-systèmes de mysql8.0 et un import dans mysql5.7 ne devrait pas poser de problème
# Un export/import peut prendre longtemps (on rejoue les INSERT pour chaque ligne de chaque table).
# La méthode est déconseillée si on veut remettre rapidement le site en état de marche, il faut plutot essayer de résoudre le problème
# Il faudra définir les bases importantes pour le client. (que thiriet_internet_v4?)
- Faire un mysqldump de la base de données sur mysqlprod2b (nouveau master)
- Démarrer mysqld sur mysqlprod2 (ancien master) et mysqlprod1 (ancien slave)
- Restaurer le dump sur mysqlprod2 (ancien master)
- Remettre la VIP 192.168.35.241 sur mysqlprod2 (master)
- Remettre la VIP 192.168.35.194 sur mysqlprod1 (slave)