Mises à jour du moteur de base de données Aurora MySQL 2024-03-15 (version 3.04.2, compatible avec MySQL 8.0.28)

Version : 3.04.2

Aurora MySQL 3.04.2 est généralement disponible. Les versions 3.04 d'Aurora MySQL sont compatibles avec MySQL 8.0.28. Pour plus d'informations sur les modifications apportées à la communauté, consultez les notes de mise à jour de MySQL 8.0.

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 plus d'informations sur les différences entre Aurora MySQL version 3 et Aurora MySQL version 2, consultez 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, consultez Comparaison entre Aurora MySQL version 3 et MySQL 8.0 Community Edition.

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.

Les versions d'Aurora MySQL actuellement prises en charge sont les suivantes : 2.07.9, 2.7.10, 2.11.*, 2.12.*, 3.03.*, 3.04.*, 3.05.* et 3.06.*.

Vous pouvez effectuer une mise à niveau sur place, restaurer un instantané ou lancer une mise à niveau bleu/vert gérée à l'aide d'Amazon RDS Blue/Green Deployments depuis n'importe quel cluster Aurora MySQL version 2 actuellement disponible vers un cluster Aurora MySQL version 3.04.2.

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.

Améliorations

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

Les correctifs CVE suivants sont inclus dans cette version :

• CVE-2020-11104

• CVE-2020-11105

• CVE-2023-38545

• CVE-2023-38546

• CVE-2023-39975

Améliorations de la disponibilité :

• Correction d'un problème en raison duquel une instance de base de données de réplication en lecture ne pouvait pas être lancée correctement lorsque la charge de travail de l'instance de base de données d'écriture était élevée.

• Correction d'un problème à cause duquel une instance de base de données Aurora MySQL Writer pouvait basculer en raison d'un défaut du composant qui communique avec le stockage Aurora. Le défaut est dû à une rupture de communication entre l'instance de base de données et le stockage sous-jacent suite à une mise à jour logicielle.

• Correction d'un problème qui pouvait provoquer le redémarrage d'une instance de base de données lors de l'exécution simultanée des instructions SHOW STATUS et PURGE BINARY LOGS. PURGE BINARY LOGSest une instruction gérée qui est exécutée pour respecter la période de conservation du journal binaire configurée par l'utilisateur.

• Correction d'un problème qui, lors du redémarrage d'une instance de base de données, pouvait entraîner un redémarrage supplémentaire.

• Correction d'un problème de conflit de verrou causé par un thread de journalisation d'audit pouvant conduire à une utilisation élevée du processeur et à des dépassements de délai d'attente pour les applications clientes.

• Correction d'un problème en raison duquel une instance de base de données Aurora MySQL pouvait subir plusieurs redémarrages au démarrage de l'instance alors que de grands segments de restauration étaient initialisés.

• Correction d'un problème qui pouvait provoquer le redémarrage d'une instance de base de données lors de l'exécution d'une requête faisant référence à une fonction d'agrégation.

Améliorations générales :

• Correction d'un problème qui pouvait entraîner l'échec d'une requête parallel en raison de problèmes réseau transitoires lors de la lecture de données depuis le volume du cluster de base de données Aurora

• Correction d'un problème empêchant l'utilisateur d'interrompre une requête ou de définir des délais d'expiration de session pour les performance_schema requêtes.

• Problème résolu : la réplication du journal binaire (binlog) configurée pour utiliser des certificats SSL personnalisés (mysql.rds_import_binlog_ssl_material) pouvait échouer lorsque l'instance de réplication était en cours de remplacement d'hôte.

• Correction d'un problème lié à la gestion des fichiers journaux d'audit qui pouvait rendre les fichiers journaux inaccessibles pour le téléchargement ou la rotation et, dans certains cas, augmenter l'utilisation du processeur.

• Restauration des AUTO_INCREMENT clés optimisée pour réduire le temps nécessaire à la restauration des instantanés, à la point-in-time restauration et au clonage de clusters de bases de données contenant un grand nombre de tables dans la base de données.

• Correction d'un problème à cause duquel les instructions SQL faisant référence à certaines performance_schema tables pouvaient renvoyer une erreur en raison de l'absence de ces tables après la migration de Community MySQL vers les versions 3.04.0 et 3.04.1 d'Aurora MySQL.

• Correction d'un problème en raison duquel les petites instances de répliques en lecture pouvaient subir un délai de réplication accru après une mise à niveau à partir de versions d'Aurora MySQL inférieures à 2.11.*.

• Correction d'un problème qui pouvait provoquer des erreurs clés dupliquées pour les AUTO_INCREMENT colonnes utilisant des index décroissants après une restauration instantanée, un retour en arrière ou une opération de clonage de base de données.

• Correction d'un problème qui empêchait les modifications du paramètre de table_open_cache base de données de prendre effet tant que l'instance de base de données n'était pas redémarrée.

• Correction d'un problème qui empêchait l'instance de base de données du lecteur d'ouvrir une table, avec une erreur 1146. Ce problème se produit lors de l'exécution de certains types d'instructions DDL (Data Definition Language) en ligne alors que l'INPLACEalgorithme est utilisé sur l'instance de base de données Writer.

• Correction d'un problème empêchant le redémarrage de l'instance pendant la mise à l'échelle d'Aurora Serverless v2 lorsque le processus de surveillance interne soumet par erreur des demandes de mise à l'échelle en double.

• Correction d'un problème qui pouvait provoquer le redémarrage de la base de données lorsque les consommateurs de journaux binaires (binlog) connectés utilisaient des identifiants de serveur de réplication de journaux binaires dupliqués.

Mises à niveau et migrations :

• Correction d'un problème qui pouvait entraîner l'échec des mises à niveau majeures vers la version 3 d'Aurora MySQL en raison de la présence d'entrées orphelines pour des espaces disque logiques déjà supprimés dans les tables système InnoDB d'Aurora MySQL version 2.

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

Cette version inclut toutes les corrections de bogues communautaires jusqu'à la version 8.0.28 incluse, en plus des suivantes. 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 en raison duquel la valeur de la ligne de cache pouvait être calculée de manière incorrecte, ce qui provoquait un échec lors du redémarrage de la base de données sur les instances basées sur Graviton. (Correctif de bogue communautaire #35479763)

• L'exécution répétée d'une routine stockée, ayant comme sous-requête une instruction SELECT contenant plusieurs ou XOR conditions ANDOR, a entraîné une consommation excessive et éventuellement un épuisement de la mémoire virtuelle. (Correctif de bogue communautaire #33852530)