ApsaraDB RDS:Mettre à niveau la version majeure de la base de données

Sélectionner une méthode de mise à niveau

La Méthode 1 : Mettre à niveau directement la version de la base de données dans la console et la Méthode 2 : Mettre à niveau la version de la base de données à l'aide de DTS prennent toutes deux en charge les chemins de mise à niveau MySQL suivants : de MySQL 5.5 à 5,6, de 5,6 à 5,7, de 5,7 à 8,0 et de 8,0 à 8,4. Avant de mettre à niveau votre base de données, sélectionnez la méthode appropriée en fonction des informations ci-dessous :

• Si votre instance appartient à l'une des quatre catégories suivantes et que sa configuration répond aux exigences correspondantes, utilisez la Méthode 1 : Mettre à niveau directement la version de la base de données dans la console.

  Remarque

  Les instances Serverless ne prennent pas en charge les mises à niveau directes depuis la console. Vous devez utiliser la Méthode 2 : Mettre à niveau la version de la base de données à l'aide de DTS.

  Cluster Edition (ESSD et disque haute performance)

  • Restriction liée à la réplication de groupe : Vous ne pouvez pas mettre à niveau les instances Cluster Edition qui utilisent MySQL Group Replication (MGR).

  • Restriction liée au proxy de base de données (le cas échéant) : Pour les mises à niveau de 5,7 vers 8.0, la version mineure du proxy de base de données doit être 1.13.41 ou ultérieure. Pour les mises à niveau de 8,0 vers 8.4, la version mineure du proxy de base de données doit être 2.25.11 ou ultérieure.

  • Restriction liée à l'état de l'instance : L'état de l'instance doit être Running, et les nœuds principal et secondaire doivent être sains et sans délai de réplication.

  • Restriction liée au moteur : La base de données et toutes ses tables doivent utiliser le moteur de stockage InnoDB.

  • L'instance ne doit pas utiliser un type d'instance obsolète.

  High-availability Edition (ESSD et disque haute performance)

  • Restriction liée au proxy de base de données (le cas échéant) : Pour les mises à niveau de 5,7 vers 8.0, la version mineure du proxy de base de données doit être 1.13.41 ou ultérieure. Pour les mises à niveau de 8,0 vers 8.4, la version mineure du proxy de base de données doit être 2.25.11 ou ultérieure.

  • Restriction liée à l'état de l'instance : L'état de l'instance doit être Running, et les nœuds principal et secondaire doivent être sains et sans délai de réplication.

  • Restriction liée au moteur : La base de données et toutes ses tables doivent utiliser le moteur de stockage InnoDB.

  • L'instance ne doit pas utiliser un type d'instance obsolète.

  High-availability Edition (disque local haute performance)

  • Restriction liée au chiffrement : La fonctionnalité de chiffrement transparent des données (TDE) doit être désactivée. Une fois le TDE activé, il ne peut pas être désactivé. Si le TDE est activé sur votre instance, vous devez utiliser la Méthode 2 : Mettre à niveau la version de la base de données à l'aide de DTS.

  • Restriction liée au proxy de base de données (le cas échéant) : Pour les mises à niveau de 5,7 vers 8.0, la version mineure du proxy de base de données doit être 1.13.41 ou ultérieure. Pour les mises à niveau de 8,0 vers 8.4, la version mineure du proxy de base de données doit être 2.25.11 ou ultérieure.

  • Restriction liée à l'état de l'instance : L'état de l'instance doit être Running, et les nœuds principal et secondaire doivent être sains et sans délai de réplication.

  • Restriction liée au nombre de tables : Le nombre de tables ne peut pas dépasser 1 million.

  • Restriction liée au moteur : La base de données et toutes ses tables doivent utiliser le moteur de stockage InnoDB.

  • Restriction liée au type d'instance : La version de la base de données après la mise à niveau doit prendre en charge les types d'instance d'origine des instances principales et en lecture seule. Les instances ne doivent pas utiliser un type d'instance obsolète. Pour plus d'informations, consultez les Types d'instance principale ApsaraDB RDS for MySQL.

  Basic Edition (ESSD et disque haute performance)

  • Restriction liée à l'état de l'instance : L'état de l'instance doit être Running.

  • Restriction liée au moteur : La base de données et toutes ses tables doivent utiliser le moteur de stockage InnoDB.

  • L'instance ne doit pas utiliser un type d'instance obsolète.

