Mises à jour du moteur de base de données Aurora MySQL 31/07/2023 (version 3.04.0, compatible avec MySQL 8.0.28) - Amazon Aurora

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Mises à jour du moteur de base de données Aurora MySQL 31/07/2023 (version 3.04.0, compatible avec MySQL 8.0.28)

Version : 3.04.0

Aurora MySQL 3.04.0 est disponible. Les versions 3.04 d'Aurora MySQL sont compatibles avec MySQL 8.0.28, les versions 3.03 d'Aurora MySQL sont compatibles avec MySQL 8.0.26 et les versions 3.02 d'Aurora MySQL sont compatibles avec MySQL 8.0.23. Pour plus d'informations sur les changements apportés entre la version 8.0.23 et la version 8.0.28, consultez Notes de mise à jour de MySQL 8.0.

Note

Cette version est désignée comme version de support à long terme (LTS). Pour plus d'informations, consultez Versions Long-Term Support (LTS) d'Aurora MySQL dans le Guide de l'utilisateur Amazon Aurora.

Nous vous recommandons de ne pas définir le AutoMinorVersionUpgrade paramètre sur true (ou de ne pas activer la mise à niveau automatique des versions mineures dans AWS Management Console) pour les versions LTS. Cela pourrait entraîner la mise à niveau de votre cluster de base de données vers une version non LTS telle que la version 3.05.2.

Pour plus d'informations sur les nouvelles fonctionnalités d'Aurora MySQL version 3, consultez Aurora MySQL version 3 compatible avec MySQL 8.0. Pour connaître les différences entre Aurora MySQL version 3 et Aurora MySQL version 2, voir Comparaison entre Aurora MySQL version 2 et Aurora MySQL version 3. Pour une comparaison entre Aurora MySQL version 3 et MySQL 8.0 Community Edition, voir Comparaison entre Aurora MySQL version 3 et MySQL 8.0 Community Edition.

Les versions d'Aurora MySQL actuellement prises en charge sont les suivantes : 2.07.9, 2.11.1, 2.11.2, 3.01.*, 3.02.*, 3.03.* et 3.04.0.

Vous pouvez effectuer une mise à niveau sur place, restaurer un instantané ou lancer une mise à niveau bleu/vert gérée à l'aide d'un déploiement bleu/vert Amazon RDS à partir de n'importe quel cluster Aurora MySQL version 2 actuellement pris en charge vers un cluster Aurora MySQL version 3.04.0.

Pour en savoir plus sur la planification d'une mise à niveau vers Aurora MySQL version 3, consultez Planification de la mise à niveau d'Aurora MySQL version 3 dans le Guide de l'utilisateur Amazon Aurora. Pour obtenir des informations générales sur les mises à niveau d'Aurora MySQL, consultez Mise à niveau des clusters de bases de données Amazon Aurora MySQL dans le Guide de l'utilisateur Amazon Aurora.

Pour plus d'informations sur la résolution des problèmes, consultez Résolution des problèmes de mise à niveau avec Aurora MySQL version 3.

Si vous avez des questions ou des préoccupations, le AWS support est disponible sur les forums communautaires et via le AWS support. Pour plus d'informations, consultez Entretien d'un cluster de base de données Amazon Aurora dans le Guide de l'utilisateur Amazon Aurora.

Note

Le journal binaire amélioré Aurora MySQL n'est actuellement pas pris en charge par l'instance de base de données Aurora Serverless v2 sur Aurora MySQL version 3.04.0. L'activation de cette fonctionnalité peut entraîner l'indisponibilité de la base de données. Si vous avez besoin du journal binaire amélioré sur Aurora MySQL version 3.04.0, nous vous recommandons d'utiliser une classe d'instances de base de données non Serverless ou de définir les unités de capacité Aurora minimale et maximale l'instance de base de données Serverless v2 sur la même valeur.

Pour plus d'informations sur le journal binaire amélioré dans Aurora MySQL, consultez le Guide de l'utilisateur d'Aurora.

Améliorations

Nouvelles fonctions :

