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 pour Amazon Aurora MySQL version 1 (obsolète)
<a name="AuroraMySQL.Updates.11Updates"></a>

Les mises à jour du moteur de base de données Amazon Aurora version 1 sont les suivantes :<a name="aurora_1x_updates"></a>
+ [Mises à jour du moteur de base de données Aurora MySQL du 30/09/2021 (version 1.23.4) (obsolète)](AuroraMySQL.Updates.1234.md)
+ [Mises à jour du moteur de base de données Aurora MySQL du 28/06/2021 (version 1.23.3) (obsolète)](AuroraMySQL.Updates.1233.md)
+ [Mises à jour du moteur de base de données Aurora MySQL du 18/03/2021 (version 1.23.2) (obsolète)](AuroraMySQL.Updates.1232.md)
+ [Mises à jour du moteur de base de données Aurora MySQL du 24/11/2020 (version 1.23.1) (obsolète)](AuroraMySQL.Updates.1231.md)
+ [Mises à jour du moteur de base de données Aurora MySQL du 02/09/2020 (version 1.23.0) (obsolète)](AuroraMySQL.Updates.1230.md)
+ [Mises à jour du moteur de base de données Aurora MySQL du 03/06/2021 (version 1.22.5) (obsolète)](AuroraMySQL.Updates.1225.md)
+ [Mises à jour du moteur de base de données Aurora MySQL du 04/02/2021 (version 1.22.4) (obsolète)](AuroraMySQL.Updates.1224.md)
+ [Mises à jour du moteur de base de données Aurora MySQL du 19/11/2020 (version 1.22.3) (obsolète)](AuroraMySQL.Updates.1223.md)
+ [Mises à jour du moteur de base de données Aurora MySQL du 05/03/2020 (version 1.22.2) (obsolète)](AuroraMySQL.Updates.1222.md)
+ [Mises à jour du moteur de base de données Aurora MySQL du 23/12/2019 (version 1.22.1) (obsolète)](AuroraMySQL.Updates.1221.md)
+ [Mises à jour du moteur de base de données Aurora MySQL du 25/11/2019 (version 1.22.0) (obsolète)](AuroraMySQL.Updates.1220.md)
+ [Mises à jour du moteur de base de données Aurora MySQL du 25/11/2019 (version 1.21.0) (obsolète)](AuroraMySQL.Updates.1210.md)
+ [Mises à jour du moteur de base de données Aurora MySQL du 05/03/2020 (version 1.20.1) (obsolète)](AuroraMySQL.Updates.1201.md)
+ [Mises à jour du moteur de base de données Aurora MySQL du 11/11/2019 (version 1.20.0) (obsolète)](AuroraMySQL.Updates.1200.md)
+ [Mises à jour du moteur de base de données Aurora MySQL du 05/03/2020 (version 1.19.6) (obsolète)](AuroraMySQL.Updates.1196.md)
+ [Mises à jour du moteur de base de données Aurora MySQL du 19/09/2019 (version 1.19.5) (obsolète)](AuroraMySQL.Updates.1195.md)
+ [Mises à jour du moteur de base de données Aurora MySQL du 05/06/2019 (version 1.19.2) (obsolète)](AuroraMySQL.Updates.1192.md)
+ [Mises à jour du moteur de base de données Aurora MySQL du 09/05/2019 (version 1.19.1) (obsolète)](AuroraMySQL.Updates.1191.md)
+ [Mises à jour du moteur de base de données Aurora MySQL du 07/02/2019 (version 1.19.0) (obsolète)](AuroraMySQL.Updates.1190.md)
+ [Mises à jour du moteur de base de données Aurora MySQL du 20/09/2018 (version 1.18.0) (obsolète)](AuroraMySQL.Updates.1180.md)
+ [Mises à jour du moteur de base de données Aurora MySQL du 05/03/2020 (version 1.17.9) (obsolète)](AuroraMySQL.Updates.1179.md)
+ [Mises à jour du moteur de base de données Aurora MySQL du 17/01/2019 (version 1.17.8) (obsolète)](AuroraMySQL.Updates.1178.md)
+ [Mises à jour du moteur de base de données Aurora MySQL du 08/10/2018 (version 1.17.7) (obsolète)](AuroraMySQL.Updates.1177.md)
+ [Mises à jour du moteur de base de données Aurora MySQL du 06/09/2018 (version 1.17.6) (obsolète)](AuroraMySQL.Updates.1176.md)
+ [Mises à jour du moteur de base de données Aurora MySQL du 14/08/2018.(version 1.17.5) (obsolète)](AuroraMySQL.Updates.1175.md)
+ [Mises à jour du moteur de base de données Aurora MySQL du 07/08/2018 (version 1.17.4) (obsolète)](AuroraMySQL.Updates.1174.md)
+ [Mises à jour du moteur de base de données Aurora MySQL du 05/06/2018 (version 1.17.3) (obsolète)](AuroraMySQL.Updates.1173.md)
+ [Mises à jour du moteur de base de données Aurora MySQL du 27/04/2018 (version 1.17.2) (obsolète)](AuroraMySQL.Updates.1172.md)
+ [Mises à jour du moteur de base de données Aurora MySQL : 23/03/2018 (version 1.17.1) (obsolète)](AuroraMySQL.Updates.1171.md)
+ [Mises à jour du moteur de base de données Aurora MySQL du 13/03/2018 (version 1.17) (obsolète)](AuroraMySQL.Updates.117.md)
+ [Mises à jour du moteur de base de données Aurora MySQL du 11/12/2017 (version 1.16) (obsolète)](AuroraMySQL.Updates.20171211.md)
+ [Mises à jour du moteur de base de données Aurora MySQL du 20/11/2017 (version 1.15.1) (obsolète)](AuroraMySQL.Updates.20171120.md)
+ [Mises à jour du moteur de base de données Aurora MySQL du 24/10/2017 (version 1.15) (obsolète)](AuroraMySQL.Updates.20171024.md)
+ [Mises à jour du moteur de base de données Aurora MySQL : 13/03/2018 (version 1.14.4) (obsolète)](AuroraMySQL.Updates.1144.md)
+ [Mises à jour du moteur de base de données Aurora MySQL : 22/09/2017 (version 1.14.1) (obsolète)](AuroraMySQL.Updates.20170922.md)
+ [Mises à jour du moteur de base de données Aurora MySQL : 07/08/2017 (version 1.14) (obsolète)](AuroraMySQL.Updates.20170807.md)
+ [Mises à jour du moteur de base de données Aurora MySQL : 15/05/2017 (version 1.13) (obsolète)](AuroraMySQL.Updates.20170515.md)
+ [Mises à jour du moteur de base de données Aurora MySQL : 05/04/2017 (version 1.12) (obsolète)](AuroraMySQL.Updates.20170405.md)
+ [Mises à jour du moteur de base de données Aurora MySQL : 23/02/2017 (version 1.11) (obsolète)](AuroraMySQL.Updates.20170223.md)
+ [Mises à jour du moteur de base de données Aurora MySQL : 12/01/2017 (version 1.10.1) (obsolète)](AuroraMySQL.Updates.20170112.md)
+ [Mises à jour du moteur de base de données Aurora MySQL : 14/12/2016 (version 1.10) (obsolète)](AuroraMySQL.Updates.20161214.md)
+ [Mises à jour du moteur de base de données Aurora MySQL : 10/11/2016 (versions 1.9.0, 1.9.1) (obsolète)](AuroraMySQL.Updates.20161110.md)
+ [Mises à jour du moteur de base de données Aurora MySQL : 26/10/2016 (version 1.8.1) (obsolète)](AuroraMySQL.Updates.20161026.md)
+ [Mises à jour du moteur de base de données Aurora MySQL : 18/10/2016 (version 1.8) (obsolète)](AuroraMySQL.Updates.20161018.md)
+ [Mises à jour du moteur de base de données Aurora MySQL : 20/09/2016 (version 1.7.1) (obsolète)](AuroraMySQL.Updates.20160920.md)
+ [Mises à jour du moteur de base de données Aurora MySQL : 30/08/2016 (version 1.7.0) (obsolète)](AuroraMySQL.Updates.20160830.md)
+ [Mises à jour du moteur de base de données Aurora MySQL : 01/06/2016 (version 1.6.5) (obsolète)](AuroraMySQL.Updates.20160601.md)
+ [Mises à jour du moteur de base de données Aurora MySQL : 06/04/2016 (version 1.6) (obsolète)](AuroraMySQL.Updates.20160406.md)
+ [Mises à jour du moteur de base de données Aurora MySQL : 11/01/2016 (version 1.5) (obsolète)](AuroraMySQL.Updates.20160111.md)
+ [Mises à jour du moteur de base de données Aurora MySQL : 03/12/2015 (version 1.4) (obsolète)](AuroraMySQL.Updates.20151203.md)
+ [Mises à jour du moteur de base de données Aurora MySQL : 16/10/2015 (versions 1.2, 1.3) (obsolète)](AuroraMySQL.Updates.20151016.md) 
+ [Mises à jour du moteur de base de données Aurora MySQL : 24/08/2015 (version 1.1) (obsolète)](AuroraMySQL.Updates.20150824.md)

# Mises à jour du moteur de base de données Aurora MySQL du 30/09/2021 (version 1.23.4) (obsolète)
<a name="AuroraMySQL.Updates.1234"></a><a name="1234"></a><a name="1.23.4"></a>

**Version **: 1.23.4

Aurora MySQL 1.23.4 est disponible. Les versions 2.\$1 d'Aurora MySQL sont compatibles avec MySQL 5.7 et les versions 1.\$1 d'Aurora MySQL sont compatibles avec MySQL 5.6.