• Si votre instance n'appartient à aucune des quatre catégories précédentes ou si le TDE est activé, utilisez la Méthode 2 : Mettre à niveau la version de la base de données à l'aide de DTS.

• Si votre instance appartient à l'une des quatre catégories précédentes mais que sa configuration ne répond pas aux exigences, vous pouvez modifier la configuration comme décrit dans le tableau suivant. Ensuite, vous pouvez utiliser soit la Méthode 1 : Mettre à niveau directement la version de la base de données dans la console, soit la Méthode 2 : Mettre à niveau la version de la base de données à l'aide de DTS.

  Problème	Solution
  L'état de l'instance n'est pas Running ; par exemple, il est Restarting.	Attendez que la tâche en cours se termine avant de mettre à niveau la version de la base de données.
  Le nombre de tables sur une instance High-availability Edition avec un disque local haute performance dépasse 1 million.	Supprimez les tables redondantes avant la mise à niveau.
  Certaines bases de données ou tables n'utilisent pas le moteur InnoDB.	Exécutez la commande ALTER TABLE <table_name> engine=InnoDB; pour passer au moteur InnoDB.
  L'instance utilise un type d'instance obsolète.	Mettez à niveau le type d'instance avant de mettre à niveau la version de la base de données. Pour plus d'informations, consultez la rubrique Modifier la configuration.
  La version mineure du proxy de base de données ne répond pas aux exigences.	Mettez à niveau la version mineure du proxy de base de données vers la version 1.13.41 ou ultérieure. Pour plus d'informations, consultez la rubrique Mettre à niveau la version mineure du moteur d'un proxy de base de données.
  Le type de stockage de l'instance est SSD standard.	Tout d'abord, mettez à niveau le SSD standard vers un SSD entreprise (ESSD), puis mettez à niveau la version de la base de données.

Pour mettre à niveau la version majeure d'autres moteurs de base de données, consultez les rubriques suivantes :

• Mettre à niveau la version majeure de la base de données d'une instance ApsaraDB RDS for PostgreSQL

• Mettre à niveau la version majeure de la base de données d'une instance ApsaraDB RDS for SQL Server

Méthode 1 : Mettre à niveau directement la version de la base de données dans la console

Méthode 2 : Mettre à niveau la version de la base de données à l'aide de DTS

Pour les instances qui ne prennent pas en charge une mise à niveau directe depuis la console, créez une nouvelle instance avec une version ultérieure de la base de données. Utilisez ensuite une tâche de migration de données DTS pour migrer les données de l'instance d'origine vers la nouvelle instance. Cette approche permet de mettre à niveau indirectement la version de la base de données. Le processus comprend les étapes suivantes :

1. Créer une nouvelle instance

2. Migrer les données vers la nouvelle instance

3. Libérer l'instance d'origine

Exemple : Vous disposez d'une instance MySQL 5.7 avec TDE activé, qui ne peut pas être mise à niveau directement depuis la console. Dans ce cas, créez une nouvelle instance exécutant MySQL 8.0, migrez les données de l'instance d'origine vers la nouvelle instance, puis libérez l'instance d'origine. Cette procédure met à niveau indirectement la version de la base de données.

Annexe 1 : Avantages de la mise à niveau de MySQL 8.0 vers MySQL 8.4

• Stabilité à long terme améliorée. MySQL 8.4 est une version LTS (Long Term Support) adaptée à une utilisation prolongée dans les environnements de production. Les versions ultérieures 8,4.x se concentrent sur la stabilité, les correctifs de sécurité et le maintien de la compatibilité.

• Authentification renforcée. Prend en charge l'authentification WebAuthn/FIDO2. L'édition Enterprise permet d'utiliser des clés de sécurité, la biométrie et d'autres méthodes d'authentification. Sous Windows, l'authentification SASL LDAP/GSSAPI/Kerberos est prise en charge.

• Fonctionnalités GTID améliorées. Prend en charge les GTID tagués. Vous pouvez utiliser le format UUID:TAG:NUMBER pour distinguer différents domaines métier, opérations administratives ou opérations sur les données, et le privilège TRANSACTION_GTID_TAG offre un contrôle d'accès.

• Disponibilité de la réplication améliorée. L'appliqueur multithread prend en charge SQL_AFTER_GTIDS, ce qui permet à la réplication parallèle de se poursuivre lorsqu'un réplica atteint un ensemble GTID spécifié.