Problèmes de sécurité corrigés et CVEs :

  • Le fournisseur SSL/TLS est passé d'OpenSSL à. AWS-LC Ce remplacement entraîne un certain nombre de changements, notamment mais sans s'y limiter :

    • Les connexions aux bases de données utilisant le protocole SSL peuvent désormais être restaurées par redémarrage et par application de correctifs sans temps d'arrêt lors de la mise à niveau d'Aurora MySQL 3.04.0 vers une version ultérieure.

    • Support de la version 3, qui TLSv1 inclut le support des chiffrements SSL TLS_AES_128_GCM_, TLS_AES_256_GCM_ et TLS_ 0_ 05_SHA256. SHA384 CHACHA2 POLY13 SHA256

    • Arrêt de la prise en charge des chiffrements DHE-RSA-* les moins sécurisés.

    Pour plus d'informations, consultez Utilisation de TLS avec les clusters de bases de données Aurora MySQL

  • Ajout du privilège dynamique SHOW_ROUTINE qui permet à rds_superuser_role d'accéder aux définitions et aux propriétés de toutes les routines stockées, telles que les procédures et les fonctions stockées. Pour plus d'informations, consultez SHOW_ROUTINE.

  • Correction d'un problème pouvant entraîner l'omission d'événements dans le journal d'audit lors de la rotation du fichier d'audit.

  • Prise en charge du protocole TLS (Transport Layer Security) 1.3 sécurisé et performant, tout en préservant la compatibilité avec la version TLS 1.2.

  • Les versions TLS TLSv1 et TLSv1 .1 sont devenues obsolètes dans la version 8.0.26 de la communauté MySQL et, par conséquent, dans Aurora MySQL 3.03. Ces protocoles ont été supprimés de la version 8.0.28 de Community MySQL 8.0.28 et, par conséquent, d'Aurora MySQL 3.04. Par défaut, tout client sécurisé qui ne peut pas communiquer via le protocole TLS 1.2 ou version ultérieure sera rejeté. Pour plus d'informations sur la connexion à vos instances de base de données à l'aide du protocole TLS, consultez Sécurité avec Amazon Aurora MySQL.

Les correctifs CVE suivants sont inclus dans cette version :

Améliorations de la disponibilité :

  • Correction d'un problème qui pouvait provoquer le redémarrage de la base de données pendant une longue période de restauration de transactions.

  • Correction d'un problème lié au chiffrement des événements des flux d'activité des bases de données, susceptible de provoquer le redémarrage de la base de données.

  • Correction d'un problème de gestion de la mémoire causé par une mémoire insuffisante lors de l'initialisation du pool de tampons InnoDB au démarrage ou de la mise à l'échelle d'Aurora Serverless v2. Ce problème peut avoir entraîné des redémarrages d'instances de base de données ou une dégradation des performances, notamment une réduction du débit ou une augmentation de la latence.

  • Correction d'un problème qui pouvait provoquer le redémarrage d'une instance de lecteur Aurora MySQL lors de l'exécution d'une requête utilisant un plan d'exécution parallèle de requêtes Aurora MySQL.

  • Correction d'un problème qui, dans certaines situations, pouvait provoquer le redémarrage des instances du lecteur Aurora lors d'une estimation de plage.

  • Correction d'un problème qui pouvait interrompre la restauration de la base de données au démarrage si le redémarrage se produisait lors de l'exécution d'opérations d'insertion intensives impliquant l'incrémentation automatique de colonnes.

  • Correction d'un problème avec l'audit avancé Aurora qui entraîne une journalisation excessive des messages d'information dans le journal des erreurs d'Aurora MySQL lorsque la variable de serveur server_audit_events est définie sur ALL ou QUERY. Ce problème peut entraîner le redémarrage d'une instance de base de données.

  • Correction d'un problème qui pouvait provoquer le redémarrage de la base de données lors de l'annulation d'une INSERT instruction lorsque la requête parallèle était activée.

  • Correction d'un problème qui provoquait le redémarrage de l'instance de base de données lors de l'exécution de l'outil de EXPLAIN ANALYZE profilage sur une requête renvoyant le résultat all select tables were optimized away dans la colonne EXTRA d'informations. Pour plus d'informations, consultez Format de sortie EXPLAIN dans la documentation de MySQL.

  • Correction d'un problème qui provoquait le redémarrage d'une instance de lecteur de région secondaire de la base de données globale Aurora utilisant le transfert d'écriture global lorsqu'une instruction de validation implicite transférée rencontrait une erreur.

  • Correction d'un problème qui provoquait le redémarrage de l'instance d'écriture d'une région principale de base de données globale Aurora lorsqu'une SELECT FOR UPDATE requête était exécutée à l'aide du transfert d'écriture global depuis une région secondaire de base de données globale Aurora.

