Mysql
 sql >> Base de données >  >> RDS >> Mysql

Passer de MySQL 5.7 à MySQL 8.0 - Ce que vous devez savoir

Avril 2018 n'est pas seulement une date pour le monde MySQL. MySQL 8.0 y est sorti, et plus d'un an après, il est probablement temps d'envisager de migrer vers cette nouvelle version.

MySQL 8.0 a d'importantes améliorations en termes de performances et de sécurité, et, comme dans toute migration vers une nouvelle version de base de données, il y a plusieurs choses à prendre en compte avant de passer en production pour éviter des problèmes difficiles comme la perte de données, une temps d'arrêt, voire une restauration pendant la tâche de migration.

Dans ce blog, nous mentionnerons certaines des nouvelles fonctionnalités de MySQL 8.0, des éléments obsolètes et ce que vous devez garder à l'esprit avant de migrer.

Quoi de neuf dans MySQL 8.0 ?

Résumons maintenant certaines des fonctionnalités les plus importantes mentionnées dans la documentation officielle de cette nouvelle version de MySQL.

  • MySQL intègre un dictionnaire de données transactionnelles qui stocke des informations sur les objets de la base de données.
  • Une instruction DDL atomique combine les mises à jour du dictionnaire de données, les opérations du moteur de stockage et les écritures de journal binaire associées à une opération DDL en une seule transaction atomique.
  • Le serveur MySQL effectue automatiquement toutes les tâches de mise à niveau nécessaires au prochain démarrage pour mettre à niveau les tables système dans le schéma mysql, ainsi que les objets dans d'autres schémas tels que le schéma sys et les schémas utilisateur. Il n'est pas nécessaire que le DBA invoque mysql_upgrade.
  • Il prend en charge la création et la gestion de groupes de ressources et permet d'attribuer des threads exécutés sur le serveur à des groupes particuliers afin que les threads s'exécutent en fonction des ressources disponibles pour le groupe.
  • Le chiffrement des tables peut désormais être géré globalement en définissant et en appliquant des valeurs de chiffrement par défaut. La variable default_table_encryption définit une valeur par défaut de chiffrement pour les schémas nouvellement créés et l'espace de table général. Les valeurs par défaut de chiffrement sont appliquées en activant la variable table_encryption_privilege_check.
  • Le jeu de caractères par défaut est passé de latin1 à utf8mb4.
  • Il prend en charge l'utilisation d'expressions comme valeurs par défaut dans les spécifications de type de données. Cela inclut l'utilisation d'expressions comme valeurs par défaut pour les types de données BLOB, TEXT, GEOMETRY et JSON.
  • La journalisation des erreurs a été réécrite pour utiliser l'architecture des composants MySQL. La journalisation traditionnelle des erreurs est implémentée à l'aide de composants intégrés, et la journalisation à l'aide du journal système est implémentée en tant que composant chargeable.
  • Un nouveau type de verrouillage de sauvegarde autorise DML lors d'une sauvegarde en ligne tout en empêchant les opérations qui pourraient entraîner un instantané incohérent. Le nouveau verrou de sauvegarde est pris en charge par la syntaxe LOCK INSTANCE FOR BACKUP et UNLOCK INSTANCE. Le privilège BACKUP_ADMIN est requis pour utiliser ces instructions.
  • MySQL Server permet désormais de configurer un port TCP/IP spécifiquement pour les connexions administratives. Cela fournit une alternative à la connexion administrative unique autorisée sur les interfaces réseau utilisées pour les connexions ordinaires, même lorsque les connexions max_connections sont déjà établies.
  • Il prend en charge les index invisibles. Cet index n'est pas utilisé par l'optimiseur et permet de tester l'effet de la suppression d'un index sur les performances des requêtes, sans le supprimer.
  • Document Store pour le développement d'applications de documents SQL et NoSQL à l'aide d'une seule base de données.
  • MySQL 8.0 permet de conserver des variables de serveur globales et dynamiques à l'aide de la commande SET PERSIST au lieu de la commande habituelle SET GLOBAL.