• Récupération du journal de relais améliorée. Permet de nettoyer les transactions incomplètes à la fin du journal de relais ainsi que les fichiers résiduels associés, réduisant ainsi le risque de récupération dû à une incohérence du journal de relais après un arrêt anormal.

• Opérations Group Replication améliorées. Au sein de la série LTS 8.4, les membres de groupe interversions et les rétrogradations sur place sont pris en charge, l'attente des opérations DDL et DCL lors d'un basculement primaire est plus complète, et le pré-nettoyage des informations d'authentification est pris en charge en mode primaire unique pour réduire les risques liés à la mémoire et au basculement.

• Statistiques améliorées. Les histogrammes prennent en charge le contrôle de mise à jour automatique ou manuel, ce qui améliore la contrôlabilité de la maintenance des statistiques de l'optimiseur.

• Diagnostic du plan d'exécution amélioré. EXPLAIN FORMAT=JSON prend en charge la sélection de la version du format, EXPLAIN FORMAT=JSON INTO écrit la sortie dans une variable utilisateur, et EXPLAIN FOR SCHEMA et FOR DATABASE sont pris en charge, facilitant ainsi le diagnostic SQL entre schémas.

• Validation des certificats TLS renforcée. Prend en charge une validation plus stricte des certificats TLS pour améliorer la sécurité des connexions chiffrées.

• Clone amélioré. Au sein de la même série majeure ou mineure, l'opération de clone ne nécessite plus une correspondance exacte de la version ponctuelle, ce qui facilite l'initialisation, la récupération et la mise à l'échelle des instances entre les versions 8.4.x.

• Audit et pare-feu améliorés. Enterprise Firewall prend en charge les rechargements périodiques du cache et les schémas d'objets internes personnalisés pour une plus grande flexibilité opérationnelle.

• Migration de la gestion des clés améliorée. Prend en charge la migration d'un composant keyring vers un plugin keyring, améliorant ainsi la flexibilité pour les scénarios de migration de chiffrement et de compatibilité.

• Observabilité de la mise à niveau améliorée. Le répertoire de données conserve un fichier mysql_upgrade_history au format JSON qui enregistre l'historique d'installation et de mise à niveau à des fins d'audit et de dépannage.

• Évolution SQL et de l'optimiseur améliorée. Ajoute des mots-clés tels que TABLESAMPLE, QUALIFY et PARALLEL pour fournir une base aux futures extensions SQL et de l'optimiseur.

Annexe 2 : Avantages de la mise à niveau de MySQL 5.7 vers MySQL 8.0

• Améliore la sécurité et offre une plus grande flexibilité dans la gestion des comptes.

• Prend en charge la création et la gestion de groupes de ressources.

• Renforce les fonctionnalités du moteur de stockage InnoDB.

• Ajoute la prise en charge de nouveaux jeux de caractères, types de données, syntaxes, nouveaux verrous de sauvegarde et indicateurs optimizer_switch.

• Améliore les fonctionnalités JSON et XML.

• Renforce les fonctionnalités de l'optimiseur.

• Améliore les performances de réplication.

• Prend en charge la création d'index multivalués et l'optimisation par poussée de conditions dérivées.

• Prend en charge la lecture des tables d'octroi MySQL.

• Prend en charge le contrôle de l'allocation des ressources.

Annexe 3 : Avantages de la mise à niveau de MySQL 5.6 vers MySQL 5.7

• Ajoute des fonctionnalités telles que la gestion des mots de passe, le verrouillage des comptes et les connexions chiffrées pour améliorer la sécurité de la base de données.

• Prend en charge les opérations DDL en ligne, telles que le renommage d'un index à l'aide de RENAME INDEX.

• Améliore l'évolutivité du moteur InnoDB et les performances des tables temporaires pour un chargement des données plus rapide.

• Prend en charge JSON.

• Prend en charge Index Condition Pushdown (ICP) pour les tables partitionnées et les nouveaux index spatiaux InnoDB.

• Optimise la plupart des analyseurs, optimiseurs et modèles de coûts pour améliorer la maintenabilité, l'évolutivité et les performances de la base de données.

• Élargit la gamme des jeux de caractères pris en charge, y compris le jeu de caractères GB18030 spécifié par la norme nationale chinoise.