Améliorations générales :

  • Ajout d'une nouvelle procédure stockée, mysql.rds_gtid_purged, pour permettre aux clients de définir la variable système GTID_PURGED. Pour plus d'informations, consultez mysql.rds_gtid_purged.

  • Ajout de deux nouvelles procédures stockées, mysql.rds_start_replication_until et mysql.rds_start_replication_until_gtid, qui permettent aux clients de configurer une position pour l'arrêt de la réplication du journal binaire. Pour plus d'informations sur la configuration d'une position pour l'arrêt de la réplication du journal binaire dans Aurora MySQL, consultez mysql.rds_start_replication_until.

  • Correction d'un problème empêchant les procédures stockées de contrôle de la réplication Aurora MySQL de modifier la variable sql_log_bin lorsqu'elle est appelée à partir d'une session dont le mode autocommit est désactivé.

  • Ajout de la prise en charge de la réplication logique pour les instructions DCL (Data Control Language) suivantes : GRANT/REVOKE et CREATE/DROP/ALTER/RENAME USER.

  • Correction d'un problème empêchant l'obsolescence des statistiques d'InnoDB, ce qui pouvait parfois générer un plan d'exécution de requêtes sous-optimal qui pouvait entraîner une augmentation de la durée d'exécution des requêtes.

  • Ajout de deux nouvelles vues du système, information_schema.aurora_global_db_instance_status et information_schema.aurora_global_db_status. Ces vues peuvent être utilisées pour afficher le statut et la topologie des ressources principales et secondaires dans un cluster de base de données globale Aurora MySQL. Pour plus d'informations sur les deux vues du système, consultez Tables information_schema spécifiques à Aurora MySQL.

  • Correction d'un problème empêchant un utilisateur d'accéder à la base de données en utilisant un caractère générique dans le nom de la base de données après avoir exécuté l'instruction SET ROLE avec un caractère générique d'échappement.

  • Correction d'un problème susceptible d'empêcher l'écriture dans le journal d'audit d'événements signalés lors du traitement des rotations du journal d'audit.

  • Correction d'un problème de création de table temporaire interne, via une exécution TRIGGER, qui peut entraîner le redémarrage d'une instance de base de données d'enregistreur.

  • Ajout d'une nouvelle variable système, innodb_aurora_max_partitions_for_range. Si les statistiques persistantes ne sont pas disponibles, vous pouvez utiliser ce paramètre pour accélérer les estimations du nombre de lignes dans des tables partitionnées. Vous trouverez de plus amples informations dans la documentation intitulée Paramètres de configuration d'Aurora MySQL.

  • Correction d'un problème autorisant à tort les clients à définir ROW_FORMAT sur COMPRESSED lors de la création de tables partitionnées. Les tables seront implicitement converties au format COMPACT et un avertissement indiquera qu'Aurora MySQL ne prend pas en charge les tables compressées.

  • Correction d'un problème qui pouvait entraîner l'arrêt de la réplication des journaux binaires multithread lorsque la replica_parallel_type variable était définie sur LOGICAL_CLOCK et que la replica_preserve_commit_order variable était activée. ON Ce problème peut se produire lorsqu'une transaction supérieure à 500 Mo est exécutée sur la source.

  • Correction d'un problème d'activation de la fonctionnalité de transfert d'écriture dans une base de données globale, qui peut entraîner le transfert involontaire des modifications apportées à la configuration performance_schema des instances de lecteur des régions secondaires vers l'instance d'enregistreur de la région principale.

  • Correction d'un problème d'absence de mise à jour de la variable d'état du serveur innodb_buffer_pool_reads après la lecture d'une page de données dans le système de fichiers de stockage Aurora.

  • Les requêtes parallèles d'Amazon Aurora MySQL ne sont pas prises en charge lors du choix de la configuration du cluster Aurora I/O-Optimized. Pour plus d'informations, consultez Limites des requêtes parallèles pour Amazon Aurora MySQL.

  • Correction d'un problème d'activation des requêtes parallèles qui conduit l'optimiseur de plan de requêtes à choisir un plan d'exécution inefficace pour certaines requêtes SELECT bénéficiant d'un index principal ou secondaire.

  • Mise à niveau des définitions de fuseaux horaires vers la version IANA 2023c.

  • Optimisation des performances de la gestion des fichiers sur les réplicas de fichiers binaires afin de réduire les conflits d'écriture dans les fichiers journaux de relais.

  • Correction d'un problème en raison duquel la RPO_LAG_IN_MILLISECONDS colonne du information_schema.aurora_global_db_status tableau et de la AuroraGlobalDBRPOLag CloudWatch métrique affichait toujours zéro, quelle que soit la charge de travail de l'utilisateur.

  • Introduction d'un nouveau paramètre, aurora_tmptable_enable_per_table_limit. Lorsque ce paramètre est activé, la tmp_table_size variable définit la taille maximale de chaque table temporaire interne en mémoire créée par le moteur TempTable de stockage. Pour plus d'informations, consultez Moteur de stockage pour tables temporaires internes (implicites).

  • Correction d'un problème d'établissement d'une connexion supplémentaire lorsque la fonctionnalité de transfert d'écriture dans une base de données globale est activée. Le problème se produit lorsque des transactions en lecture seule sur une instance de lecteur transmettent de manière incorrecte une instruction implicit commit à l'enregistreur.

  • Correction d'un problème de renseignement des champs PROCESSLIST_USER et PROCESSLIST_HOST de la table performance_schema.threads sur l'enregistreur de la région principale pour les connexions utilisant la fonctionnalité de transfert d'écriture dans la base de données globale. Vous trouverez plus d'informations sur cette table et ce schéma de performance dans le manuel de référence MySQL, The threads Table, et le guide de l'utilisateur Présentation du schéma de performance.

  • Correction d'un problème d'affichage de valeurs incorrectes dans la métrique CommitLatency CloudWatch pour les instances de lecteur des régions secondaires lorsque la fonctionnalité de transfert d'écriture dans la base de données globale est utilisée. Pour surveiller la latence des instructions DML transférées sur des clusters de bases de données secondaires, il est recommandé d'utiliser les métriques ForwardingReplicaDMLLatency et ForwardingWriterDMLLatency La latence de la validation peut également être observée à l'aide de la métrique CommitLatency sur l'instance d'enregistreur de la région principale. De plus amples informations sont disponibles dans le guide de l'utilisateur d'Aurora, Amazon CloudWatch metrics for write forwarding.

  • Correction d'un problème de signalement inapproprié d'erreurs par les procédures stockées de contrôle de la réplication Aurora MySQL utilisées pour gérer et configurer la réplication du journal binaire lorsque la réplication multithread dans le journal binaire est configurée avec une valeur supérieure à 0 pour la variable replica_parallel_workers.

  • Correction d'un problème qui pouvait entraîner une consommation élevée du processeur lorsque plusieurs sessions tentaient d'accéder à une page qui n'existe pas en mémoire.