Sécurité MySQL et gestion des comptes

Comme il existe de nombreuses améliorations liées à la sécurité et à la gestion des utilisateurs, nous les énumérerons dans une section distincte.

  • Les tables de droits dans la base de données du système mysql sont maintenant des tables InnoDB.
  • Le nouveau plugin d'authentification caching_sha2_password est désormais la méthode d'authentification par défaut dans MySQL 8.0. Il implémente le hachage de mot de passe SHA-256, mais utilise la mise en cache pour résoudre les problèmes de latence au moment de la connexion. Il fournit un cryptage de mot de passe plus sécurisé que le plugin mysql_native_password et offre de meilleures performances que sha256_password.
  • MySQL prend désormais en charge les rôles, qui sont des collections nommées de privilèges. Des privilèges peuvent être accordés et révoqués aux rôles, et ils peuvent être accordés et révoqués aux comptes d'utilisateurs.
  • MySQL conserve désormais des informations sur l'historique des mots de passe, permettant des restrictions sur la réutilisation des mots de passe précédents.
  • Il permet aux administrateurs de configurer des comptes d'utilisateurs de sorte qu'un trop grand nombre d'échecs de connexion consécutifs dus à des mots de passe incorrects entraînent un verrouillage temporaire du compte.

Améliorations InnoDB

Comme au point précédent, il existe également de nombreuses améliorations liées à ce sujet, nous les énumérerons donc également dans une section distincte.

  • La valeur maximale actuelle du compteur d'auto-incrémentation est écrite dans le journal de rétablissement chaque fois que la valeur change, et enregistrée dans une table système privée du moteur à chaque point de contrôle. Ces modifications rendent la valeur maximale actuelle du compteur d'auto-incrémentation persistante lors des redémarrages du serveur
  • En cas de corruption de l'arborescence d'index, InnoDB écrit un indicateur de corruption dans le journal de rétablissement, ce qui rend l'indicateur de corruption à l'abri des pannes. InnoDB écrit également les données d'indicateur de corruption en mémoire dans une table système privée du moteur sur chaque point de contrôle. Pendant la récupération, InnoDB lit les indicateurs de corruption des deux emplacements et fusionne les résultats avant de marquer les objets de table et d'index en mémoire comme corrompus.
  • Une nouvelle variable dynamique, innodb_deadlock_detect, peut être utilisée pour désactiver la détection de blocage. Sur les systèmes à forte concurrence, la détection des interblocages peut provoquer un ralentissement lorsque de nombreux threads attendent le même verrou. Parfois, il peut être plus efficace de désactiver la détection d'interblocage et de s'appuyer sur le paramètre innodb_lock_wait_timeout pour l'annulation de la transaction lorsqu'un interblocage se produit.
  • Les tables temporaires InnoDB sont maintenant créées dans l'espace de table temporaire partagé, ibtmp1.
  • les tables système mysql et les tables de dictionnaire de données sont désormais créées dans un seul fichier d'espace de table InnoDB nommé mysql.ibd dans le répertoire de données MySQL. Auparavant, ces tables étaient créées dans des fichiers d'espace de table InnoDB individuels dans le répertoire de la base de données mysql.
  • Par défaut, les journaux d'annulation résident désormais dans deux espaces de table d'annulation créés lors de l'initialisation de l'instance MySQL. Les journaux d'annulation ne sont plus créés dans l'espace de table système.
  • La nouvelle variable innodb_dedicated_server, qui est désactivée par défaut, peut être utilisée pour qu'InnoDB configure automatiquement les options suivantes en fonction de la quantité de mémoire détectée sur le serveur :innodb_buffer_pool_size, innodb_log_file_size et innodb_flush_method. Cette option est destinée aux instances de serveur MySQL qui s'exécutent sur un serveur dédié.
  • Les fichiers d'espace de table peuvent être déplacés ou restaurés vers un nouvel emplacement lorsque le serveur est hors ligne à l'aide de l'option innodb_directories.

