Mises à jour du moteur de base de données Aurora MySQL du 19/11/2020 (version 1.22.3) (obsolète)

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.

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

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

Cette version est désignée comme version de support à long terme (LTS). Pour plus d'informations, consultez Versions Long-Term Support (LTS) d'Aurora MySQL dans le Guide de l'utilisateur Amazon Aurora.

En cas de question ou de doute, l'équipe AWS Support est disponible sur les forums de la communauté et via AWS Support. Pour plus d'informations, consultez Entretien d'un cluster de base de données Amazon Aurora dans le Guide de l'utilisateur Amazon Aurora.

Améliorations

Correctifs de sécurité :

Correctifs et autres améliorations visant à peaufiner la gestion dans un environnement géré. Correctifs de CVE supplémentaires ci-dessous :

• CVE-2020-14559

• CVE-2020-14539

• CVE-2020-2579

• CVE-2020-2812

• CVE-2020-2780

• 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

• 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 sur le maître à une colonne BIGINT 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_type_conversions. Pour en savoir plus, consultez la section Row-based replication: attribute promotion and demotion, 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_key_checks=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 sur une table avec des dépendances de clé étrangère déclenchait une assertion.