Mises à niveau et migrations :

  • Pour effectuer la mise à niveau d'une version mineure d'une base de données globale Aurora MySQL version 3.01, 3.02 ou 3.03 vers Aurora MySQL version 3.04 ou ultérieure, consultez Mise à niveau d'Aurora MySQL par modification de la version du moteur.

  • Correction d'un problème susceptible de faire échouer la prévérification de la mise à niveau en raison d'incohérences de schéma signalées pour les tables mysql.general_log_backup, mysql.general_log, mysql.slow_log_backup et mysql.slow_log lors de la mise à niveau d'Aurora MySQL 2 vers Aurora MySQL 3. Pour plus d'informations sur la résolution des problèmes, consultez Résolution des problèmes de mise à niveau avec Aurora MySQL version 3.

  • Correction d'un problème pouvant provoquer l'échec de mises à niveau majeures lors de la mise à niveau vers Aurora MySQL version 3 si la définition d'un déclencheur contient un mot-clé réservé qui n'est pas entre guillemets.

Intégration de correctifs de bogues de l'édition MySQL Community Edition

Outre les corrections ci-dessous, cette version inclut tous les correctifs de bogues jusqu'à la version 8.0.28 incluse. Pour plus d'informations, consultez Corrections de bogues effectuées par les mises à jour du moteur de base de données d'Aurora MySQL 3.x.

  • Correction d'un problème de déplacement d'un bloc de mémoire tampon contenant une page de table temporaire intrinsèque lors du parcours d'une page, provoquant un échec d'assertion (Bogue n° 33715694)

  • InnoDB : empêcher les opérations DDL en ligne d'accéder à la out-of-bounds mémoire (bogue n° 34750489, bogue n° 108925)

  • Correction d'un problème qui pouvait parfois produire des résultats de requête incorrects lors du traitement d'instructions SQL complexes composées de plusieurs expressions de table communes imbriquées (CTEs) (bogue n° 34572040, bogue n° 34634469, bogue n° 33856374)