• Fournit le plugin d'analyseur de texte intégral ngram, qui prend en charge le chinois, le japonais et le coréen.

• Optimise les threads de vidage source pour réduire la contention des verrous et augmenter le débit source.

• Réduit considérablement le délai de réplication.

• Ajoute la base de données système sys, qui fournit plusieurs métriques et réduit l'utilisation du stockage, améliorant ainsi considérablement l'utilisabilité de la base de données.

Annexe 4 : Différences de fonctionnalités entre MySQL 8.4 et MySQL 8.0

Annexe 5 : Différences de fonctionnalités entre MySQL 8.0 et MySQL 5.7

Annexe 6 : Différences de fonctionnalités entre MySQL 5.7 et MySQL 5.6

Annexe 7 : Différences de fonctionnalités entre MySQL 5.5 et MySQL 5.6

FAQ

• Q : Pourquoi un basculement d'instance se produit-il lors de la mise à niveau ? Existe-t-il d'autres risques majeurs ?

  R : Afin de garantir la stabilité du service, les instances dotées de disques locaux haute performance sont mises à niveau en mettant d'abord à niveau le nœud secondaire, puis en effectuant un basculement. Les instances équipées de disques ESSD sont mises à niveau en créant un nouveau nœud, puis en effectuant un basculement. Il n'existe aucun autre risque majeur. Pour plus d'informations sur l'impact d'un basculement primaire/secondaire, consultez la section Impact d'un basculement primaire/secondaire.

• Q : Les nœuds primaire et secondaire sont-ils mis à niveau simultanément ?

  R : Lors de la mise à niveau d'un disque local haute performance, l'instance secondaire est mise à niveau en premier, suivie de l'instance principale.

• Q : Comment mettre à niveau une instance Basic Edition exécutant MySQL 5.7 avec des disques SSD standard ?

  R : Vous ne pouvez pas mettre à niveau directement ce type d'instance. Pour mettre à niveau une instance Basic Edition exécutant MySQL 5.7 avec des disques SSD standard, vous devez d'abord modifier le type de stockage pour passer des SSD standard aux disques ESSD, puis mettre à niveau la version de la base de données.

• Q : Le modèle de paramètres est-il conservé après la mise à niveau de la version de la base de données ?

  R : Cela dépend. Si l'instance utilise un modèle de paramètres système avant la mise à niveau, elle bascule automatiquement vers le modèle de paramètres système correspondant à la nouvelle version. Par exemple, une instance utilisant le modèle de paramètres MySQL_InnoDB_5,7_High-availability_Performance basculera vers le modèle MySQL_InnoDB_8,0_High-availability_Performance après une mise à niveau de MySQL 5.7 vers 8,0. En revanche, si l'instance utilise un modèle de paramètres personnalisé, celui-ci n'est pas conservé après la mise à niveau.

• Q : Puis-je modifier l'instance pendant la mise à niveau de la version de la base de données ?

  R : Non, cela est impossible. Vous ne pourrez effectuer d'autres opérations sur l'instance qu'une fois la mise à niveau terminée.

• Q : La version de la base de données prend-elle en charge les mises à niveau automatiques ?

  R : Non. Les mises à niveau majeures automatiques ne sont pas prises en charge.

• Q : Puis-je rétrograder la version de la base de données ?

  R : Non, vous ne pouvez pas rétrograder directement la version depuis la console. Choisissez l'une des méthodes suivantes selon que l'instance contient ou non des données métier :

  • Avec des données métier : Achetez une instance exécutant une version antérieure, utilisez DTS pour migrer les données de l'instance de version supérieure vers la nouvelle instance de version inférieure, puis libérez l'instance de version supérieure une fois la migration terminée. Cette procédure permet de rétrograder indirectement la version de la base de données. Pour plus d'informations, consultez la section Migration de données entre instances RDS.

  • Sans données métier : Désabonnez-vous de l'instance d'origine et achetez une nouvelle instance exécutant la version antérieure requise. Pour les instances par abonnement, suivez la procédure de remboursement pour vous désabonner. Pour les instances au paiement à l'utilisation, libérez-les directement.