Maintenant, regardons quelques-unes des fonctionnalités que vous ne devriez plus utiliser dans cette nouvelle version de MySQL.

Qu'est-ce qui est obsolète dans MySQL 8.0 ?

Les fonctionnalités suivantes sont obsolètes et seront supprimées dans une future version.

  • Le jeu de caractères utf8mb3 est obsolète. Veuillez utiliser utf8mb4 à la place.
  • Étant donné que caching_sha2_password est le plug-in d'authentification par défaut dans MySQL 8.0 et fournit un sur-ensemble des fonctionnalités du plug-in d'authentification sha256_password, sha256_password est obsolète.
  • Le plugin validate_password a été réimplémenté pour utiliser l'infrastructure du composant serveur. Le formulaire de plugin de validate_password est toujours disponible mais est obsolète.
  • La clause ENGINE pour les instructions ALTER TABLESPACE et DROP TABLESPACE.
  • Le mode SQL PAD_CHAR_TO_FULL_LENGTH.
  • La prise en charge d'AUTO_INCREMENT est obsolète pour les colonnes de type FLOAT et DOUBLE (et tous les synonymes). Envisagez de supprimer l'attribut AUTO_INCREMENT de ces colonnes ou convertissez-les en un type entier.
  • L'attribut UNSIGNED est obsolète pour les colonnes de type FLOAT, DOUBLE et DECIMAL (et tous les synonymes). Envisagez d'utiliser une simple contrainte CHECK à la place pour ces colonnes.
  • La syntaxe FLOAT(M,D) et DOUBLE(M,D) pour spécifier le nombre de chiffres pour les colonnes de type FLOAT et DOUBLE (et tous les synonymes) est une extension MySQL non standard. Cette syntaxe est obsolète.
  • Les &&, || et ! de style C non standard les opérateurs synonymes des opérateurs SQL standard AND, OR et NOT, respectivement, sont obsolètes. Les applications qui utilisent les opérateurs non standard doivent être ajustées pour utiliser les opérateurs standard.
  • Le client mysql_upgrade est obsolète car ses capacités de mise à niveau des tables système dans le schéma système mysql et des objets dans d'autres schémas ont été déplacées vers le serveur MySQL.
  • Le fichier mysql_upgrade_info, qui est un répertoire de données créé et utilisé pour stocker le numéro de version de MySQL.
  • La variable système relay_log_info_file et l'option --master-info-file sont obsolètes. Auparavant, ils étaient utilisés pour spécifier le nom du journal d'informations du journal de relais et du journal d'informations principal lorsque relay_log_info_repository=FILE et master_info_repository=FILE étaient définis, mais ces paramètres sont devenus obsolètes. L'utilisation de fichiers pour le journal d'informations du journal de relais et le journal d'informations principal a été remplacée par des tables esclaves résistantes aux pannes, qui sont la valeur par défaut dans MySQL 8.0.
  • L'utilisation de la variable d'environnement MYSQL_PWD pour spécifier un mot de passe MySQL est obsolète.

Et maintenant, examinons certaines des fonctionnalités que vous devez cesser d'utiliser dans cette version de MySQL.

Qu'est-ce qui a été supprimé dans MySQL 8.0 ?

