Mises à jour du moteur de base de données Aurora MySQL 2024-06-04 (version 3.07.0, compatible avec MySQL 8.0.36)

Support activé pour la cryptographie validée par la norme FIPS, une implémentation entièrement détenue. AWS Pour plus d'informations, consultez la section « AWS-LC est désormais certifiée FIPS 140-3 » sur le AWS blog de sécurité.

CVE-2020-11104

CVE-2020-11105

CVE-2023-38545

CVE-2023-38546

CVE-2023-39975

Correction d'un problème qui pouvait provoquer le redémarrage d'une instance de base de données de lecteur lors de la lecture d'une table modifiée ou supprimée sur l'instance de base de données d'écriture.

Correction d'un problème qui pouvait provoquer le redémarrage d'une instance de base de données Aurora MySQL Writer lorsqu'une session de transfert d'écriture était fermée lors de l'exécution d'une requête transférée.

Correction d'un problème qui provoquait le redémarrage d'une instance de base de données lors de la gestion de grands ensembles GTID sur une instance activée pour les journaux binaires.

Correction d'un problème lors du traitement des INSERT requêtes sur des tables partitionnées InnoDB qui pouvait entraîner une diminution progressive de la mémoire libre dans l'instance.

Correction d'un problème qui, dans de rares cas, pouvait entraîner le redémarrage des instances de base de données du lecteur.

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 exécutée pour respecter la période de conservation du journal binaire configurée par l'utilisateur.

Correction d'un problème qui pouvait provoquer la fermeture inattendue du serveur après l'exécution d'instructions DML (Data Manipulation Language) sur une table dont les colonnes non virtuelles étaient réorganisées avec une MODIFY COLUMN instruction or. CHANGE COLUMN

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 qui pouvait provoquer le redémarrage d'une instance de base de données de lecteur utilisant le transfert d'écriture lorsqu'une instruction de validation implicite transférée rencontrait une erreur.

Correction d'un problème qui, dans de rares cas, pouvait provoquer le redémarrage d'une instance de lecteur lors de l'exécution de SELECT requêtes sur des tables soumises à une contrainte de clé étrangère.

Correction d'un problème selon lequel les instances de base de données utilisant des volumes de cluster Aurora de plusieurs To pouvaient subir des temps d'arrêt accrus lors du redémarrage en raison d'échecs de validation du pool de mémoire tampon InnoDB.

Correction d'un problème qui provoquait le redémarrage d'une base de données lorsqu'une contrainte de clé DELETE étrangère UPDATE ou en cascade était définie sur une table où une colonne virtuelle était impliquée soit en tant que colonne dans la contrainte de clé étrangère, soit en tant que membre de la table référencée.

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 d'opérations d'insertion intensives impliquant des AUTO_INCREMENT colonnes.

Correction d'un problème dans Aurora Serverless v2 cela peut entraîner le redémarrage de la base de données lors de la mise à l'échelle.

Réduction de l'utilisation des E/S et amélioration des performances pour un sous-ensemble de requêtes d'analyse par plage de clés primaires utilisant une requête parallèle.

La version 3.06.0 d'Aurora MySQL a ajouté le support pour l'intégration d'Amazon Bedrock. Dans ce cadre, de nouveaux mots clés réservés (accept,aws_bedrock_invoke_model, aws_sagemaker_invoke_endpointcontent_type, ettimeout_ms) ont été ajoutés. Dans Aurora MySQL version 3.07.0, ces mots clés ont été remplacés par des mots clés non réservés, qui sont autorisés comme identifiants sans guillemets. Pour plus d'informations sur la façon dont MySQL gère les mots clés réservés et non réservés, consultez la section Mots clés et mots réservés dans la documentation MySQL.

Correction d'un problème qui ne renvoyait pas clairement de message d'erreur au client lors de l'appel du service Amazon Bedrock depuis un cluster de base de données Aurora MySQL alors qu' Région AWS Amazon Bedrock n'était pas encore disponible.

Correction d'un problème qui pouvait entraîner une consommation de mémoire excessive lors de l'interrogation de BLOB colonnes à l'aide de la requête parallèle Aurora.

