Mysql migration master slave

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 5.7 --> 8.0
En avance de phase :
- merge config prod et preprod mysql8 - FAIT
- stopper les mysqls sur mysqlprod1b et mysqlprod2b si ils fonctionnent
- preparer les fichiers de config réseau pour les IP de service
- rsync du dossier data mysql vers mysqlprod1b et mysqlprod2b


Phase de migration :
- mettre le site en maintenance si il y a une méthode de définie
- supprimer la VIP 192.168.35.241 sur mysqlprod2 (master)
- supprimer la VIP 192.168.35.194 sur mysqlprod1 (slave)
- executer : SET GLOBAL innodb_fast_shutdown = 0; sur mysqlprod2 et mysqlprod1
- Stopper mysql sur mysqlprod2 puis mysqlprod1
- sur mysqlprod2B (futur master)
  * rsync de /var/lib/mysql depuis mysqlprod2 (ancien master) vers le futur master 
  * 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)
  * Démarrer le service mysqld
                
- sur mysqlprod1B (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)