Mises à jour du moteur de base de données Aurora MySQL du 21/01/2022 (version 2.10.2) (obsolète)

Version : 2.10.2

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

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.*.

Vous pouvez mettre à niveau un cluster de bases de données Aurora MySQL 2.* existant vers Aurora MySQL 2.10.0. Pour les clusters exécutant Aurora MySQL version 1, vous pouvez mettre à niveau un cluster Aurora MySQL 1.23 existant ou d'une version ultérieure directement vers la version 2.10.0. Vous pouvez restaurer un instantané à partir d'une version Aurora MySQL actuellement prise en charge dans Aurora MySQL 2.10.0.

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.

Note

Pour plus d'informations sur la mise à niveau de votre cluster de base de données Aurora MySQL, consultez Mise à niveau de la version mineure ou du niveau de correctif d'un cluster de bases de données Aurora MySQL dans le Guide de l'utilisateur Amazon Aurora.

Améliorations

Problèmes de sécurité et CVE corrigés ci-dessous :

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

• CVE-2021-36222

• CVE-2021-35624

• CVE-2021-35604

• CVE-2021-22926

• CVE-2021-2390

• CVE-2021-2389

• CVE-2021-2385

• CVE-2021-2356

• CVE-2019-17543

• CVE-2019-2960

Améliorations générales :

• Ajout d'une optimisation des performances pour aider à réduire la latence I/O de la base de données dans les classes d'instances 24XL.

• Ajout de la prise en charge des chiffrements SSL ECDHE. Pour plus d'informations sur la configuration de vos clients pour utiliser ces chiffrements SSL, veuillez consulter la documentation MySQL suivante : encrypted connection protocols ciphers

• Correction de problèmes de sécurité liés à l'intégration d'Aurora MySQL avec d'autres services AWS comme Amazon S3, Amazon ML et AWS Lambda.

• Correction d'un problème susceptible d'entraîner l'échec du redémarrage d'une instance de base de données lorsque la base de données comporte environ plus d'1 Go de combinaisons d'utilisateurs et de privilèges.

• Correction d'un problème lié à une requête parallèle susceptible d'entraîner le renvoi par la base de données de groupements ou d'ordres de tri incorrects lors de l'exécution de requêtes avec une clause GROUP BY et une clause WHERE contenant un prédicat de plage.

• Correction d'un problème entraînant l'inaccessibilité des tables general_log et slow_log après une mise à niveau de la version majeure sur place d'Aurora MySQL 1.x (compatible avec MySQL 5.6) vers Aurora MySQL 2.x (compatible avec MySQL 5.7).

• Correction d'un problème entraînant, dans de rares cas, le redémarrage de l'instance de base de données lorsque les tables innodb_trx, innodb_locks ou innodb_lockwaits sont interrogées alors que la base de données est soumise à une charge de travail importante. Les outils de surveillance tels que Performance Insights peuvent interroger ces tables.

• Correction d'un problème où la valeur d'une colonne TIMESTAMP d'une ligne existante est mise à jour avec l'horodatage le plus récent lorsque toutes les conditions suivantes sont remplies :

  1. Il existe un déclencheur pour la table.

  2. Une instruction INSERT est exécutée sur la table qui comporte une clause ON DUPLICATE KEY UPDATE.

  3. La ligne insérée provoque une violation de valeur en double dans un index UNIQUE ou CLÉ PRIMAIRE.

  4. Une ou plusieurs colonnes sont de type TIMESTAMP et affichent une valeur par défaut de CURRENT_TIMESTAMP.

• Correction d'un problème qui, dans de rares cas, pouvait empêcher un réplica de journal binaire de se connecter à une instance dont le journal binaire était activé.

• Correction d'un problème où, dans de rares conditions, les transactions n'étaient pas en mesure d'être validées lors de l'exécution sur une instance dont le journal binaire était activé.