Ajout de la prise en charge connection_memory_limit des connection_memory_chunk_size paramètres et à définir au niveau de la session pour qu'ils se comportent de la même manière que dans MySQL Community Edition. Le connection_memory_limit est utilisé pour définir la quantité maximale de mémoire pouvant être utilisée par une connexion utilisateur unique. Le connection_memory_chunk_size paramètre peut être utilisé pour définir la taille de segmentation pour les mises à jour du compteur global d'utilisation de la mémoire.

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.

Ajout de la variable d'état Aurora_fts_cache_memory_used globale pour suivre l'utilisation de la mémoire par le système de recherche en texte intégral dans toutes les tables. Pour plus d'informations, consultez les variables d'état globales Aurora MySQL dans le guide de l'utilisateur Amazon Aurora.

Correction d'un problème selon lequel un cluster Amazon Redshift configuré comme destination zéro ETL pouvait subir une augmentation temporaire IntegrationLaglorsqu'un cluster de base de données Amazon Aurora MySQL était configuré en tant que réplique de journal binaire, avec une intégration Binlog améliorée et Zero-ETL activée.

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.

Problème résolu : l'événement wait/io/redo_log_flush n'apparaissait pas dans les tableaux récapitulatifs des événements d'attente du schéma de performance.

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 provoquait le redémarrage d'une instance de base de données d'écriture lorsqu'une instance de base de données de lecture utilisant le transfert d'écriture exécutait une instruction DML (Data Manipulation Language) contenant une valeur d'horodatage et que le paramètre de time_zone base de données était défini sur. UTC

Problème résolu : une SELECT requête sur une instance de lecteur Aurora pouvait échouer en raison de l'inexistence de la table d'erreurs lorsque la table contient au moins un index de recherche en texte intégral (FTS) et qu'une TRUNCATE instruction est exécutée sur l'instance de base de données Aurora Writer.

Correction d'un problème qui, dans de rares cas, entraînait l'échec des correctifs sans interruption de service (ZDP).

Correction d'un problème qui pouvait entraîner un ensemble de résultats incomplet lors de l'exécution de requêtes impliquant LEFT JOIN ou d'RIGHT JOINopérations utilisant l'algorithme de jointure par hachage avec requête parallèle.

Correction d'un problème qui pouvait provoquer des échecs de mise à niveau d'Aurora MySQL version 2 vers Aurora MySQL version 3 lorsqu'une FTS_DOC_ID colonne définie par l'utilisateur était présente dans le schéma de table.

Correction d'un problème qui pouvait provoquer des échecs de mise à niveau d'Aurora MySQL version 2 vers Aurora MySQL version 3 en raison d'un problème de synchronisation lors du traitement des tablespaces InnoDB.

Correction d'un problème qui pouvait entraîner l'échec des mises à niveau majeures vers Aurora MySQL version 3 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.

Correction d'un problème en raison duquel la valeur SERVER_ID n'était pas mise à jour après le passage au mode bleu/vert d'Amazon RDS. Cela a entraîné des problèmes : les pilotes intelligents tels que le pilote JDBC Amazon Web Services (AWS) étaient incapables de découvrir la topologie du cluster de bases de données après un blue/green switchover. With this fix, Aurora DB clusters renamed as part of an RDS Blue/Green déploiement, qui s'exécutaient sur Aurora MySQL version 3.07 ou supérieure, et dont la SERVER_ID valeur était mise à jour dans le cadre du passage au numérique. Pour les versions antérieures, les instances de base de données des clusters bleu et vert peuvent être redémarrées pour mettre à jour la SERVER_ID valeur.

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)

Correction d'un problème en raison duquel certaines instances de sous-requêtes dans les routines stockées n'étaient pas traitées correctement. (Correctif de bogue communautaire #35377192)

Correction d'un problème qui pouvait entraîner une augmentation de l'utilisation du processeur en raison de la rotation des certificats TLS en arrière-plan (Community Bug Fix #34284186).

Correction d'un problème en raison duquel InnoDB autorisait l'ajout de INSTANT colonnes aux tables dans le schéma système MySQL dans les versions d'Aurora MySQL inférieures à 3.05, ce qui pouvait entraîner la fermeture inattendue du serveur (redémarrage de l'instance de base de données) après la mise à niveau vers la version 3.05.0 d'Aurora MySQL. (Correctif de bogue communautaire #35625510).