• Q : Lors de la mise à niveau d'une instance RDS for MySQL de la version 5.6 vers 5.7 ou de 5,7 vers 8,0, l'opération échoue. Le message suivant s'affiche : « The current instance has a full-text index and its minor version is earlier than 20221130. Please upgrade the minor version before deleting and rebuilding the full-text index » ou « The current instance contains a full-text index built in the system tablespace. Please delete and rebuild the corresponding full-text index before proceeding with the upgrade. » Quelle en est la cause et quelle est la solution ?

  R : Voici la cause et la solution :

  • Cause

    En raison d'un problème historique dans MySQL, lorsque vous créez un index en texte intégral sur une version ancienne de MySQL 5.6, celui-ci est construit dans le tablespace système. Lors de la mise à niveau vers les versions 5.7 ou 8.0, un index en texte intégral situé dans le tablespace système peut entraîner une corruption du tablespace. Par conséquent, vous devez résoudre ce problème avant la mise à niveau afin d'éviter toute corruption des données et leur inaccessibilité.

    Remarque

    Ce problème a été corrigé dans la version 20221130 de RDS for MySQL 5.6. Les index en texte intégral sont désormais construits dans un tablespace distinct.

  • Solution

    Important

    Les index en texte intégral sur les versions antérieures de RDS for MySQL 5.6 sont créés dans le tablespace système. Par conséquent, assurez-vous que la version source est RDS for MySQL 5.6 20221130 ou ultérieure avant de procéder à la mise à niveau vers RDS for MySQL 5.7. Si vous utilisez une version antérieure, mettez d'abord à niveau vers la dernière version de RDS for MySQL 5.6.

    1. Sur la base du nom de table indiqué dans l'invite, supprimez l'index en texte intégral qui a été construit dans le tablespace système.

       # Delete the full-text index.
       ALTER TABLE $table_name DROP INDEX $fts_name;

    2. Recréez l'index en texte intégral.

       # Re-create the full-text index.
       ALTER TABLE $table_name ADD FULLTEXT INDEX $fts_name;

    3. Après avoir créé l'index, vous pouvez exécuter l'instruction SQL suivante pour vérifier les index en texte intégral sur l'instance actuelle. L'instruction renvoie tous les index en texte intégral construits dans le tablespace système. Si la requête renvoie un résultat vide, la mise à niveau de RDS for MySQL 5.6 vers RDS for MySQL 5.7 n'échouera pas en raison de ce problème.

       # Query for full-text indexes built in the system tablespace.
       SELECT NAME FROM information_schema.INNODB_SYS_TABLES WHERE TABLE_ID IN ( SELECT CONV(SUBSTRING_INDEX(SUBSTRING_INDEX(NAME, '_', -4),'_', 1),16,10) FROM INNODB_SYS_TABLES WHERE NAME LIKE '%fts_00000000%' AND SPACE = 0);

• Q : Lors de la mise à niveau d'une instance RDS for MySQL de la version 5.7 vers 8.0, l'erreur 267 - Illegal mix of collations (utf8mb4_general_ci,IMPLICIT) and (utf8mb4_0900_ai_ci,IMPLICIT) for operation '=' est signalée. Comment y remédier ?

  R : Vérifiez le jeu de caractères et l'interclassement dans MySQL. Si vous utilisez utf8mb4_general_ci, exécutez les instructions SQL suivantes pour le remplacer par utf8mb4_0900_ai_ci.

  # Modify the character set and collation of the database.
  ALTER DATABASE database_name CHARACTER SET = utf8mb4 COLLATE = utf8mb4_0900_ai_ci;
  # Modify the character set and collation of the table.
  ALTER TABLE table_name CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci;
  # Modify the character set and collation of the field.
  ALTER TABLE table_name CHANGE column_name column_name type CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci;

  Si vous créez une table avec l'interclassement utf8mb4_general_ci dans MySQL 5.7, puis effectuez une mise à niveau vers MySQL 8.0, le système utilise utf8mb4_0900_ai_ci comme interclassement par défaut. Si vous exécutez une requête comparant une colonne utilisant utf8mb4_general_ci avec une colonne utilisant utf8mb4_0900_ai_ci, MySQL ne peut pas traiter ces deux interclassements différents, ce qui génère une erreur.

• Q : La durée de la coupure de connexion temporaire lors d'une mise à niveau majeure est-elle toujours de 15 secondes, indépendamment de la présence d'instances en lecture seule ?

  R : Oui. Nous vous recommandons d'effectuer la mise à niveau pendant les heures creuses.

Opérations API associées