• Correction d'un problème qui empêchait d'établir de nouvelles connexions à une instance dont le journal binaire était activé.

• Correction d'un problème qui pouvait entraîner une journalisation interne excessive lors d'une tentative de correctif sans temps d'arrêt et redémarrage sans interruption provoquant le remplissage du stockage local.

• Correction d'un problème entraînant l'arrêt d'un réplica de journal binaire avec une erreur HA_ERR_FOUND_DUPP_KEY lors de la réplication de certaines instructions DDL et DCL. Le problème se produit lorsque l'instance source est configurée avec un format de journalisation binaire MIXED et un niveau d'isolation READ COMMITTED ou READ UNCOMMITTED.

• Correction d'un problème où le thread d'I/O de réplication du journal binaire n'était pas en mesure de suivre l'instance principale lorsque la réplication multithread était activée.

• Correction d'un problème où, dans de rares conditions, un nombre élevé de connexions actives à l'instance de base de données pouvait entraîner un signalement incorrect de la métrique CloudWatch CommitLatency.

• Correction d'un problème qui entraînait le remplissage du stockage local sur les instances Graviton lors de l'exécution de LOAD FROM S3 ou SELECT INTO S3.

• Correction d'un problème qui pouvait entraîner des résultats de requête erronés lors de l'interrogation d'une table avec une clé étrangère si les deux conditions suivantes étaient réunies :

  1. Cache de requête activé

  2. Une transaction comportant une suppression ou une mise à jour en cascade sur cette table est annulée

• Correction d'un problème susceptible, dans de rares conditions, d'entraîner le redémarrage des instances de lecteur Aurora. Le risque que ce problème se produise augmente à mesure que le nombre d'annulations de transactions augmente.

• Correction d'un problème où le nombre d'occurrences du mutex « LOCK_epoch_id_master » dans le schéma de performances augmente lorsqu'une session est ouverte et fermée.

• Correction d'un problème susceptible d'entraîner un nombre croissant de blocages pour les charges de travail comportant de nombreuses transactions mettant à jour simultanément le même jeu de lignes.

• Correction d'un problème susceptible, dans de rares conditions, d'entraîner le redémarrage des instances lorsque le volume de la base de données augmente jusqu'à un multiple de 160 Go.

• Correction d'un problème lié à la requête parallèle susceptible d'entraîner le redémarrage de la base de données lors de l'exécution d'instructions SQL avec une clause LIMIT.

• Correction d'un problème susceptible, dans de rares conditions, d'entraîner le redémarrage de l'instance de base de données lors de l'utilisation de transactions XA avec le niveau d'isolation READ COMMITTED.

• Correction d'un problème où, après le redémarrage d'une instance Aurora en lecture, celle-ci pouvait redémarrer à nouveau si elle comportait une charge de travail DDL lourde pendant le redémarrage.

• Correction d'un problème lié au signalement incorrect d'un retard de réplication de lecteur Aurora.

• Correction d'un problème qui, dans de rares conditions, peut entraîner le redémarrage d'une instance d'enregistreur en cas d'échec d'une vérification de l'intégrité des données en mémoire.

• Correction d'un problème susceptible, dans de rares conditions, d'afficher à tort le graphique « Charge de base de données » dans les sessions Performance Insights (PI) comme utilisant activement l'UC, même si les sessions ont terminé le traitement et sont inactives.

• Correction d'un problème qui, dans de rares conditions, pouvait entraîner le redémarrage du serveur de base de données lorsqu'une requête était traitée à l'aide de la requête parallèle.

• Correction d'un problème susceptible, dans de rares conditions, d'entraîner le redémarrage de l'instance d'enregistreur dans le cluster de base de données globale en raison d'une condition de concurrence lors de la réplication de base de données globale.

• Correction d'un problème pouvait survenir lors du redémarrage d'une instance de base de données, susceptible d'entraîner plusieurs redémarrages.

