Aurora MySQL 8.4.8, 3 septembre 2026

Ajout de la prise en charge de la réplication de journaux binaires (binlog) multi-sources. Cette fonctionnalité permet à un cluster de bases de données Aurora MySQL de répliquer des données provenant de plusieurs bases de données MySQL-compatible sources en même temps. Chaque connexion source est gérée via un canal de réplication dédié avec son propre thread récepteur, ses propres fils applicateurs et son journal de relais. Vous pouvez configurer et gérer les canaux à l'aide de nouvelles procédures stockées par canal. Pour plus d'informations, consultez la section Utilisation de la réplication multisource avec Aurora MySQL dans le guide de l'utilisateur Amazon Aurora.

Ajout de la prise en charge de la réplication différée des journaux binaires (binlog), dans laquelle un cluster de bases de données Aurora MySQL agissant comme une réplique du journal binaire peut être configuré pour attendre un certain nombre de secondes avant d'appliquer les transactions reçues de la source. La réplication différée peut être utilisée pour vous protéger contre les modifications accidentelles des données, telles que des modifications involontaires DROP TABLE ou DELETE des instructions. Vous disposez ainsi d'une fenêtre de restauration permettant d'identifier et de corriger les erreurs avant qu'elles ne se propagent à la réplique. Pour plus d'informations, consultez la section Configuration de l'intervalle de délai de réplication dans le guide de l'utilisateur Amazon Aurora.

A introduit le aurora_transaction_timeout paramètre. Ce paramètre définit la durée maximale, en secondes, d'une transaction InnoDB. Vous pouvez utiliser ce paramètre pour empêcher que des transactions de longue durée (actives ou inactives) ne bloquent la purge d'InnoDB, ce qui peut entraîner des problèmes de performances. Pour plus d'informations, consultez la section Délai d'expiration des transactions Aurora MySQL dans le guide de l'utilisateur Amazon Aurora.

Ajout de la prise en charge de l'échange de clés hybrides post-quantiques (X25519MLKEM768 et SecP256R1MLKEM768) pour les connexions TLS 1.3. Les clients qui prennent en charge l'échange de clés post-quantique négocient automatiquement un secret partagé résistant au quantum. Pour confirmer le groupe négocié par la session en cours, interrogez la variable Aurora_ssl_named_group d'état. Par exemple : SHOW STATUS LIKE 'Aurora_ssl_named_group';.

Correction d'un problème en raison duquel le journal d'audit avancé enregistrait un utilisateur et un hôte incorrects pour les instructions SQL exécutées dans une routine SQL SECURITY DEFINER (procédure stockée, fonction ou déclencheur). Ces enregistrements indiquaient l'utilisateur et l'hôte du définisseur de la routine (par exemple'user'@'%') au lieu du client SQL qui avait invoqué la routine. Après ce correctif, les enregistrements indiquent l'utilisateur et l'hôte du client SQL à l'origine de l'appel.

Correction d'un problème à cause duquel les requêtes exécutées via des instructions préparées pouvaient générer des entrées dupliquées dans le journal d'audit avancé.

Correction d'un problème qui SET ROLE NONE empêchait d'effacer correctement les privilèges d'un rôle précédemment actif dans les sessions utilisant le transfert d'écriture, ce qui pouvait autoriser des opérations qui auraient dû être refusées après la désactivation du rôle.

CVE-2026-46863

CVE-2026-60163

CVE-2026-61094

CVE-2026-21936

CVE-2026-21937

CVE-2026-21941

CVE-2026-21948

CVE-2026-21968

CVE-2026-60585

CVE-2026-60332

CVE-2026-60331

CVE-2026-60747

CVE-2026-47023

CVE-2026-60186

CVE-2026-60184

CVE-2026-60185

CVE-2026-60187

CVE-2026-60188

CVE-2026-60189

CVE-2026-60191

CVE-2026-60190

Correction d'un problème qui pouvait entraîner le redémarrage d'une instance de base de données ADD PARTITION lors de l'exécution ALTER TABLE ... REORGANIZE PARTITION ou lorsque des opérations simultanées (telles que des requêtes de schéma de performances, l'optimisation de la recherche en texte intégral ou la collecte de statistiques) accédaient à la même table. DROP PARTITION

Correction d'un problème qui peut provoquer le redémarrage d'une instance de base de données lorsque des requêtes sont activées performance_schema.data_lock_waits ou performance_schema.data_locks exécutées simultanément avec des tables dont ALTER TABLE ... REORGANIZE PARTITION des colonnes ont été ajoutées à l'aide ALGORITHM=INSTANT de.

Correction d'un problème qui pouvait entraîner le redémarrage de l'instance de rédaction lors du traitement d'une ALTER TABLE ... REORGANIZE PARTITION instruction SQL modifiant l'ordre des sous-partitions.

Correction d'un problème à cause duquel les opérations DDL sur l'instance d'écriture pouvaient bloquer ou supprimer certaines instructions SQL sur les instances de lecture. Les instructions concernées comprenaient les opérations d'écriture telles que UPDATE ou TRUNCATE sur performance_schema des tables, et les opérations d'écriture sur des tables et JOIN des opérations temporaires.

Correction d'un problème à cause duquel l'instance du rédacteur de base de données pouvait redémarrer de manière inattendue lors d'une opération de basculement global de la base de données lors du nettoyage des tables temporaires après le traitement des instructions SQL. Ce redémarrage peut entraîner un allongement du temps de transition.

Correction d'un problème qui pouvait entraîner l'arrêt du fonctionnement du transfert d'écriture sur une instance de base de données de lecteur, nécessitant un redémarrage du lecteur pour rétablir le transfert d'écriture. Cela peut se produire lorsqu'une requête transférée a été annulée ou a expiré lors de l'utilisation du transfert d'écriture global ou du transfert d'écriture local.