Les fonctionnalités suivantes ont été supprimées dans MySQL 8.0.

  • La variable système innodb_locks_unsafe_for_binlog a été supprimée. Le niveau d'isolement READ COMMITTED offre des fonctionnalités similaires.
  • Utilisation de GRANT pour créer des utilisateurs. Utilisez plutôt CREATE USER. Suivre cette pratique rend le mode SQL NO_AUTO_CREATE_USER immatériel pour les instructions GRANT, donc il est également supprimé, et une erreur est maintenant écrite dans le journal du serveur lorsque la présence de cette valeur pour l'option sql_mode dans le fichier d'options empêche mysqld de démarrer.
  • Utilisation de GRANT pour modifier les propriétés du compte autres que les attributions de privilèges. Cela inclut les propriétés d'authentification, SSL et de limitation des ressources. Au lieu de cela, établissez ces propriétés au moment de la création du compte avec CREATE USER ou modifiez-les ultérieurement avec ALTER USER.
  • IDENTIFIED BY PASSWORD 'auth_string' syntaxe pour CREATE USER et GRANT. À la place, utilisez IDENTIFIED WITH auth_plugin AS 'auth_string' pour CREATE USER et ALTER USER, où la valeur 'auth_string' est dans un format compatible avec le plugin nommé.
  • La fonction PASSWORD(). De plus, la suppression de PASSWORD() signifie que la syntaxe SET PASSWORD ... =PASSWORD('auth_string') n'est plus disponible.
  • La variable système old_passwords.
  • Les instructions FLUSH QUERY CACHE et RESET QUERY CACHE.
  • Ces variables système :query_cache_limit, query_cache_min_res_unit, query_cache_size, query_cache_type, query_cache_wlock_invalidate.
  • Ces variables d'état :Qcache_free_blocks, Qcache_free_memory, Qcache_hits, Qcache_inserts, Qcache_lowmem_prunes, Qcache_not_cached, Qcache_queries_in_cache, Qcache_total_blocks.
  • Ces états de thread :vérification des privilèges sur la requête mise en cache, vérification du cache de requête pour une requête, invalidation des entrées du cache de requête, envoi du résultat mis en cache au client, stockage du résultat dans le cache de requête, attente du verrouillage du cache de requête.
  • Les variables système tx_isolation et tx_read_only ont été supprimées. Utilisez transaction_isolation et transaction_read_only à la place.
  • La variable système sync_frm a été supprimée car les fichiers .frm sont devenus obsolètes.
  • La variable système secure_auth et l'option cliente --secure-auth ont été supprimées. L'option MYSQL_SECURE_AUTH pour la fonction API C mysql_options() a été supprimée.
  • La variable système log_warnings et l'option de serveur --log-warnings ont été supprimées. Utilisez plutôt la variable système log_error_verbosity.
  • La portée globale de la variable système sql_log_bin a été supprimée. sql_log_bin a une portée de session uniquement, et les applications qui dépendent de l'accès à @@GLOBAL.sql_log_bin doivent être ajustées.
  • Les variables système inutilisées date_format, datetime_format, time_format et max_tmp_tables sont supprimées.
  • Les qualificateurs ASC ou DESC obsolètes pour les clauses GROUP BY sont supprimés. Les requêtes qui reposaient auparavant sur le tri GROUP BY peuvent produire des résultats différents des versions précédentes de MySQL. Pour produire un ordre de tri donné, fournissez une clause ORDER BY.
  • L'analyseur ne traite plus \N comme synonyme de NULL dans les instructions SQL. Utilisez NULL à la place. Cette modification n'affecte pas les opérations d'importation ou d'exportation de fichiers texte effectuées avec LOAD DATA ou SELECT ... INTO OUTFILE, pour lesquelles NULL continue d'être représenté par \N.
  • Les options côté client --ssl et --ssl-verify-server-cert ont été supprimées. Utilisez --ssl-mode=REQUIRED au lieu de --ssl=1 ou --enable-ssl. Utilisez --ssl-mode=DISABLED au lieu de --ssl=0, --skip-ssl ou --disable-ssl. Utilisez --ssl-mode=VERIFY_IDENTITY au lieu des options --ssl-verify-server-cert.
  • Le programme mysql_install_db a été supprimé des distributions MySQL. L'initialisation du répertoire de données doit être effectuée en appelant mysqld avec l'option --initialize ou --initialize-insecure à la place. De plus, l'option --bootstrap pour mysqld qui était utilisée par mysql_install_db a été supprimée, et l'option CMake INSTALL_SCRIPTDIR qui contrôlait l'emplacement d'installation de mysql_install_db a été supprimée.
  • L'utilitaire mysql_plugin a été supprimé. Les alternatives incluent le chargement des plug-ins au démarrage du serveur à l'aide de l'option --plugin-load ou --plugin-load-add, ou lors de l'exécution à l'aide de l'instruction INSTALL PLUGIN.
  • L'utilitaire resolveip est supprimé. nslookup, host ou dig peuvent être utilisés à la place.

