MySQL 8.0 est déjà avec nous depuis un certain temps et de nombreux utilisateurs de MySQL ont déjà mis à niveau vers cette version. Pour ceux qui utilisent encore des versions plus anciennes de MySQL, nous aimerions présenter ce blog où nous partagerons quelques conseils et informations qui vous aideront dans le processus de mise à niveau vers MySQL 8.0.
Attention à votre version
Les versions logicielles sont très importantes dans le processus de mise à niveau. Pour commencer, une seule différence de version majeure est prise en charge. Vous devez exécuter MySQL 5.7 avant de pouvoir passer à MySQL 8.0. Ceci est très important à garder à l'esprit étant donné que MySQL 5.6 approche de sa fin de vie et qu'il ne sera plus pris en charge. Pour tous ceux d'entre vous qui utilisent MySQL 5.6, vous devez d'abord vous assurer de le mettre à niveau vers MySQL 5.7, puis, éventuellement, vers MySQL 8.0.
Il est fortement recommandé de mettre à niveau vers la dernière version disponible pour MySQL 5.7. Au moment de la rédaction de ce blog, c'était le 5.7.31, mais cela finira par changer, vous pouvez toujours le rechercher sur le site Web de MySQL.
Veuillez également noter que les mises à niveau à partir de versions non GA (et vers des versions non GA) ne sont pas prises en charge. Non pas qu'il soit logique d'exécuter des versions non GA en production, mais nous voulions également clarifier celle-ci.
C'est un aller simple
Chaque fois que vous décidez d'effectuer la mise à niveau, sachez qu'une fois la mise à niveau terminée, vous ne pourrez plus revenir en arrière. Les modifications ne sont pas compatibles et vous ne pouvez tout simplement pas utiliser le répertoire de données de MySQL 8.0 sur MySQL 5.7. Assurez-vous d'effectuer une sauvegarde de vos données MySQL 5.7 juste avant la mise à niveau - vous pourrez les restaurer sur l'instance MySQL 5.7 si vous devez annuler la modification. Veuillez également garder à l'esprit, car cela peut surprendre, que la mise à niveau de MySQL 8.0.x vers MySQL 8.0.x + 1 peut également ne pas être compatible et, même s'il s'agit d'une mise à niveau de version mineure, vous ne devez pas vous attendre à ce rétrogradation serait possible. C'est le résultat du cycle de déploiement d'Oracle - au lieu de geler les fonctionnalités pour la dernière branche GA, comme c'était le cas avec les versions précédentes, de nouvelles fonctionnalités, parfois incompatibles, sont poussées en tant que nouvelles versions de la branche 8.0.
La mise à niveau sur place est un Go
Dans le passé, il n'était pas toujours possible d'effectuer une mise à niveau sur place de MySQL. Dans certains cas, vous avez été obligé de vider les données au format SQL, puis de les recharger dans la nouvelle version. Heureusement, MySQL 8.0 est plus convivial pour les administrateurs et la mise à niveau sur place est prise en charge. Tout ce que vous avez à faire est d'exécuter apt upgrade ou yum update et vous êtes prêt. La mise à niveau est encore plus pratique - dans le passé, il fallait garder à l'esprit d'exécuter mysql_upgrade pour s'assurer que toutes les tables système sont correctement mises à niveau au format requis par la nouvelle version de MySQL. Dans MySQL 8.0, à partir de MySQL 8.0.16, cela n'est plus nécessaire - tout ce que vous avez à faire est de démarrer le processus MySQL, mysqld, et, par défaut, la mise à niveau sera effectuée sur le dictionnaire de données et d'autres schémas système chaque fois qu'il est jugée nécessaire. Il est possible de modifier ce comportement en passant différents paramètres à l'option serveur --upgrade mais dans la majorité des cas vous aimeriez bénéficier de cette amélioration.
Puis-je mettre à niveau en toute sécurité ?
Bien sûr, il y a des conditions préalables pour la mise à niveau en toute sécurité. Examinons quelques méthodes qui devraient vous aider à vous assurer que vous pouvez effectuer une mise à niveau vers MySQL 8.0 en toute sécurité.
Vérifications d'intégrité
Avant de tenter quoi que ce soit, vous devez vérifier que votre configuration MySQL 5.7 existante coche toutes les cases de la liste de vérification avant de passer à MySQL 8.0. La documentation MySQL présente une longue liste de choses à tester. Cela n'a pas de sens de parcourir la liste ici car elle est couverte dans la documentation MySQL, mais voici quelques points que vous voudrez peut-être garder à l'esprit.
Tout d'abord, le partitionnement n'est désormais pris en charge que dans les moteurs qui l'implémentent de leur côté, c'est-à-dire NDB et InnoDB uniquement. Assurez-vous que toutes les tables partitionnées utilisent l'un de ces moteurs de stockage ou que vous supprimez le partitionnement avant la mise à niveau.
Vous voudrez peut-être courir
mysqlcheck -u root -p --all-databases --check-upgradepour revérifier que les tableaux sont au bon format.
Il existe également d'autres vérifications que vous devez effectuer - presque chaque nouvelle version de MySQL est livrée avec une liste mise à jour de mots réservés et vous devez vérifier que vous ne les utilisez pas dans votre base de données. Vous devez vérifier les noms des contraintes de clé étrangère, ils ne peuvent pas dépasser 64 caractères. Certaines options pour sql_mode ont été supprimées, vous devez donc vous assurer de ne pas les utiliser. Comme nous l'avons mentionné, il existe une longue liste de choses à tester.
MySQL Shell à la rescousse
Tester toutes ces conditions prend beaucoup de temps, c'est pourquoi Oracle a créé une option dans MySQL Shell qui est destinée à exécuter une série de tests pour vérifier si votre installation existante peut être mise à niveau vers MySQL 8.0 en toute sécurité. Pour commencer, si vous n'avez pas installé MySQL Shell, vous devriez le faire. Vous pouvez trouver des téléchargements sur le site Web d'Oracle. Une fois que vous l'avez configuré, vous pouvez vous connecter à votre MySQL 5.7 et exécuter le test. Voyons à quoi cela peut ressembler :
[email protected]:~# mysqlsh
MySQL Shell 8.0.21
Copyright (c) 2016, 2020, Oracle and/or its affiliates. All rights reserved.
Oracle is a registered trademark of Oracle Corporation and/or its affiliates.
Other names may be trademarks of their respective owners.
Type '\help' or '\?' for help; '\quit' to exit.
MySQL JS > \c [email protected]
Creating a session to '[email protected]'
Please provide the password for '[email protected]': ****
Save password for '[email protected]'? [Y]es/[N]o/Ne[v]er (default No):
Fetching schema names for autocompletion... Press ^C to stop.
Your MySQL connection id is 71 (X protocol)
Server version: 5.7.31-log MySQL Community Server (GPL)
No default schema selected; type \use <schema> to set one.Nous nous sommes connectés à l'instance MySQL sur l'hôte local à l'aide de MySQL Shell. Nous pouvons maintenant lancer la vérification. Nous vous transmettrons le chemin d'accès au fichier de configuration pour des tests plus approfondis :
MySQL localhost:33060+ ssl JS > util.checkForServerUpgrade({"configPath":"/etc/mysql/my.cnf"})Ensuite, nous avons une longue sortie.
The MySQL server at localhost:33060, version 5.7.31-log - MySQL Community
Server (GPL), will now be checked for compatibility issues for upgrade to MySQL
8.0.21...
1) Usage of old temporal type
No issues found
2) Usage of db objects with names conflicting with new reserved keywords
No issues found
3) Usage of utf8mb3 charset
No issues found
4) Table names in the mysql schema conflicting with new tables in 8.0
No issues found
5) Partitioned tables using engines with non native partitioning
No issues found
6) Foreign key constraint names longer than 64 characters
No issues found
7) Usage of obsolete MAXDB sql_mode flag
No issues found
8) Usage of obsolete sql_mode flags
No issues found
9) ENUM/SET column definitions containing elements longer than 255 characters
No issues found
10) Usage of partitioned tables in shared tablespaces
No issues found
11) Circular directory references in tablespace data file paths
No issues found
12) Usage of removed functions
No issues found
13) Usage of removed GROUP BY ASC/DESC syntax
No issues found
14) Removed system variables for error logging to the system log configuration
No issues found
15) Removed system variables
Error: Following system variables that were detected as being used will be
removed. Please update your system to not rely on them before the upgrade.
More information:
https://dev.mysql.com/doc/refman/8.0/en/added-deprecated-removed.html#optvars-removed
log_warnings - is set and will be removed, consider using log_error_verbosity
instead
query_cache_size - is set and will be removed
query_cache_type - is set and will be removed
16) System variables with new default values
Warning: Following system variables that are not defined in your
configuration file will have new default values. Please review if you rely on
their current values and if so define them before performing upgrade.
More information:
https://mysqlserverteam.com/new-defaults-in-mysql-8-0/
back_log - default value will change
character_set_server - default value will change from latin1 to utf8mb4
collation_server - default value will change from latin1_swedish_ci to
utf8mb4_0900_ai_ci
event_scheduler - default value will change from OFF to ON
explicit_defaults_for_timestamp - default value will change from OFF to ON
innodb_flush_neighbors - default value will change from 1 (enable) to 0
(disable)
innodb_max_dirty_pages_pct - default value will change from 75 (%) 90 (%)
innodb_max_dirty_pages_pct_lwm - default value will change from_0 (%) to 10
(%)
innodb_undo_log_truncate - default value will change from OFF to ON
innodb_undo_tablespaces - default value will change from 0 to 2
log_error_verbosity - default value will change from 3 (Notes) to 2 (Warning)
max_error_count - default value will change from 64 to 1024
optimizer_trace_max_mem_size - default value will change from 16KB to 1MB
performance_schema_consumer_events_transactions_current - default value will
change from OFF to ON
performance_schema_consumer_events_transactions_history - default value will
change from OFF to ON
slave_rows_search_algorithms - default value will change from 'INDEX_SCAN,
TABLE_SCAN' to 'INDEX_SCAN, HASH_SCAN'
transaction_write_set_extraction - default value will change from OFF to
XXHASH64
17) Zero Date, Datetime, and Timestamp values
No issues found
18) Schema inconsistencies resulting from file removal or corruption
No issues found
19) Tables recognized by InnoDB that belong to a different engine
No issues found
20) Issues reported by 'check table x for upgrade' command
No issues found
21) New default authentication plugin considerations
Warning: The new default authentication plugin 'caching_sha2_password' offers
more secure password hashing than previously used 'mysql_native_password'
(and consequent improved client connection authentication). However, it also
has compatibility implications that may affect existing MySQL installations.
If your MySQL installation must serve pre-8.0 clients and you encounter
compatibility issues after upgrading, the simplest way to address those
issues is to reconfigure the server to revert to the previous default
authentication plugin (mysql_native_password). For example, use these lines
in the server option file:
[mysqld]
default_authentication_plugin=mysql_native_password
However, the setting should be viewed as temporary, not as a long term or
permanent solution, because it causes new accounts created with the setting
in effect to forego the improved authentication security.
If you are using replication please take time to understand how the
authentication plugin changes may impact you.
More information:
https://dev.mysql.com/doc/refman/8.0/en/upgrading-from-previous-series.html#upgrade-caching-sha2-password-compatibility-issues
https://dev.mysql.com/doc/refman/8.0/en/upgrading-from-previous-series.html#upgrade-caching-sha2-password-replication
Errors: 3
Warnings: 18
Notices: 0
3 errors were found. Please correct these issues before upgrading to avoid compatibility issues.Comme vous pouvez le voir, 21 tests au total ont été effectués, la vérification a trouvé 3 erreurs liées aux options de configuration qui n'existeront pas dans MySQL 8.0.21. Les tests sont assez détaillés. Entre autres choses, vous apprendrez les changements dans les valeurs par défaut pour les variables que vous n'avez pas configurées dans votre configuration MySQL (ainsi, ces paramètres changeront une fois que vous aurez installé MySQL 8.0).
Annuler une mise à jour ayant échoué
Comme nous l'avons mentionné précédemment, vous ne pouvez pas rétrograder à partir de MySQL 8.0 une fois la mise à niveau terminée. Heureusement, cela ne signifie pas que vous ne pouvez pas annuler la mise à niveau si elle échoue au milieu. En fait, cela se produit semi-automatiquement si l'un des problèmes dont nous avons discuté dans la section précédente est détecté. La seule action manuelle requise serait de supprimer les journaux redo et de démarrer MySQL 5.7 pour résoudre les problèmes détectés lors de la mise à niveau. Ensuite, vous devez effectuer un arrêt lent (innodb_fast_shutdown=0) pour vous assurer que tout est écrit dans les espaces de table, puis vous êtes tous prêts à tenter la mise à niveau une fois de plus.
Conseils finaux
Il y a deux changements assez importants dans le comportement par défaut fourni avec MySQL 8.0 que nous aimerions souligner.
Caching_sha2_password par défaut
Veuillez vous assurer de bien vérifier si vos applications et proxys fonctionneront correctement avec le plug-in d'authentification caching_sha2_password car il devient celui par défaut dans MySQL 8.0. Les applications plus anciennes peuvent être affectées et ne pas pouvoir se connecter à la base de données. Bien sûr, vous pouvez changer cela en n'importe quel plugin d'authentification que vous voulez (comme mysql_native_password par exemple, car c'était la valeur par défaut dans les versions précédentes de MySQL) afin que ce ne soit en aucun cas un bloqueur. N'oubliez pas de tester avant la mise à niveau afin de ne pas vous retrouver avec MySQL 8.0 et des applications qui ne peuvent pas s'y connecter à moins que vous ne reconfiguriez votre base de données pour utiliser un mécanisme d'authentification plus ancien.
UTF8mb4 comme jeu de caractères par défaut
Cela ne devrait pas être une surprise compte tenu de l'ampleur des discussions sur le passage à UTF8 dans la communauté, mais c'est le fait - MySQL 8.0 est livré avec le jeu de caractères UTF8mb4 par défaut. Cela a un impact supplémentaire dont vous devez être conscient. Tout d'abord, la taille de votre jeu de données peut augmenter si vous utilisez le jeu de caractères UTF8mb4. Cela conduit à des tampons de mémoire capables de stocker de plus petites quantités de données que pour les données avec le jeu de caractères latin1. Deuxièmement, les performances de MySQL devraient être réduites. Bien sûr, Oracle a fait un excellent travail pour minimiser l'impact de ce changement, mais vous ne pouvez pas vous attendre à ce qu'il n'y ait aucun impact sur les performances ; il y en aura.
Nous espérons que cet article de blog vous aidera à passer à travers le processus de mise à niveau de MySQL 5.7 vers MySQL 8.0. Si vous avez des idées sur le processus, nous vous encourageons à les partager dans les commentaires sous cet article.