Intégration de correctifs de bogues de l'édition MySQL Community Edition

• Correction d'un problème dans InnoDB où une erreur de code liée aux statistiques de table déclenchait une assertion dans le fichier source dict0stats.cc. (Bogue n°24585978)

• Correction d'un problème où un index secondaire sur une colonne virtuelle devenait corrompu lorsque l'index était créé en ligne. Pour les instructions UPDATE, nous corrigeons ce problème comme suit : si la valeur de colonne virtuelle du registre d'index est définie sur NULL, nous générons cette valeur à partir du registre d'index du cluster. (Bogue n°30556595)

• Correction d'un problème dans InnoDB où la suppression de lignes marquées permettait d'acquérir un verrou de lecture externe avant la fin d'une restauration partielle. Le verrou de lecture externe empêchait la conversion d'un verrou implicite en verrou explicite pendant la restauration partielle, provoquant un échec d'assertion. (Bogue n°29195848)

• Correction d'un problème où les noms d'hôtes vides dans les comptes pouvaient entraîner un comportement erroné du serveur. (Bogue n°28653104)

• Correction d'un problème dans InnoDB où une interruption de requête pendant un temps d'attente de verrouillage provoquait une erreur. (bogue n°28068293)

• Correction d'un problème de réplication pour lequel les transactions entrelacées pouvaient parfois bloquer l'applicateur esclave lorsque le niveau d'isolement des transactions était défini sur REPEATABLE READ. (Bogue n° 25040331)

• Correction d'un problème qui pouvait entraîner le blocage des réplicas de journaux binaires en raison du délai d'attente du verrouillage. (Bogue n°27189701)

Comparaison avec Aurora MySQL version 1

Les fonctionnalités Amazon Aurora MySQL suivantes sont prises en charge dans Aurora MySQL version 1 (compatible avec MySQL 5.6), mais ne sont pas actuellement prises en charge dans Aurora MySQL version 2 (compatible avec MySQL 5.7).

• Jointures par hachage. Pour plus d'informations, consultez Optimisation des requêtes de jointure MySQL Aurora volumineuses avec des jointures de hachage dans le Guide de l'utilisateur Amazon Aurora.

• Fonctions natives pour l'appel synchrone de fonctions AWS Lambda. Pour plus d'informations, consultez Appel d'une fonction Lambda avec une fonction native Aurora MySQL dans le Guide de l'utilisateur Amazon Aurora.

• Traitement par lot des analyses. Pour plus d'informations, consultez Mises à jour du moteur de base de données Aurora MySQL du 11/12/2017 (version 1.16) (obsolète).

• Migration des données à partir de MySQL à l'aide d'un compartiment Amazon S3. Pour plus d'informations, consultez Migration des données à partir de MySQL à l'aide d'un compartiment Amazon S3 dans le Guide de l'utilisateur Amazon Aurora.

Compatibilité avec MySQL 5.7

Cette version d'Aurora MySQL est compatible réseau avec MySQL 5.7 et inclut des fonctionnalités telles que la prise en charge de JSON, les index spatiaux et les colonnes générées. Aurora MySQL utilise une implémentation native de l'indexation spatiale à l'aide de courbes en z pour offrir des performances d'écriture 20 fois meilleures et des performances de lecture 10 fois meilleures que MySQL 5.7 pour des ensembles de données spatiaux.

Cette version d'Aurora MySQL ne prend actuellement pas en charge les fonctionnalités MySQL 5.7 suivantes :

• Plugin de réplication de groupe

• Augmentation de la taille de page

• Chargement du pool de mémoires tampons InnoDB au démarrage

• Plugin d'analyse de texte intégral InnoDB

• Réplication multi-source

• Redimensionnement de pool de mémoires tampons en ligne

• Plugin de validation de mot de passe

• Plugins de réécriture de requête

• Filtrage de réplication

• Instruction SQL CREATE TABLESPACE