Il existe de nombreuses fonctionnalités nouvelles, obsolètes et supprimées. Vous pouvez consulter le site officiel pour des informations plus détaillées.

Considérations avant de migrer vers MySQL 8.0

Évoquons maintenant certaines des choses les plus importantes à considérer avant de migrer vers cette version de MySQL.

Méthode d'authentification

Comme nous l'avons mentionné, caching_sha2_password n'est pas la méthode d'authentification par défaut, vous devez donc vérifier si votre application/connecteur la prend en charge. Si ce n'est pas le cas, voyons comment changer à nouveau la méthode d'authentification par défaut et le plug-in d'authentification de l'utilisateur en "mysql_native_password".

Pour modifier la méthode d'authentification par défaut, modifiez le fichier de configuration my.cnf et ajoutez/modifiez la ligne suivante :

$ vi /etc/my.cnf

[mysqld]

default_authentication_plugin=mysql_native_password

Pour changer le plugin d'authentification des utilisateurs, exécutez la commande suivante avec un utilisateur privilégié :

$ mysql -p

ALTER USER ‘username’@’hostname’ IDENTIFIED WITH ‘mysql_native_password’ BY ‘password’;

De toute façon, ces changements ne sont pas une solution permanente car l'ancienne authentification pourrait bientôt être obsolète, vous devez donc en tenir compte lors d'une future mise à jour de la base de données.

Les rôles sont également une caractéristique importante ici. Vous pouvez réduire les privilèges individuels en l'attribuant à un rôle et en y ajoutant les utilisateurs correspondants.

Par exemple, vous pouvez créer un nouveau rôle pour les équipes marketing et développeurs :

$ mysql -p

CREATE ROLE 'marketing', 'developers';

Attribuez des privilèges à ces nouveaux rôles :

GRANT SELECT ON *.* TO 'marketing';

GRANT ALL PRIVILEGES ON *.* TO 'developers';

Et ensuite, attribuez le rôle aux utilisateurs :

GRANT 'marketing' TO 'marketing1'@'%';

GRANT 'marketing' TO 'marketing2'@'%';

GRANT 'developers' TO 'developer1'@'%';

Et c'est tout. Vous aurez les privilèges suivants :

SHOW GRANTS FOR 'marketing1'@'%';

+-------------------------------------------+

| Grants for [email protected]%                   |

+-------------------------------------------+

| GRANT USAGE ON *.* TO `marketing1`@`%`    |

| GRANT `marketing`@`%` TO `marketing1`@`%` |

+-------------------------------------------+

2 rows in set (0.00 sec)

SHOW GRANTS FOR 'marketing';

+----------------------------------------+

| Grants for [email protected]%                 |

+----------------------------------------+

| GRANT SELECT ON *.* TO `marketing`@`%` |

+----------------------------------------+

1 row in set (0.00 sec)

Jeux de caractères

Comme le nouveau jeu de caractères par défaut est utf8mb4, vous devez vous assurer que vous n'utilisez pas celui par défaut car il changera.

Pour éviter certains problèmes, vous devez spécifier les variables character_set_server et collation_server dans le fichier de configuration my.cnf.

$ vi /etc/my.cnf

[mysqld]

character_set_server=latin1

collation_server=latin1_swedish_ci

Moteur MyISAM

Les tables de privilèges MySQL dans le schéma MySQL sont déplacées vers InnoDB. Vous pouvez créer une table engine=MyISAM, et cela fonctionnera comme avant, mais la copie d'une table MyISAM dans un serveur MySQL en cours d'exécution ne fonctionnera pas car elle ne sera pas découverte.

