Et oui, c’est maintenant la fin de mysql_upgrade à partir de la version de MySQL 8.0.16 !!!
Une mise à jour de MySQL se fait en 2 étapes sur l’installation existante :
- la mise à jour du dictionnaire de données : les tables du dictionnaire de données dans le schéma mysql et le schéma performance ainsi qu’information_schema.
- la mise à jour au niveau du serveur : les tables systèmes restantes du dictionnaire de données dans le schéma mysql, le schéma sys et les schémas utilisateur.
Cependant, avant la version 8.0.16, nous étions obligés de lancer le client mysql_upgrade pour qu’il envoie les requêtes de mise à jour de tables systèmes et utilisateurs au serveur à exécuter.
“Le changement, c’est maintenant” car depuis la version 8.0.16, les binaires mysqld se chargent entièrement de la procédure de migration si celle-ci est nécessaire et ne dépend plus de la commande mysql_upgrade.
mysql_upgrade devient donc obsolète à partir de cette version 8.0.16 et sera supprimé dans les prochaines versions de MySQL.
Depuis MySQL 8.0.16, pour mettre à jour votre version, cela se passe en 2 étapes :
- arrêt du serveur avec installation des nouveaux binaires
- démarrage du serveur MySQL qui se chargera de la mise à jour des tables du dictionnaire de données et des tables systèmes, help et utilisateurs si besoin est.
La mise à jour des tables systèmes, help et utilisateurs font entièrement partie du processus “mise à jour serveur” et est le nouveau changement en 8.0.16 qui remplace mysql_upgrade.
Le temps de mise à jour sera donc plus court car on a une étape en moins qui était de lancer le client mysql_upgrade. Si des tables utilisateurs ne sont pas mises à jour, un gain de temps en plus sera récupéré.
Pour ma part, j’ai fait 2 tests de mise à jour de mon serveur MySQL 8.0.14 sur Windows 7 :
- 1er test : mise à jour de 8.0.14 à 8.0.16 avec l’utilitaire MySQL Installer – Community sur Windows.
- 2ème tests : mise à jour de 8.0.16 à 8.0.17 en installant les derniers binaires et en démarrant mon serveur MySQL.
J’ai pu constater lors de mon deuxième test que le service MySQL80 a mis un peu plus de temps que d’habitude à démarrer car il mettait à jour les différentes tables nécessaires en 8.0.17
Bien sûr, si l’on ne veut pas que les choses changent, il existe 4 valeurs possibles sur la nouvelle option –upgrade :
- NONE : aucune mise à jour n’est faite et si une mise à jour est requise, celle-ci sera annulée par le serveur. La nouvelle version n’est pas autorisée à démarrer.
- AUTO : valeur par défaut qui va obliger le serveur à faire tant la mise à jour du dictionnaire de données que celle du serveur.
- MINIMAL : va tenter uniquement la mise à jour du dictionnaire de données et pas celle du serveur lors de son démarrage. Cela correspond à comme avant la version 8.0.16 et il faut maintenant redémarrer le serveur sans aucune option de mise à jour afin de mettre à jour le partie serveur.
- FORCE : va tenter une mise à jour du serveur même si celui-ci est déjà mis à jour et cela correspond à la même utilisation du client mysql_upgrade avec l’option -force.
Donc, à chaque démarrage du serveur, une mise à jour est tentée si celle-ci est nécessaire sauf si l’option –upgrade = NONE ou MINIMAL est utilisée.
Cette suppression de l’utilisation du client mysql_upgrade nous permet donc de faire :
- un processus de mise à jour plus simple et plus rapide
- moins d’étapes dans le processus et donc facilement automatisable
- moins de temps d’indisponibilité car pas de redémarrage
A bientôt pour de nouveaux articles sur le Blog Capdata !
Erwan Ollitrault
Continuez votre lecture sur le blog :
- Nouveautés MySQL 8.0 : Configuration automatique de variables avec innodb_dedicated_server (Capdata team) [MySQL]
- Nouveautés MySQL 8.0 : Variables persistés (Capdata team) [MySQL]
- Abonnez-vous au blog de la CapData team ! (Benjamin VESAN) [GénéralMySQLOracleSQL ServerSybase]
- Déplacer le répertoire de données (datadir) MySQL vers un nouvel emplacement sur Debian (Capdata team) [MySQL]
- Réplication MySQL : Resynchronisation d’un Slave MySQL (Capdata team) [MySQL]