Correction d'un problème en raison duquel un retard dans le redimensionnement de la structure de données critique pendant les opérations de dimensionnement pouvait entraîner le redémarrage de Aurora serverless l'instance de base de données par la surveillance de l'état RDS.

Correction d'un problème qui pouvait entraîner le redémarrage de l'instance de rédaction en raison d'un conflit de synchronisation interne lors d'opérations d'écriture hautement simultanées.

Correction d'un problème qui pouvait entraîner le redémarrage d'une instance de base de données lorsque le binlog amélioré était activé.

Correction d'un bogue qui pouvait provoquer une brève déconnexion et une reconnexion de la réplique à l'enregistreur, ce qui provoquait un pic temporaire du décalage de réplication (AuroraReplicaLag).

Correction d'un problème dans le démon de stockage Aurora qui, dans de rares cas, pouvait entraîner un redémarrage inattendu de la base de données.

Correction d'un problème à cause duquel, lorsque le transfert d'écriture était activé, une session de lecture aurora_replica_read_consistency définie sur global risquait de ne pas lire les dernières modifications validées.

Correction d'un problème qui pouvait entraîner le redémarrage du moteur lorsqu'une requête SIG Z-order spatiale utilisait un index spatial sur une colonne déclarée avec une annotation SRID explicite.

Correction d'un problème à cause duquel des déconnexions régulières du lecteur pouvaient être incrémentées de manière incorrecte Aborted_clients sur l'instance d'écriture lorsque le transfert d'écriture était activé.

Correction d'un problème en raison duquel, dans certains cas, l'état de connexion n'était pas préservé après une mise à niveau sans interruption, ce qui pouvait entraîner un comportement inattendu.

Correction d'un problème à cause duquel, pendant le transfert d'écriture, le redémarrage d'une instance de lecteur pouvait laisser une session de transfert orpheline sur l'instance d'écriture, et l'arrêt de cette session pouvait entraîner le redémarrage de l'enregistreur.

Réduction des temps d'arrêt lors de l'application de correctifs sans interruption (ZDP) en optimisant la communication entre l'instance de base de données et la couche de stockage après l'application des correctifs.

Correction d'un problème lié à la gestion de la mémoire Aurora MySQL qui empêchait de désactiver de manière fiable les actions de réponse hors mémoire (OOM) après un délai d'expiration interne en cas de modification simultanée de la valeur du paramètre de aurora_oom_response base de données.

Correction d'un problème dans Enhanced Binlog qui signalait des coordonnées de journal binaire incorrectes après la restauration d'un instantané. Auparavant, cela pouvait entraîner une configuration de réplication de journal binaire non valide lorsque Enhanced Binlog s'exécutait sur le cluster source et que certaines transactions étaient annulées.

Correction d'un problème dans la fonction de restauration par incrémentation automatique qui empêchait de récupérer correctement les valeurs d'incrémentation automatique des tables partitionnées, ce qui pouvait entraîner des erreurs DUPLICATE KEY.

Ajout d'une nouvelle CloudWatch métriqueAuroraTempTableVolumeTotalBytes, qui indique le volume total d'octets du cluster utilisés par les tablespaces temporaires internes et externes d'InnoDB sur les instances de Writer. Cette métrique indique la consommation de stockage temporaire des tablespaces pour toutes les sessions actives. Vous pouvez l'utiliser pour suivre les tendances de croissance, identifier les charges de travail gourmandes en stockage et définir des alarmes. CloudWatch Pour plus d'informations sur cette métrique, consultez la section CloudWatch Statistiques Amazon pour Amazon Aurora dans le guide de l'utilisateur Amazon Aurora. Pour plus d'informations sur les tables temporaires, consultez les sections tables temporaires externes et tables temporaires internes sur le site Web de MySQL.

Correction d'un problème en raison duquel les métriques de débit de transfert d'écriture et de latence signalaient à tort 0 après un événement de basculement sur des clusters où le transfert d'écriture était activé. Ces mesures reflètent désormais avec précision l'activité de transfert d'écriture suite à un basculement :ForwardingReplicaDMLLatency, ForwardingReplicaDMLThroughputForwardingReplicaSelectLatency, et. ForwardingReplicaSelectThroughput

Correction d'un problème de performances en raison duquel l'optimiseur sélectionnait un plan d'exécution de requêtes sous-optimal avec des instructions préparées utilisant des valeurs IN paramétrées.

Correction d'un problème en raison duquel les requêtes utilisant des jointures par hachage renvoyaient des résultats incorrects lorsque la requête parallèle est activée et que la mémoire requise pour une jointure par hachage dépasse la limite.

Correction d'un problème en raison duquel les opérations de clonage de clusters de bases de données pouvaient prendre plus de temps à se terminer.

Correction d'une régression introduite dans MySQL 8.0.42 où l'insertion dans une table partitionnée à l'aide d'une instruction préparée ou d'une procédure stockée pouvait échouer avec ERROR 1748 (« Une ligne trouvée ne correspondant pas à l'ensemble de partitions donné »). Cela s'est produit lorsque la colonne de clé de partition est utiliséeDEFAULT CURRENT_TIMESTAMP. L'élagage des partitions au moment de la préparation verrouillait une partition en fonction de l'horodatage actuel, mais lors d'une réexécution ultérieure, l'horodatage pouvait correspondre à une autre partition. Pour plus d'informations sur ce correctif, consultez le bug #119784 en amont de MySQL sur le site Web MySQL Bugs.