Partitionnement

Aucune table partitionnée ne doit utiliser un moteur de stockage qui ne prend pas en charge le partitionnement natif. Vous pouvez exécuter la requête suivante pour vérifier ce point.

$ mysql -p

SELECT TABLE_SCHEMA, TABLE_NAME FROM INFORMATION_SCHEMA.TABLES WHERE ENGINE NOT IN ('innodb', 'ndbcluster') AND CREATE_OPTIONS LIKE '%partitioned%';

Si vous avez besoin de changer le moteur d'une table, vous pouvez exécuter :

ALTER TABLE table_name ENGINE = INNODB;

Vérification de la mise à niveau

En dernière étape, vous pouvez exécuter la commande mysqlcheck en utilisant l'indicateur check-upgrade pour confirmer si tout semble correct.

$ mysqlcheck -uroot -p --all-databases --check-upgrade

Enter password:

mysql.columns_priv                                 OK

mysql.component                                    OK

mysql.db                                           OK

mysql.default_roles                                OK

mysql.engine_cost                                  OK

mysql.func                                         OK

mysql.general_log                                  OK

mysql.global_grants                                OK

mysql.gtid_executed                                OK

mysql.help_category                                OK

mysql.help_keyword                                 OK

mysql.help_relation                                OK

mysql.help_topic                                   OK

mysql.innodb_index_stats                           OK

mysql.innodb_table_stats                           OK

mysql.password_history                             OK

mysql.plugin                                       OK

mysql.procs_priv                                   OK

mysql.proxies_priv                                 OK

mysql.role_edges                                   OK

mysql.server_cost                                  OK

mysql.servers                                      OK

mysql.slave_master_info                            OK

mysql.slave_relay_log_info                         OK

mysql.slave_worker_info                            OK

mysql.slow_log                                     OK

mysql.tables_priv                                  OK

mysql.time_zone                                    OK

mysql.time_zone_leap_second                        OK

mysql.time_zone_name                               OK

mysql.time_zone_transition                         OK

mysql.time_zone_transition_type                    OK

mysql.user                                         OK

sys.sys_config                                     OK

world_x.city                                       OK

world_x.country                                    OK

world_x.countryinfo                                OK

world_x.countrylanguage                            OK

Il y a plusieurs choses à vérifier avant d'effectuer la mise à niveau. Vous pouvez consulter la documentation officielle de MySQL pour des informations plus détaillées.

Méthodes de mise à jour

Il existe différentes façons de mettre à niveau MySQL 5.7 vers 8.0. Vous pouvez utiliser la mise à niveau sur place ou même créer un esclave de réplication dans la nouvelle version, afin de pouvoir la promouvoir ultérieurement.

Mais avant la mise à niveau, l'étape 0 doit sauvegarder vos données. La sauvegarde doit inclure toutes les bases de données, y compris les bases de données système. Donc, en cas de problème, vous pouvez revenir en arrière dès que possible.

Une autre option, selon les ressources disponibles, peut être de créer une réplication en cascade MySQL 5.7 -> MySQL 8.0 -> MySQL 5.7, donc après avoir promu la nouvelle version, si quelque chose ne va pas, vous pouvez promouvoir la nœud esclave avec l'ancienne version. Mais cela pourrait être dangereux s'il y avait un problème avec les données, donc la sauvegarde est indispensable avant.

Pour toute méthode à utiliser, il est nécessaire d'avoir un environnement de test pour vérifier que l'application fonctionne sans aucun problème avec la nouvelle version de MySQL 8.0.

Conclusion

Plus d'un an après la sortie de MySQL 8.0, il est temps de commencer à penser à migrer votre ancienne version de MySQL, mais heureusement, comme la fin du support de MySQL 5.7 est 2023, vous avez le temps de créer un plan de migration et de tester le comportement de l'application sans précipitation. Il est nécessaire de passer du temps dans cette étape de test pour éviter tout problème après la migration.