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 2026-08-27 (version 3.13.0, compatible avec MySQL 8.0.45)
**Version : ** 3.13.0
Aurora MySQL 3.13.0 est désormais disponible pour tous et est compatible avec MySQL 8.0.45. Pour plus d'informations sur les modifications apportées à la communauté, consultez les notes de version de [ MySQL 8.0 ](https://dev.mysql.com/doc/relnotes/mysql/8.0/en/) sur le site Web de MySQL.
Pour plus d'informations sur les nouvelles fonctionnalités d'Aurora MySQL version 3, consultez [Aurora MySQL version 3 compatible avec MySQL 8.0](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.MySQL80.html).
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](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Compare-v2-v3.html).
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 ](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Compare-80-v3.html) dans le guide de l'utilisateur * Amazon Aurora*.
Vous pouvez effectuer une mise à niveau depuis n'importe quel cluster Aurora MySQL version 2 actuellement pris en charge vers un cluster Aurora MySQL version 3.13.0 de trois manières : effectuer une mise à niveau sur place à l'aide de [ Zero Downtime Patching (ZDP)](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Updates.ZDP.html), restaurer un snapshot ou lancer une mise à blue/green niveau gérée à l'aide d'Amazon RDS Deployments. [ Blue/Green ](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/blue-green-deployments-overview.html)
Pour plus d'informations sur la planification d'une mise à niveau vers la version 3 d'Aurora MySQL, voir [ Planification d'une mise à niveau majeure pour un cluster Aurora MySQL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Updates.MajorVersionUpgrade.html#AuroraMySQL.Upgrading.Planning). Pour obtenir des informations générales sur la mise à niveau, consultez [ la section Mise à niveau des clusters de bases de données Aurora MySQL ](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Updates.Upgrading.html) dans le guide de l'utilisateur * Amazon Aurora*.
Pour plus d'informations sur la résolution des problèmes, consultez la section [ Résolution des problèmes liés à la mise à niveau sur place d'Aurora MySQL ](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Updates.MajorVersionUpgrade.html#AuroraMySQL.Upgrading.Troubleshooting) dans le guide * de l'utilisateur * Amazon Aurora.
Si vous avez des questions ou des préoccupations, Support est disponible sur les forums de la communauté et via [Support](https://aws.amazon.com/support). Pour plus d'informations, consultez la section [ Gestion d'un cluster de base de données Aurora ](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_UpgradeDBInstance.Maintenance.html) dans le guide de l'utilisateur * Amazon Aurora*.
## Améliorations
### Correctifs de sécurité
Cette version inclut des correctifs pour les CVE de haute gravité suivants :
+ [CVE-2026-46863](https://www.cve.org/CVERecord?id=CVE-2026-46863)
Cette version inclut des correctifs pour les CVE de gravité moyenne suivants :
+ [CVE-2026-21936](https://www.cve.org/CVERecord?id=CVE-2026-21936)
+ [CVE-2026-21937](https://www.cve.org/CVERecord?id=CVE-2026-21937)
+ [CVE-2026-21941](https://www.cve.org/CVERecord?id=CVE-2026-21941)
+ [CVE-2026-21948](https://www.cve.org/CVERecord?id=CVE-2026-21948)
+ [CVE-2026-21968](https://www.cve.org/CVERecord?id=CVE-2026-21968)
### Améliorations de disponibilité
+ 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'échec de la création d'un nouveau cluster de bases de données, nécessitant sa suppression et sa recréation.
+ Correction d'un problème dans le mécanisme d'évitement de la mémoire insuffisante (OOM) qui pouvait provoquer le redémarrage d'une instance de base de données lors d'une tentative de restauration de la mémoire sous une pression de mémoire critique.
+ Correction d'un problème qui pouvait entraîner le redémarrage répété de l'instance de rédaction lorsque l'instance d'écriture redémarrait lors de la purge d'un enregistrement d'annulation pour une table contenant des index sur des colonnes virtuelles.
+ Correction d'un problème qui pouvait entraîner le redémarrage des répliques de lecture lorsque l'instance d'écriture effectuait une transaction importante avec binlog activé. Ce problème peut également provoquer des erreurs lors de la lecture du fichier binlog contenant la transaction importante.
+ Correction d'un problème en raison duquel un retard dans le redimensionnement du pool de mémoire tampon InnoDB pendant Aurora serverless les opérations de dimensionnement pouvait empêcher l'instance de base de données de répondre et de redémarrer.
+ Correction d'un problème à cause duquel une instance de lecteur pouvait redémarrer à plusieurs reprises après avoir été redémarrée alors que l'instance de rédaction effectuait une purge forcée des journaux d'annulation.
+ Correction d'un problème qui pouvait provoquer le redémarrage d'une instance de base de données d'écriture lorsqu'une instance de base de données de lecteur redémarrait alors que le transfert d'écriture local ou global était activé.
+ Correction d'un problème qui pouvait provoquer un redémarrage inattendu de la base de données sur les instances de lecteur lorsque les sous-requêtes utilisant des requêtes de requêtes parallèles n'étaient pas correctement fermées à la fin.
+ Correction d'un problème en raison duquel une instance de réplication pouvait redémarrer lors de l'exécution d'instructions préparées par protocole binaire qui étaient transmises à l'auteur via le transfert d'écriture.
+ 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.
+ Amélioration des performances de la réplication physique Aurora en appliquant les modifications apportées par l'instance d'écriture aux instances de lecture utilisant plusieurs threads.
### Améliorations générales
+ 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 peu fréquent qui pouvait entraîner le redémarrage de l'instance de base de données lorsque des instructions SQL en cours étaient lues à partir de tables temporaires lors du redimensionnement du pool de mémoire tampon ou des opérations d'expulsion de pages.
+ Correction de l'ordre des validations sur les répliques de binlog avec Enhanced Binlog activé pour respecter correctement le paramètre. `replica_preserve_commit_order` Ce comportement de classement n'a pas affecté l'intégrité des données ni provoqué de conflits entre les transactions, car il ne s'appliquait qu'au séquençage des transactions non dépendantes.
+ Correction d'un problème qui pouvait entraîner le renvoi des résultats de requête dans l'ordre croissant au lieu de l'ordre décroissant demandé lors de l'utilisation `ORDER BY DESC` avec une comparaison de plages et`LIMIT`.
+ Correction d'un problème de disponibilité du cluster qui pouvait survenir lors des mises à niveau du serveur de base de données lorsque les opérations DML sur les tables système faisaient référence à des valeurs d'incrémentation automatique obsolètes.
+ Correction d'un problème qui pouvait provoquer des erreurs de réplication lors du traitement d'événements binlog supérieurs à la taille de cache `aurora_in_memory_relaylog` fixe (128 Mo).
+ Correction d'un problème à cause duquel le lecteur génère des rapports `ERROR 1146` (tableau introuvable) lors de certaines opérations DDL en ligne sur l'enregistreur lors de l'utilisation de l'`INPLACE`algorithme.
+ Correction d'un problème qui pouvait retarder la disponibilité des instances lors d'opérations de correction sans interruption (ZDP) ou de redémarrage sans interruption (ZDR).
+ 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.
### Mises à niveau et migrations
+ 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.
## Intégration de correctifs de bogues de l'édition MySQL Community Edition
Cette version inclut toutes les corrections de bogues de la communauté jusqu'à la version 8.0.45 incluse. Pour de plus amples informations, veuillez consulter [Corrections de bogues effectuées par les mises à jour du moteur de base de données d'Aurora MySQL 3.x](AuroraMySQL.Updates.MySQLBugs.md#AuroraMySQL.Updates.MySQLBugs.v3).
+ 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ée`DEFAULT 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. Référence : [ Bug \#119784 en amont de MySQL](https://bugs.mysql.com/bug.php?id=119784).