L'obsolescence de cette version du moteur est prévue pour le 28 février 2023. Pour plus d'informations, consultez [Préparation à la fin de vie d'Amazon Aurora Édition compatible avec MySQL version 1](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.MySQL56.EOL.html).

 Les versions d'Aurora MySQL actuellement prises en charge sont les suivantes : 1.19.5, 1.19.6, 1.22.\$1, 1.23.\$1, 2.04.\$1, 2.07.\$1, 2.08.\$1, 2.09.\$1, 2.10.\$1, 3.01.\$1 et 3.02.\$1. 

 Pour créer un cluster avec une ancienne version d'Aurora MySQL, spécifiez la version du moteur via la console RDS, la AWS CLI ou l'API Amazon RDS. 

 Si vous avez des questions ou des préoccupations, le AWS support est disponible sur les forums communautaires et via le [AWS support](https://aws.amazon.com/support). Pour plus d'informations, consultez [Entretien d'un cluster de base de données Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_UpgradeDBInstance.Maintenance.html) dans le *Guide de l'utilisateur Amazon Aurora*. 

## Améliorations
<a name="AuroraMySQL.Updates.1234.Improvements"></a>

 **Améliorations générales :** 
+  Correction d'un problème qui pouvait entraîner une consommation élevée de l'UC sur les instances de lecture en raison de la journalisation excessive des messages d'information dans les fichiers journaux de diagnostic internes. 

 **Correctifs à priorité élevée :** 
+ [CVE-2021-2307](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-2307)
+ [CVE-2021-2226](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-2226)
+ [CVE-2021-2160](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-2160)
+ [CVE-2021-2154](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-2154)
+ [CVE-2021-2060](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-2060)
+ [CVE-2021-2032](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-2032)
+ [CVE-2021-2001](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-2001)

# Mises à jour du moteur de base de données Aurora MySQL du 28/06/2021 (version 1.23.3) (obsolète)
<a name="AuroraMySQL.Updates.1233"></a><a name="1233"></a><a name="1.23.3"></a>

**Version :** 1.23.3

Aurora MySQL 1.23.3 est disponible. Les versions 1.x d'Aurora MySQL sont compatibles avec MySQL 5.6 et les versions 2.x d'Aurora MySQL sont compatibles avec MySQL 5.7.

L'obsolescence de cette version du moteur est prévue pour le 28 février 2023. Pour plus d'informations, consultez [Préparation à la fin de vie d'Amazon Aurora Édition compatible avec MySQL version 1](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.MySQL56.EOL.html).

 Les versions d'Aurora MySQL actuellement prises en charge sont les suivantes : 1.19.5, 1.19.6, 1.22.\$1, 1.23.\$1, 2.04.\$1, 2.07.\$1, 2.08.\$1, 2.09.\$1, 2.10.\$1, 3.01.\$1 et 3.02.\$1. 

 Pour créer un cluster avec une ancienne version d'Aurora MySQL, spécifiez la version du moteur via la console RDS, la AWS CLI ou l'API Amazon RDS. 

 Si vous avez des questions ou des préoccupations, le AWS support est disponible sur les forums communautaires et via le [AWS support](https://aws.amazon.com/support). Pour plus d'informations, consultez [Entretien d'un cluster de base de données Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_UpgradeDBInstance.Maintenance.html) dans le *Guide de l'utilisateur Amazon Aurora*. 

## Améliorations
<a name="AuroraMySQL.Updates.1233.Improvements"></a>

 Améliorations générales de la stabilité et de la disponibilité. 

 **Correctifs de sécurité :** 
+ [CVE-2021-23841](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-23841)
+ [CVE-2021-3449](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-3449)
+ [CVE-2020-28196](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-28196)

# Mises à jour du moteur de base de données Aurora MySQL du 18/03/2021 (version 1.23.2) (obsolète)
<a name="AuroraMySQL.Updates.1232"></a><a name="1232"></a><a name="1.23.2"></a>

**Version :** 1.23.2

Aurora MySQL 1.23.2 est disponible. Les versions 1.x d'Aurora MySQL sont compatibles avec MySQL 5.6 et les versions 2.x d'Aurora MySQL sont compatibles avec MySQL 5.7.

L'obsolescence de cette version du moteur est prévue pour le 28 février 2023. Pour plus d'informations, consultez [Préparation à la fin de vie d'Amazon Aurora Édition compatible avec MySQL version 1](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.MySQL56.EOL.html).

 Les versions d'Aurora MySQL actuellement prises en charge sont les suivantes : 1.19.5, 1.19.6, 1.22.\$1, 1.23.\$1, 2.04.\$1, 2.07.\$1, 2.08.\$1, 2.09.\$1, 2.10.\$1, 3.01.\$1 et 3.02.\$1. 

 Pour créer un cluster avec une ancienne version d'Aurora MySQL, spécifiez la version du moteur via la console RDS, la AWS CLI ou l'API Amazon RDS. 

**Note**  
 Cette version n'est actuellement pas disponible dans les régions suivantes : AWS GovCloud (US-East) [us-gov-east-1], AWS GovCloud (US-West) [us-gov-west-1]. Sa disponibilité fera l'objet d'une annonce distincte. 

 Si vous avez des questions ou des préoccupations, le AWS support est disponible sur les forums communautaires et via le [AWS support](https://aws.amazon.com/support). Pour plus d'informations, consultez [Entretien d'un cluster de base de données Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_UpgradeDBInstance.Maintenance.html) dans le *Guide de l'utilisateur Amazon Aurora*. 

## Améliorations
<a name="AuroraMySQL.Updates.1232.Improvements"></a>

 **Correctifs à priorité élevée :** 
+ [CVE-2020-14867](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-14867)
+ [CVE-2020-14812](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-14812)
+ [CVE-2020-14769](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-14769)
+ [CVE-2020-14765](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-14765)
+ [CVE-2020-14793](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-14793)
+ [CVE-2020-14672](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-14672)
+ [CVE-2020-1971](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-1971)
+ [CVE-2018-3143](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-3143)

 **Améliorations de la disponibilité :** 
+  Correction d'un problème dans la fonction de redimensionnement dynamique qui pouvait entraîner le redémarrage des instances de base de données du lecteur. 
+  Correction d'un problème de basculement dû à une condition de concurrence dans l'instruction `RESET QUERY CACHE`. 
+  Correction d'un incident dans un appel de procédure stockée imbriquée avec cache de requête. 
+  Correction d'un problème afin d'empêcher le redémarrage répété de `mysqld` lors de la récupération à partir d'une troncature incomplète de tables partitionnées ou sous-partitionnées. 
+  Correction d'un problème qui pouvait provoquer l'échec d'une migration depuis le site ou RDS for MySQL vers Aurora MySQL. 
+  Correction d'une condition de concurrence rare dans laquelle la base de données pouvait redémarrer pendant la mise à l'échelle du volume de stockage. 
+  Correction d'un problème lié au gestionnaire de verrous, où une condition de concurrence pouvait provoquer le partage d'un verrou par deux transactions, provoquant le redémarrage de la base de données. 
+  Correction d'un problème lié à la gestion de la mémoire de verrouillage des transactions avec des transactions d'écriture longues entraînant un redémarrage de la base de données. 
+  Correction d'une condition de concurrence dans le gestionnaire de verrous qui entraînait le redémarrage de la base de données ou le basculement pendant la restauration d'une transaction. 
+  Correction d'un problème lors de la mise à niveau de la version 5.6 vers la version 5.7 lorsque la fonction Fast Online DDL était activée dans la table en mode Lab dans la version 5.6. 
+  Correction de plusieurs problèmes dans lesquels le moteur pouvait redémarrer pendant l'application de correctifs sans temps d'arrêt lors de la recherche d'un point de repos dans l'activité de la base de données pour l'application de correctifs. 
+  Correction de plusieurs problèmes liés aux redémarrages répétés dus à l'interruption des opérations DDL, telles que `DROP TRIGGER`, `ALTER TABLE` et en particulier `ALTER TABLE` qui modifie le type de partitionnement ou le nombre de partitions dans une table. 
+  Mise à jour de la valeur par défaut de `table_open_cache` sur les instances 16XL et 24XL afin d'éviter des redémarrages répétés et une utilisation élevée du processeur sur les classes d'instances volumineuses (R4/R5-16XL, R5-12XL, R5-24XL). Cela a eu un impact sur les versions 1.21.x et 1.22.x. 
+  Correction d'un problème qui provoquait l'arrêt d'un réplica de journal binaire avec une erreur `HA_ERR_KEY_NOT_FOUND`. 

## Intégration de correctifs de bogues de l'édition MySQL Community Edition
<a name="AuroraMySQL.Updates.1232.Patches"></a>
+  *Réplication* : pendant l'exécution d'une instruction `SHOW BINLOG EVENTS`, toute transaction parallèle a été bloquée. Le correctif garantit que le processus `SHOW BINLOG EVENTS` n'acquiert désormais un verrou que pendant la durée du calcul de la position finale du fichier ; par conséquent, les transactions parallèles ne sont pas bloquées pendant de longues durées. (Bogue n° 76618, Bogue n° 20928790) 

# Mises à jour du moteur de base de données Aurora MySQL du 24/11/2020 (version 1.23.1) (obsolète)
<a name="AuroraMySQL.Updates.1231"></a><a name="1231"></a><a name="1.23.1"></a>

**Version :** 1.23.1

Aurora MySQL 1.23.1 est disponible. Les versions 1.x d'Aurora MySQL sont compatibles avec MySQL 5.6 et les versions 2.x d'Aurora MySQL sont compatibles avec MySQL 5.7.

L'obsolescence de cette version du moteur est prévue pour le 28 février 2023. Pour plus d'informations, consultez [Préparation à la fin de vie d'Amazon Aurora Édition compatible avec MySQL version 1](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.MySQL56.EOL.html).

 Les versions d'Aurora MySQL actuellement prises en charge sont les suivantes : 1.19.5, 1.19.6, 1.22.\$1, 1.23.\$1, 2.04.\$1, 2.07.\$1, 2.08.\$1, 2.09.\$1, 2.10.\$1, 3.01.\$1 et 3.02.\$1. 

 Pour créer un cluster avec une ancienne version d'Aurora MySQL, spécifiez la version du moteur via la console RDS, la AWS CLI ou l'API Amazon RDS. 

 Si vous avez des questions ou des préoccupations, le AWS support est disponible sur les forums communautaires et via le [AWS support](https://aws.amazon.com/support). Pour plus d'informations, consultez [Entretien d'un cluster de base de données Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_UpgradeDBInstance.Maintenance.html) dans le *Guide de l'utilisateur Amazon Aurora*. 

## Améliorations
<a name="AuroraMySQL.Updates.1231.Improvements"></a>

 **Correctifs de sécurité :** 

 Correctifs et autres améliorations visant à peaufiner la gestion dans un environnement géré. Correctifs CVE supplémentaires ci-dessous : 
+ [CVE-2020-14559](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-14559)
+ [CVE-2020-14539](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-14539)

 **Modifications incompatibles :** 

 Cette version introduit une modification d'autorisation qui affecte le comportement de la commande `mysqldump`. Les utilisateurs doivent disposer du privilège `PROCESS` pour accéder à la table `INFORMATION_SCHEMA.FILES`. Pour exécuter la commande `mysqldump` sans aucune modification, accordez le privilège `PROCESS` à l'utilisateur de base de données auquel la commande `mysqldump` se connecte. Vous pouvez également exécuter la commande `mysqldump` avec l'option `--no-tablespaces`. Avec cette option, la sortie `mysqldump ` n'inclut aucune instruction `CREATE LOGFILE GROUP` ou `CREATE TABLESPACE`. Dans ce cas, la commande `mysqldump` n'accède pas à la table `INFORMATION_SCHEMA.FILES` et vous n'avez pas besoin d'accorder l'autorisation `PROCESS`. 

 **Améliorations de la disponibilité :** 
+  Correction d'un problème entraînant le redémarrage répété d'une instance de lecteur Aurora dans un cluster secondaire de base de données globale exécutant 1.23.0. 
+  Correction d'un problème entraînant le redémarrage des réplicas d'une région secondaire de base de données globale lors de la mise à niveau vers la version 1.23.0 alors que le scripteur de la région principale était sur une version antérieure. 
+  Correction d'une fuite de mémoire dans la fonction de redimensionnement dynamique, introduite dans Aurora MySQL 1.23.0. 
+  Correction d'un problème pouvant entraîner le redémarrage du serveur pendant l'exécution d'une requête à l'aide de la fonction de requête parallèle. 
+  Correction d'un problème pouvant entraîner le blocage d'une séance client lorsque le moteur de base de données rencontrait une erreur lors de la lecture ou de l'écriture sur le réseau. 

# Mises à jour du moteur de base de données Aurora MySQL du 02/09/2020 (version 1.23.0) (obsolète)
<a name="AuroraMySQL.Updates.1230"></a><a name="1230"></a><a name="1.23.0"></a>

**Version :** 1.23.0

Aurora MySQL 1.23.0 est disponible. Les versions 1.x d'Aurora MySQL sont compatibles avec MySQL 5.6 et les versions 2.x d'Aurora MySQL sont compatibles avec MySQL 5.7.

L'obsolescence de cette version du moteur est prévue pour le 28 février 2023. Pour plus d'informations, consultez [Préparation à la fin de vie d'Amazon Aurora Édition compatible avec MySQL version 1](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.MySQL56.EOL.html).

 Les versions d'Aurora MySQL actuellement prises en charge sont les suivantes : 1.19.5, 1.19.6, 1.22.\$1, 1.23.\$1, 2.04.\$1, 2.07.\$1, 2.08.\$1, 2.09.\$1, 2.10.\$1, 3.01.\$1 et 3.02.\$1. 

 Vous pouvez restaurer l'instantané d'une base de données Aurora MySQL 1.\$1 à la version Aurora MySQL 1.23.0. 

**Important**  
 Les améliorations apportées au stockage Aurora dans cette version limitent les chemins de mise à niveau disponibles d'Aurora MySQL 1.23 à Aurora MySQL 2.\$1. Lorsque vous mettez à niveau un cluster d'Aurora MySQL version 1.23 vers une version 2.\$1, vous devez effectuer une mise à niveau vers Aurora MySQL version 2.09.0 ou ultérieure. 

 Pour créer un cluster avec une ancienne version d'Aurora MySQL, veuillez spécifier la version du moteur via la console RDS, la AWS CLI ou l'API Amazon RDS. 

**Note**  
 Cette version n'est actuellement pas disponible dans les régions suivantes : AWS GovCloud (US-East) [us-gov-east-1], AWS GovCloud (US-West) [us-gov-west-1]. Sa disponibilité fera l'objet d'une annonce distincte. 

 Si vous avez des questions ou des préoccupations, le AWS support est disponible sur les forums communautaires et via le [AWS support](https://aws.amazon.com/support). Pour plus d'informations, consultez [Entretien d'un cluster de base de données Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_UpgradeDBInstance.Maintenance.html) dans le *Guide de l'utilisateur Amazon Aurora*. 

## Améliorations
<a name="AuroraMySQL.Updates.1230.Improvements"></a>

 **Nouvelles fonctions :** 
+  Vous pouvez désormais activer ou désactiver la requête parallèle pour un cluster existant en modifiant la valeur du paramètre de cluster de base de données `aurora_parallel_query`. Vous n'avez pas besoin d'utiliser `parallelquery` pour le paramètre `--engine-mode` lors de la création du cluster. 

   La requête parallèle est désormais étendue et disponible dans toutes les régions où Aurora MySQL est disponible. 

   Un certain nombre d'autres améliorations de fonction et de modifications de procédure ont été apportées pour la mise à niveau et l'activation des requêtes parallèles dans un cluster Aurora. Pour plus d'informations, consultez [Utilisation des requêtes parallèles pour Amazon Aurora MySQL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-mysql-parallel-query.html) dans le *Guide de l'utilisateur Amazon Aurora*. 
+  Avec cette version, vous pouvez créer des instances de base de données Amazon Aurora MySQL avec jusqu'à 128 tébioctets (TiO) de stockage. La nouvelle limite de stockage est une augmentation par rapport à la limite précédente de 64 Tio. La taille de stockage de 128 Tio prend en charge des bases de données de taille plus importante. Cette capacité n'est pas prise en charge sur les petites tailles d'instance (db.t2 ou db.t3). Un espace disque logique unique ne peut pas dépasser 64 Tio en raison des [limitations InnoDB avec une taille de page de 16 Ko](https://dev.mysql.com/doc/refman/5.7/en/innodb-limits.html). 

   Aurora vous avertit lorsque la taille du volume du cluster est proche de 128 Tio, afin que vous puissiez prendre des mesures avant d'atteindre la limite de taille. Les alertes apparaissent dans le journal mysql et les événements RDS dans AWS Management Console. 
+  Amélioration du traitement du journal binaire (binlog) pour réduire le temps de récupération sur incident et la latence de temps de validation lorsque de très grandes transactions sont incluses. 
+  Aurora redimensionne dynamiquement l'espace de stockage de votre cluster. Avec le redimensionnement dynamique, l'espace de stockage de votre cluster de base de données Aurora diminue automatiquement lorsque vous supprimez des données du cluster de base de données. Pour plus d'informations, consultez [Dimensionnement du stockage](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.Managing.Performance.html#Aurora.Managing.Performance.StorageScaling) dans le *Guide de l'utilisateur Amazon Aurora*. 
**Note**  
 La fonctionnalité de redimensionnement dynamique est déployée par étapes dans les AWS régions où Aurora est disponible. Selon la région où se trouve votre cluster, il se peut que cette fonction ne soit pas encore disponible. Pour plus d'informations, veuillez consulter l'[annonce des nouveautés](https://aws.amazon.com/about-aws/whats-new/2020/10/amazon-aurora-enables-dynamic-resizing-database-storage-space/). 

 **Correctifs à priorité élevée :** 
+ [CVE-2019-2911](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-2911)
+ [CVE-2019-2537](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-2537)
+ [CVE-2018-2787](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-2787)
+ [CVE-2018-2784](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-2784)
+ [CVE-2018-2645](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-2645)
+ [CVE-2018-2640](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-2640)

 **Améliorations de la disponibilité :** 
+  Correction d'un problème lié au gestionnaire de verrous, où une condition de concurrence pouvait provoquer le partage d'un verrou par deux transactions, provoquant le redémarrage de la base de données. 
+  Correction d'un problème lié à la gestion de la mémoire de verrouillage des transactions avec des transactions d'écriture longues entraînant un redémarrage de la base de données. 
+  Correction d'une condition de concurrence dans le gestionnaire de verrous qui entraînait le redémarrage de la base de données ou le basculement pendant la restauration d'une transaction. 
+  Correction d'un problème lors de la mise à niveau de la version 5.6 vers la version 5.7 lors d'une modification `innodb_file_format` sur une table sur laquelle Fast DLL était activée. 
+  Correction de plusieurs problèmes dans lesquels le moteur pouvait redémarrer pendant l'application de correctifs sans temps d'arrêt lors de la recherche d'un point de repos dans l'activité de la base de données pour l'application de correctifs. 
+  Correction d'un problème lié à la récupération DDL qui avait un impact sur le redémarrage de l'instance de base de données lors de la récupération d'une opération `DROP TRIGGER` interrompue. 
+  Correction d'un bogue qui pouvait entraîner l'indisponibilité de la base de données en cas de plantage lors de l'exécution de certaines opérations de partitionnement. Plus précisément, une opération `ALTER TABLE` interrompue qui modifie le type de partitionnement ou le nombre de partitions dans une table. 
+  Correction de la valeur par défaut de `table_open_cache` sur les instances 16XL et 24XL qui pouvait provoquer des basculements répétés et une utilisation élevée du processeur sur les classes d'instances volumineuses (R4/R5-16XL, R5-12XL, R5-24XL). Cela a eu un impact sur 1.21.x et 1.22.x. 

 **Bases de données globales :** 
+  Renseignez les données manquantes dans la `INFORMATION_SCHEMA.REPLICA_HOST_STATUS` vue MySQL sur les AWS régions principales et secondaires d'une base de données globale Aurora. 
+  Correction d'échecs de requête inattendus qui pouvaient se produire dans une région secondaire de base de données globale en raison d'un nettoyage mémoire des enregistrements UNDO dans la région principale, après des problèmes de connectivité réseau temporaires entre les régions principale et secondaire. 

 **Requête parallèle :** 
+  Correction d'un problème dans lequel une requête parallèle pouvait provoquer un retour de résultat vide dans une requête longue. 
+  Correction d'un problème dans lequel une requête sur une petite table du réplica en lecture Aurora pouvait prendre plus d'une seconde. 
+  Correction d'un problème qui pouvait provoquer un redémarrage lorsqu'une requête parallèle et une instruction DML s'exécutaient simultanément sous une charge de travail lourde. 

 **Améliorations générales :** 
+  Correction d'un problème où les requêtes utilisant l'index spatial pouvaient renvoyer des résultats partiels si l'index spatial était créé sur des tables avec des valeurs spatiales importantes déjà existantes. 
+  Augmentation de la longueur maximale autorisée pour les variables du système d'audit `server_audit_incl_users` et `server_audit_excl_users` de 1024 octets à 2000 octets. 
+  Correction d'un problème dans lequel un réplica de journal binaire connecté à un principal de journal binaire Aurora MySQL pouvait afficher des données incomplètes lorsque le principal de journal binaire Aurora MySQL chargeait les données depuis S3 sous `statement` `binlog_format`. 
+  Respectez le comportement de la communauté pour mapper `mixed` binlog\$1format à `row` au lieu de `statement` pour le chargement des données. 
+  Correction d'un problème provoquant l'arrêt de la réplication de journal binaire lorsque l'utilisateur ferme la connexion et que la session utilise des tables temporaires. 
+  Temps de réponse amélioré d'une requête impliquant des tables temporaires MyISAM. 
+  Correction d'un problème d'autorisation lorsque le travail de journal binaire exécute une fonction lambda native. 
+  Correction d'un problème sur les réplicas en lecture Aurora lorsque vous tentez d'interroger ou de faire pivoter le journal lent ou le journal général. 
+  Correction d'un problème qui interrompait la réplication logique lorsque le paramètre `binlog_checksum` était défini sur des valeurs différentes sur l'élément principal et le réplica. 
+  Correction d'un problème dans lequel le réplica en lecture pouvait voir temporairement les résultats partiels d'une transaction récemment validée sur le rédacteur. 
+  Incluez les informations de transaction de la transaction annulée dans `show engine innodb status` lorsqu'un blocage est résolu. 

## Intégration de correctifs de bogues de l'édition MySQL Community Edition
<a name="AuroraMySQL.Updates.1230.Patches"></a>
+  Les événements Binlog avec `ALTER TABLE ADD COLUMN ALGORITHM=QUICK` seront réécrits en tant que `ALGORITHM=DEFAULT` de manière à être compatibles avec l'édition de la communauté. 
+  BOGUE \$122350047 : SI LE CLIENT EST TUÉ APRÈS LA RESTAURATION AU POINT DE SAUVEGARDE PRÉCÉDENT STMTS VALIDÉ 
+  Bogue \$129915479 : L'EXÉCUTION DE COM\$1REGISTER\$1SLAVE SANS COM\$1BINLOG\$1DUMP PEUT GÉNÉRER L'ARRÊT DU SERVEUR 
+  Bogue \$130441969 : BOGUE \$129723340 : INCIDENT MYSQL SERVER APRÈS REQUÊTE SQL AVEC ?AST DE DONNÉES 
+  Bogue \$130628268 : INCIDENT DE MÉMOIRE INSUFFISANTE 
+  Bogue \$127081349 : COMPORTEMENT INATTENDU LORS D'UNE SUPPRESSION AVEC FONCTION SPATIALE 
+  Bogue \$127230859 : COMPORTEMENT INATTENDU LORS DE LA GESTION D'UN POLYGONE NON VALIDE 
+  Bogue \$127081349 : COMPORTEMENT INATTENDU LORS DE LA SUPPRESSION AVEC FONCTION SPATIALE 
+  Bogue \$126935001 : AUTO\$1INCREMENT DE MODIFICATION DE TABLE TENTE DE LIRE L'INDEX À PARTIR D'UN ESPACE DE TABLE SUPPRIMÉ 
+  Bogue \$129770705 : INCIDENT SERVEUR PENDANT L'EXÉCUTION DE SELECT AVEC CLAUSE WHERE SPÉCIFIQUE 
+  Bogue \$127659490 : SELECT AVEC UTILISATION DE PLAGE DYNAMIQUE ET DE FUSION D'INDEX NÉCESSITE TROP DE MÉMOIRE (MÉMOIRE INSUFFISANTE) 
+  Bogue \$124786290 : INTERRUPTION DE LA RÉPLICATION LORSQUE LE BOGUE \$174145 SE PRODUIT SUR LE PRINCIPAL 
+  Bogue \$127703912 : UTILISATION DE MÉMOIRE EXCESSIVE AVEC NOMBREUSES PRÉPARATIONS 
+  Bug \$120527363 : CRASH DE LA TABLE TEMPORAIRE TRUNCATE : \$1 TF2DICT\$1 \$1FLAG\$1IS\$1SET (TABLE, DICT\$1 \$1TEMPORAIRE) TF2 
+  Bogue \$123103937 : PS\$1TRUNCATE\$1ALL\$1TABLES() NE FONCTIONNE PAS EN MODE SUPER\$1READ\$1ONLY 
+  Bogue \$125053286 : L'UTILISATION DE VUE AVEC CONDITION DANS LA PROCÉDURE GÉNÈRE UN COMPORTEMENT INCORRECT (corrigé dans 5.6.36) 
+  Bogue \$125586773 : COMPORTEMENT INCORRECT POUR SÉLECTION DE TABLE DE CRÉATION DANS UNE BOUCLE DANS SP (corrigé dans 5.6.39) 
+  Bogue \$127407480 : AUTOMATIC\$1SP\$1PRIVILEGES NÉCESSITE LES PRIVILÈGES INSERT POUR LA TABLE MYSQL.USER 
+  Bogue \$126997096 : la valeur de `relay_log_space` n'est pas mise à jour de manière synchronisée, de sorte qu'elle est parfois beaucoup plus élevée que l'espace disque réel utilisé par les journaux relais. 
+  Bogue \$115831300 SLAVE\$1TYPE\$1CONVERSIONS=ALL\$1NON\$1LOSSY NE FONCTIONNE PAS COMME PRÉVU 
+  Bogue backport bogue SSL \$117087862, bogue \$120551271 
+  Bogue \$116894092 : RÉGRESSION DE PERFORMANCE DANS 5.6.6\$1 POUR INSERT INTO ... SELECT ... FROM (corrigé dans 5.6.15). 
+  Porter un correctif de bogue lié à `SLAVE_TYPE_CONVERSIONS`. 

# Mises à jour du moteur de base de données Aurora MySQL du 03/06/2021 (version 1.22.5) (obsolète)
<a name="AuroraMySQL.Updates.1225"></a><a name="1225"></a><a name="1.22.5"></a>

 **Version :** 1.22.5 

 Aurora MySQL 1.22.5 est disponible. Les versions 1.x d'Aurora MySQL sont compatibles avec MySQL 5.6 et les versions 2.x d'Aurora MySQL sont compatibles avec MySQL 5.7. 

L'obsolescence de cette version du moteur est prévue pour le 28 février 2023. Pour plus d'informations, consultez [Préparation à la fin de vie d'Amazon Aurora Édition compatible avec MySQL version 1](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.MySQL56.EOL.html).

 Les versions d'Aurora MySQL actuellement prises en charge sont les suivantes : 1.19.5, 1.19.6, 1.22.\$1, 1.23.\$1, 2.04.\$1, 2.07.\$1, 2.08.\$1, 2.09.\$1, 2.10.\$1, 3.01.\$1 et 3.02.\$1. 

 Pour créer un cluster avec une version plus ancienne d'Aurora MySQL, spécifiez la version du moteur via la console RDS, l' AWS CLI ou l'API Amazon RDS. 

**Note**  <a name="lts_notice_1225"></a>
 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](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Updates.Versions.html#AuroraMySQL.Updates.LTS) dans le *Guide de l'utilisateur Amazon Aurora*. 

 Si vous avez des questions ou des préoccupations, le AWS support est disponible sur les forums communautaires et via le [AWS support](https://aws.amazon.com/support). Pour plus d'informations, consultez [Entretien d'un cluster de base de données Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_UpgradeDBInstance.Maintenance.html) dans le *Guide de l'utilisateur Amazon Aurora*. 

## Améliorations
<a name="AuroraMySQL.Updates.1225.Improvements"></a>

 **Améliorations de la disponibilité :** 
+  Résolution d'un problème qui pouvait entraîner l'arrêt de la base de données, puis un redémarrage ou un basculement en raison d'un conflit de simultanéité entre les threads de nettoyage internes. 
+  Résolution d'un problème qui pouvait entraîner l'indisponibilité du cluster si la base de données redémarrait tout en conservant les transactions XA à l'état préparé, puis redémarrait à nouveau avant que ces transactions ne soient validées ou annulées. Avant ce correctif, vous pouviez résoudre le problème en restaurant le cluster à un moment donné avant le premier redémarrage. 
+  Résolution d'un problème qui pouvait entraîner le blocage de la purge InnoDB si la base de données redémarre pendant le traitement d'une instruction DDL. Par conséquent, la longueur de la liste de l'historique InnoDB augmenterait et le volume de stockage du cluster continuerait de croître jusqu'à ce qu'il soit rempli, rendant ainsi la base de données indisponible. Avant ce correctif, vous pouviez atténuer le problème en redémarrant à nouveau la base de données pour débloquer la purge. 

# Mises à jour du moteur de base de données Aurora MySQL du 04/02/2021 (version 1.22.4) (obsolète)
<a name="AuroraMySQL.Updates.1224"></a><a name="1224"></a><a name="1.22.4"></a>

**Version :** 1.22.4

Aurora MySQL 1.22.4 est disponible. Les versions 1.x d'Aurora MySQL sont compatibles avec MySQL 5.6 et les versions 2.x d'Aurora MySQL sont compatibles avec MySQL 5.7.

L'obsolescence de cette version du moteur est prévue pour le 28 février 2023. Pour plus d'informations, consultez [Préparation à la fin de vie d'Amazon Aurora Édition compatible avec MySQL version 1](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.MySQL56.EOL.html).

 Les versions d'Aurora MySQL actuellement prises en charge sont les suivantes : 1.19.5, 1.19.6, 1.22.\$1, 1.23.\$1, 2.04.\$1, 2.07.\$1, 2.08.\$1, 2.09.\$1, 2.10.\$1, 3.01.\$1 et 3.02.\$1. 

 Pour créer un cluster avec une ancienne version d'Aurora MySQL, spécifiez la version du moteur via la console RDS, la AWS CLI ou l'API Amazon RDS. 

**Note**  <a name="lts_notice_1224"></a>
 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](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Updates.Versions.html#AuroraMySQL.Updates.LTS) dans le *Guide de l'utilisateur Amazon Aurora*. 

 Si vous avez des questions ou des préoccupations, le AWS support est disponible sur les forums communautaires et via le [AWS support](https://aws.amazon.com/support). Pour plus d'informations, consultez [Entretien d'un cluster de base de données Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_UpgradeDBInstance.Maintenance.html) dans le *Guide de l'utilisateur Amazon Aurora*. 

## Améliorations
<a name="AuroraMySQL.Updates.1224.Improvements"></a>

 **Correctifs de sécurité :** 

 Correctifs et autres améliorations visant à peaufiner la gestion dans un environnement géré. Correctifs CVE supplémentaires ci-dessous : 
+ [CVE-2020-14867](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-14867)
+ [CVE-2020-14812](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-14812)
+ [CVE-2020-14793](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-14793)
+ [CVE-2020-14769](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-14769)
+ [CVE-2020-14765](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-14765)
+ [CVE-2020-14672](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-14672)
+ [CVE-2020-1971](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-1971)

 **Améliorations de la disponibilité :** 
+  Correction d'un problème susceptible de déclencher un redémarrage ou un basculement de la base de données au cours d'une commande `kill session`. Si vous rencontrez ce problème, contactez le AWS support pour activer ce correctif sur votre instance. 
+  Amélioration de la journalisation binaire pour réduire le temps de récupération sur incident et la latence de validation lorsque de grandes transactions sont incluses. 
+  Correction d'un problème qui provoquait l'arrêt d'un réplica de journal binaire avec une erreur `HA_ERR_KEY_NOT_FOUND`. 

# Mises à jour du moteur de base de données Aurora MySQL du 19/11/2020 (version 1.22.3) (obsolète)
<a name="AuroraMySQL.Updates.1223"></a><a name="1223"></a><a name="1.22.3"></a>

**Version :** 1.22.3

Aurora MySQL 1.22.3 est disponible. Les versions 1.x d'Aurora MySQL sont compatibles avec MySQL 5.6 et les versions 2.x d'Aurora MySQL sont compatibles avec MySQL 5.7.

L'obsolescence de cette version du moteur est prévue pour le 28 février 2023. Pour plus d'informations, consultez [Préparation à la fin de vie d'Amazon Aurora Édition compatible avec MySQL version 1](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.MySQL56.EOL.html).

 Les versions d'Aurora MySQL actuellement prises en charge sont les suivantes : 1.19.5, 1.19.6, 1.22.\$1, 1.23.\$1, 2.04.\$1, 2.07.\$1, 2.08.\$1, 2.09.\$1, 2.10.\$1, 3.01.\$1 et 3.02.\$1. 

 Pour créer un cluster avec une ancienne version d'Aurora MySQL, spécifiez la version du moteur via la console RDS, la AWS CLI ou l'API Amazon RDS. 

**Note**  <a name="lts_notice_1223"></a>
 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](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Updates.Versions.html#AuroraMySQL.Updates.LTS) dans le *Guide de l'utilisateur Amazon Aurora*. 

 Si vous avez des questions ou des préoccupations, le AWS support est disponible sur les forums communautaires et via le [AWS support](https://aws.amazon.com/support). Pour plus d'informations, consultez [Entretien d'un cluster de base de données Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_UpgradeDBInstance.Maintenance.html) dans le *Guide de l'utilisateur Amazon Aurora*. 

## Améliorations
<a name="AuroraMySQL.Updates.1223.Improvements"></a>

 **Correctifs de sécurité :** 

 Correctifs et autres améliorations visant à peaufiner la gestion dans un environnement géré. Correctifs CVE supplémentaires ci-dessous : 
+ [CVE-2020-14559](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-14559)
+ [CVE-2020-14539](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-14539)
+ [CVE-2020-2579](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-2579)
+ [CVE-2020-2812](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-2812)
+ [CVE-2020-2780](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-2780)
+ [CVE-2020-2763](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-2763)

 **Modifications incompatibles :** 

 Cette version introduit une modification d'autorisation qui affecte le comportement de la commande `mysqldump`. Les utilisateurs doivent disposer du privilège `PROCESS` pour accéder à la table `INFORMATION_SCHEMA.FILES`. Pour exécuter la commande `mysqldump` sans aucune modification, accordez le privilège `PROCESS` à l'utilisateur de base de données auquel la commande `mysqldump` se connecte. Vous pouvez également exécuter la commande `mysqldump` avec l'option `--no-tablespaces`. Avec cette option, la sortie `mysqldump ` n'inclut aucune instruction `CREATE LOGFILE GROUP` ou `CREATE TABLESPACE`. Dans ce cas, la commande `mysqldump` n'accède pas à la table `INFORMATION_SCHEMA.FILES` et vous n'avez pas besoin d'accorder l'autorisation `PROCESS`. 

 **Améliorations de la disponibilité :** 
+  Correction de problèmes pouvant entraîner le redémarrage du serveur lors de la restauration d'une instruction DDL qui n'a pas été validée. 
+  Correction des conditions de concurrence dans le gestionnaire de verrous pouvant provoquer le redémarrage du serveur. 
+  Correction d'un problème pouvant entraîner le redémarrage du serveur par l'agent de surveillance lors de la récupération d'une transaction volumineuse. 

 **Améliorations générales :** 
+  Comportement modifié pour mapper `MIXED` `binlog_format` sur `ROW` au lieu de `STATEMENT` lors de l'exécution de `LOAD DATA FROM INFILE | S3`. 
+  Correction d'un problème dans lequel un réplica de journal binaire connecté à un principal de journal binaire Aurora MySQL pouvait afficher des données incomplètes lorsque le principal exécutait `LOAD DATA FROM S3` et `binlog_format` défini sur `STATEMENT`. 

## Intégration de correctifs de bogues de l'édition MySQL Community Edition
<a name="AuroraMySQL.Updates.1223.Patches"></a>
+  Bogue n° 26654685 : Un ID d'index corrompu rencontré lors d'une vérification de clé étrangère déclenchait une assertion. 
+  Bogue n° 15831300 : Par défaut, lors de la promotion de nombres entiers d'un type plus petit sur le maître à un type plus grand sur l'esclave (par exemple, d'une colonne [SMALLINT](https://dev.mysql.com/doc/refman/5.6/en/integer-types.html) sur le maître à une colonne [BIGINT](https://dev.mysql.com/doc/refman/5.6/en/integer-types.html) sur l'esclave), les valeurs promues sont traitées comme si elles étaient signées. Dans de tels cas, il est possible de modifier ou de remplacer ce comportement à l'aide de `ALL_SIGNED`, de `ALL_UNSIGNED` ou des deux dans l'ensemble des valeurs spécifiées pour la variable système serveur [slave\$1type\$1conversions](https://dev.mysql.com/doc/refman/5.6/en/replication-options-replica.html#sysvar_slave_type_conversions). Pour en savoir plus, consultez la section [Row-based replication: attribute promotion and demotion](https://dev.mysql.com/doc/refman/5.6/en/replication-features-differing-tables.html#replication-features-attribute-promotion), ainsi que la description de la variable. 
+  Bogue n° 17449901 : Avec `foreign_key_checks=0`, InnoDB permettait de supprimer un index requis par une contrainte de clé étrangère, plaçant la table dans une incohérence et provoquant l'échec de la vérification de la clé étrangère lors du chargement de la table. InnoDB empêche désormais de supprimer un index requis par une contrainte de clé étrangère, même avec foreign\$1key\$1checks=0. La contrainte de clé étrangère doit être supprimée avant de supprimer l'index de clé étrangère. 
+  BOGUE n° 20768847 : Une opération [ALTER TABLE ... Opération DROP INDEX](https://dev.mysql.com/doc/refman/5.7/en/alter-table.html) sur une table avec des dépendances de clé étrangère déclenchait une assertion. 

# Mises à jour du moteur de base de données Aurora MySQL du 05/03/2020 (version 1.22.2) (obsolète)
<a name="AuroraMySQL.Updates.1222"></a>

**Version :** 1.22.2

Aurora MySQL 1.22.2 est en disponibilité générale. Les versions 1.x d'Aurora MySQL sont compatibles avec MySQL 5.6 et les versions 2.x d'Aurora MySQL sont compatibles avec MySQL 5.7.

L'obsolescence de cette version du moteur est prévue pour le 28 février 2023. Pour plus d'informations, consultez [Préparation à la fin de vie d'Amazon Aurora Édition compatible avec MySQL version 1](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.MySQL56.EOL.html).

 Les versions d'Aurora MySQL actuellement prises en charge sont les suivantes : 1.19.5, 1.19.6, 1.22.\$1, 1.23.\$1, 2.04.\$1, 2.07.\$1, 2.08.\$1, 2.09.\$1, 2.10.\$1, 3.01.\$1 et 3.02.\$1. 

 Pour créer un cluster avec une ancienne version d'Aurora MySQL, veuillez spécifier la version du moteur via la console RDS, la AWS CLI ou l'API Amazon RDS. 

**Note**  
 Cette version n'est actuellement pas disponible dans les régions suivantes : AWS GovCloud (US-East) [us-gov-east-1], AWS GovCloud (US-West) [us-gov-west-1]. Sa disponibilité fera l'objet d'une annonce distincte.   
 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](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Updates.Versions.html#AuroraMySQL.Updates.LTS) dans le *Guide de l'utilisateur Amazon Aurora*. 

Si vous avez des questions ou des préoccupations, le AWS support est disponible sur les forums communautaires et via le [AWS support](https://aws.amazon.com/support). Pour plus d'informations, consultez [Entretien d'un cluster de base de données Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_UpgradeDBInstance.Maintenance.html) dans le *Guide de l'utilisateur Amazon Aurora*.

## Améliorations
<a name="AuroraMySQL.Updates.1222.Improvements"></a>

 **Correctifs à priorité élevée :** 
+  Correction d'un problème d'échecs intermittents de connexion après la rotation du certificat. 
+  Correction d'un problème qui entraînait un clonage plus long sur certains clusters de bases de données avec des charges d'écriture élevées. 
+  Correction d'un problème qui interrompait la réplication logique lorsque le paramètre `binlog_checksum` était défini sur des valeurs différentes sur l'élément principal et le réplica. 
+  Correction d'un problème de rotation des journaux lents et des journaux généraux sur les réplicas en lecture. 
+  Correction d'un problème avec le comportement du niveau d'isolation Read Committed ANSI. 

# Mises à jour du moteur de base de données Aurora MySQL du 23/12/2019 (version 1.22.1) (obsolète)
<a name="AuroraMySQL.Updates.1221"></a>

**Version :** 1.22.1

 Aurora MySQL 1.22.1 est en général disponible. Les versions 1.x d'Aurora MySQL sont compatibles avec MySQL 5.6 et les versions 2.x d'Aurora MySQL sont compatibles avec MySQL 5.7. 

L'obsolescence de cette version du moteur est prévue pour le 28 février 2023. Pour plus d'informations, consultez [Préparation à la fin de vie d'Amazon Aurora Édition compatible avec MySQL version 1](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.MySQL56.EOL.html).

 Les versions d'Aurora MySQL actuellement prises en charge sont les suivantes : 1.19.5, 1.19.6, 1.22.\$1, 1.23.\$1, 2.04.\$1, 2.07.\$1, 2.08.\$1, 2.09.\$1, 2.10.\$1, 3.01.\$1 et 3.02.\$1. 

 Pour créer un cluster avec une ancienne version d'Aurora MySQL, veuillez spécifier la version du moteur par le biais de l'API AWS Management Console, de l'API AWS CLI ou de l'API RDS. Vous avez la possibilité de mettre à niveau les clusters de bases de données Aurora MySQL 1.\$1 existants vers Aurora MySQL 1.22.1. 

**Note**  
 Cette version n'est actuellement pas disponible dans les AWS régions suivantes : AWS GovCloud (US-East) [us-gov-east-1], AWS GovCloud (US-West) [us-gov-west-1], Chine (Ningxia) [cn-northwest-1], Asie-Pacifique (Hong Kong) [ap-east-1] et Moyen-Orient (Bahreïn) [me-south-1]. Sa disponibilité fera l'objet d'une annonce distincte. 

 Si vous avez des questions ou des préoccupations, le AWS support est disponible sur les forums communautaires et via le [AWS support](https://aws.amazon.com/support). Pour plus d'informations, consultez [Entretien d'un cluster de base de données Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_UpgradeDBInstance.Maintenance.html) dans le *Guide de l'utilisateur Amazon Aurora*. 

**Note**  
La procédure de mise à niveau du cluster de bases de données a changé. Pour plus d'informations, consultez [Mise à niveau de la version mineure ou du niveau de correctif d'un cluster de bases de données Aurora MySQL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Updates.Patching.html) dans le *Guide de l'utilisateur Amazon Aurora*.

## Améliorations
<a name="AuroraMySQL.Updates.1221.Improvements"></a>

 **Correctifs critiques :** 
+ Correction de problèmes qui empêchaient la récupération du moteur impliquant des verrous de table et des tables temporaires.
+ Amélioration de la stabilité du journal binaire lorsque des tables temporaires sont utilisées.

 **Correctifs à priorité élevée :** 
+ Correction d'une fuite de mémoire lente dans le sous-système de suivi et de journalisation de base de données spécifique à Aurora qui réduisait la mémoire libérable.

# Mises à jour du moteur de base de données Aurora MySQL du 25/11/2019 (version 1.22.0) (obsolète)
<a name="AuroraMySQL.Updates.1220"></a>

**Version :** 1.22.0

 Aurora MySQL 1.22.0 est en général disponible. Les versions 1.x d'Aurora MySQL sont compatibles avec MySQL 5.6 et les versions 2.x d'Aurora MySQL sont compatibles avec MySQL 5.7. 

L'obsolescence de cette version du moteur est prévue pour le 28 février 2023. Pour plus d'informations, consultez [Préparation à la fin de vie d'Amazon Aurora Édition compatible avec MySQL version 1](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.MySQL56.EOL.html).

 Les versions d'Aurora MySQL actuellement prises en charge sont les suivantes : 1.19.5, 1.19.6, 1.22.\$1, 1.23.\$1, 2.04.\$1, 2.07.\$1, 2.08.\$1, 2.09.\$1, 2.10.\$1, 3.01.\$1 et 3.02.\$1. 

 Pour créer un cluster avec une ancienne version d'Aurora MySQL, veuillez spécifier la version du moteur par le biais de l'API AWS Management Console, de l'API AWS CLI ou de l'API RDS. Vous avez la possibilité de mettre à niveau les clusters de bases de données Aurora MySQL 1.\$1 existants vers Aurora MySQL 1.22.0. 

**Note**  
 Cette version n'est actuellement pas disponible dans les AWS régions suivantes : AWS GovCloud (US-East) [us-gov-east-1], AWS GovCloud (US-West) [us-gov-west-1], Chine (Ningxia) [cn-northwest-1], Asie-Pacifique (Hong Kong) [ap-east-1], Moyen-Orient (Bahreïn) [me-south-1] et Amérique du Sud (São Paulo) [sa-east-1] [1]. Sa disponibilité fera l'objet d'une annonce distincte. 

 Si vous avez des questions ou des préoccupations, le AWS support est disponible sur les forums communautaires et via le [AWS support](https://aws.amazon.com/support). Pour plus d'informations, consultez [Entretien d'un cluster de base de données Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_UpgradeDBInstance.Maintenance.html) dans le *Guide de l'utilisateur Amazon Aurora*. 

**Note**  
La procédure de mise à niveau du cluster de bases de données a changé. Pour plus d'informations, consultez [Mise à niveau de la version mineure ou du niveau de correctif d'un cluster de bases de données Aurora MySQL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Updates.Patching.html) dans le *Guide de l'utilisateur Amazon Aurora*.

## Améliorations
<a name="AuroraMySQL.Updates.1220.Improvements"></a>

 **Nouvelles fonctions :** 
+  Les clusters Aurora MySQL prennent désormais en charge les types d'instance db.r5.8xlarge, db.r5.16xlarge et db.r5.24xlarge. 
+  Nouvelles améliorations apportées aux journaux binaires (binlog) pour une meilleure latence de validation lorsque de très larges transactions sont impliquées. 
+  Aurora MySQL possède désormais un mécanisme pour réduire la fenêtre de temps pendant laquelle les événements d'une transaction volumineuse sont écrits sur les journaux binaires à la validation. Cette solution empêche les interminables récupérations hors connexion lorsque les arrêts de base de données se produisent pendant cette fenêtre temporelle. Cette fonctionnalité corrige aussi le problème où une transaction volumineuse bloque les petites transactions sur la validation des journaux binaires. Cette fonctionnalité est désactivée par défaut et peut être activée par l'équipe du service si nécessaire pour la charge de travail. Lorsqu'elle est activée, elle est déclenchée lorsqu'une taille de transaction est > 500 Mo. 
+  Ajout de la prise en charge pour le niveau d'isolation ANSI `READ COMMITTED` sur les réplicas en lecture. Ce niveau d'isolation permet aux requêtes de longue durée sur le réplica en lecture de s'exécuter sans impacter le haut débit des écritures sur le nœud d'écriture. Pour plus d'informations, veuillez consulter [Niveaux d'isolation Aurora MySQL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Reference.html#AuroraMySQL.Reference.IsolationLevels). 
+  Les bases de données mondiales permettent désormais d'ajouter des régions de réplication secondaires en lecture seule pour les clusters de bases de données déployés dans ces AWS régions : régions : USA Est (Virginie du Nord) [us-east-1], USA Est (Ohio) [us-east-2], USA Ouest (Californie du Nord) [us-west-1], USA Ouest (Oregon) [us-west-2], Europe (Irlande) [eu-west-2] eu-west-1], Europe (Londres) [eu-west-2], Europe (Paris) [eu-west-3], Asie-Pacifique (Tokyo) [ap-northeast-1], Asie-Pacifique (Séoul) [ap-northeast-2], Asie-Pacifique (Singapour) [ap-northeast-2] ap-southeast-1], Asie-Pacifique (Sydney) [ap-southeast-2], Canada (centre) [ca-central-1], Europe (Francfort) [ eu-central-1] et Asie-Pacifique (Mumbai) [ap-south-1]. 
+  La fonctionnalité de conflits entre lignes critiques est désormais disponible et ne nécessite pas que le mode lab Aurora soit activé (ON). Cette fonction améliore nettement le débit pour les charges où de nombreuses transactions sont en conflit pour les lignes d'une même page. 
+  Cette version possède des fichiers de fuseau horaire mis à jour pour prendre en charge la dernière mise à jour du fuseau du Brésil pour les nouveaux clusters. 

 **Correctifs critiques :** 
+ [CVE-2019-2922](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-2922)
+ [CVE-2019-2923](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-2923)
+ [CVE-2019-2924](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-2924)
+ [CVE-2019-2910](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-2910)

 **Correctifs à priorité élevée :** 
+ [CVE-2019-2805](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-2805)
+ [CVE-2019-2730](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-2730)
+ [CVE-2019-2740](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-2740)
+ [CVE-2018-3064](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-3064)
+ [CVE-2018-3058](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-3058)
+ [CVE-2017-3653](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-3653)
+ [CVE-2017-3464](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-3464)
+ [CVE-2017-3244](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-3244)
+ [CVE-2016-5612](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-5612)
+ [CVE-2016-5439](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-5439)
+ [CVE-2016-0606](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-0606)
+ [CVE-2015-4904](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-4904)
+ [CVE-2015-4879](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-4879)
+ [CVE-2015-4864](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-4864)
+ [CVE-2015-4830](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-4830)
+ [CVE-2015-4826](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-4826)
+ [CVE-2015-2620](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-2620)
+ [CVE-2015-0382](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-0382)
+ [CVE-2015-0381](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-0381)
+ [CVE-2014-6555](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-6555)
+ [CVE-2014-4258](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-4258)
+ [CVE-2014-4260](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-4260)
+ [CVE-2014-2444](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-2444)
+ [CVE-2014-2436](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-2436)
+ [CVE-2013-5881](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-5881)
+ [CVE-2014-0393](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0393)
+ [CVE-2013-5908](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-5908)
+ [CVE-2013-5807](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-5807)
+ [CVE-2013-3806](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-3806)
+ [CVE-2013-3811](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-3811)
+ [CVE-2013-3804](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-3804)
+ [CVE-2013-3807](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-3807)
+ [CVE-2013-2378](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-2378)
+ [CVE-2013-2375](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-2375)
+ [CVE-2013-1523](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-1523)
+ [CVE-2013-2381](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-2381)
+ [CVE-2012-5615](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-5615)
+ [CVE-2014-6489](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-6489)
+  Correction du problème du composant de récupération de DLL qui entraînait un arrêt prolongé de la base de données. Les clusters devenus indisponibles après l'exécution d'une requête `TRUNCATE TABLE` sur une table avec une colonne `AUTO_INCREMENT` doivent être mis à jour. 
+  Correction du problème du composant de récupération de DLL qui entraînait un arrêt prolongé de la base de données. Les clusters devenus indisponibles après l'exécution d'une requête `DROP TABLE` sur plusieurs tables en parallèle doivent être mis à jour. 

 **Correctifs de stabilité générale :** 
+  Correction d'un problème qui provoquait le redémarrage de réplicas en lecture pendant une transaction de longue durée. Les clients confrontés à des démarrages de réplicas coïncidant avec une suppression accélérée dans la mémoire libérable doivent envisager de mettre cette version à niveau. 
+  Correction d'un problème signalant à tort une erreur `ERROR 1836` lorsqu'une requête imbriquée est exécutée sur une table temporaire sur le réplica en lecture. 
+  Résolution d'une erreur d'annulation de requête sur les instances de lecteur Aurora pendant l'exécution d'une charge de travail intense en écriture sur l'instance d'écriture Aurora. 
+  Correction du problème qui entraîne le redémarrage d'une base de données configurée comme « journal binaire principal (binlog) » tandis qu'une charge massive de travail en écriture est en cours d'exécution. 
+  Correction du problème d'indisponibilité prolongée lors du redémarrage du moteur. La correction concerne un problème d'initialisation du pool de mémoires tampon. Ce problème se produit rarement, mais peut éventuellement impacter toute version prise en charge. 
+  Correction d'un problème qui générait des données non cohérentes dans la table `information_schema.replica_host_status`. 
+  Correction d'une condition de course entre la requête parallèle et les chemins d'exécution standard qui entraînait le redémarrage intermittent des nœuds en lecture. 
+  Amélioration de la stabilité de la base de données lorsque le nombre de connexions clients dépasse la valeur du paramètre `max_connections`. 
+  Amélioration de la stabilité des instances en lecture grâce au blocage des DLL non prises en charge et des requêtes `LOAD FROM S3`. 

## Intégration de correctifs de bogues de l'édition MySQL Community Edition
<a name="AuroraMySQL.Updates.1220.Patches"></a>
+  Bogue \$116346241 - ARRÊT DU SERVEUR DANS ITEM\$1PARAM::QUERY\$1VAL\$1STR 
+  Bogue \$117733850 - ARRÊT DE NAME\$1CONST() DANS ITEM\$1NAME\$1CONST::ITEM\$1NAME\$1CONST() 
+  Bogue \$120989615: INNODB AUTO\$1INCREMENT GÉNÈRE DEUX FOIS LA MÊME VALEUR 
+  Bogue \$120181776 - LE CONTRÔLE D'ACCÈS NE CORRESPOND PAS À L'HÔTE LE PLUS SPÉCIFIQUE QUAND IL CONTIENT DES CARACTÈRES GÉNÉRIQUES 
+  Bug \$127326796 - BLOCAGE DE MYSQL AVEC ÉCHEC DE L'ASSERTION INNODB DANS LE FICHIER PARS.CC PARS0 
+  Bug \$120590013 - IF YOU HAVE A FULLTEXT INDEX AND DROP IT YOU CAN NO LONGER PERFORM ONLINE DDL 

# Mises à jour du moteur de base de données Aurora MySQL du 25/11/2019 (version 1.21.0) (obsolète)
<a name="AuroraMySQL.Updates.1210"></a>

**Version :** 1.21.0

 Aurora MySQL 1.21.0 est en général disponible. Les versions 1.x d'Aurora MySQL sont compatibles avec MySQL 5.6 et les versions 2.x d'Aurora MySQL sont compatibles avec MySQL 5.7. 

Versions Aurora MySQL actuellement prises en charge : 1.14.\$1, 1.15.\$1, 1.16.\$1, 1.17.\$1, 1.18.\$1, 1.19.\$1, 1.20.\$1, 1.21.\$1, 1.22.\$1, 2.01.\$1, 2.02.\$1, 2.03.\$1, 2.04.\$1, 2.05.\$1, 2.06.\$1 et 2.07.\$1. Pour créer un cluster avec une ancienne version d'Aurora MySQL, veuillez spécifier la version du moteur par le biais de l'API AWS Management Console, de l'API AWS CLI ou de l'API RDS. Vous avez la possibilité de mettre à niveau les clusters de bases de données Aurora MySQL 1.\$1 existants vers Aurora MySQL 1.21.0. 

**Note**  
 Cette version n'est actuellement pas disponible dans les AWS régions suivantes : AWS GovCloud (US-East) [us-gov-east-1], AWS GovCloud (US-West) [us-gov-west-1], Chine (Ningxia) [cn-northwest-1], Asie-Pacifique (Hong Kong) [ap-east-1], Europe (Stockholm) [eu-north-1] et Moyen-Orient (Bahreïn) [me-south-1]. Sa disponibilité fera l'objet d'une annonce distincte. 

 Si vous avez des questions ou des préoccupations, le AWS support est disponible sur les forums communautaires et via le [AWS support](https://aws.amazon.com/support). Pour plus d'informations, consultez [Entretien d'un cluster de base de données Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_UpgradeDBInstance.Maintenance.html) dans le *Guide de l'utilisateur Amazon Aurora*. 

**Note**  
La procédure de mise à niveau du cluster de bases de données a changé. Pour plus d'informations, consultez [Mise à niveau de la version mineure ou du niveau de correctif d'un cluster de bases de données Aurora MySQL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Updates.Patching.html) dans le *Guide de l'utilisateur Amazon Aurora*.

## Améliorations
<a name="AuroraMySQL.Updates.1210.Improvements"></a>

 **Correctifs critiques :** 
+ [CVE-2018-0734](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-0734)
+ [CVE-2019-2534](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-2534)
+ [CVE-2018-2612](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-2612)
+ [CVE-2017-3599](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-3599)
+ [CVE-2018-2562](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-2562)
+ [CVE-2017-3329](https://nvd.nist.gov/vuln/detail/CVE-2017-3329)
+ [CVE-2018-2696](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-2696)
+ [CVE-2015-4737](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-4737)

 **Correctifs à priorité élevée :** 
+  Il est vivement recommandé aux clients dont la taille de la base de données est proche de 64 tébioctets (TiO) de procéder à une mise à niveau vers cette version pour éviter les arrêts dus aux bogues de stabilité affectant les volumes proches de la limite de stockage Aurora. 

 **Correctifs de stabilité générale :** 
+  Résolution d'une erreur d'annulation de requête sur les instances de lecteur Aurora pendant l'exécution d'une charge de travail intense en écriture sur l'instance d'écriture Aurora. 
+  Résolution d'un problème sur les instances de lecteur Aurora qui ont réduit la mémoire disponible pendant des transactions longues alors qu'il y a un trafic important d'engagement des transactions sur l'instance d'écriture. 
+  La valeur du paramètre `aurora_disable_hash_join` est maintenant conservée après le redémarrage de la base de données ou le remplacement de l'hôte. 
+  Résolution d'un problème lié au cache de recherche de la totalité du texte en raison duquel l'instance Aurora a manqué de mémoire. Les clients qui utilisent la recherche en texte intégral doivent procéder à une mise à niveau. 
+  Amélioration de la stabilité de la base de données lorsque la fonction de jointure de hachage est activée et que l'instance dispose de peu de mémoire. Les clients qui utilisent la jointure par hachage doivent procéder à une mise à niveau. 
+  Résolution d'un problème dans le cache de requête selon lequel l'erreur « Trop de connexions » pouvait entraîner un redémarrage. 
+  Résolution du calcul de mémoire disponible sur les instances T2 de façon à inclure un espace d'échange de mémoire pour empêcher les redémarrages superflus. 

## Intégration de correctifs de bogues de l'édition MySQL Community Edition
<a name="AuroraMySQL.Updates.1210.Patches"></a>
+  Bug \$119929406 : HANDLE\$1FATAL\$1SIGNAL (SIG=11) DANS \$1\$1MEMMOVE\$1 \$1BACK FROM STRING : :COPY SSSE3 
+  Bogue n° 17059925 : pour les instructions [UNION](https://dev.mysql.com/doc/refman/5.6/en/union.html), la valeur examinée par les lignes a été calculée de façon incorrecte. Cela a donné des valeurs trop importantes pour la colonne `ROWS_EXAMINED` des tables de l'instruction Schéma des performances (par exemple, [events\$1statements\$1current](https://dev.mysql.com/doc/refman/8.0/en/performance-schema-events-statements-current-table.html)). 
+  Bogue n° 11827369 : certaines requêtes avec des sous-requêtes imbriquées `SELECT ... FROM DUAL` ont généré une assertion. 
+  Bogue n° 16311231 : des résultats incorrects ont été renvoyés lorsqu'une requête contenait une sous-requête dans une clause `IN` qui contenait une opération [XOR](https://dev.mysql.com/doc/refman/5.6/en/logical-operators.html#operator_xor) dans la clause `WHERE`. 

# Mises à jour du moteur de base de données Aurora MySQL du 05/03/2020 (version 1.20.1) (obsolète)
<a name="AuroraMySQL.Updates.1201"></a>

**Version :** 1.20.1

Aurora MySQL 1.20.1 est en disponibilité générale. Les versions 1.x d'Aurora MySQL sont compatibles avec MySQL 5.6 et les versions 2.x d'Aurora MySQL sont compatibles avec MySQL 5.7.

 Versions Aurora MySQL actuellement prises en charge : 1.14.\$1, 1.15.\$1, 1.16.\$1, 1.17.\$1, 1.18.\$1, 1.19.\$1, 1.20.\$1, 1.21.\$1, 1.22.\$1, 2.01.\$1, 2.02.\$1, 2.03.\$1, 2.04.\$1, 2.05.\$1, 2.06.\$1 et 2.07.\$1. Vous pouvez restaurer l'instantané d'une base de données Aurora MySQL 1.\$1 à la version Aurora MySQL 1.20.1. 

 Pour créer un cluster avec une ancienne version d'Aurora MySQL, veuillez spécifier la version du moteur via la console RDS, la AWS CLI ou l'API Amazon RDS. 

**Note**  
 Cette version n'est actuellement pas disponible dans les régions suivantes : AWS GovCloud (US-East) [us-gov-east-1], AWS GovCloud (US-West) [us-gov-west-1]. Sa disponibilité fera l'objet d'une annonce distincte. 

Si vous avez des questions ou des préoccupations, le AWS support est disponible sur les forums communautaires et via le [AWS support](https://aws.amazon.com/support). Pour plus d'informations, consultez [Entretien d'un cluster de base de données Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_UpgradeDBInstance.Maintenance.html) dans le *Guide de l'utilisateur Amazon Aurora*.

## Améliorations
<a name="AuroraMySQL.Updates.1201.Improvements"></a>

 **Correctifs à priorité élevée :** 
+  Correction d'un problème d'échecs intermittents de connexion après la rotation du certificat. 
+  Correction d'un problème lié à la simultanéité de la fermeture des connexions qui entraînerait un basculement sur incident en cas de charge de travail importante. 

 **Correctifs de stabilité générale :** 
+  Correction d'un incident lors de l'exécution d'une requête complexe impliquant une agrégation et des jointures de plusieurs tables utilisant en interne des tables intermédiaires. 

# Mises à jour du moteur de base de données Aurora MySQL du 11/11/2019 (version 1.20.0) (obsolète)
<a name="AuroraMySQL.Updates.1200"></a>

**Version :** 1.20.0

 Aurora MySQL 1.20.0 est en général disponible. Les versions 1.x d'Aurora MySQL sont compatibles avec MySQL 5.6 et les versions 2.x d'Aurora MySQL sont compatibles avec MySQL 5.7. 

 Versions Aurora MySQL actuellement prises en charge : 1.14.\$1, 1.15.\$1, 1.16.\$1, 1.17.\$1, 1.18.\$1, 1.19.\$1, 1.20.\$1, 2.01.\$1, 2.02.\$1, 2.03.\$1 et 2.04.\$1. Pour créer un cluster avec une ancienne version d'Aurora MySQL, veuillez spécifier la version du moteur par le biais de l'API AWS Management Console, de l'API AWS CLI ou de l'API RDS. Vous avez la possibilité de mettre à niveau les clusters de bases de données Aurora MySQL 1.\$1 existants vers 1.19.5 ou Aurora MySQL 1.20.0. 

**Note**  
 Cette version n'est actuellement pas disponible dans les AWS régions suivantes : AWS GovCloud (US-East) [us-gov-east-1], AWS GovCloud (US-West) [us-gov-west-1], Chine (Ningxia) [cn-northwest-1], Asie-Pacifique (Hong Kong) [ap-east-1], Europe (Stockholm) [eu-north-1] et Moyen-Orient (Bahreïn) [me-south-1]. Sa disponibilité fera l'objet d'une annonce distincte. 

 Si vous avez des questions ou des préoccupations, le AWS support est disponible sur les forums communautaires et via le [AWS support](https://aws.amazon.com/support). Pour plus d'informations, consultez [Entretien d'un cluster de base de données Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_UpgradeDBInstance.Maintenance.html) dans le *Guide de l'utilisateur Amazon Aurora*. 

**Note**  
La procédure de mise à niveau du cluster de bases de données a changé. Pour plus d'informations, consultez [Mise à niveau de la version mineure ou du niveau de correctif d'un cluster de bases de données Aurora MySQL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Updates.Patching.html) dans le *Guide de l'utilisateur Amazon Aurora*.

## Améliorations
<a name="AuroraMySQL.Updates.1200.Improvements"></a>

 **Correctifs critiques :** 
+ [CVE-2018-0734](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-0734)
+ [CVE-2019-2534](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-2534)
+ [CVE-2018-2612](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-2612)
+ [CVE-2017-3599](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-3599)
+ [CVE-2018-2562](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-2562)
+ [CVE-2017-3329](https://nvd.nist.gov/vuln/detail/CVE-2017-3329)
+ [CVE-2018-2696](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-2696)
+ [CVE-2015-4737](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-4737)

 **Correctifs à priorité élevée :** 
+  Il est vivement recommandé aux clients dont la taille de la base de données est proche de 64 tébioctets (TiO) de procéder à une mise à niveau vers cette version pour éviter les arrêts dus aux bogues de stabilité affectant les volumes proches de la limite de stockage Aurora. 

 **Correctifs de stabilité générale :** 
+  Résolution d'une erreur d'annulation de requête sur les instances de lecteur Aurora pendant l'exécution d'une charge de travail intense en écriture sur l'instance d'écriture Aurora. 
+  Résolution d'un problème sur les instances de lecteur Aurora qui ont réduit la mémoire disponible pendant des transactions longues alors qu'il y a un trafic important d'engagement des transactions sur l'instance d'écriture. 
+  La valeur du paramètre `aurora_disable_hash_join` est maintenant conservée après le redémarrage de la base de données ou le remplacement de l'hôte. 
+  Résolution d'un problème lié au cache de recherche de la totalité du texte en raison duquel l'instance Aurora a manqué de mémoire. Les clients qui utilisent la recherche en texte intégral doivent procéder à une mise à niveau. 
+  Amélioration de la stabilité de la base de données lorsque la fonction de jointure de hachage est activée et que l'instance dispose de peu de mémoire. Les clients qui utilisent la jointure par hachage doivent procéder à une mise à niveau. 
+  Résolution d'un problème dans le cache de requête selon lequel l'erreur « Trop de connexions » pouvait entraîner un redémarrage. 
+  Résolution du calcul de mémoire disponible sur les instances T2 de façon à inclure un espace d'échange de mémoire pour empêcher les redémarrages superflus. 

## Intégration de correctifs de bogues de l'édition MySQL Community Edition
<a name="AuroraMySQL.Updates.1200.Patches"></a>
+  Bug \$119929406 : HANDLE\$1FATAL\$1SIGNAL (SIG=11) DANS \$1\$1MEMMOVE\$1 \$1BACK FROM STRING : :COPY SSSE3 
+  Bogue n° 17059925 : pour les instructions [UNION](https://dev.mysql.com/doc/refman/5.6/en/union.html), la valeur examinée par les lignes a été calculée de façon incorrecte. Cela a donné des valeurs trop importantes pour la colonne `ROWS_EXAMINED` des tables de l'instruction Schéma des performances (par exemple, [events\$1statements\$1current](https://dev.mysql.com/doc/refman/8.0/en/performance-schema-events-statements-current-table.html)). 
+  Bogue n° 11827369 : certaines requêtes avec des sous-requêtes imbriquées `SELECT ... FROM DUAL` ont généré une assertion. 
+  Bogue n° 16311231 : des résultats incorrects ont été renvoyés lorsqu'une requête contenait une sous-requête dans une clause `IN` qui contenait une opération [XOR](https://dev.mysql.com/doc/refman/5.6/en/logical-operators.html#operator_xor) dans la clause `WHERE`. 

# Mises à jour du moteur de base de données Aurora MySQL du 05/03/2020 (version 1.19.6) (obsolète)
<a name="AuroraMySQL.Updates.1196"></a>

**Version :** 1.19.6

Aurora MySQL 1.19.6 est en disponibilité générale. Les versions 1.x d'Aurora MySQL sont compatibles avec MySQL 5.6 et les versions 2.x d'Aurora MySQL sont compatibles avec MySQL 5.7.

L'obsolescence de cette version du moteur est prévue pour le 28 février 2023. Pour plus d'informations, consultez [Préparation à la fin de vie d'Amazon Aurora Édition compatible avec MySQL version 1](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.MySQL56.EOL.html).

 Les versions d'Aurora MySQL actuellement prises en charge sont les suivantes : 1.19.5, 1.19.6, 1.22.\$1, 1.23.\$1, 2.04.\$1, 2.07.\$1, 2.08.\$1, 2.09.\$1, 2.10.\$1, 3.01.\$1 et 3.02.\$1. 

 Vous pouvez restaurer l'instantané d'une base de données Aurora MySQL 1.\$1 à la version Aurora MySQL 1.19.6. 

 Pour créer un cluster avec une ancienne version d'Aurora MySQL, veuillez spécifier la version du moteur via la console RDS, la AWS CLI ou l'API Amazon RDS. 

**Note**  
 Cette version n'est actuellement pas disponible dans les régions suivantes : AWS GovCloud (US-East) [us-gov-east-1], AWS GovCloud (US-West) [us-gov-west-1]. Sa disponibilité fera l'objet d'une annonce distincte. 

Si vous avez des questions ou des préoccupations, le AWS support est disponible sur les forums communautaires et via le [AWS support](https://aws.amazon.com/support). Pour plus d'informations, consultez [Entretien d'un cluster de base de données Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_UpgradeDBInstance.Maintenance.html) dans le *Guide de l'utilisateur Amazon Aurora*.

## Améliorations
<a name="AuroraMySQL.Updates.1196.Improvements"></a>

 **Correctifs à priorité élevée :** 
+  Correction d'un problème d'échecs intermittents de connexion après la rotation du certificat. 

# Mises à jour du moteur de base de données Aurora MySQL du 19/09/2019 (version 1.19.5) (obsolète)
<a name="AuroraMySQL.Updates.1195"></a>

**Version :** 1.19.5

 Aurora MySQL 1.19.5 est disponible pour le grand public. Les versions 1.x d'Aurora MySQL sont compatibles avec MySQL 5.6 et les versions 2.x d'Aurora MySQL sont compatibles avec MySQL 5.7. 

L'obsolescence de cette version du moteur est prévue pour le 28 février 2023. Pour plus d'informations, consultez [Préparation à la fin de vie d'Amazon Aurora Édition compatible avec MySQL version 1](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.MySQL56.EOL.html).

 Les versions d'Aurora MySQL actuellement prises en charge sont les suivantes : 1.19.5, 1.19.6, 1.22.\$1, 1.23.\$1, 2.04.\$1, 2.07.\$1, 2.08.\$1, 2.09.\$1, 2.10.\$1, 3.01.\$1 et 3.02.\$1. 

 Vous avez la possibilité de mettre à niveau les clusters de bases de données existants vers Aurora MySQL 1.19.5. Vous pouvez restaurer les instantanés d'Aurora MySQL 1.14.\$1, 1.15.\$1, 1.16.\$1, 1.17.\$1, 1.18.\$1, 1.19.1 et 1.19.2 dans Aurora MySQL 1.19.5. 

 Pour utiliser une ancienne version d'Aurora MySQL, vous pouvez créer de nouveaux clusters de bases de données en spécifiant la version du moteur par le biais de l'API AWS Management Console, de AWS CLI, ou de l'API RDS. 

 Si vous avez des questions ou des préoccupations, le AWS support est disponible sur les forums communautaires et via le [AWS support](https://aws.amazon.com/support). Pour plus d'informations, consultez [Entretien d'un cluster de base de données Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_UpgradeDBInstance.Maintenance.html) dans le *Guide de l'utilisateur Amazon Aurora*. 

**Note**  
 Cette version n'est actuellement pas disponible dans les AWS régions suivantes : Europe (Londres) [eu-west-2] AWS GovCloud , (US-Est) [-1], (US-Ouest) us-gov-east [-1] AWS GovCloud , Chine (Ningxia) us-gov-west [cn-northwest-1] et Asie-Pacifique (Hong Kong) [ap-east-1]. Sa disponibilité fera l'objet d'une annonce distincte. 

**Note**  
La procédure de mise à niveau du cluster de bases de données a changé. Pour plus d'informations, consultez [Mise à niveau de la version mineure ou du niveau de correctif d'un cluster de bases de données Aurora MySQL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Updates.Patching.html) dans le *Guide de l'utilisateur Amazon Aurora*.

## Améliorations
<a name="AuroraMySQL.Updates.1195.Improvements"></a>
+  Résolution d'un problème sur les instances de lecteur Aurora qui ont réduit la mémoire disponible pendant des transactions longues alors qu'il y a un trafic important d'engagement des transactions sur l'instance d'écriture. 
+  Résolution d'une erreur d'annulation de requête sur les instances de lecteur Aurora pendant l'exécution d'une charge de travail intense en écriture sur l'instance d'écriture Aurora. 
+  La valeur du paramètre `aurora_disable_hash_join` est maintenant conservée après le redémarrage de la base de données ou le remplacement de l'hôte. 
+  Résolution d'un problème lié au cache de recherche de la totalité du texte en raison duquel l'instance Aurora a manqué de mémoire. 
+  Amélioration de la stabilité de la base de données lorsque la taille du volume est proche de la limite des 64 tébioctets (Tio) en réservant 160 Go d'espace pour que le flux de travail soit réalisé sans basculement. 
+  Amélioration de la stabilité de la base de données lorsque la fonction de jointure de hachage est activée et que l'instance dispose de peu de mémoire. 
+  Résolution du calcul de mémoire disponible de façon à inclure un espace d'échange de mémoire sur les instances T2 ayant entraîné un redémarrage prématuré. 
+  Résolution d'un problème dans le cache de requête selon lequel l'erreur « Trop de connexions » pouvait entraîner un redémarrage. 

## Intégration de correctifs de bogues de l'édition MySQL Community Edition
<a name="AuroraMySQL.Updates.1195.Patches"></a>
+  [CVE-2018-2696](http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-2696) 
+  [CVE-2015-4737](http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-4737) 
+  Bug \$119929406 : HANDLE\$1FATAL\$1SIGNAL (SIG=11) DANS \$1\$1MEMMOVE\$1 \$1BACK FROM STRING : :COPY SSSE3 
+  Bogue n° 17059925 : pour les instructions [UNION](https://dev.mysql.com/doc/refman/5.6/en/union.html), la valeur examinée par les lignes a été calculée de façon incorrecte. Cela a donné des valeurs trop importantes pour la colonne `ROWS_EXAMINED` des tables de l'instruction Schéma des performances (par exemple, [events\$1statements\$1current](https://dev.mysql.com/doc/refman/8.0/en/performance-schema-events-statements-current-table.html)). 
+  Bogue n° 11827369 : certaines requêtes avec des sous-requêtes imbriquées `SELECT ... FROM DUAL` ont généré une assertion. 
+  Bogue n° 16311231 : des résultats incorrects ont été renvoyés lorsqu'une requête contenait une sous-requête dans une clause `IN` qui contenait une opération [XOR](https://dev.mysql.com/doc/refman/5.6/en/logical-operators.html#operator_xor) dans la clause `WHERE`. 

# Mises à jour du moteur de base de données Aurora MySQL du 05/06/2019 (version 1.19.2) (obsolète)
<a name="AuroraMySQL.Updates.1192"></a>

**Version :** 1.19.2

 Aurora MySQL 1.19.2 est généralement disponible. Tous les nouveaux clusters de bases de données Aurora MySQL compatibles avec MySQL 5.6, y compris ceux restaurés à partir d'instantanés, peuvent être créés avec 1.17.8, 1.19.0, 1.19.1 ou 1.19.2. Vous avez la possibilité, sans y être obligé, de mettre à niveau les clusters de bases de données existants vers Aurora MySQL 1.19.2. Pour utiliser une version antérieure, vous pouvez créer des clusters de bases de données dans Aurora MySQL 1.14.4, Aurora MySQL 1.15.1, Aurora MySQL 1.16, Aurora MySQL 1.17.8 ou Aurora MySQL 1.18. Vous pouvez le faire à l'aide de l'API AWS CLI ou de l'API Amazon RDS et en spécifiant la version du moteur. 

 Si vous avez des questions ou des préoccupations, le AWS support est disponible sur les forums communautaires et via le [AWS support](https://aws.amazon.com/support). Pour plus d'informations, consultez [Entretien d'un cluster de base de données Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_UpgradeDBInstance.Maintenance.html) dans le *Guide de l'utilisateur Amazon Aurora*. 

**Note**  
 Cette version n'est actuellement pas disponible dans les régions AWS GovCloud (US-West) [us-gov-west-1], Europe (Stockholm) [eu-north-1], Chine (Ningxia) [cn-northwest-1] et Asie-Pacifique (Hong Kong) [ap-east-1]. AWS Sa disponibilité fera l'objet d'une annonce distincte. 

**Note**  
La procédure de mise à niveau du cluster de bases de données a changé. Pour plus d'informations, consultez [Mise à niveau de la version mineure ou du niveau de correctif d'un cluster de bases de données Aurora MySQL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Updates.Patching.html) dans le *Guide de l'utilisateur Amazon Aurora*.

## Améliorations
<a name="AuroraMySQL.Updates.1192.Improvements"></a>
+  Résolution d'un problème qui pouvait entraîner des échecs lors du chargement de données vers Aurora à partir de Amazon S3. 
+  Résolution d'un problème qui pouvait entraîner des échecs lors du chargement de données à partir d'Aurora vers Amazon S3. 
+  Résolution d'un problème qui créait des sessions zombie à l'état Supprimé. 
+  Résolution d'un problème qui interrompait les connexions lors du traitement d'une erreur de gestion du protocole réseau. 
+  Résolution d'un problème qui pouvait entraîner un blocage lors du traitement de tables partitionnées. 
+  Résolution d'un problème lié à la réplication des journaux binaires de la création des déclencheurs. 

# Mises à jour du moteur de base de données Aurora MySQL du 09/05/2019 (version 1.19.1) (obsolète)
<a name="AuroraMySQL.Updates.1191"></a>

**Version :** 1.19.1

 Aurora MySQL 1.19.1 est en disponibilité générale. Tous les nouveaux clusters de bases de données Aurora MySQL compatibles avec MySQL 5.6, y compris ceux restaurés à partir d'instantanés, peuvent être créés avec 1.17.8, 1.19.0 ou 1.19.1. Vous avez la possibilité, sans y être obligé, de mettre à niveau les clusters de bases de données existants vers Aurora MySQL 1.19.1. Pour utiliser une version antérieure, vous pouvez créer des clusters de bases de données dans Aurora MySQL 1.14.4, Aurora MySQL 1.15.1, Aurora MySQL 1.16, Aurora MySQL 1.17.8 ou Aurora MySQL 1.18. Vous pouvez le faire à l'aide de l'API AWS CLI ou de l'API Amazon RDS et en spécifiant la version du moteur. 

Si vous avez des questions ou des préoccupations, le AWS support est disponible sur les forums communautaires et via le [AWS support](https://aws.amazon.com/support). Pour plus d'informations, consultez [Entretien d'un cluster de base de données Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_UpgradeDBInstance.Maintenance.html) dans le *Guide de l'utilisateur Amazon Aurora*.

**Note**  
 Cette version n'est actuellement pas disponible dans les régions AWS GovCloud (USA Ouest) [us-gov-west-1] et Chine (Pékin) [cn-north-1]. Sa disponibilité fera l'objet d'une annonce distincte. 

**Note**  
La procédure de mise à niveau du cluster de bases de données a changé. Pour plus d'informations, consultez [Mise à niveau de la version mineure ou du niveau de correctif d'un cluster de bases de données Aurora MySQL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Updates.Patching.html) dans le *Guide de l'utilisateur Amazon Aurora*.

## Améliorations
<a name="AuroraMySQL.Updates.1191.Improvements"></a>
+  Correction d'un bogue dans la réplication des journaux binaires pouvant entraîner un problème sur les instances Aurora configurées en tant que travailleur des journaux binaires. 
+  Correction d'une erreur survenant lors de la gestion de certains types de commandes `ALTER TABLE`. 
+  Correction d'une erreur d'interruption des connexions en raison d'une erreur de gestion du protocole réseau. 

# Mises à jour du moteur de base de données Aurora MySQL du 07/02/2019 (version 1.19.0) (obsolète)
<a name="AuroraMySQL.Updates.1190"></a>

**Version :** 1.19.0

 Aurora MySQL 1.19.0 est en disponibilité générale. Tous les nouveaux clusters de bases de données Aurora MySQL compatibles avec MySQL 5.6, y compris ceux restaurés à partir d'instantanés, peuvent être créés avec 1.17.8 ou 1.19.0. Vous avez la possibilité, sans y être obligé, de mettre à niveau les clusters de bases de données existants vers Aurora MySQL 1.19.0. Pour utiliser une version antérieure, vous pouvez créer des clusters de bases de données dans Aurora MySQL 1.14.4, Aurora MySQL 1.15.1, Aurora MySQL 1.16, Aurora MySQL 1.17.8 ou Aurora MySQL 1.18.0. Vous pouvez le faire à l'aide de l'API AWS CLI ou de l'API Amazon RDS et en spécifiant la version du moteur. 

Si vous avez des questions ou des préoccupations, le AWS support est disponible sur les forums communautaires et via le [AWS support](https://aws.amazon.com/support). Pour plus d'informations, consultez [Entretien d'un cluster de base de données Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_UpgradeDBInstance.Maintenance.html) dans le *Guide de l'utilisateur Amazon Aurora*.

**Note**  
 Cette version n'est actuellement pas disponible dans les régions AWS GovCloud (USA Ouest) [us-gov-west-1] et Chine (Pékin) [cn-north-1]. Sa disponibilité fera l'objet d'une annonce distincte. 

**Note**  
La procédure de mise à niveau du cluster de bases de données a changé. Pour plus d'informations, consultez [Mise à niveau de la version mineure ou du niveau de correctif d'un cluster de bases de données Aurora MySQL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Updates.Patching.html) dans le *Guide de l'utilisateur Amazon Aurora*.

## Caractéristiques
<a name="AuroraMySQL.Updates.1190.Features"></a>
+  **Sélecteur de version Aurora** - Depuis la version Aurora MySQL 1.19.0, vous avez le choix entre plusieurs versions Aurora compatibles avec MySQL 5.6 dans la console Amazon RDS. Pour plus d'informations, consultez [Vérification ou spécification de versions du moteur Aurora MySQL via AWS](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Updates.Versions.html#AuroraMySQL.Updates.EngineVersions) dans le *Guide de l'utilisateur Amazon Aurora*. 

## Améliorations
<a name="AuroraMySQL.Updates.1190.Improvements"></a>
+  Résolution d'un problème de stabilité lié à la requête `CHECK TABLE` sur un réplica Aurora. 
+  Lancement d'une nouvelle variable utilisateur global `aurora_disable_hash_join` pour désactiver la jointure par hachage. 
+  Résolution d'un problème de stabilité lors de la génération de la ligne de sortie pendant la jointure par hachage de plusieurs tables. 
+  Résolution d'un problème entraînant un résultat incorrect en raison d'un changement de plan pendant la vérification de l'applicabilité d'une jointure de hachage. 
+  L'application de correctifs sans temps d'arrêt est prise en charge avec les transactions de longue durée. Cette amélioration prendra effet lors de la mise à niveau de la version 1.19 à une version supérieure. 
+  L'application de correctifs sans temps d'arrêt est désormais prise en charge lorsque la journalisation binaire est activée. Cette amélioration prendra effet lors de la mise à niveau de la version 1.19 à une version supérieure. 
+  Résolution d'un problème qui entraînait un pic d'utilisation de l'UC sur le réplica Aurora non associé à la charge de travail. 
+  Correction d'une condition de concurrence dans le gestionnaire de verrous qui entraînait le redémarrage de la base de données. 
+  Correction d'une condition de concurrence dans le composant du gestionnaire de verrous pour améliorer la stabilité des instances Aurora. 
+  Amélioration de la stabilité du détecteur d'interblocage dans le composant du gestionnaire de verrous. 
+  `INSERT`L'opération sur une table est interdite si InnoDB détecte que l'index est corrompu. 
+  Résolution d'un problème de stabilité dans Fast DDL. 
+  Amélioration de la stabilité Aurora par réduction de la consommation de la mémoire dans le traitement par lot des analyses pour une sous-requête à une seule ligne. 
+  Résolution d'un problème de stabilité survenant après la suppression d'une clé étrangère alors que la variable système `foreign_key_checks` est définie sur 0. 
+  Résolution d'un problème de la fonction d'évitement de mémoire insuffisante entraînant le remplacement par erreur des modifications apportées à la valeur `table_definition_cache` par l'utilisateur. 
+  Résolution de problèmes de stabilité de la fonction d'évitement de mémoire insuffisante. 
+  Résolution d'un problème qui définissait `query_time` et `lock_time` dans `slow_query_log` en valeurs de garbage. 
+  Résolution d'un problème de stabilité des requêtes parallèles déclenché par une gestion incorrecte du classement des chaînes en interne. 
+  Résolution d'un problème de stabilité des requêtes parallèles déclenché par une recherche d'index secondaire. 
+  Résolution d'un problème de stabilité des requêtes parallèles déclenché par la mise à jour de plusieurs tables. 

## Intégration de correctifs de bogues de l'édition MySQL Community Edition
<a name="AuroraMySQL.Updates.1190.Patches"></a>
+  Bogue n°32917 : DETECT ORPHAN TEMP-POOL FILES, AND HANDLE GRACEFULLY 
+  Bogue n°63144 : CREATE TABLE IF NOT EXISTS METADATA LOCK IS TOO RESTRICTIVE 

# Mises à jour du moteur de base de données Aurora MySQL du 20/09/2018 (version 1.18.0) (obsolète)
<a name="AuroraMySQL.Updates.1180"></a>

**Version :** 1.18.0

Aurora MySQL 1.18.0 est en général disponible. Tous les nouveaux clusters compatibles avec les requêtes parallèles Aurora MySQL et compatibles avec MySQL 5.6, y compris ceux restaurés à partir d'instantanés, seront créés dans Aurora MySQL 1.18.0. Vous avez la possibilité, sans y être obligé, de mettre à niveau les clusters compatibles avec les requêtes parallèles vers Aurora MySQL 1.18.0. Vous pouvez créer de nouveaux clusters de bases de données dans Aurora MySQL 1.14.4, Aurora MySQL 1.15.1, Aurora MySQL 1.16 ou Aurora MySQL 1.17.6. Vous pouvez le faire à l'aide de l'API AWS CLI ou de l'API Amazon RDS et en spécifiant la version du moteur. 

Avec la version 1.18.0 d'Aurora MySQL, nous utilisons un modèle d'application de correctifs de cluster dans lequel tous les nœuds d'un cluster de bases de données Aurora sont corrigés en même temps. 

**Important**  
 Aurora MySQL 1.18.0 s'applique uniquement aux clusters compatibles avec les requêtes parallèles Aurora. Si vous mettez à niveau un cluster 5.6.10a alloué, la version résultante est 1.17.8. Si vous mettez à niveau un cluster 5.6.10a compatible avec les requêtes parallèles, la version résultante est 1.18.0. 

Si vous avez des questions ou des préoccupations, le AWS support est disponible sur les forums communautaires et via le [AWS support](https://aws.amazon.com/support). Pour plus d'informations, consultez [Entretien d'un cluster de base de données Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_UpgradeDBInstance.Maintenance.html) dans le *Guide de l'utilisateur Amazon Aurora*.

## Caractéristiques
<a name="AuroraMySQL.Updates.1180.Features"></a>
+  La fonction de **Requête parallèle** est disponible avec cette version, pour les nouveaux clusters et les instantanés restaurés. La requête parallèle Aurora MySQL est une optimisation qui parallélise une partie des calculs impliqués dans le traitement I/O des requêtes gourmandes en données. Les tâches qui sont mises en parallèle incluent la récupération des lignes à partir du stockage, l’extraction des valeurs des colonnes et la détermination des lignes répondant aux conditions définies dans la clause `WHERE` et dans les clauses JOIN. Ces tâches de gestion des gros volumes de données sont déléguées à différents nœuds de la couche de stockage distribué Aurora. Dans le jargon, on parle également d’optimisation de base de données par pushdown. Sans la fonction de requête parallèle, chaque requête envoie toutes les données analysées à un même nœud au sein du cluster Aurora MySQL (le nœud principal) et y effectue toutes les tâches de traitement nécessaires. 
  + Lorsque la fonction de requête parallèle est activée, le moteur Aurora MySQL détermine automatiquement quand utiliser cette dernière, sans nécessiter de modifications SQL telles que les indicateurs ou les attributs de table.

  Pour plus d'informations, consultez [Utilisation des requêtes parallèles pour Amazon Aurora MySQL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-mysql-parallel-query.html) dans le *Guide de l'utilisateur Amazon Aurora*. 
+  La fonction d'**évitement de mémoire insuffisante** surveille la mémoire système et suit la mémoire consommée par les divers composants de la base de données. Lorsque le système manque de mémoire, il effectue une liste d'actions pour libérer de la mémoire à partir des divers composants suivis afin d'essayer d'éviter un dépassement de mémoire de la base de données et donc un redémarrage de cette base de données. Cette fonction d'optimisation est activée par défaut pour les instances t2 et peut être activée pour les autres classes d'instance via un nouveau paramètre d'instance nommé `aurora_oom_response`. Ce paramètre d'instance accepte une chaîne d'actions séparées par des virgules, qu'une instance doit effectuer lorsque sa mémoire est faible. Les actions valides incluent « print », « tune », « decline », « kill\$1query » et toute combinaison de ces valeurs. Une chaîne vide signifie qu'aucune action ne doit être effectuée et revient en fait à désactiver la fonction. Notez que les actions par défaut de cette fonction sont « print, tune ». Exemples d'utilisation : 
  + « print » – imprime uniquement les requêtes exigeant une grande quantité de mémoire.
  + « tune » – affine les caches de table interne pour restituer de la mémoire au système.
  + « decline » – refuse les nouvelles requêtes une fois que l'instance manque de mémoire.
  + « kill\$1query » – arrête les requêtes dans l'ordre décroissant de leur consommation de mémoire jusqu'à ce que la mémoire de l'instance passe au-dessus du seuil bas. Les instructions en langage de manipulation de données (DDL) ne sont pas abandonnées.
  + « print, tune » – effectue les actions décrites pour « print » et « tune ».
  + « tune, decline, kill\$1query » – effectue les actions décrites pour « tune », « decline » et « kill\$1query ».

  Pour plus d'informations sur out-of-memory les conditions de manipulation et d'autres conseils de dépannage, consultez la section [Problèmes de mémoire insuffisante d'Amazon Aurora MySQL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-mysql-troubleshooting-workload.html#AuroraMySQLOOM) dans le *guide de l'utilisateur Amazon Aurora*. 

# Mises à jour du moteur de base de données Aurora MySQL du 05/03/2020 (version 1.17.9) (obsolète)
<a name="AuroraMySQL.Updates.1179"></a>

**Version :** 1.17.9

Aurora MySQL 1.17.9 est en disponibilité générale. Les versions 1.x d'Aurora MySQL sont compatibles avec MySQL 5.6 et les versions 2.x d'Aurora MySQL sont compatibles avec MySQL 5.7.

 Versions Aurora MySQL actuellement prises en charge : 1.14.\$1, 1.15.\$1, 1.16.\$1, 1.17.\$1, 1.18.\$1, 1.19.\$1, 1.20.\$1, 1.21.\$1, 1.22.\$1, 2.01.\$1, 2.02.\$1, 2.03.\$1, 2.04.\$1, 2.05.\$1, 2.06.\$1 et 2.07.\$1. Vous pouvez restaurer l'instantané d'une base de données Aurora MySQL 1.\$1 à la version Aurora MySQL 1.17.9. 

 Pour créer un cluster avec une ancienne version d'Aurora MySQL, veuillez spécifier la version du moteur via la console RDS, la AWS CLI ou l'API Amazon RDS. 

**Note**  
 Cette version n'est actuellement pas disponible dans les régions suivantes : AWS GovCloud (US-East) [us-gov-east-1], AWS GovCloud (US-West) [us-gov-west-1]. Sa disponibilité fera l'objet d'une annonce distincte. 

Si vous avez des questions ou des préoccupations, le AWS support est disponible sur les forums communautaires et via le [AWS support](https://aws.amazon.com/support). Pour plus d'informations, consultez [Entretien d'un cluster de base de données Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_UpgradeDBInstance.Maintenance.html) dans le *Guide de l'utilisateur Amazon Aurora*.

## Améliorations
<a name="AuroraMySQL.Updates.1179.Improvements"></a>

 **Correctifs à priorité élevée :** 
+  Correction d'un problème d'échecs intermittents de connexion après la rotation du certificat. 

# Mises à jour du moteur de base de données Aurora MySQL du 17/01/2019 (version 1.17.8) (obsolète)
<a name="AuroraMySQL.Updates.1178"></a>

**Version :** 1.17.8

Aurora MySQL 1.17.8 est en général disponible. Tous les nouveaux clusters de bases de données Aurora MySQL compatibles avec MySQL 5.6, y compris ceux restaurés à partir d'instantanés, seront créés dans Aurora MySQL 1.17.8. Vous avez la possibilité, sans y être obligé, de mettre à niveau les clusters de bases de données existants vers Aurora MySQL 1.17.8. Pour utiliser une version antérieure, vous pouvez créer des clusters de bases de données dans Aurora MySQL 1.14.4, 1.15.1, 1.16 ou 1.17.7. Vous pouvez le faire à l'aide de l'API AWS CLI ou de l'API Amazon RDS et en spécifiant la version du moteur. 

Avec la version 1.17.8 d'Aurora MySQL, nous utilisons un modèle d'application de correctifs de cluster dans lequel tous les nœuds d'un cluster de bases de données Aurora sont corrigés en même temps. 

**Note**  
 Cette version n'est actuellement pas disponible dans les régions AWS GovCloud (USA Ouest) [us-gov-west-1] et Chine (Pékin) [cn-north-1]. Sa disponibilité fera l'objet d'une annonce distincte. 

Si vous avez des questions ou des préoccupations, le AWS support est disponible sur les forums communautaires et via le [AWS support](https://aws.amazon.com/support). Pour plus d'informations, consultez [Entretien d'un cluster de base de données Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_UpgradeDBInstance.Maintenance.html) dans le *Guide de l'utilisateur Amazon Aurora*.

## Améliorations
<a name="AuroraMySQL.Updates.1178.Improvements"></a>
+  Résolution d'un problème de performances qui augmentait l'utilisation de l'UC sur un réplica Aurora après un redémarrage. 
+  Correction d'un problème de stabilité pour les requêtes `SELECT` qui utilisaient une jonction de hachage. 

## Intégration de correctifs de bogues de l'édition MySQL Community Edition
<a name="AuroraMySQL.Updates.1178.Patches"></a>
+  BOGUE 13418638 : CREATE TABLE IF NOT EXISTS METADATA LOCK IS TOO RESTRICTIVE 

# Mises à jour du moteur de base de données Aurora MySQL du 08/10/2018 (version 1.17.7) (obsolète)
<a name="AuroraMySQL.Updates.1177"></a>

**Version :** 1.17.7

Aurora MySQL 1.17.7 est en général disponible. Tous les nouveaux clusters de bases de données Aurora MySQL compatibles avec MySQL 5.6, y compris ceux restaurés à partir d'instantanés, seront créés dans Aurora MySQL 1.17.7. Vous avez la possibilité, sans y être obligé, de mettre à niveau les clusters de bases de données existants vers Aurora MySQL 1.17.7. Pour utiliser une version antérieure, vous pouvez créer des clusters de bases de données dans Aurora MySQL 1.14.4, 1.15.1, 1.16 ou 1.17.6. Vous pouvez le faire à l'aide de l'API AWS CLI ou de l'API Amazon RDS et en spécifiant la version du moteur. 

Avec la version 1.17.7 d'Aurora MySQL, nous utilisons un modèle d'application de correctifs de cluster dans lequel tous les nœuds d'un cluster de bases de données Aurora sont corrigés en même temps. 

**Note**  
 Cette version n'est actuellement pas disponible dans les régions AWS GovCloud (USA Ouest) [us-gov-west-1] et Chine (Pékin) [cn-north-1]. Sa disponibilité fera l'objet d'une annonce distincte. 

Si vous avez des questions ou des préoccupations, le AWS support est disponible sur les forums communautaires et via le [AWS support](https://aws.amazon.com/support). Pour plus d'informations, consultez [Entretien d'un cluster de base de données Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_UpgradeDBInstance.Maintenance.html) dans le *Guide de l'utilisateur Amazon Aurora*.

## Améliorations
<a name="AuroraMySQL.Updates.1177.Improvements"></a>
+  La variable d'état InnoDB `innodb_buffer_pool_size` a été rendue visible publiquement pour permettre aux clients de la modifier. 
+  Correction d'un problème de stabilité sur le cluster Aurora, qui se produisait lors des basculements. 
+  Amélioration de la disponibilité du cluster en corrigeant un problème de récupération DDL qui se produisait après l'échec d'une opération `TRUNCATE`. 
+  Correction d'un problème de stabilité lié à la mise à jour de la table `mysql.innodb_table_stats`, déclenché par les opérations DDL. 
+  Correction des problèmes de stabilité des réplicas Aurora déclenchés lors de l'invalidation du cache de requêtes après une opération DDL. 
+  Correction d'un problème de stabilité déclenché par un accès à la mémoire non valide pendant l'expulsion régulière du cache de dictionnaire en arrière-plan. 

## Intégration de correctifs de bogues de l'édition MySQL Community Edition
<a name="AuroraMySQL.Updates.1177.Patches"></a>
+  Bogue n° 16208542 : une opération Drop Index sur une colonne de clé étrangère entraîne un problème de table manquante. 
+  Bogue n° 76349 : fuite de mémoire dans add\$1derived\$1key(). 
+  Bogue n° 16862316 : pour les tables partitionnées, les requêtes peuvent renvoyer différents résultats en fonction de l'utilisation ou non de la fusion d'index. 
+  Bogue n° 17588348 : les requêtes utilisant l'optimisation index\$1merge (consultez [Index Merge Optimization](https://dev.mysql.com/doc/refman/5.6/en/index-merge-optimization.html)) peuvent renvoyer des résultats non valides lorsqu'elles sont exécutées sur des tables qui ont été partitionnées par HASH. 

# Mises à jour du moteur de base de données Aurora MySQL du 06/09/2018 (version 1.17.6) (obsolète)
<a name="AuroraMySQL.Updates.1176"></a>

**Version :** 1.17.6

Aurora MySQL 1.17.6 est en général disponible. Tous les nouveaux clusters de bases de données Aurora MySQL compatibles avec MySQL 5.6, y compris ceux restaurés à partir d'instantanés, seront créés dans Aurora MySQL 1.17.6. Vous avez la possibilité, sans y être obligé, de mettre à niveau les clusters de bases de données existants vers Aurora MySQL 1.17.6. Pour utiliser une version antérieure, vous pouvez créer des clusters de bases de données dans Aurora MySQL 1.14.4, 1.15.1, 1.16 ou 1.17.5. Vous pouvez le faire à l'aide de l'API AWS CLI ou de l'API Amazon RDS et en spécifiant la version du moteur. 

Avec la version 1.17.6 d'Aurora MySQL, nous utilisons un modèle d'application de correctifs de cluster dans lequel tous les nœuds d'un cluster de bases de données Aurora sont corrigés en même temps. 

**Note**  
 Cette version n'est actuellement pas disponible dans les régions AWS GovCloud (USA Ouest) [us-gov-west-1] et Chine (Pékin) [cn-north-1]. Sa disponibilité fera l'objet d'une annonce distincte. 

Si vous avez des questions ou des préoccupations, le AWS support est disponible sur les forums communautaires et via le [AWS support](https://aws.amazon.com/support). Pour plus d'informations, consultez [Entretien d'un cluster de base de données Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_UpgradeDBInstance.Maintenance.html) dans le *Guide de l'utilisateur Amazon Aurora*.

## Améliorations
<a name="AuroraMySQL.Updates.1176.Improvements"></a>
+  Correction d'un problème de stabilité sur le lecteur Aurora pour les requêtes `SELECT` pendant que l'enregistreur Aurora exécute des opérations DDL sur la même table. 
+  Correction d'un problème de stabilité causé par la création et la suppression de journaux DDL pour les tables temporaires utilisant le Heap/Memory moteur. 
+  Correction d'un problème de stabilité sur le travailleur des journaux binaires lorsque des instructions DDL sont répliquées pendant que la connexion au maître des journaux binaires est instable. 
+  Correction d'un problème de stabilité rencontré lors de l'écriture dans le journal des requêtes lentes. 
+  Correction d'un problème lié à la table d'états de réplica qui exposait des informations de retard du lecteur Aurora incorrectes. 

## Intégration de correctifs de bogues de l'édition MySQL Community Edition
<a name="AuroraMySQL.Updates.1176.Patches"></a>
+  Pour une instruction [ALTER TABLE](https://dev.mysql.com/doc/refman/5.6/en/alter-table.html) qui renommait ou modifiait la valeur par défaut d'une colonne [BINARY](https://dev.mysql.com/doc/refman/5.6/en/binary-varbinary.html), l'altération était effectuée en utilisant une copie de la table et non sur place. (Bogues n° 67141, 14735373, 69580 et 17024290) 
+  Une jointure externe entre une table standard et une table dérivée qu'elle regroupe implicitement peut entraîner l'arrêt du serveur. (Bogue n° 16177639) 

# Mises à jour du moteur de base de données Aurora MySQL du 14/08/2018.(version 1.17.5) (obsolète)
<a name="AuroraMySQL.Updates.1175"></a>

**Version :** 1.17.5

Aurora MySQL 1.17.5 est en général disponible. Tous les nouveaux clusters de bases de données Aurora MySQL compatibles avec MySQL 5.6, y compris ceux restaurés à partir d'instantanés, seront créés dans Aurora MySQL 1.17.5. Vous avez la possibilité, sans y être obligé, de mettre à niveau les clusters de bases de données existants vers Aurora MySQL 1.17.5. Pour utiliser une version antérieure, vous pouvez créer des clusters de bases de données dans Aurora MySQL 1.14.4, 1.15.1, 1.16 ou 1.17.4. Vous pouvez le faire à l'aide de l'API AWS CLI ou de l'API Amazon RDS et en spécifiant la version du moteur. 

Avec la version 1.17.5 d'Aurora MySQL, nous utilisons un modèle d'application de correctifs de cluster dans lequel tous les nœuds d'un cluster de bases de données Aurora sont corrigés en même temps. 

**Note**  
 Cette version n'est actuellement pas disponible dans les régions AWS GovCloud (USA Ouest) [us-gov-west-1] et Chine (Pékin) [cn-north-1]. Sa disponibilité fera l'objet d'une annonce distincte. 

Si vous avez des questions ou des préoccupations, le AWS support est disponible sur les forums communautaires et via le [AWS support](https://aws.amazon.com/support). Pour plus d'informations, consultez [Entretien d'un cluster de base de données Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_UpgradeDBInstance.Maintenance.html) dans le *Guide de l'utilisateur Amazon Aurora*.

## Améliorations
<a name="AuroraMySQL.Updates.1175.Improvements"></a>
+  Résolution d'un problème à cause duquel un enregistreur Aurora peut redémarrer après la correction d'un cluster Aurora à l'aide de la fonction d'application de correctifs sans temps d'arrêt. 

# Mises à jour du moteur de base de données Aurora MySQL du 07/08/2018 (version 1.17.4) (obsolète)
<a name="AuroraMySQL.Updates.1174"></a>

**Version :** 1.17.4

Aurora MySQL 1.17.4 est en général disponible. Tous les nouveaux clusters de bases de données Aurora MySQL compatibles avec MySQL 5.6, y compris ceux restaurés à partir d'instantanés, seront créés dans Aurora MySQL 1.17.4. Vous avez la possibilité, sans y être obligé, de mettre à niveau les clusters de bases de données existants vers Aurora MySQL 1.17.4. Pour utiliser une version antérieure, vous pouvez créer des clusters de bases de données dans Aurora MySQL 1.14.4, 1.15.1, 1.16 ou 1.17.3. Vous pouvez le faire à l'aide de l'API AWS CLI ou de l'API Amazon RDS et en spécifiant la version du moteur. 

Avec la version 1.17.4 d'Aurora MySQL, nous utilisons un modèle d'application de correctifs de cluster dans lequel tous les nœuds d'un cluster de bases de données Aurora sont corrigés en même temps. 

**Note**  
 Cette version n'est actuellement pas disponible dans les régions AWS GovCloud (USA Ouest) [us-gov-west-1] et Chine (Pékin) [cn-north-1]. Sa disponibilité fera l'objet d'une annonce distincte. 

Si vous avez des questions ou des préoccupations, le AWS support est disponible sur les forums communautaires et via le [AWS support](https://aws.amazon.com/support). Pour plus d'informations, consultez [Entretien d'un cluster de base de données Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_UpgradeDBInstance.Maintenance.html) dans le *Guide de l'utilisateur Amazon Aurora*.

## Améliorations
<a name="AuroraMySQL.Updates.1174.Improvements"></a>
+  Améliorations apportées à la réplication : 
  +  Trafic réseau réduit par la non transmission d'enregistrements de journaux binaires à des réplicas de clusters. Cette améliorations sont activées par défaut. 
  +  Réduction du trafic réseau en compressant les messages de réplication. Cette amélioration est activée par défaut pour les classes d'instance de 8xlarge et 16xlarge. Ces grandes instances peut gérer un fort volume de trafic en écriture qui entraîne un trafic réseau considérable en termes de messages de réplication. 
  +  Correctifs du cache de requête de réplica. 
+  Résolution d'un problème dans lequel `ORDER BY LOWER(col_name)` pouvait produire un ordre incorrect lors de l'utilisation du classement `utf8_bin`. 
+  Résolution d'un problème dans lequel les instructions DDL (notamment `TRUNCATE TABLE`) pouvaient entraîner des problèmes sur les réplicas Aurora, y compris une instabilité ou des tables manquantes. 
+  Résolution d'un problème dans lequel les sockets sont laissés dans un état semi-ouvert lorsque les nœuds de stockage sont redémarrés. 
+ Les nouveaux paramètres de cluster de bases de données suivants sont disponibles :
  + `aurora_enable_zdr` – autorise les connexion ouvertes sur un réplica Aurora à rester actives au redémarrage du réplica.
  + `aurora_enable_replica_log_compression` – autorise la compression des charges utiles de réplication pour améliorer l'utilisation de la bande passante réseau entre le maître et les réplicas Aurora.
  + `aurora_enable_repl_bin_log_filtering` – autorise le filtrage des enregistrements de réplication qui ne peuvent pas être utilisés par les réplicas Aurora sur le maître.

# Mises à jour du moteur de base de données Aurora MySQL du 05/06/2018 (version 1.17.3) (obsolète)
<a name="AuroraMySQL.Updates.1173"></a>

**Version :** 1.17.3

Aurora MySQL 1.17.3 est en général disponible. Tous les nouveaux clusters de bases de données Aurora MySQL compatibles avec MySQL 5.6, y compris ceux restaurés à partir d'instantanés, seront créés dans Aurora MySQL 1.17.3. Vous avez la possibilité, sans y être obligé, de mettre à niveau les clusters de bases de données existants vers Aurora MySQL 1.17.3. Vous pouvez créer de nouveaux clusters de bases de données dans Aurora MySQL 1.14.4, Aurora MySQL 1.15.1 ou Aurora MySQL 1.16. Vous pouvez le faire à l'aide de l'API AWS CLI ou de l'API Amazon RDS et en spécifiant la version du moteur. 

Avec la version 1.17.3 d'Aurora MySQL, nous utilisons un modèle d'application de correctifs de cluster dans lequel tous les nœuds d'un cluster de bases de données Aurora sont corrigés en même temps. 

**Note**  
 Cette version n'est actuellement pas disponible dans les régions AWS GovCloud (USA Ouest) [us-gov-west-1] et Chine (Pékin) [cn-north-1]. Sa disponibilité fera l'objet d'une annonce distincte. 

Si vous avez des questions ou des préoccupations, le AWS support est disponible sur les forums communautaires et via le [AWS support](https://aws.amazon.com/support). Pour plus d'informations, consultez [Entretien d'un cluster de base de données Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_UpgradeDBInstance.Maintenance.html) dans le *Guide de l'utilisateur Amazon Aurora*.

## Améliorations
<a name="AuroraMySQL.Updates.1173.Improvements"></a>
+ Correction d'un problème impliquant le redémarrage d'un réplica Aurora lors de l'utilisation des restaurations de curseur optimisé pendant la lecture des enregistrements.
+ Correction d'un problème à cause duquel un Aurora Writer redémarrait lorsqu'il essayait de fermer une session MySQL (kill *<session id>* « ») alors que le schéma de performance était activé.
+ Correction d'un problème impliquant le redémarrage d'un enregistreur Aurora lors du calcul d'un seuil pour le nettoyage de la mémoire.
+ Correction d'un problème impliquant le redémarrage occasionnel d'un enregistreur Aurora lors du suivi de la progression du réplica Aurora dans l'application de journal.
+ Correction d'un problème avec le cache de requêtes entraînant des lectures obsolètes lorsque la validation automatique est désactivée.

# Mises à jour du moteur de base de données Aurora MySQL du 27/04/2018 (version 1.17.2) (obsolète)
<a name="AuroraMySQL.Updates.1172"></a>

**Version :** 1.17.2

Aurora MySQL 1.17.2 est en général disponible. Tous les nouveaux clusters de bases de données Aurora MySQL compatibles avec MySQL 5.6, y compris ceux restaurés à partir d'instantanés, seront créés dans Aurora MySQL 1.17.2. Vous avez la possibilité, sans y être obligé, de mettre à niveau les clusters de bases de données existants vers Aurora MySQL 1.17.2. Vous pouvez créer de nouveaux clusters de bases de données dans Aurora MySQL 1.14.4, Aurora MySQL 1.15.1 ou Aurora MySQL 1.16. Vous pouvez le faire à l'aide de l'API AWS CLI ou de l'API Amazon RDS et en spécifiant la version du moteur. 

Avec la version 1.17.2 d'Aurora MySQL, nous utilisons un modèle d'application de correctifs de cluster dans lequel tous les nœuds d'un cluster de bases de données Aurora sont corrigés en même temps. 

Si vous avez des questions ou des préoccupations, le AWS support est disponible sur les forums communautaires et via le [AWS support](https://aws.amazon.com/support). Pour plus d'informations, consultez [Entretien d'un cluster de base de données Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_UpgradeDBInstance.Maintenance.html) dans le *Guide de l'utilisateur Amazon Aurora*.

## Améliorations
<a name="AuroraMySQL.Updates.1172.Improvements"></a>
+ Correction d'un problème entraînant le redémarrage au cours de certaines opérations de partition DDL.
+ Correction d'un problème en raison duquel la prise en charge de l'invocation de AWS Lambda fonctions via les fonctions natives d'Aurora MySQL était désactivée.
+ Correction d'un problème d'invalidation du cache entraînant le redémarrage sur les réplicas Aurora.
+ Correction d'un problème dans le gestionnaire de verrou entraînant des redémarrages.

# Mises à jour du moteur de base de données Aurora MySQL : 23/03/2018 (version 1.17.1) (obsolète)
<a name="AuroraMySQL.Updates.1171"></a>

**Version :** 1.17.1

Aurora MySQL 1.17.1 est en général disponible. Tous les nouveaux clusters de bases de données, y compris ceux restaurés à partir d'instantanés, seront créés dans Aurora MySQL 1.17.1. Vous avez la possibilité, sans y être obligé, de mettre à niveau les clusters de bases de données existants vers Aurora MySQL 1.17.1. Vous pouvez créer de nouveaux clusters de bases de données dans Aurora MySQL 1.15.1, Aurora MySQL 1.16 ou Aurora MySQL 1.17. Vous pouvez le faire à l'aide de l'API AWS CLI ou de l'API Amazon RDS et en spécifiant la version du moteur. 

Avec la version 1.17.1 d'Aurora MySQL, nous utilisons un modèle d'application de correctifs de cluster dans lequel tous les nœuds d'un cluster de bases de données Aurora sont corrigés en même temps. Cette version corrige certains problèmes de moteur identifiés, ainsi que certaines régressions. 

Si vous avez des questions ou des préoccupations, le AWS support est disponible sur les forums communautaires et via le [AWS support](https://aws.amazon.com/support). Pour plus d'informations, consultez [Entretien d'un cluster de base de données Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_UpgradeDBInstance.Maintenance.html) dans le *Guide de l'utilisateur Amazon Aurora*.

**Note**  
Il existe un problème dans la dernière version du moteur Aurora MySQL. Après la mise à niveau vers 1.17.1, la version du moteur a été mentionnée de façon incorrecte comme `1.17`. Si vous avez effectué une mise à niveau vers la version 1.17.1, vous pouvez la confirmer en vérifiant la colonne **Maintenance** du cluster de bases de données dans AWS Management Console. Si elle affiche `none`, alors le moteur est mis à niveau vers 1.17.1.

## Améliorations
<a name="AuroraMySQL.Updates.1171.Improvements"></a>
+ Correction d'un problème dans la récupération de journal binaire qui se traduisait par des temps de récupération plus longs pour les cas avec des fichiers d'index de journal binaire volumineux à même de se produire si les journaux binaires sont soumis à une rotation très fréquente.
+ Correction de problème de l'optimiseur de requête qui générait un plan de requête inefficace pour les tables partitionnées.
+ Correction du problème de l'optimiseur de requête où une requête de la plage entraînait un redémarrage du moteur de base de données.

# Mises à jour du moteur de base de données Aurora MySQL du 13/03/2018 (version 1.17) (obsolète)
<a name="AuroraMySQL.Updates.117"></a>

**Version :** 1.17

Aurora MySQL 1.17 est en général disponible. Les versions Aurora MySQL 1.x sont uniquement compatibles avec MySQL 5.6 et non avec MySQL 5.7. Tous les nouveaux clusters de bases de données compatibles avec la version 5.6, y compris ceux restaurés à partir d'instantanés, seront créés dans Aurora 1.17. Vous avez la possibilité, sans y être obligé, de mettre à niveau les clusters de bases de données existants vers Aurora 1.17. Vous pouvez créer de nouveaux clusters de bases de données dans Aurora 1.14.1, Aurora 1.15.1 ou Aurora 1.16. Vous pouvez le faire à l'aide de la AWS CLI ou de l'API Amazon RDS et en spécifiant la version du moteur.

Avec la version 1.17 d'Aurora, nous utilisons un modèle d'application de correctifs de cluster dans lequel tous les nœuds d'un cluster de bases de données Aurora sont corrigés en même temps. Nous prenons en charge l'application de correctifs sans temps d'arrêt, basée sur l'optimisation, afin de conserver les connexions client tout au long du processus de mise à jour corrective. Pour plus d'informations, consultez [Entretien d'un cluster de base de données Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_UpgradeDBInstance.Maintenance.html) dans le *Guide de l'utilisateur Amazon Aurora*. 

Si vous avez des questions ou des préoccupations, le AWS support est disponible sur les forums communautaires et via le [AWS support](https://aws.amazon.com/support).

## Application de correctifs sans temps d'arrêt
<a name="AuroraMySQL.Updates.117.ZDP"></a>

La fonction d'application de correctifs sans temps d'arrêt tente, dans un souci d'*optimisation*, de conserver les connexions client tout au long de la mise à jour corrective du moteur. Pour plus d'informations sur l'application de correctifs sans temps d'arrêt, consultez [Utilisation des correctifs sans temps d'arrêt](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Updates.Patching.html#AuroraMySQL.Updates.ZDP) dans le *Guide de l'utilisateur Amazon Aurora*. 

## Nouvelles fonctionnalités
<a name="AuroraMySQL.Updates.117.New"></a>
+  Aurora MySQL prend désormais en charge la compression de verrou, qui optimise l'utilisation de la mémoire du gestionnaire de verrou. À partir de la version 1.17, vous pouvez utiliser cette fonction sans activer le mode Lab. 

## Améliorations
<a name="AuroraMySQL.Updates.117.Improvements"></a>
+ Correction d'un problème rencontré essentiellement par les instances avec moins de cœurs où un seul cœur peut avoir 100 % d'utilisation d'UC même si la base de données est inactive.
+ Amélioration des performances d'extraction des journaux binaires à partir des clusters Aurora.
+ Correction d'un problème où les réplicas Aurora tentent d'écrire des statistiques de table sur un stockage permanent, et échouent.
+ Correction d'un problème où le cache de requête n'a pas fonctionné comme prévu sur les réplicas Aurora.
+ Correction d'une condition de concurrence dans le gestionnaire de verrou qui s'est traduite par un redémarrage du moteur.
+ Correction d'un problème où les verrous acceptés par les transactions en lecture seule et à validation automatique se sont traduites par un redémarrage du moteur.
+ Correction d'un problème où certaines requêtes n'ont pas été écrites sur les journaux d'audit.
+ Correction d'un problème lié à la récupération de certaines opérations de maintenance d'une partition lors d'un basculement.

## Intégration de correctifs de bogues MySQL.
<a name="AuroraMySQL.Updates.117.BugFixes"></a>
+ LAST\$1INSERT\$1ID n'est pas répliqué correctement si les filtres de réplication sont utilisés (bogue n° 69861)
+ La requête retourne différents résultats en fonction du paramètre INDEX\$1MERGE (bogue n° 16862316)
+ Réexécution de la routine stockée du traitement de requête, plan de requête inefficace (bogue n° 16346367)
+ INNODB FTS : assertion dans FTS\$1CACHE\$1APPEND\$1DELETED\$1DOC\$1IDS (bogue n° 18079671)
+ Assertion RBT\$1EMPTY(INDEX\$1CACHE->WORDS) dans ALTER TABLE CHANGE COLUMN (bogue n° 17536995)
+ La recherche INNODB en texte intégral ne trouve pas d'enregistrements lorsque des points de sauvegarde sont impliqués (bogue n° 70333, bogue n° 17458835)

# Mises à jour du moteur de base de données Aurora MySQL du 11/12/2017 (version 1.16) (obsolète)
<a name="AuroraMySQL.Updates.20171211"></a>

**Version :** 1.16

Aurora MySQL 1.16 est en disponibilité générale. Tous les nouveaux clusters de bases de données, y compris ceux restaurés à partir d'instantanés, seront créés dans Aurora 1.16. Vous avez la possibilité, sans y être obligé, de mettre à niveau les clusters de bases de données existants vers Aurora 1.16. Vous pouvez créer de nouveaux clusters de bases de données dans Aurora 1.14.1 ou Aurora 1.15.1. Vous pouvez le faire à l'aide de l'API AWS CLI ou de l'API Amazon RDS et en spécifiant la version du moteur.

Avec la version 1.16 d'Aurora, nous utilisons un modèle d'application de correctifs de cluster dans lequel tous les nœuds d'un cluster de bases de données Aurora sont corrigés en même temps. Nous activons l'application de correctifs sans temps d'arrêt, basée sur l'optimisation, afin de conserver les connexions client tout au long du processus de mise à jour corrective. Pour plus d'informations, consultez [Entretien d'un cluster de base de données Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_UpgradeDBInstance.Maintenance.html) dans le *Guide de l'utilisateur Amazon Aurora*.

Si vous avez des questions ou des préoccupations, le AWS support est disponible sur les forums communautaires et via le [AWS support](https://aws.amazon.com/support).

## Application de correctifs sans temps d'arrêt
<a name="AuroraMySQL.Updates.20171211.ZDP"></a>

La fonction d'application de correctifs sans temps d'arrêt tente, dans un souci d'*optimisation*, de conserver les connexions client tout au long de la mise à jour corrective du moteur. Pour plus d'informations sur l'application de correctifs sans temps d'arrêt, consultez [Utilisation des correctifs sans temps d'arrêt](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Updates.Patching.html#AuroraMySQL.Updates.ZDP) dans le *Guide de l'utilisateur Amazon Aurora*. 

## Nouvelles fonctionnalités
<a name="AuroraMySQL.Updates.20171211.New"></a>
+ Aurora MySQL prend désormais en charge les AWS Lambda invocations synchrones via la fonction native. `lambda_sync()` La fonction native `lambda_async()` est également disponible et peut être utilisée comme alternative à la procédure stockée existante pour l'appel Lambda asynchrone. Pour plus d'informations, consultez [Appel d'une fonction Lambda à partir d'un cluster de bases de données Amazon Aurora MySQL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Integrating.Lambda.html) dans le *Guide de l'utilisateur Amazon Aurora*.
+ Aurora MySQL prend désormais en charge les jointures par hachage afin d'accélérer les requêtes d'équijointure. L'optimiseur Aurora basé sur les coûts peut décider automatiquement du moment auquel utiliser des jointures par hachage, ou bien vous pouvez imposer leur utilisation dans un plan de requête. Pour plus d'informations, consultez [Optimisation des requêtes de jointure MySQL Aurora volumineuses avec des jointures de hachage](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.BestPractices.html#Aurora.BestPractices.HashJoin) dans le *Guide de l'utilisateur Amazon Aurora.*
+ Aurora MySQL prend désormais en charge le traitement par lot des analyses afin d'accélérer considérablement les requêtes orientées analyse en mémoire. Cette fonction augmente les performances des analyses complètes de tables, des analyses complètes d'index et des analyses de plages d'index avec un traitement par lot.

## Améliorations
<a name="AuroraMySQL.Updates.20171211.Improvements"></a>
+ Correction d'un problème en raison duquel les réplicas en lecture se bloquaient lors de l'exécution de requêtes sur des tables qui venaient d'être supprimées sur l'instance maître. 
+ Correction d'un problème en raison duquel le redémarrage de l'enregistreur sur un cluster de bases de données avec un très grand nombre d'index `FULLTEXT` entraîne une récupération plus longue que prévu.
+ Correction d'un problème en raison duquel le vidage des journaux binaires entraîne des incidents `LOST_EVENTS` dans les événements de journaux binaires.
+ Correction de problèmes de stabilité avec le planificateur lorsque le schéma de performance est activé.
+ Correction d'un problème en raison duquel une sous-requête utilisant des tables temporaires pouvait renvoyer des résultats partiels.

## Intégration de correctifs de bogues MySQL.
<a name="AuroraMySQL.Updates.20171211.BugFixes"></a>

Aucune

# Mises à jour du moteur de base de données Aurora MySQL du 20/11/2017 (version 1.15.1) (obsolète)
<a name="AuroraMySQL.Updates.20171120"></a>

**Version :** 1.15.1

Aurora MySQL 1.15.1 est en disponibilité générale. Tous les nouveaux clusters de bases de données, y compris ceux restaurés à partir d'instantanés, seront créés dans Aurora 1.15.1. Vous avez la possibilité, sans y être obligé, de mettre à niveau les clusters de bases de données existants vers Aurora 1.15.1. Vous pouvez créer de nouveaux clusters de bases de données dans Aurora 1.14.1. Vous pouvez le faire à l'aide de l'API AWS CLI ou de l'API Amazon RDS et en spécifiant la version du moteur.

Avec la version 1.15.1 d'Aurora, nous utilisons un modèle d'application de correctifs de cluster dans lequel tous les nœuds d'un cluster de bases de données Aurora sont corrigés en même temps. Nous activons l'application de correctifs sans temps d'arrêt, basée sur l'optimisation, afin de conserver les connexions client tout au long du processus de mise à jour corrective. Pour plus d'informations, consultez [Entretien d'un cluster de base de données Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_UpgradeDBInstance.Maintenance.html) dans le *Guide de l'utilisateur Amazon Aurora*.

Si vous avez des questions ou des préoccupations, le AWS support est disponible sur les forums communautaires et via le [AWS support](https://aws.amazon.com/support). Pour plus d'informations, consultez [Entretien d'un cluster de base de données Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_UpgradeDBInstance.Maintenance.html) dans le *Guide de l'utilisateur Amazon Aurora*.

## Application de correctifs sans temps d'arrêt
<a name="AuroraMySQL.Updates.20171120.ZDP"></a>

La fonction d'application de correctifs sans temps d'arrêt tente, dans un souci d'*optimisation*, de conserver les connexions client tout au long de la mise à jour corrective du moteur. Pour plus d'informations sur l'application de correctifs sans temps d'arrêt, consultez [Utilisation des correctifs sans temps d'arrêt](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Updates.Patching.html#AuroraMySQL.Updates.ZDP) dans le *Guide de l'utilisateur Amazon Aurora*. 

## Améliorations
<a name="AuroraMySQL.Updates.20171120.Improvements"></a>
+ Résolution d'un problème du sélecteur de segment adaptatif pour une requête de lecture qui provoquerait deux fois de suite le choix du même segment, entraînant ainsi un pic de latence de lecture dans certaines conditions.
+ Résolution d'un problème issu d'une optimisation dans Aurora MySQL pour le planificateur de thread. Ce problème se manifeste sous la forme d'erreurs intempestives pendant l'écriture dans le journal lent, tandis que les requêtes associées fonctionnent correctement.
+ Résolution d'un problème de stabilité lié aux réplicas en lecture sur de grands volumes (> 5 To).
+ Résolution d'un problème impliquant l'augmentation continue du nombre de threads de travail en raison d'un faux nombre de connexions restantes.
+ Résolution d'un problème de verrous de table qui provoquait de longues attentes de sémaphore pendant les charges de travail d'insert.
+ Rétablissement des correctifs de bogues MySQL suivants compris dans Aurora MySQL 1.15 :
  + Ralentissement de l'instance MySQL « doing SYNC index » (bogue n° 73816)
  + Assertion RBT\$1EMPTY(INDEX\$1CACHE->WORDS) dans ALTER TABLE CHANGE COLUMN (bogue n° 17536995)
  + La recherche InnoDB Fulltext ne trouve pas d'enregistrements lorsque des points de sauvegarde sont impliqués (bogue n° 70333)

## Intégration de correctifs de bogues MySQL.
<a name="AuroraMySQL.Updates.20171024.BugFixes"></a>

Aucune

# Mises à jour du moteur de base de données Aurora MySQL du 24/10/2017 (version 1.15) (obsolète)
<a name="AuroraMySQL.Updates.20171024"></a>

**Version :** 1.15

Aurora MySQL 1.15 est en disponibilité générale. Tous les nouveaux clusters de bases de données, y compris ceux restaurés à partir d'instantanés, seront créés dans Aurora 1.15. Vous avez la possibilité, sans y être obligé, de mettre à niveau les clusters de bases de données existants vers Aurora 1.15. Vous pouvez créer de nouveaux clusters de bases de données dans Aurora 1.14.1. Vous pouvez le faire à l'aide de l'API AWS CLI ou de l'API Amazon RDS et en spécifiant la version du moteur.

Avec la version 1.15 d'Aurora, nous utilisons un modèle d'application de correctifs de cluster dans lequel tous les nœuds d'un cluster de bases de données Aurora sont corrigés en même temps. Les mises à jour nécessitent un redémarrage de la base de données, si bien que vous rencontrerez 20 à 30 secondes d'indisponibilité, après quoi vous pourrez reprendre l'utilisation de votre ou de vos clusters de bases de données. Si vos clusters de bases de données exécutent actuellement Aurora 1.14 ou Aurora 1.14.1, la fonction d'application de correctifs sans temps d'arrêt d'Aurora MySQL peut permettre aux connexions client à votre instance principale Aurora MySQL de persister tout au long de la mise à niveau, en fonction de votre charge de travail.

Si vous avez des questions ou des préoccupations, le AWS support est disponible sur les forums communautaires et via le [AWS support](https://aws.amazon.com/support). Pour plus d'informations, consultez [Entretien d'un cluster de base de données Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_UpgradeDBInstance.Maintenance.html) dans le *Guide de l'utilisateur Amazon Aurora*.

## Application de correctifs sans temps d'arrêt
<a name="AuroraMySQL.Updates.20171024.ZDP"></a>

La fonction d'application de correctifs sans temps d'arrêt tente, dans un souci d'*optimisation*, de conserver les connexions client tout au long de la mise à jour corrective du moteur. Pour plus d'informations sur l'application de correctifs sans temps d'arrêt, consultez [Utilisation des correctifs sans temps d'arrêt](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Updates.Patching.html#AuroraMySQL.Updates.ZDP) dans le *Guide de l'utilisateur Amazon Aurora*. 

## Nouvelles fonctionnalités
<a name="AuroraMySQL.Updates.20171024.New"></a>
+ **Lecture anticipée asynchrone des clés** – la lecture anticipée asynchrone des clés (AKP) est une fonction qui vise à améliorer les performances des jointures d'index non mises en cache en récupérant au préalable les clés en mémoire avant qu'elles ne soient nécessaires. Le cas d'utilisation principale visé par AKP est une jointure d'index entre une petite table externe et une grande table interne, où l'index de la grande table est très sélectif. Lorsque l'interface Multi-Range Read (MRR) est activée, AKP sera exploité pour une recherche d'index secondaire vers principal. Les instances plus petites avec des contraintes de mémoire peuvent dans certains cas exploiter la fonction AKP selon la cardinalité de clé. Pour plus d'informations, consultez [Optimisation des requêtes de jointure indexées Aurora MySQL avec lecture anticipée asynchrone des clés](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.BestPractices.html#Aurora.BestPractices.AKP) dans le *Guide de l'utilisateur Amazon Aurora.*
+ **Fast DDL** – nous avons étendu cette fonction publiée dans [Aurora 1.13](AuroraMySQL.Updates.20170515.md) aux opérations qui incluent des valeurs par défaut. Avec cette extension, FAST DLL est applicable pour les opérations qui ajoutent une colonne acceptant la valeur null à la fin d'une table, avec ou sans valeurs par défaut. Cette fonction reste sous le mode Lab d'Aurora. Pour plus d'informations, consultez [Modification de tables dans Amazon Aurora à l'aide de Fast DDL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Managing.FastDDL.html) dans le *Guide de l'utilisateur Amazon Aurora*.

## Améliorations
<a name="AuroraMySQL.Updates.20171024.Improvements"></a>
+ Correction d'une erreur de calcul lors de l'optimisation des requêtes WITHIN/CONTAINS spatiales qui entraînait auparavant un jeu de résultats vide.
+ Résolution du problème associé à la commande `SHOW VARIABLE` afin d'afficher la valeur du paramètre `innodb_buffer_pool_size` mise à jour en cas de modification dans le groupe de paramètres.
+ Amélioration de la stabilité de l'instance principale pendant l'insertion en bloc dans une table modifiée avec Fast DDL lorsque l'indexation de hachage est désactivée et lorsque l'enregistrement à insérer est le premier d'une page.
+ Amélioration de la stabilité d'Aurora lorsque l'utilisateur tente de définir la valeur du paramètre de cluster de bases de données **server\$1audit\$1events** sur **default**.
+ Résolution d'un problème où une modification de jeu de caractères de base de données pour une instruction ALTER TABLE exécutée sur l'instance principale d'Aurora n'était pas répliquée sur les réplicas Aurora avant leur redémarrage.
+ Amélioration de la stabilité grâce à la correction d'une condition de concurrence sur l'instance principale qui permettait précédemment d'enregistrer un réplica Aurora même si l'instance principale avait fermé son propre volume.
+ Amélioration des performances de l'instance principale pendant la création d'index sur une table de grande taille en changeant le protocole de verrouillage pour permettre les instructions DML simultanées pendant la construction d'index.
+ Correction du problème d'incohérence des métadonnées InnoDB pendant la requête ALTER TABLE RENAME pour une meilleure stabilité. Exemple : lorsque les colonnes de la table t1(c1, c2) sont renommées cycliquement en t1(c2,c3) dans la même instruction ALTER.
+ Amélioration de la stabilité des réplicas Aurora lorsqu'un réplica Aurora n'a pas de charge de travail active et que l'instance principale ne répond pas.
+ Amélioration de la disponibilité des réplicas Aurora lorsqu'un réplica Aurora contient un verrou explicite sur une table et empêche le thread de réplication d'appliquer les modifications DDL reçues à partir de l'instance principale.
+ Amélioration de la stabilité de l'instance principale lorsqu'une clé étrangère et une colonne sont ajoutées simultanément à une table à partir de deux sessions séparées et que la fonction Fast DDL a été activée.
+ Amélioration de la stabilité du thread de purge sur l'instance principale pendant une lourde charge de travail en écriture en bloquant la troncature d'enregistrements d'annulation jusqu'à ce qu'ils soient purgés.
+ Amélioration de la stabilité en corrigeant l'ordre de libération du verrou pendant le processus d'engagement des transactions qui ignore des tables.
+ Correction d'un défaut lié aux réplicas Aurora dans lequel l'instance de base de données ne pouvait par terminer le démarrage et indiquait que le port 3306 était déjà utilisé.
+ Correction d'une condition de concurrence dans laquelle l'exécution d'une requête SELECT sur certaines tables information\$1schema (innodb\$1trx, innodb\$1lock, innodb\$1lock\$1waits) augmentait l'instabilité du cluster.

## Intégration de correctifs de bogues MySQL.
<a name="AuroraMySQL.Updates.20171024.BugFixes"></a>
+ CREATE USER accepte le plugin et le hachage du mot de passe, mais ignore le hachage du mot de passe (bogue n° 78033)
+ Le moteur de partitionnement ajoute des champs à l'ensemble de bits de lecture pour pouvoir retourner des entrées triées à partir d'un index partitionné. Par conséquent, le tampon de jointure essaie de lire des champs non nécessaires. Corrigé en n'ajoutant pas tous les champs de partitionnement à read\$1set, mais en triant uniquement les champs à préfixe déjà spécifié de read\$1set. Ajout d'un DBUG\$1ASSERT qui implique la lecture du premier champ en cas de key\$1cmp (bogue n° 16367691).
+ Ralentissement de l'instance MySQL « doing SYNC index » (bogue n° 73816)
+ Assertion RBT\$1EMPTY(INDEX\$1CACHE->WORDS) dans ALTER TABLE CHANGE COLUMN (bogue n° 17536995)
+ La recherche InnoDB Fulltext ne trouve pas d'enregistrements lorsque des points de sauvegarde sont impliqués (bogue n° 70333)

# Mises à jour du moteur de base de données Aurora MySQL : 13/03/2018 (version 1.14.4) (obsolète)
<a name="AuroraMySQL.Updates.1144"></a>

**Version :** 1.14.4

Aurora MySQL 1.14.4 est en disponibilité générale. Vous pouvez créer de nouveaux clusters de bases de données dans Aurora 1.14.4, à l'aide de la AWS CLI ou de l'API Amazon RDS et en spécifiant la version du moteur. Vous avez la possibilité, sans y être obligé, de mettre à niveau les clusters de bases de données 1.14.x vers Aurora 1.14.4.

Avec la version 1.14.4 d'Aurora, nous utilisons un modèle d'application de correctifs de cluster dans lequel tous les nœuds d'un cluster de bases de données Aurora sont corrigés en même temps. Nous prenons en charge l'application de correctifs sans temps d'arrêt, basée sur l'optimisation, afin de conserver les connexions client tout au long du processus de mise à jour corrective. Pour plus d'informations, consultez [Entretien d'un cluster de base de données Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_UpgradeDBInstance.Maintenance.html) dans le *Guide de l'utilisateur Amazon Aurora*.

Si vous avez des questions ou des préoccupations, le AWS support est disponible sur les forums communautaires et via le [AWS support](https://aws.amazon.com/support). Pour plus d'informations, consultez [Entretien d'un cluster de base de données Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_UpgradeDBInstance.Maintenance.html) dans le *Guide de l'utilisateur Amazon Aurora*.

## Application de correctifs sans temps d'arrêt
<a name="AuroraMySQL.Updates.1144.ZDP"></a>

La fonction d'application de correctifs sans temps d'arrêt tente, dans un souci d'*optimisation*, de conserver les connexions client tout au long de la mise à jour corrective du moteur. Pour plus d'informations sur l'application de correctifs sans temps d'arrêt, consultez [Utilisation des correctifs sans temps d'arrêt](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Updates.Patching.html#AuroraMySQL.Updates.ZDP) dans le *Guide de l'utilisateur Amazon Aurora*. 

## Nouvelles fonctionnalités
<a name="AuroraMySQL.Updates.1144.New"></a>
+ Aurora MySQL prend désormais en charge les classes d'instance db.r4.

## Améliorations
<a name="AuroraMySQL.Updates.1144.Improvements"></a>
+ Correction d'un problème où `LOST_EVENTS` étaient générés lors de l'écriture d'événements de journaux binaires volumineux.

## Intégration de correctifs de bogues MySQL.
<a name="AuroraMySQL.Updates.1144.BugFixes"></a>
+ Les événements pouvant être ignorés ne fonctionnent pas et ne sont pas testés (bogue n° 74683)
+ NEW->OLD ASSERT FAILURE 'GTID\$1MODE > 0' (Bug \$120436436)

# Mises à jour du moteur de base de données Aurora MySQL : 22/09/2017 (version 1.14.1) (obsolète)
<a name="AuroraMySQL.Updates.20170922"></a>

**Version :** 1.14.1

Aurora MySQL 1.14.1 est en disponibilité générale. Tous les nouveaux clusters de bases de données, y compris ceux restaurés à partir d'instantanés, seront créés dans Aurora MySQL 1.14.1. Aurora MySQL 1.14.1 est également une mise à niveau obligatoire pour les clusters de bases de données Aurora MySQL existants. Pour plus d'informations, consultez [Annonce : extension du calendrier de mise à niveau obligatoire pour Amazon Aurora](https://forums.aws.amazon.com/ann.jspa?annID=4983) sur le site Web des forums pour AWS développeurs.

Avec la version 1.14.1 d'Aurora MySQL, nous utilisons un modèle d'application de correctifs de cluster dans lequel tous les nœuds d'un cluster de bases de données Aurora MySQL sont corrigés en même temps. Les mises à jour nécessitent un redémarrage de la base de données, si bien que vous rencontrerez 20 à 30 secondes d'indisponibilité, après quoi vous pourrez reprendre l'utilisation de votre ou de vos clusters de bases de données. Si vos clusters de bases de données exécutent actuellement la version 1.13 ou ultérieure, la fonction d'application de correctifs sans temps d'arrêt d'Aurora MySQL peut permettre aux connexions client à votre instance principale Aurora MySQL de persister tout au long de la mise à niveau, en fonction de votre charge de travail.

Si vous avez des questions ou des préoccupations, le AWS support est disponible sur les forums communautaires et via le [AWS support](https://aws.amazon.com/support).

## Améliorations
<a name="AuroraMySQL.Updates.20170922.Improvements"></a>
+ Correction de conditions de concurrence associées aux insertions et purge pour améliorer la stabilité de la fonction Fast DDL qui reste en mode Lab Aurora MySQL.

# Mises à jour du moteur de base de données Aurora MySQL : 07/08/2017 (version 1.14) (obsolète)
<a name="AuroraMySQL.Updates.20170807"></a>

**Version :** 1.14

Aurora MySQL 1.14 est en général disponible. Tous les nouveaux clusters de bases de données, y compris ceux restaurés à partir d'instantanés, seront créés dans Aurora MySQL 1.14. Aurora MySQL 1.14 est également une mise à niveau obligatoire pour les clusters de bases de données Aurora MySQL existants. Nous enverrons une annonce séparée avec le calendrier de prise en charge des versions précédentes d'Aurora MySQL. 

Avec la version 1.14 d'Aurora MySQL, nous utilisons un modèle d'application de correctifs de cluster dans lequel tous les nœuds d'un cluster de bases de données Aurora sont corrigés en même temps. Les mises à jour nécessitent un redémarrage de la base de données, si bien que vous rencontrerez 20 à 30 secondes d'indisponibilité, après quoi vous pourrez reprendre l'utilisation de votre ou de vos clusters de bases de données. Si vos clusters de bases de données exécutent actuellement la version 1.13, la fonction d'application de correctifs sans temps d'arrêt d'Aurora peut permettre aux connexions client à votre instance principale Aurora de persister tout au long de la mise à niveau, en fonction de votre charge de travail.

Si vous avez des questions ou des préoccupations, le AWS support est disponible sur les forums communautaires et via le [AWS support](https://aws.amazon.com/support).

## Application de correctifs sans temps d'arrêt
<a name="AuroraMySQL.Updates.20170807.ZDP"></a>

La fonction d'application de correctifs sans temps d'arrêt tente, dans un souci d'*optimisation*, de conserver les connexions client tout au long de la mise à jour corrective du moteur. Pour plus d'informations sur l'application de correctifs sans temps d'arrêt, consultez [Utilisation des correctifs sans temps d'arrêt](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Updates.Patching.html#AuroraMySQL.Updates.ZDP) dans le *Guide de l'utilisateur Amazon Aurora*. 

## Améliorations
<a name="AuroraMySQL.Updates.20170807.Improvements"></a>
+ Correction d'une erreur incorrecte « Enregistrement introuvable » lorsqu'un enregistrement est trouvé dans l'index secondaire, mais pas dans l'index principal.
+ Correction d'un problème de stabilité susceptible de se produire suite à une assertion de défense (ajoutée dans la version 1.12) qui était trop forte dans le cas où une écriture individuelle s'étend sur 32 pages. Une telle situation peut se produire, par exemple, avec des valeurs BLOB élevées.
+ Correction d'un problème de stabilité à cause des incohérences entre le cache de l'espace disque logique et le cache de dictionnaire.
+ Correction d'un problème au cours duquel le réplica Aurora cesse de réagir après avoir dépassé le nombre maximal de tentatives de connexion à l'instance principale. Un réplica Aurora redémarre maintenant si la période d'inactivité est supérieure à la période de pulsation utilisée pour la vérification de l'état par l'instance principale.
+ Correction d'un blocage opérationnel susceptible de se produire à la suite d'actions simultanées lorsqu'une connexion tente d'acquérir un blocage de métadonnées exclusif au moment de l'émission d'une commande, telle que `ALTER TABLE`.
+ Correction d'un problème de stabilité dans une réplique d'Aurora Read en présence de logical/parallel Read Ahead.
+ Amélioration de `LOAD FROM S3` de deux façons :

  1. Meilleure gestion des erreurs de délai d'attente Amazon S3 à l'aide de la nouvelle tentative du kit SDK en plus de la tentative existante.

  1. Optimisation des performances lors de la charge de très gros fichiers ou de grands nombres de fichiers par la mise en cache et la réutilisation de l'état du client.
+ Correction des problèmes de stabilité suivants avec Fast DDL pour les opérations `ALTER TABLE` :

  1.  Lorsque l'instruction `ALTER TABLE` comporte plusieurs commandes `ADD COLUMN` et que les noms de colonne ne sont pas dans l'ordre croissant. 

  1. Lorsque la chaîne de nom de la colonne à mettre à jour et sa chaîne de nom correspondante, extraites à partir de la table système interne, varient en fonction d'un caractère de fin null (/0).

  1. Sous certaines opérations de fractionnement de l'arbre B (B-tree).

  1. Lorsque la table comporte une clé primaire de longueur variable.
+ Correction d'un problème de stabilité avec les réplicas Aurora lorsqu'il faut trop de temps pour rendre le cache d'index de recherche en texte intégral cohérent avec celui de l'instance principale. Cela peut se produire si une grande partie des entrées d'index de recherche en texte intégral récemment créées sur l'instance principale n'a pas encore été vidée sur le disque.
+ Correction d'un problème de stabilité susceptible de se produire pendant la création de l'index.
+ Nouvelle infrastructure qui suit la consommation de mémoire par connexion et télémétrie associée qui sera utilisée pour élaborer des stratégies d'évitement Out-Of-Memory (OOM).
+ Correction d'un problème où `ANALYZE TABLE` était incorrectement autorisé sur les réplicas Aurora. Ceci est maintenant bloqué.
+ Correction d'un problème de stabilité causé par un blocage rare suite à une condition rare entre la lecture anticipée logique et la purge.

## Intégration de correctifs de bogues MySQL.
<a name="AuroraMySQL.Updates.20170807.BugFixes"></a>
+ Une recherche en texte intégral associée aux tables dérivées (sous-requêtes de la clause `FROM`) entraînait un arrêt du serveur. Maintenant, si une opération de texte intégral dépend d'une table dérivée, le serveur produit une erreur indiquant qu'une recherche en texte intégral ne peut pas être effectuée sur une table matérialisée. (Bogues n° 68751 et 16539903)

# Mises à jour du moteur de base de données Aurora MySQL : 15/05/2017 (version 1.13) (obsolète)
<a name="AuroraMySQL.Updates.20170515"></a>

**Version :** 1.13

**Note**  
Nous avons activé une nouvelle fonction - SELECT INTO OUTFILE S3 - dans la version 1.13 d'Aurora MySQL après la version initiale et mis à jour les notes de mise à jour de manière à refléter cette modification.

Aurora MySQL 1.13 est en général disponible. Tous les nouveaux clusters de bases de données, y compris ceux restaurés à partir d'instantanés, seront créés dans Aurora MySQL 1.13. Vous avez la possibilité, sans y être obligé, de mettre à niveau les clusters de bases de données existants vers Aurora MySQL 1.13. Avec la version 1.13 d'Aurora, nous utilisons un modèle d'application de correctifs de cluster dans lequel tous les nœuds d'un cluster de bases de données Aurora sont corrigés en même temps. Nous activons l'application de correctifs sans temps d'arrêt, basée sur l'optimisation, afin de conserver les connexions client tout au long du processus de mise à jour corrective. Pour plus d'informations, consultez [Entretien d'un cluster de base de données Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_UpgradeDBInstance.Maintenance.html) dans le *Guide de l'utilisateur Amazon Aurora*.

## Application de correctifs sans temps d'arrêt
<a name="AuroraMySQL.Updates.20170515.ZDP"></a>

La fonction d'application de correctifs sans temps d'arrêt tente, dans un souci d'*optimisation*, de conserver les connexions client tout au long de la mise à jour corrective du moteur. Pour plus d'informations sur l'application de correctifs sans temps d'arrêt, consultez [Utilisation des correctifs sans temps d'arrêt](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Updates.Patching.html#AuroraMySQL.Updates.ZDP) dans le *Guide de l'utilisateur Amazon Aurora*. 

## Nouvelles fonctions :
<a name="AuroraMySQL.Updates.20170515.NewFeatures"></a>
+ **SELECT INTO OUTFILE S3** – Aurora MySQL vous permet maintenant de charger les résultats d'une requête dans un ou plusieurs fichiers d'un compartiment Amazon S3. Pour plus d'informations, consultez [Enregistrement de données d'un cluster de bases de données Amazon Aurora MySQL dans des fichiers texte stockés dans un compartiment Amazon S3](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Integrating.SaveIntoS3.html) dans le *Guide de l'utilisateur Amazon Aurora*.

## Améliorations :
<a name="AuroraMySQL.Updates.20170515.Improvements"></a>
+ La troncation des fichiers journaux au format CSV au démarrage du moteur a été mise en œuvre pour éviter une longue durée de récupération. Désormais, les tables `general_log_backup`, `general_log`, `slow_log_backup` et `slow_log` ne survivent pas à un redémarrage de la base de données. 
+ Correction d'un problème d'échec de la migration d'une base de données nommée **test**.
+ La stabilité au niveau du récupérateur de mémoire du gestionnaire de verrous a été améliorée en réutilisant les segments de verrouillage corrects.
+ La stabilité du gestionnaire de verrous a été améliorée par la suppression des assertions non valides au cours de l'exécution de l'algorithme de détection de blocage. 
+ La réplication asynchrone a été réactivée et un problème associé a été corrigé qui entraînait un retard du réplica incorrect à signaler sous une charge de travail nulle ou en lecture seule. Les améliorations du pipeline de réplication ont été introduites dans la version 1.10. Ces améliorations ont été introduites afin d'appliquer les mises à jour des flux de journaux au cache des tampons d'un réplica Aurora, ce qui permet d'améliorer les performances de lecture et la stabilité sur les réplicas Aurora.
+ Un problème a été corrigé où autocommit=OFF conduisait au blocage d'événements planifiés et au maintien de longues transactions ouvertes jusqu'au redémarrage du serveur.
+ Un problème a été corrigé où les journaux des requêtes générales, d'audit et lentes ne pouvaient pas consigner les requêtes traitées par la validation asynchrone.
+ Les performances de la fonction de lecture anticipée logique ont été améliorées jusqu'à 2,5 fois. Cela s'est fait en autorisant la poursuite des récupérations au préalable sur les pages intermédiaires dans une arborescence B.
+ La validation des paramètres a été ajoutée pour que les variables d'audit suppriment les espaces inutiles.
+ Une régression a été corrigée, qui avait été introduite dans Aurora MySQL version 1.11, en raison de laquelle les requêtes pouvaient retourner des résultats incorrects lors de l'utilisation de l'option SQL\$1CALC\$1FOUND\$1ROWS et de l'appel de la fonction FOUND\$1ROWS().
+ Un problème de stabilité a été corrigé qui correspondait à l'établissement incorrect de la liste des verrous de métadonnées.
+ La stabilité est améliorée lorsque sql\$1mode a pour valeur PAD\$1CHAR\$1TO\$1FULL\$1LENGTH et que la commande `SHOW FUNCTION STATUS WHERE Db='string'` est exécutée.
+ Un cas rare a été corrigé où les instances n'étaient pas démarrées après la mise à niveau de la version d'Aurora en raison d'un contrôle de cohérence de volume erroné.
+ Correction du problème de performances, introduit dans Aurora MySQL version 1.12, où les performances de l'enregistreur Aurora étaient réduites lorsque les utilisateurs possédaient un grand nombre de tables. 
+ Amélioration du problème de stabilité lorsque l'enregistreur Aurora est configuré en tant que travailleur des journaux binaires et que le nombre de connexions approche les 16 000. 
+ Correction d'un problème rare où un réplica Aurora pouvait redémarrer lorsqu'une connexion était bloquée en attente d'un verrou de métadonnées lors de l'exécution d'une DDL sur le maître Aurora. 

## Intégration de correctifs de bogues MySQL.
<a name="AuroraMySQL.Updates.20170515.BugFixes"></a>
+ Avec une table InnoDB vide, il est impossible de diminuer la valeur auto\$1increment à l'aide d'une instruction ALTER TABLE, même lorsque la table est vide. (Bogue n° 69882)
+ Les requêtes MATCH()... AGAINST utilisant une longue chaîne comme argument pour AGAINST() pouvaient entraîner une erreur lorsqu'elles étaient exécutées sur une table InnoDB avec un index de recherche en texte intégral. (Bogue n° 17640261)
+ Le traitement de SQL\$1CALC\$1FOUND\$1ROWS en association avec ORDER BY et LIMIT pouvait mener à des résultats incorrects pour FOUND\$1ROWS(). (Bogues n° 68458 et 16383173)
+ ALTER TABLE n'autorise pas la modification de la possibilité de valeur NULL de la colonne si une clé étrangère existe. (Bogue n° 77591)

# Mises à jour du moteur de base de données Aurora MySQL : 05/04/2017 (version 1.12) (obsolète)
<a name="AuroraMySQL.Updates.20170405"></a>

**Version :** 1.12

Aurora MySQL 1.12 constitue désormais la version conseillée pour la création de nouveaux clusters de bases de données, y compris les restaurations à partir d'instantanés.

Il n'est pas obligatoire d'effectuer la mise à niveau pour les clusters existants. Vous pourrez mettre à niveau les clusters existants vers la version 1.12 une fois que nous aurons terminé d'appliquer le correctif à l'échelle du parc à la version 1.11 (consultez les [notes de mise à jour](AuroraMySQL.Updates.20170223.md) d'Aurora 1.11 et l'[annonce du forum](https://forums.aws.amazon.com/ann.jspa?annID=4444) correspondante). Avec la version 1.12 d'Aurora, nous utilisons un modèle d'application de correctifs de cluster dans lequel tous les nœuds d'un cluster de bases de données Aurora sont corrigés en même temps. Pour plus d'informations, consultez [Entretien d'un cluster de base de données Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_UpgradeDBInstance.Maintenance.html) dans le *Guide de l'utilisateur Amazon Aurora*.

## Nouvelles fonctionnalités
<a name="AuroraMySQL.Updates.20170405.New"></a>
+ **Fast DDL** – Aurora MySQL vous permet désormais d'exécuter une opération ALTER TABLE *tbl\$1name* ADD COLUMN *col\$1name* *column\$1definition* presque instantanément. L'opération s'effectue sans nécessiter la copie de la table et sans impact matériel sur les autres instructions DML. Puisque l'opération ne consomme pas de stockage temporaire pour une copie de table, les instructions DDL sont pratiques même pour des tables volumineuses sur des classes d'instance Small. FAST DLL prend actuellement uniquement en charge l'ajout d'une colonne acceptant la valeur null, sans valeur par défaut, à la fin d'une table. Cette fonction n'est actuellement disponible qu'au mode Lab d'Aurora. Pour plus d'informations, consultez [Modification de tables dans Amazon Aurora à l'aide de Fast DDL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Managing.FastDDL.html) dans le *Guide de l'utilisateur Amazon Aurora*.
+ **Show volume status** – Nous avons ajouté une nouvelle commande de surveillance, SHOW VOLUME STATUS, qui permet d'afficher le nombre de nœuds et de disques d'un volume. Pour plus d'informations, consultez [Affichage du statut du volume pour un cluster de base de données Aurora MySQL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Managing.VolumeStatus.html) dans le *Guide de l'utilisateur Amazon Aurora*.

## Améliorations
<a name="AuroraMySQL.Updates.20170405.Improvements"></a>
+ Modifications implémentées pour verrouiller la compression en vue de réduire davantage la mémoire allouée par objet verrouillé. Cette amélioration est disponible au mode Lab.
+ Un problème de diminution rapide de la métrique `trx_active_transactions`, même quand la base de données est inactive, a été résolu.
+ Un problème de message d'erreur non valide concernant la syntaxe de la requête d'injection d'erreurs en cas d'échec de la simulation dans les disques et les nœuds a été résolu.
+ Plusieurs problèmes de conditions de concurrence et de verrous morts dans le gestionnaire de verrous ont été résolus.
+ Un problème de dépassement de mémoire tampon dans l'optimiseur de requête a été résolu.
+ Un problème de stabilité dans les réplicas en lecture de l'Aurora lorsque les nœuds de stockage sous-jacents ont une mémoire disponible faible a été résolu.
+ Un problème de persistance de connexions inactives au-delà de la définition du paramètre `wait_timeout` a été résolu.
+ Un problème de renvoi par `query_cache_size` d'une valeur inattendue après le redémarrage d'une instance a été résolu.
+ Un problème de performance résultant d'un fil de diagnostic détectant le réseau trop souvent dans le cas où les écritures ne progressent pas vers le stockage a été résolu.

## Intégration de correctifs de bogues MySQL.
<a name="AuroraMySQL.Updates.20170405.BugFixes"></a>
+ Le rechargement d'une table qui a été expulsée quand elle était vide a provoqué la réinitialisation d'une valeur AUTO\$1INCREMENT. (Bogues n° 21454472 et 77743)
+ Un enregistrement d'index a été introuvable à la restauration en raison d'incohérences dans la structure purge\$1node\$1t. Celles-ci ont entraîné des messages d'avertissement et d'erreur tels que « erreur dans la mise à jour de l'entrée d'index secondaire », « impossible de purger un enregistrement » et « tentative de purge de l'entrée d'index secondaire non marquée pour la suppression ». (Bogues n° 19138298, 70214, 21126772 et 21065746) 
+ Le calcul incorrect de la taille de la pile de l'opération qsort entraîne un dépassement de la pile. (Bogue n° 73979)
+ Enregistrement introuvable dans un index à la restauration. (Bogues n° 70214 et 72419)
+ ALTER TABLE ajoute la colonne TIMESTAMP sur la mise à jour CURRENT\$1TIMESTAMP insère des données ZERO (Bogue n° 17392)

# Mises à jour du moteur de base de données Aurora MySQL : 23/02/2017 (version 1.11) (obsolète)
<a name="AuroraMySQL.Updates.20170223"></a>

**Version :** 1.11

Nous corrigerons tous les clusters de bases de données Aurora MySQL avec la dernière version sur une courte période suivant la sortie. Les clusters de bases de données sont corrigés grâce à la procédure existante avec un temps d'arrêt d'environ 5 à 30 secondes. 

La correction se déroule pendant la fenêtre de maintenance du système que vous avez spécifiée pour chacune de vos instances de base de données. Vous pouvez consulter ou modifier cette fenêtre grâce à l AWS Management Console. Pour plus d'informations, consultez [Entretien d'un cluster de base de données Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_UpgradeDBInstance.Maintenance.html) dans le *Guide de l'utilisateur Amazon Aurora*.

Vous pouvez également appliquer le correctif immédiatement dans le en AWS Management Console choisissant un cluster de base de données, en choisissant **Cluster Actions**, puis en choisissant **Upgrade Now**.

Avec la version 1.11 d'Aurora MySQL, nous utilisons un modèle d'application de correctifs de cluster dans lequel tous les nœuds d'un cluster de bases de données Aurora sont corrigés en même temps.

## Nouvelles fonctions
<a name="AuroraMySQL.Updates.20170223.New"></a>
+ **Option MANIFEST de la commande LOAD DATA FROM S3** – La commande LOAD DATA FROM S3 a été introduite dans la version 1.8. Les options de cette commande ont été développées et vous pouvez désormais spécifier une liste de fichiers à charger dans un cluster de bases de données Aurora à partir d'Amazon S3 à l'aide d'un fichier manifeste. Cela facilite le chargement des données à partir de fichiers spécifiques dans un ou plusieurs emplacements, comparé au chargement des données à partir d'un seul fichier grâce à l'option FILE ou au chargement des données à partir de plusieurs fichiers ayant le même emplacement et préfixe grâce à l'option PREFIX. Le format du fichier manifest est identique à celui utilisé par Amazon Redshift. Pour plus d'informations sur l'utilisation de LOAD DATA FROM S3 avec l'option MANIFEST, consultez [Utilisation d'un manifeste pour spécifier les fichiers de données à charger](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Integrating.LoadFromS3.html#AuroraMySQL.Integrating.LoadFromS3.Manifest) dans le *Guide de l'utilisateur Amazon Aurora*.
+ **Indexation spatiale activée par défaut** – Cette fonction est sortie en mode Lab dans la version 1.10 et est désormais activée par défaut. L'indexation spatiale améliore les performances des requêtes sur des jeux de données volumineux pour les requêtes qui utilisent des données spatiales. Pour plus d'informations sur l'utilisation de l'indexation spatiale, consultez [Amazon Aurora MySQL et données spatiales](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.AuroraMySQL.Overview.html#Aurora.AuroraMySQL.Spatial) dans le *Guide de l'utilisateur Amazon Aurora*.
+ **Modification de la durée de l'audit avancé** – Cette fonction est sortie dans la version 1.10.1 pour fournir une installation hautement performante afin de réaliser l'audit de l'activité de la base de données. Dans cette version, la précision des horodatages de journaux d'audit a été modifiée d'une seconde à une microseconde. Les horodatages plus précis vous permettent de mieux comprendre quand un événement d'audit se produit. Pour plus d'informations sur l'audit, consultez [Utilisation de l'Audit avancé avec un cluster de bases de données Amazon Aurora MySQL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Auditing.html) dans le *Guide de l'utilisateur Amazon Aurora*.

## Améliorations
<a name="AuroraMySQL.Updates.20170223.Improvements"></a>
+ Modification du paramètre `thread_handling` pour vous empêcher de lui affecter une autre valeur que **multiple-connections-per-thread**, qui est le seul modèle pris en charge avec le groupe de threads d'Aurora.
+ Résolution d'un problème causé lorsque vous configurez le paramètre `buffer_pool_size` ou `query_cache_size` pour qu'il dépasse la mémoire totale du cluster de bases de données. Dans ces cas-là, Aurora configure le paramètre modifié sur la valeur par défaut, afin que le cluster de bases de données puisse démarrer sans tomber en panne.
+ Résolution d'un problème dans le cache de requête où une transaction obtient des résultats de lecture obsolètes si la table est invalidée dans une autre transaction.
+ Résolution d'un problème où des fichiers de journaux binaires à supprimer sont effacés après un court délai au lieu d'être supprimés immédiatement.
+ Résolution d'un problème où une base de données créée avec le nom **tmp** est traitée comme une base de données système stockée sur un stockage éphémère au lieu d'être conservée dans un stockage distribué Aurora.
+ Modification du comportement de SHOW TABLES pour exclure certaines tables système internes. Cette modification permet d'éviter un basculement inutile causé par le verrouillage par mysqldump de tous les fichiers affichés dans SHOW TABLES, qui à son tour empêche les écritures sur la table système interne causées par le basculement.
+ Résolution d'un problème où un réplica Aurora redémarre de manière incorrecte lors de la création d'une table temporaire à partir d'une requête qui invoque une fonction dont l'argument est une colonne d'une table InnoDB.
+ Résolution d'un problème lié à un conflit de verrouillage de métadonnées dans un nœud de réplica Aurora qui fait prendre du retard au réplica Aurora par rapport au cluster de bases de données principal et entraîne finalement son redémarrage.
+ Réparation d'un verrou mort dans le pipeline de réplication des nœuds du lecteur qui fait prendre du retard au réplica Aurora pour finalement être redémarré.
+ Résolution d'un problème où un réplica Aurora se décale trop avec les volumes chiffrés supérieurs à 1 téraoctet (To).
+ Amélioration de la détection des verrous morts du réplica Aurora grâce à un meilleur moyen de lire l'horloge système.
+ Résolution d'un problème où un réplica Aurora peut redémarrer deux fois au lieu d'une suite à l'annulation de l'enregistrement par l'enregistreur.
+ Résolution d'un problème de performances de requête lentes sur des réplicas Aurora qui se produisent lorsque les statistiques transitoires entraînent des écarts de statistiques sur les colonnes d'index non uniques.
+ Résolution d'un problème où un réplica Aurora peut tomber en panne lorsqu'une instruction DDL est répliquée sur le réplica Aurora alors que ce réplica Aurora traite une requête connexe.
+ Modification des améliorations du pipeline de réplication présentées dans la version 1.10 et activées par défaut qui sont désormais désactivées par défaut. Ces améliorations ont été introduites afin d'appliquer des mises à jour de flux de journaux au cache des tampons d'un réplica Aurora, et bien que cette fonction permette d'améliorer les performances de lecture et la stabilité des réplicas Aurora, elle augmente le retard du réplica dans certaines charges de travail.
+ Résolution d'un problème où l'occurrence simultanée d'une instruction DDL continue et de la lecture anticipée parallèle en attente sur une même table cause un échec d'assertion lors de la phase de validation de la transaction DDL.
+ Amélioration du journal général et du journal des requêtes lentes pour survivre au redémarrage du cluster de bases de données.
+ Correction d'un out-of-memory problème lié à certaines requêtes de longue durée en réduisant la consommation de mémoire dans le module ACL.
+ Résolution d'un problème de redémarrage qui se produit lorsqu'une table possède des index non spatiaux, lorsque des prédicats spatiaux se trouvent dans la requête, lorsque le planificateur choisit d'utiliser un index non spatial et lorsque le planificateur transmet de manière incorrecte la condition spatiale à l'index.
+ Correction d'un problème à cause duquel le cluster de base de données redémarre en cas de suppression, de mise à jour ou de purge d'objets géospatiaux de très grande taille stockés en externe (par exemple LOBs).
+ Correction d'un problème de simulation de panne avec ALTER SYSTEM SIMULATE ... FOR INTERVAL ne fonctionne pas correctement.
+ Résolution d'un problème de stabilité causé par une assertion non valide sur un invariant incorrect dans le gestionnaire de verrous.
+ Désactivation des deux améliorations suivantes dans InnoDB Full-Text Search présentées dans la version 1.10 car elles causaient des problèmes de stabilité pour les charges de travail exigeantes :
  +  Mise à jour du cache uniquement après une demande de lecture à un réplica Aurora afin d'améliorer la vitesse de réplication de cache d'index de recherche en texte intégral. 
  + Déchargement de la tâche de synchronisation du cache sur un thread séparé dès que la taille du cache dépasse 10 % de la taille totale, afin d'éviter que les requêtes MySQL ne calent trop longtemps au cours de la synchronisation du cache FTS sur le disque. (Bogues n° 22516559, n° 73816).

## Intégration de correctifs de bogues MySQL.
<a name="AuroraMySQL.Updates.20170223.BugFixes"></a>
+ L'exécution d'une clé étrangère DROP de table ALTER simultanément avec une autre opération DROP fait disparaître la table. (Bogue n° 16095573)
+ Certaines requêtes INFORMATION\$1SCHEMA qui utilisaient ORDER BY n'utilisaient pas d'optimisation filesort comme elles le faisaient auparavant. (Bogue n° 16423536)
+ FOUND\$1ROWS () renvoie le mauvais nombre de lignes sur une table. (Bogue n° 68458)
+ Le serveur échoue au lieu d'indiquer une erreur lorsque trop de tables temporaires sont ouvertes. (Bogue n° 18948649)

# Mises à jour du moteur de base de données Aurora MySQL : 12/01/2017 (version 1.10.1) (obsolète)
<a name="AuroraMySQL.Updates.20170112"></a>

**Version :** 1.10.1

La version 1.10.1 d'Aurora MySQL est une version d'acceptation qui n'est pas utilisée pour corriger vos instances de bases de données. Elle est disponible pour créer des instances Aurora et mettre à niveau les instances existantes. Vous pouvez appliquer le correctif en choisissant un cluster dans la [console Amazon RDS](https://console.aws.amazon.com/rds/), puis **Actions de clusters** et **Mettre à niveau maintenant**. Pour appliquer un correctif, vous devez redémarrer la base de données en respectant un temps d'arrêt de 5 à 30 secondes en général, après quoi vous pouvez de nouveau utiliser vos clusters de bases de données. Ce correctif utilise un modèle d'application de correctifs de cluster dans lequel tous les nœuds d'un cluster Aurora sont corrigés en même temps.

## Nouvelles fonctions
<a name="AuroraMySQL.Updates.20170112.New"></a>
+ **Audit avancé** – Aurora MySQL propose une fonction d'audit avancé hautes performances que vous pouvez utiliser pour effectuer un audit de l'activité de la base de données. Pour plus d'informations sur l'activation et l'utilisation de l'audit avancé, consultez la section [Utilisation de l'Audit avancé avec un cluster de bases de données Amazon Aurora MySQL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Auditing.html) dans le *Guide de l'utilisateur Amazon Aurora*.

## Améliorations
<a name="AuroraMySQL.Updates.20170112.Improvements"></a>
+ Résolution d'un problème avec l'indexation spatiale lorsque vous créez une colonne et que vous y ajoutez un index dans la même instruction.
+ Résolution d'un problème dans lequel les statistiques spatiales ne sont pas conservées après le redémarrage du cluster de bases de données.

# Mises à jour du moteur de base de données Aurora MySQL : 14/12/2016 (version 1.10) (obsolète)
<a name="AuroraMySQL.Updates.20161214"></a>

**Version :** 1.10

## Nouvelles fonctions
<a name="AuroraMySQL.Updates.20161214.New"></a>
+ **Application de correctifs sans temps d'arrêt** – Cette fonction permet d'appliquer des correctifs à une instance de base de données sans aucun temps d'arrêt. Autrement dit, les mises à niveau de la base de données sont effectuées sans déconnecter les applications clientes ni redémarrer la base de données. Cette approche augmente la disponibilité de vos clusters de bases de données Aurora pendant la fenêtre de maintenance. Notez que les données temporaires comme celles dans le schéma de performances sont réinitialisées au cours du processus de mise à niveau. Cette fonction s'applique aux correctifs fournis par le service au cours d'une fenêtre de maintenance, ainsi qu'aux correctifs initiés par l'utilisateur. 

  Lorsqu'un correctif est démarré, le service s'assure qu'il n'existe aucun verrou ouvert, aucune transaction ni aucune table temporaire, puis attend une fenêtre propice à la correction et au redémarrage de la base de données. Les sessions d'application sont conservées, même en cas de baisse de débit pendant l'application des correctifs (pendant environ 5 secondes). Si aucune fenêtre adaptée n'est disponible, l'application des correctifs correspond par défaut au comportement standard d'application des correctifs.

  L'application des correctifs sans temps d'arrêt se déroule autant que faire se peut, sous certaines restrictions, comme décrit ci-dessous :
  + Cette fonction est actuellement en vigueur pour l'application des correctifs aux clusters de bases de données à un seul nœud ou aux instances de l'enregistreur dans des clusters de bases de données à plusieurs nœuds.
  + Les connexions SSL ne sont pas prises en charge conjointement à cette fonction. S'il existe des connexions SSL actives, Amazon Aurora MySQL n'appliquera pas de correctif sans temps d'arrêt et, à la place, réessaiera régulièrement de voir si les connexions SSL ont pris fin. Si tel est le cas, l'application de correctifs sans temps d'arrêt a lieu. Si les connexions SSL persistent plus de quelques secondes, l'application de correctifs standard avec temps d'arrêt a lieu.
  + La fonction est disponible dans Aurora 1.10 et versions ultérieures. Nous allons désormais identifier toutes les versions ou correctifs qui ne peuvent pas être appliqués via l'application de correctifs sans temps d'arrêt.
  + Cette fonction n'est pas applicable si la réplication basée sur la journalisation binaire est active.
+ **Indexation spatiale** – L'indexation spatiale améliore les performances des requêtes sur les jeux de données volumineux pour les requêtes qui utilisent des données spatiales. Pour plus d'informations sur l'utilisation de l'indexation spatiale, consultez [Amazon Aurora MySQL et données spatiales](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.AuroraMySQL.Overview.html#Aurora.AuroraMySQL.Spatial) dans le *Guide de l'utilisateur Amazon Aurora*.

  Cette fonction est désactivée par défaut et peut être activée en activant le mode Lab d'Aurora. Pour plus d'informations, consultez [Mode Lab Amazon Aurora MySQL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Updates.LabMode.html) dans le *Guide de l'utilisateur Amazon Aurora*.
+ **Améliorations du pipeline de réplication** – Aurora MySQL utilise désormais un mécanisme amélioré pour appliquer les mises à jour des flux de journaux au cache des tampons d'un réplica Aurora. Cette fonction améliore les performances en lecture et la stabilité sur les réplicas Aurora en cas de lourde charge en écriture sur le maître et d'une charge en lecture importante sur le réplica. Cette caractéristique est activée par défaut. 
+ **Amélioration du débit pour les charges de travail avec des lectures mises en cache** – Aurora MySQL utilise désormais un algorithme simultané sans verrou pour implémenter les vues en lecture, ce qui permet un meilleur débit pour les requêtes de lecture traitées par le cache de tampons. Grâce à ces améliorations et à d'autres, Amazon Aurora MySQL peut atteindre un débit de 625 000 lectures par seconde, contre 164 000 lectures par seconde pour MySQL 5.7 pour une charge de travail basée uniquement sur la sélection. SysBench 
+ **Amélioration du débit pour les charges de travail avec des conflits entre les lignes critiques** – Aurora MySQL utilise un nouvel algorithme de publication de verrou qui améliore les performances, en particulier en cas de conflit de page critique (c'est-à-dire lorsque de nombreuses transactions sont en conflit pour les lignes de la même page). Dans les tests de référence TPC-C, cela peut entraîner une amélioration du débit permettant de multiplier par 16 le nombre de transactions par minute par rapport à MySQL 5.7. Cette fonction est désactivée par défaut et peut être activée en activant le mode Lab d'Aurora. Pour plus d'informations, consultez [Mode Lab Amazon Aurora MySQL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Updates.LabMode.html) dans le *Guide de l'utilisateur Amazon Aurora*.

## Améliorations
<a name="AuroraMySQL.Updates.20161214.Improvements"></a>
+ La vitesse de réplication du cache d'index de recherche en texte intégral a été augmentée en mettant à jour le cache uniquement après une demande de lecture adressée à un réplica Aurora. Cette approche évite les lectures du disque par le thread de réplication. 
+ Correction d'un problème où l'invalidation du cache de dictionnaire ne fonctionne pas sur un réplica Aurora pour les tables qui ont un caractère spécial dans le nom de base de données ou le nom de table.
+ Correction d'un problème `STUCK IO` lors de la migration des données pour les nœuds de stockage distribués lorsque la gestion de la chaleur de stockage est activée.
+ Correction d'un problème dans le gestionnaire de verrous, alors qu'une vérification d'assertion échoue pour le thread d'attente de verrouillage de transaction lors de la préparation de la restauration ou de la validation d'une transaction.
+ Correction d'un problème lors de l'ouverture d'une table de dictionnaire endommagée en mettant à jour correctement le nombre de référence dans les entrées de la table de dictionnaire.
+ Correction d'un bogue selon lequel le point de lecture minimal du cluster de bases de données peut être détenu par des réplicas Aurora lents.
+ Correction d'une fuite de mémoire potentielle dans le cache de requête.
+ Correction d'un bogue selon lequel un réplica Aurora place un verrou de niveau de ligne sur une table lorsqu'une requête est utilisée dans une instruction `IF` d'une procédure stockée.

## Intégration de correctifs de bogues MySQL.
<a name="AuroraMySQL.Updates.20161214.BugFixes"></a>
+ L'UNION de tables dérivées retourne des résultats erronés avec des clauses '1=0/false'. (Bogue n° 69471)
+ Le serveur se bloque dans ITEM\$1FUNC\$1GROUP\$1CONCAT::FIX\$1FIELDS à la 2e exécution de la procédure stockée. (Bogue n° 20755389)
+ Empêchez les requêtes MySQL de caler trop longtemps au cours de la synchronisation du cache FTS sur le disque en déchargeant la tâche de synchronisation du cache sur un thread séparé, dès que la taille du cache dépasse 10 % de la taille totale. (Bogue n° 22516559, n° 73816)

# Mises à jour du moteur de base de données Aurora MySQL : 10/11/2016 (versions 1.9.0, 1.9.1) (obsolète)
<a name="AuroraMySQL.Updates.20161110"></a>

**Version :** 1.9.0, 1.9.1

## Nouvelles fonctions
<a name="AuroraMySQL.Updates.20161110.New"></a>
+ **Construction d'index améliorée** – La création d'index secondaires fonctionne désormais suivant un mode de construction de bas en haut, qui élimine les fractionnements de pages inutiles. Cela peut réduire le temps nécessaire à la création d'un index ou la reconstruction d'une table de 75 % (sur la base d'une instance de base de données `db.r3.8xlarge`). Cette fonction était en mode Lab dans Aurora MySQL version 1.7 et est activée par défaut dans Aurora 1.9 et versions ultérieures. Pour plus d'informations, consultez [Mode Lab Amazon Aurora MySQL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Updates.LabMode.html) dans le *Guide de l'utilisateur Amazon Aurora*.
+ **Compression de verrou (mode Lab)** – Cette implémentation réduit de manière significative la quantité de mémoire consommée par le gestionnaire de verrous, jusqu'à 66 %. Le gestionnaire de verrous peut acquérir davantage de verrous de ligne sans rencontrer d' out-of-memoryexception. Cette fonction est désactivée par défaut et peut être activée en activant le mode Lab d'Aurora. Pour plus d'informations, consultez [Mode Lab Amazon Aurora MySQL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Updates.LabMode.html) dans le *Guide de l'utilisateur Amazon Aurora*.
+ **Schéma de performances** – Aurora MySQL prend désormais en charge le schéma de performances avec un impact minimal sur les performances. Lors de nos tests d'utilisation SysBench, l'activation du schéma de performance pourrait dégrader les performances de MySQL jusqu'à 60 %.

  SysBench les tests d'un cluster de base de données Aurora ont montré un impact sur les performances 4 fois inférieur à celui de MySQL. L'exécution de la classe d'`db.r3.8xlarge`instance de base de données a généré 100 000 requêtes SQL writes/sec et plus de 550 000 lectures SQL par seconde, même avec le schéma de performance activé.
+ **Amélioration des conflits entre les lignes critiques** – Cette fonction réduit l'utilisation de l'UC et augmente le débit lorsqu'un grand nombre de connexions accèdent à un petit nombre de lignes critiques. Cette fonction élimine également l'` error 188` en cas de conflits entre les lignes critiques.
+ ** out-of-memoryGestion améliorée** : lorsque des instructions SQL verrouillables non essentielles sont exécutées et que le pool de mémoire réservé est violé, Aurora force l'annulation de ces instructions SQL. Cette fonctionnalité permet de libérer de la mémoire et d'éviter les pannes de moteur dues à des out-of-memory exceptions.
+ **Sélecteur de lecture intelligent** : cette implémentation améliore la latence de lecture en choisissant le segment de stockage optimal parmi les différents segments pour chaque lecture, ce qui améliore le débit de lecture. SysBench les tests ont montré une augmentation des performances allant jusqu'à 27 % pour les charges de travail d'écriture.

## Améliorations
<a name="AuroraMySQL.Updates.20161110.Improvements"></a>
+ Résolution d'un problème où un réplica Aurora détecte un verrouillage partagé au démarrage du moteur.
+ Résolution d'un problème possible sur un réplica Aurora lorsque le pointeur de vue de lecture sur le système de purge est NULL.

# Mises à jour du moteur de base de données Aurora MySQL : 26/10/2016 (version 1.8.1) (obsolète)
<a name="AuroraMySQL.Updates.20161026"></a>

**Version :** 1.8.1

## Améliorations
<a name="AuroraMySQL.Updates.20161026.Improvements"></a>
+ Correction d'un problème où les insertions en bloc utilisent des déclencheurs qui appellent les procédures AWS Lambda échouent.
+ Correction d'un problème où la migration de catalogue échoue lorsque la validation automatique est désactivée de manière globale.
+ Résolution d'un échec de connexion à Aurora lors de l'utilisation du protocole SSL et amélioration du groupe Diffie-Hellman pour faire face aux attaques. LogJam 

## Intégration de correctifs de bogues MySQL.
<a name="AuroraMySQL.Updates.20161026.BugFixes"></a>
+ OpenSSL a modifié les paramètres de longueur de clé Diffie-Hellman en raison de ce problème. LogJam (Bogue n° 18367167)

# Mises à jour du moteur de base de données Aurora MySQL : 18/10/2016 (version 1.8) (obsolète)
<a name="AuroraMySQL.Updates.20161018"></a>

**Version :** 1.8

## Nouvelles fonctionnalités
<a name="AuroraMySQL.Updates.20161018.New"></a>
+ **AWS Lambda intégration** — Vous pouvez désormais appeler de manière asynchrone une AWS Lambda fonction à partir d'un cluster de base de données Aurora à l'`mysql.lambda_async`aide de cette procédure. Pour plus d'informations, consultez [Appel d'une fonction Lambda à partir d'un cluster de bases de données Amazon Aurora MySQL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Integrating.Lambda.html) dans le *Guide de l'utilisateur Amazon Aurora*.
+ **Chargement de données à partir d'Amazon S3** – Vous pouvez désormais charger du texte ou des fichiers XML d'un compartiment Amazon S3 dans votre cluster de bases de données Aurora à l'aide des commandes `LOAD DATA FROM S3` ou `LOAD XML FROM S3`. Pour plus d'informations, consultez [Chargement de données dans un cluster de bases de données Amazon Aurora MySQL à partir de fichiers texte stockés dans un compartiment Amazon S3](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Integrating.LoadFromS3.html) dans le *Guide de l'utilisateur Amazon Aurora*.
+ **Migration du catalogue** – Aurora conserve désormais les métadonnées de catalogue dans le volume de cluster pour prendre en charge la gestion des versions. Cela permet une migration de catalogue transparente entre différentes versions et restaurations.
+ **Maintenance et application de correctifs au niveau du cluster** – Aurora gère désormais les mises à jour de maintenance pour un cluster de bases de données tout entier. Pour plus d'informations, consultez [Entretien d'un cluster de base de données Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_UpgradeDBInstance.Maintenance.html) dans le *Guide de l'utilisateur Amazon Aurora*.

## Améliorations
<a name="AuroraMySQL.Updates.20161018.Improvements"></a>
+ Correction d'un problème où un réplica Aurora se bloque s'il n'accorde pas de verrou de métadonnées dans une DDL en vol.
+ Les réplicas Aurora sont autorisés à modifier des tables non-InnoDB pour faciliter la rotation des fichiers journaux CSV généraux et lents où `log_output=TABLE`.
+ Correction d'un décalage dans la mise à jour des statistiques entre l'instance principale et un réplica Aurora. Sans ce correctif, les statistiques du réplica Aurora peuvent se trouver désynchronisées par rapport à celles de l'instance principale et engendrer un plan de requête différent (et sous-performant) sur un réplica Aurora. 
+ Correction d'une condition de concurrence qui garantit qu'un réplica Aurora n'acquiert pas de verrous.
+ Correction d'un scénario rare où un réplica Aurora qui s'enregistre ou se désenregistre de l'instance principale peut échouer. 
+ Correction d'une condition de concurrence pouvant conduire à un blocage sur les instances `db.r3.large` lors de l'ouverture ou de la fermeture d'un volume.
+ Correction d'un out-of-memory problème qui pouvait survenir en raison de la combinaison d'une charge de travail d'écriture importante et de défaillances du service de stockage distribué Aurora.
+ Correction d'un problème de consommation élevée de l'UC en raison de la rotation du thread de purge en présence d'une transaction de longue durée. 
+ Correction d'un problème se produisant lorsqu'un schéma d'informations en cours d'exécution cherche à obtenir des informations sur les verrous dans des conditions de charge importante.
+ Correction d'un problème relatif à un processus de diagnostic pouvant, dans de rares cas, entraîner des blocages et des redémarrages/basculements d'écritures Aurora dans des nœuds de stockage.
+ Correction d'une condition où une table créée avec succès peut être supprimée pendant une récupération d'incident si l'incident s'est produit pendant le traitement d'une instruction `CREATE TABLE [if not exists]`.
+ Correction d'un problème de rupture de la procédure de rotation des journaux lorsque le journal général et le journal lent ne sont pas stockés sur disque par atténuation des risques au catalogue.
+ Correction d'un blocage se produisant lorsqu'un utilisateur crée une table temporaire au sein d'une fonction définie par l'utilisateur, puis utilise la fonction définie par l'utilisateur dans la liste de sélection de la requête.
+ Correction d'un incident qui se produisait lors de la relecture des événements GTID. GTID n'est pas pris en charge par Aurora MySQL.

## Intégration de correctifs de bogues MySQL :
<a name="AuroraMySQL.Updates.20161018.Fixes"></a>
+ Lors de l'abandon de tous les index sur une colonne à index multiples, InnoDB ne parvenait pas à bloquer une opération INDEX DEPOSER lorsqu'une contrainte de clé étrangère avait besoin d'un index. (Bogue n° 16896810)
+ Résoudre l'incident lié à l'ajout d'une contrainte de clé étrangère. (Bogue n° 16413976)
+ Correction d'un incident se produisant lors de la récupération d'un curseur dans une procédure stockée pendant l'analyse ou du vidage de la table. (Bogue n° 18158639)
+ Correction d'un bogue d'incrémentation automatique se produisant lorsqu'un utilisateur modifie une table pour changer la valeur AUTO\$1INCREMENT à moins de la valeur maximale de la colonne d'incrémentation automatique. (Bogue n° 16310273)

# Mises à jour du moteur de base de données Aurora MySQL : 20/09/2016 (version 1.7.1) (obsolète)
<a name="AuroraMySQL.Updates.20160920"></a>

**Version :** 1.7.1

## Améliorations
<a name="AuroraMySQL.Updates.20160920.Improvements"></a>
+ Résout un problème dans le cadre duquel un réplica Aurora se bloque si le cache de recherche en texte intégral InnoDB est plein.
+ Résout un problème dans le cadre duquel le moteur de base de données se bloque si un thread d'outil de traitement du pool de threads s'attend lui-même.
+ Résout un problème dans le cadre duquel un réplica Aurora se bloque si un verrouillage de métadonnées dans une table est à l'origine d'un blocage.
+ Résout un problème dans le cadre duquel le moteur de base de données se bloque en raison d'une condition de concurrence entre les deux threads d'outil de traitement dans le pool de threads.
+ Résout un problème dans le cadre duquel un basculement inutile se produit dans des conditions de charge importante si l'agent de surveillance ne détecte pas la progression des opérations d'écriture dans le sous-système de stockage distribué.

# Mises à jour du moteur de base de données Aurora MySQL : 30/08/2016 (version 1.7.0) (obsolète)
<a name="AuroraMySQL.Updates.20160830"></a>

**Version :** 1.7.0

## Nouvelles fonctions
<a name="AuroraMySQL.Updates.20160830.New"></a>
+ **Planificateur NUMA** – Le planificateur de tâches du moteur Aurora MySQL prend désormais en charge l'accès mémoire non uniforme (NUMA, Non-Uniform Memory Access). Cela réduit les conflits de sockets inter-CPU ce qui se traduit par des performances améliorées en termes de débit pour la classe d'instance de base de données `db.r3.8xlarge`.
+ **Fonctionnement de la lecture anticipée en parallèle de manière asynchrone en arrière-plan** – La lecture anticipée en parallèle a été repensée pour améliorer les performances en utilisant un thread dédié pour réduire les conflits entre threads.
+ **Construction d'index améliorée (mode Lab)** – La création d'index secondaires fonctionne désormais suivant un mode de construction de bas en haut, qui élimine les fractionnements de pages inutiles. Cela permet de réduire le temps de création d'un index ou de reconstruction d'une table. Cette fonction est désactivée par défaut et peut être activée en activant le mode Lab d'Aurora. Pour plus d'informations, consultez [Mode Lab Amazon Aurora MySQL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Updates.LabMode.html) dans le *Guide de l'utilisateur Amazon Aurora*.

## Améliorations
<a name="AuroraMySQL.Updates.20160830.Improvements"></a>
+ Correction d'un problème de lenteur de la connexion en cas d'augmentation du nombre de connexions demandées pour une instance.
+ Correction d'un problème où une défaillance générale se produisait si ALTER TABLE était exécutée sur une table partitionnée qui n'utilisait pas InnoDB.
+ Correction d'un problème où une lourde charge de travail en écriture pouvait entraîner un basculement.
+ Correction d'une assertion erronée qui entraînait une défaillance si RENAME TABLE était exécutée sur une table partitionnée.
+ Stabilité améliorée en cas de restauration d'une transaction pendant une importante charge de travail d'insertion.
+ Correction d'un problème où les index de recherche en texte intégral n'étaient pas fiables sur un réplica Aurora.

## Intégration de correctifs de bogues MySQL.
<a name="AuroraMySQL.Updates.20160830.BugFixes"></a>
+ Amélioration de l'évolutivité par partitionnement du verrou LOCK\$1grant. (Port WL \$18355)
+ L'ouverture du curseur sur SELECT dans la procédure stockée entraîne une erreur de segmentation. (Bogue de port n° 16499751)
+ MySQL donne un faux résultat dans certains cas d'utilisation. (Bogue n° 11751794)
+ Défaillance générale dans GET\$1SEL\$1ARG\$1FOR\$1KEYPART – causée par le correctif du bogue 11751794. (Bogue n° 16208709)
+ Mauvais résultats pour une requête simple avec GROUP BY. (Bogue n° 17909656)
+ Lignes supplémentaires sur requête semi-jointure avec prédicats de plage. (Bogue n° 16221623)
+ L'ajout d'une clause ORDER BY à la suite d'une sous-requête IN pourrait entraîner le renvoi de lignes en double. (Bogue n° 16308085)
+ Défaillance générale pour une requête avec balayage large pour GROUP BY, MySQL. (Bogue n° 16222245)
+ L'analyse d'index large avec prédicat d'entier à quota renvoie des données aléatoires. (Bogue n° 16394084)
+ Si l'optimiseur utilisait une analyse d'index large, le serveur pouvait quitter pendant la tentative de création d'une table temporaire. (Bogue n° 16436567)
+ Alors qu'elle ne devrait pas le faire, la fonction COUNT(DISTINCT) comptait les valeurs NULL lorsque l'optimiseur utilisait l'analyse d'index large. (Bogue n° 17222452)
+ Si une requête utilisait à la fois la fonction MIN()/MAX() et la fonction aggregate\$1function(DISTINCT) (par exemple, SUM(DISTINCT)) et était exécutée avec l'analyse d'index large, les valeurs produites par la fonction MIN()/MAX() étaient incorrectement définies. (Bogue n° 17217128)

# Mises à jour du moteur de base de données Aurora MySQL : 01/06/2016 (version 1.6.5) (obsolète)
<a name="AuroraMySQL.Updates.20160601"></a>

**Version :** 1.6.5

## Nouvelles fonctions
<a name="AuroraMySQL.Updates.20160601.New"></a>
+ **Stockage efficace des journaux binaires** – Le stockage efficace des journaux binaires est maintenant activé par défaut pour tous les clusters de bases de données Aurora MySQL et n'est pas configurable. Le stockage efficace des journaux binaires a été commercialisé avec la mise à jour d'avril 2016. Pour de plus amples informations, veuillez consulter [Mises à jour du moteur de base de données Aurora MySQL : 06/04/2016 (version 1.6) (obsolète)](AuroraMySQL.Updates.20160406.md).

## Améliorations
<a name="AuroraMySQL.Updates.20160601.Improvements"></a>
+ Stabilité améliorée pour les réplicas Aurora lorsque l'instance principale rencontre une lourde charge de travail. 
+ Stabilité améliorée pour les réplicas Aurora lorsque vous exécutez des requêtes sur les tables partitionnés et les tables dont le nom comporte des caractères spéciaux. 
+ Correction des problèmes de connexion en cas d'utilisation de connexion sécurisée.

## Intégration de correctifs de bogues MySQL.
<a name="AuroraMySQL.Updates.20160601.BugFixes"></a>
+ SLAVE CAN'T CONTINUE REPLICATION AFTER MASTER'S CRASH RECOVERY (Port Bug \$117632285)

# Mises à jour du moteur de base de données Aurora MySQL : 06/04/2016 (version 1.6) (obsolète)
<a name="AuroraMySQL.Updates.20160406"></a>

**Version :** 1.6

Cette mise à jour inclut les améliorations suivantes :

## Nouvelles fonctions
<a name="AuroraMySQL.Updates.20160406.New"></a>
+ **Lecture anticipée parallèle** – La lecture anticipée parallèle est désormais activée par défaut pour tous les clusters de bases de données Aurora MySQL et n'est pas configurable. La lecture anticipée parallèle a été commercialisée avec la mise à jour de décembre 2015. Pour plus d'informations, consultez [Mises à jour du moteur de base de données Aurora MySQL : 03/12/2015 (version 1.4) (obsolète)](AuroraMySQL.Updates.20151203.md).

  En plus de permettre la lecture anticipée parallèle par défaut, cette version inclut les améliorations suivantes à la lecture anticipée parallèle :
  + Logique améliorée pour que la lecture anticipée parallèle soit moins agressive, ce qui est utile lorsque votre cluster DB rencontre de nombreuses charges de travail parallèles.
  + Stabilité améliorée des tables plus petites.
+ **Stockage efficace des journaux binaires (mode Lab)** – Les fichiers journaux binaires MySQL sont désormais stockés plus efficacement dans Aurora MySQL. La nouvelle implémentation de stockage permet de supprimer les fichiers journaux binaires beaucoup plus tôt et améliore les performances système d'une instance dans un cluster de bases de données Aurora MySQL qui est un maître de réplication de journal binaire.

  Pour activer le stockage efficace des journaux binaires, affectez au paramètre `aurora_lab_mode` la valeur `1` dans le groupe de paramètres pour votre instance principale ou votre réplica Aurora. Le paramètre `aurora_lab_mode` est un paramètre au niveau d'une instance qui figure par défaut dans le groupe de paramètres `default.aurora5.6`. Pour plus d'informations sur la modification d'un groupe de paramètres de base de données, consultez [Modification de paramètres dans un groupe de paramètres de bases de données](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_WorkingWithParamGroups.html#USER_WorkingWithParamGroups.Modifying) dans le *Guide de l'utilisateur Amazon Aurora*. Pour plus d'informations sur les groupes de paramètres et Aurora MySQL, consultez [Paramètres de configuration d'Aurora MySQL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Reference.html#AuroraMySQL.Reference.ParameterGroups) dans le *Guide de l'utilisateur Amazon Aurora*.

  Activez uniquement le stockage efficace des journaux binaires pour des instances dans un cluster de bases de données Aurora MySQL qui sont des instances du maître de réplication de journaux binaires MySQL.
+ **Variable système AURORA\$1VERSION** – Vous pouvez maintenant obtenir la version Aurora de votre cluster de bases de données Aurora MySQL en recherchant la variable système `AURORA_VERSION`.

  Pour obtenir la version d'Aurora, utilisez l'une des requêtes suivantes :

  ```
  select AURORA_VERSION();
  select @@aurora_version;
  show variables like '%version';
  ```

  Vous pouvez également voir la version d'Aurora AWS Management Console lorsque vous modifiez un cluster de base de données, ou en appelant la [describe-db-engine-versions](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-engine-versions.html) AWS CLI commande ou l'opération d'API [Describe DBEngine Versions](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBEngineVersions.html).
+ **Métrique d'utilisation de la mémoire du gestionnaire de verrous** – Les informations sur l'utilisation de la mémoire du gestionnaire de verrous sont désormais disponibles sous la forme d'une métrique.

  Pour obtenir la métrique d'utilisation de la mémoire du gestionnaire de verrous, utilisez l'une des requêtes suivantes :

  ```
  show global status where variable_name in ('aurora_lockmgr_memory_used');
  select * from INFORMATION_SCHEMA.GLOBAL_STATUS where variable_name in ('aurora_lockmgr_memory_used');
  ```

## Améliorations
<a name="AuroraMySQL.Updates.20160406.Improvements"></a>
+ Stabilité améliorée pendant la récupération des journaux binaires et de transaction XA.
+ Correction d'un problème de mémoire résultant d'un grand nombre de connexions.
+ Amélioration de la précision dans les métriques suivantes : `Read Throughput`,` Read IOPS`, `Read Latency`, `Write Throughput`, `Write IOPS`, `Write Latency` et `Disk Queue Depth`.
+ Correction d'un problème de stabilité entraînant un démarrage lent pour des instances importantes après un incident.
+ Amélioration de la concurrence dans le dictionnaire de données concernant les mécanismes de synchronisation et l'expulsion du cache. 
+ Améliorations de la stabilité et des performances pour les réplicas Aurora :
  + Correction d'un problème de stabilité pour les réplicas Aurora lors de charges de travail en écriture intensive ou à forte densité pour l'instance principale.
  + Amélioration du retard du réplica pour les instances db.r3.4xlarge et db.r3.8xlarge. 
  + Amélioration des performances en réduisant les conflits entre les applications d'enregistrements de journal et les lectures simultanées sur un réplica Aurora.
  + Correction d'un problème d'actualisation des statistiques concernant les réplicas Aurora pour les statistiques nouvellement créés ou mises à jour.
  + Amélioration de la stabilité pour les réplicas Aurora lorsqu'il existe de nombreuses transactions sur l'instance principale et des lectures simultanées sur les réplicas Aurora sur les mêmes données.
  + Amélioration de la stabilité pour les réplicas Aurora lorsque de l'exécution des instructions `UPDATE` et `DELETE` avec des instructions `JOIN`.
  + Amélioration la stabilité des réplicas Aurora lors de l'exécution d'instructions `INSERT ... SELECT`.

## Intégration de correctifs de bogues MySQL.
<a name="AuroraMySQL.Updates.20160406.BugFixes"></a>
+ BACKPORT Bug \$118694052 FIX FOR ASSERTION `\$1M\$1ORDERED\$1REC\$1BUFFER' FAILED TO 5.6 (Port Bug \$118305270) 
+ SEGV IN MEMCPY(), HA\$1PARTITION::POSITION (Port Bug \$1 18383840)
+ WRONG RESULTS WITH PARTITIONING,INDEX\$1MERGE AND NO PK (Port Bug \$1 18167648)
+ FLUSH TABLES FOR EXPORT: ASSERTION IN HA\$1PARTITION::EXTRA (Port Bug \$1 16943907)
+ SERVER CRASH IN VIRTUAL HA\$1ROWS HANDLER::MULTI\$1RANGE\$1READ\$1INFO\$1CONST (Port Bug \$1 16164031)
+ RANGE OPTIMIZER CRASHES IN SEL\$1ARG::RB\$1INSERT() (Port Bug \$1 16241773)

# Mises à jour du moteur de base de données Aurora MySQL : 11/01/2016 (version 1.5) (obsolète)
<a name="AuroraMySQL.Updates.20160111"></a>

**Version :** 1.5

Cette mise à jour inclut les améliorations suivantes :

## Améliorations
<a name="AuroraMySQL.Updates.20160111.Improvements"></a>
+ Correction d'une pause de 10 s des opérations d'écriture pour les instances inactives au cours des déploiements du stockage Aurora.
+ La lecture anticipée logique fonctionne à présent quand `innodb_file_per_table` a la valeur `No`. Pour plus d'informations sur la lecture anticipée logique, consultez [Mises à jour du moteur de base de données Aurora MySQL : 03/12/2015 (version 1.4) (obsolète)](AuroraMySQL.Updates.20151203.md).
+ Correction de problèmes liés à la reconnexion des réplicas Aurora à l'instance principale. Cette amélioration corrige également un problème qui se posait lorsque vous spécifiiez une valeur importante pour le paramètre `quantity` dans le cadre du test des échecs des réplicas Aurora à l'aide de requêtes d'injection d'erreurs. Pour plus d'informations, consultez [Test d'une défaillance d'un réplica Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Managing.FaultInjectionQueries.html#AuroraMySQL.Managing.FaultInjectionQueries.ReplicaFailure) dans le *Guide de l'utilisateur Amazon Aurora*.
+ Amélioration de la supervision des retards et des redémarrages des réplicas Aurora.
+ Correction d'un problème qui entraînait le retard, la désinscription puis le redémarrage d'un réplica Aurora.
+ Correction d'un problème qui se posait lors de l'exécution de la commande `show innodb status` au cours d'un interblocage.
+ Correction d'un problème de basculement pour les instances volumineuses lors d'un débit élevé d'écriture.

## Intégration de correctifs de bogues MySQL.
<a name="AuroraMySQL.Updates.20160111.BugFixes"></a>
+ Traitement d'un correctif incomplet dans la recherche en texte intégral MySQL affectant les tables dans lesquelles le nom de base de données commence par un chiffre. (Bogue de port n° 17607956) 

# Mises à jour du moteur de base de données Aurora MySQL : 03/12/2015 (version 1.4) (obsolète)
<a name="AuroraMySQL.Updates.20151203"></a>

**Version :** 1.4

Cette mise à jour inclut les améliorations suivantes :

## Nouvelles fonctions
<a name="AuroraMySQL.Updates.20151203.New"></a>
+ **Insertion rapide** – Accélère les insertions parallèles triées par leur clé primaire. Pour plus d'informations, consultez [Améliorations des performances Amazon Aurora MySQL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.AuroraMySQL.Overview.html#Aurora.AuroraMySQL.Performance) dans le *Guide de l'utilisateur Amazon Aurora*. 
+ **Performances de lecture des grands ensembles de données** – Aurora MySQL détecte automatiquement une lourde charge de travail d'I/O et démarre plus de threads afin d'améliorer les performances du cluster de bases de données. Le planificateur Aurora examine l'activité d'I/O et décide d'ajuster dynamiquement le nombre optimal de threads dans le système en l'adaptant rapidement en fonction des charges de travail exigeantes en I/O et exigeantes en UC, sans frais généraux importants.
+ **Lecture anticipée parallèle** – Améliore les performances des analyses de l'arbre B (B-Tree) qui sont trop grandes pour la mémoire disponible sur votre instance principale ou votre réplica Aurora (y compris les requêtes de plage). La lecture anticipée parallèle détecte automatiquement les modèles de lecture de page et récupère au préalable les pages dans le cache des tampons pour anticiper le moment où elles seront requises. La lecture anticipée parallèle traite plusieurs tables au même moment, dans la même transaction.

## Améliorations :
<a name="AuroraMySQL.Updates.20151203.Improvements"></a>
+ Correction des problèmes de brève disponibilité de base de données Aurora au cours des déploiements du stockage Aurora. 
+ Application correcte de la limite `max_connection`.
+ Amélioration de la purge des fichiers journaux binaires quand Aurora est l'entité principale de journalisation et que la base de données redémarre après une lourde charge de données. 
+ Correction de problèmes de gestion de mémoire avec le cache des tables. 
+ Ajout de la prise en charge des très grandes pages dans le cache des tampons de mémoire partagée pour accélérer la récupération. 
+ Correction d'un problème lié à non-initialisation du stockage local des threads. 
+ Autorisation de 16 000 connexions par défaut. 
+ Pool de threads dynamiques pour les charges de travail exigeantes en I/O. 
+ Correction d'un problème d'invalidation correcte des vues impliquant UNION dans le cache de requêtes. 
+ Correction d'un problème de stabilité avec le thread stats du dictionnaire. 
+ Correction d'une fuite de mémoire dans le sous-système du dictionnaire associée à l'expulsion du cache. 
+ Correction d'un problème de latence de lecture élevée sur les réplicas Aurora lorsque la charge d'écriture est très faible sur le maître. 
+ Correction de problèmes de stabilité sur les réplicas Aurora lors de la réalisation d'opérations sur les tables partitionnées DDL telles que ALTER TABLE... REORGANIZE PARTITION sur le maître. 
+ Correction de problèmes de stabilité sur les réplicas Aurora lors d'une croissance du volume. 
+ Correction d'un problème de performance pour les analyses sur les index non organisés en cluster sur les réplicas Aurora. 
+ Correction d'un problème de stabilité entraînant un retard des réplicas Aurora et leur désinscription et redémarrage éventuels. 

## Intégration de correctifs de bogues MySQL.
<a name="AuroraMySQL.Updates.20151203.BugFixes"></a>
+ SEGV dans FTSPARSE(). (Bogue n° 16446108)
+ Le dictionnaire de données InnoDB n'est pas mis à jour lorsque la colonne est renommée. (Bogue n° 19465984)
+ Incident FTS après qu'une table a été renommée dans une autre base de données. (Bogue n° 16834860)
+ L'échec de la préparation du déclenchement sur les tables tronquées entraîne l'erreur 1054. (Bogue n° 18596756)
+ Des modifications des métadonnées peuvent entraîner des problèmes de déclenchement d'exécution. (Bogue n° 18684393)
+ La matérialisation n'est pas choisie pour le champ UTF8 VARCHAR long. (Bogue n° 17566396)
+ Plan d'exécution médiocre pour ORDER BY avec la limite X. (Bogue n°16697792)
+ Bogue de rétroportage n° 11765744 pour 5.1, 5.5 et 5.6. (Bogue n° 17083851)
+ Problème de mutex dans SQL/SQL\$1SHOW.CC entraînant. SIG6 Source probable FILL\$1VARIABLES. (Bogue n° 20788853)
+ Bogue de rétroportage n° 18008907 pour les versions 5.5\$1. (Bogue n° 18903155)
+ Adaptation d'un correctif pour une erreur de dépassement de capacité de pile dans MySQL 5.7. (Bogue n° 19678930)

# Mises à jour du moteur de base de données Aurora MySQL : 16/10/2015 (versions 1.2, 1.3) (obsolète)
<a name="AuroraMySQL.Updates.20151016"></a>

**Versions :** 1.2, 1.3

Cette mise à jour inclut les améliorations suivantes :

## Correctifs
<a name="AuroraMySQL.Updates.20151016.Fixes"></a>
+  out-of-memoryProblème résolu dans le nouveau gestionnaire de verrous avec des transactions de longue durée
+ Résolution d'une faille de sécurité lors de la réplication avec des bases de données MySQL non-RDS
+ Mise à jour pour garantir que les écritures de quorum sont réessayées correctement en cas de défaillances de stockage
+ Mise à jour pour signaler plus précisément un retard du réplica
+ Amélioration de la performance en réduisant les conflits lorsque de nombreuses transactions simultanées essaient de modifier une même ligne
+ Résolution de l'invalidation du cache de requêtes pour les vues qui sont créées en joignant deux tables
+ Désactivation du cache de requêtes pour les transactions avec isolation `UNCOMMITTED_READ`

## Améliorations
<a name="AuroraMySQL.Updates.20151016.Improvements"></a>
+ Meilleures performances pour les requêtes lentes de catalogue sur les caches à chaud
+ Amélioration de la simultanéité dans les statistiques de dictionnaire
+ Meilleure stabilité pour le nouveau gestionnaire de ressources du cache de requêtes, la gestion de l'extension, les fichiers stockés dans le stockage intelligent Amazon Aurora et les écritures par lots des enregistrements de journaux

## Intégration de correctifs de bogues MySQL.
<a name="AuroraMySQL.Updates.20151016.BugFixes"></a>
+ L'arrêt d'une requête dans innodb entraîne finalement un incident avec une assertion. (Bogue n° 1608883)
+ Pour un échec lors de la création d'un nouveau thread pour le planificateur d'événement, l'exécution d'un événement ou une nouvelle connexion, aucun message n'a été consigné dans le journal des erreurs. (Bogue n° 16865959)
+ Si une connexion a changé la base de données par défaut alors que simultanément une autre connexion a exécuté SHOW PROCESSLIST, la seconde connexion a pu accéder à de la mémoire non valide lors de la tentative d'affichage de la mémoire de base de données par défaut de la première connexion. (Bogue n° 11765252)
+ PURGE BINARY LOGS, par conception, ne supprime pas les fichiers journaux binaires qui sont utilisés ou actifs, mais n'a pas fourni aucun avis lorsque cela s'est produit. (Bogue n° 13727933)
+ Pour certaines instructions, des fuites de mémoire pouvaient être générées lorsque l'optimiseur supprimait des clauses de sous-requête superflues. (Bogue n° 15875919) 
+ Pendant l'arrêt, le serveur pouvait essayer de verrouiller un mutex non initialisé. (Bogue n° 16016493)
+ Une instruction préparée qui utilisait GROUP\$1CONCAT() et une clause ORDER BY qui nommait plusieurs colonnes pouvait entraîner l'arrêt du serveur. (Bogue n° 16075310)
+ L'instrumentation du schéma de performance était manquante pour les threads de travailleur de réplicas. (Bogue n° 16083949)
+ `STOP SLAVE` pouvait provoquer un blocage lorsqu'il était émis en même temps qu'une instruction telle que SHOW STATUS ayant extrait les valeurs pour une ou plusieurs des variables d'état `Slave_retried_transactions`, `Slave_heartbeat_period`, `Slave_received_heartbeats`, `Slave_last_heartbeat` ou `Slave_running`. (Bogue n° 16088188)
+ Une requête en texte intégral utilisant le mode booléen pouvait ne retourner aucun résultat dans certains cas où le terme recherché était une phrase entre guillemets. (Bogue n° 16206253)
+ La tentative de l'optimiseur de supprimer les clauses de sous-requête redondantes générait une assertion lors de l'exécution d'une instruction préparée avec une sous-requête dans la clause ON d'une jointure dans une sous-requête. (Bogue n° 16318585)
+ GROUP\$1CONCAT instable, incident dans ITEM\$1SUM::CLEAN\$1UP\$1AFTER\$1REMOVAL. (Bogue n° 16347450)
+ Une tentative de remplacement de la liste de mots vides de recherche en texte intégral InnoDB par défaut en créant une table InnoDB avec la même structure que INFORMATION\$1SCHEMA.INNODB\$1FT\$1DEFAULT\$1STOPWORD générait une erreur. (Bogue n° 16373868)
+ Après que le thread client sur un travailleur a effectué une opération FLUSH TABLES WITH READ LOCK suivie de quelques mises à jour sur le maître, le travailleur restait bloqué lors de l'exécution de `SHOW SLAVE STATUS`. (Bogue n° 16387720)
+ Lors de l'analyse d'une chaîne de recherche délimitée telle que « abc-def » dans une recherche en texte intégral, InnoDB utilise à présent les mêmes délimiteurs de mot que MyISAM. (Bogue n° 16419661)
+ Incident dans FTS\$1AST\$1TERM\$1SET\$1WILDCARD. (Bogue n° 16429306)
+ SEGFAULT dans FTS\$1AST\$1VISIT() pour le test RQG de recherche en texte intégral. (Bogue n° 16435855)
+ Pour les versions de débogage, lorsque l'optimiseur supprimait un Item\$1ref pointant sur une sous-requête, il entraînait un arrêt du serveur. (Bogue n° 16509874)
+ La recherche en texte intégral sur des tables InnoDB échouait lors de recherches d'expressions littérales combinées aux opérateurs \$1 ou -. (Bogue n° 16516193)
+ `START SLAVE`a échoué lorsque le serveur a été démarré avec les options -- master-info-repository =TABLE relay-log-info-repository =TABLE et avec autocommit défini sur 0, ainsi que. `--skip-slave-start` (Bogue n° 16533802)
+ Les résultats d'une recherche en texte intégral InnoDB très étendue pouvaient consommer une quantité excessive de mémoire. (Bogue n° 16625973)
+ Dans les versions de débogage, une assertion pouvait survenir dans OPT\$1CHECK\$1ORDER\$1BY lors de l'utilisation de données binaires directement dans une chaîne de recherche, car les données binaires peuvent inclure des octets NULL et d'autres caractères non significatifs. (Bogue n° 16766016)
+ Pour certaines instructions, des fuites de mémoire pouvaient être générées lorsque l'optimiseur supprimait des clauses de sous-requête superflues. (Bogue n° 16807641)
+ Il était possible de générer un interblocage après l'émission de FLUSH TABLES WITH READ LOCK en émettant `STOP SLAVE` dans une nouvelle connexion à l'esclave, puis en émettant `SHOW SLAVE STATUS` à l'aide de la connexion d'origine. (Bogue n° 16856735)
+ GROUP\$1CONCAT() avec un séparateur non valide pouvait causer un arrêt du serveur. (Bogue n° 16870783)
+ Le serveur a effectué un verrouillage excessif sur les mutex LOCK\$1active\$1mi et active\$1mi->rli->data\$1lock pour toute instruction SHOW STATUS LIKE 'modèle', même lorsque le modèle ne correspond pas aux variables d'état qui utilisent ces mutex (`Slave_heartbeat_period`, `Slave_last_heartbeat`, `Slave_received_heartbeats`, `Slave_retried_transactions`, `Slave_running`). (Bogue n° 16904035)
+ Une recherche en texte intégral utilisant le modificateur IN BOOLEAN MODE entraînait un échec d'assertion. (Bogue n° 16927092)
+ Une recherche en texte intégral sur les tables InnoDB échouait pour les recherches qui utilisaient l'opérateur booléen \$1. (Bogue n° 17280122)
+ Interblocage quadridirectionnel : zombies, purge des journaux binaires, show processlist, show binlogs. (Bogue n° 17283409)
+ Lorsqu'un thread SQL qui attendait un verrou de validation était supprimé et redémarré, une transaction était ignorée sur le travailleur. (Bogue n° 17450876)
+ Un échec de recherche en texte intégral InnoDB survenait en raison d'un jeton « non terminé ». La chaîne et la longueur de chaîne devaient être transmises pour la comparaison de chaîne. (Bogue n° 17659310)
+ Un grand nombre de tables InnoDB partitionnées pouvaient consommer beaucoup plus de mémoire lorsqu'elles étaient utilisées dans MySQL 5.6 ou 5.7 que la mémoire utilisée par les mêmes tables dans les versions précédentes du serveur MySQL. (Bogue n° 17780517)
+ Pour les requêtes en texte intégral, ne pas vérifier si num\$1token était inférieur à max\$1proximity\$1item pouvait entraîner une assertion. (Bogue n° 18233051)
+ Certaines requêtes relatives aux tables INFORMATION\$1SCHEMA TABLES et COLUMNS pouvaient entraîner une utilisation excessive de mémoire lorsque de nombreuses tables InnoDB étaient vides. (Bogue n° 18592390)
+ Lors de la validation d'une transaction, un indicateur est désormais utilisé pour vérifier si un thread a été créé, plutôt que la vérification du thread lui-même, qui utilise plus de ressources, en particulier lors de l'exécution du serveur avec master\$1info\$1repository=TABLE. (Bogue n° 18684222)
+ Si un thread client sur un travailleur exécutait FLUSH TABLES WITH READ LOCK alors que le maître exécutait une commande DML, l'exécution de `SHOW SLAVE STATUS` dans le même client se bloquait, entraînant un interblocage. (Bogue n° 19843808)
+ Le tri selon un résultat GROUP\$1CONCAT() pouvait causer l'arrêt du serveur. (Bogue n° 19880368)

# Mises à jour du moteur de base de données Aurora MySQL : 24/08/2015 (version 1.1) (obsolète)
<a name="AuroraMySQL.Updates.20150824"></a>

**Version :** 1.1

Cette mise à jour inclut les améliorations suivantes :
+ Améliorations de la stabilité de réplication lors de la réplication avec une base de données MySQL (réplication des journaux binaires). Pour plus d'informations sur la réplication d'Aurora MySQL avec MySQL, consultez [Réplication avec Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.Replication.html) dans le *Guide de l'utilisateur Amazon Aurora*. 
+ Limite de 1 gigaoctet (Go) sur la taille des journaux relais accumulés pour un cluster de bases de données Aurora MySQL qui est un travailleur de réplication. Ceci améliore la gestion des fichiers pour les clusters DB Aurora.
+ Améliorations de la stabilité dans les zones de lecture anticipée, relations de clé étrangère récursives et réplication Aurora.
+ Intégration de correctifs de bogues MySQL.
  + Les bases de données InnoDB dont les noms commencent par un chiffre entraînent une erreur d'analyse de la recherche de texte intégral (FTS). (Bogue n° 17607956)
  + Les recherches de texte intégral InnoDB échouent dans les bases de données dont les noms commencent par un chiffre. (Bogue n° 17161372)
  + Pour les bases de données InnoDB sous Windows, l'ID d'objet de la recherche de texte intégral (FTS) n'est pas au format hexadécimal attendu. (Bogue n° 16559254)
  + Une régression de code présentée dans MySQL 5.6 a impacté de manière négative les performances DROP TABLE et ALTER TABLE. Cela pourrait entraîner une baisse des performances entre MySQL Server 5.5.x et 5.6.x. (Bogue n° 16864741)
+ Journalisation simplifiée pour réduire la taille des fichiers journaux et le volume de stockage qu'ils requièrent.