Mises à jour du moteur de base de données Aurora MySQL du 10/11/2020 (version 2.07.3) (obsolète) - Amazon Aurora
AméliorationsIntégration de correctifs de bogues de l'édition MySQL Community EditionComparaison avec Aurora MySQL Version 1Compatibilité avec MySQL 5.7

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

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

Version : 2.07.3

Aurora MySQL 2.07.3 est disponible. Les versions 2.* d'Aurora MySQL sont compatibles avec MySQL 5.7 et les versions 1.* 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 restaurer un instantané à partir d'une version Aurora MySQL actuellement prise en charge dans Aurora MySQL 2.07.3. Vous avez également la possibilité de mettre à niveau les clusters de bases de données Aurora MySQL 2.* vers Aurora MySQL 2.07.3. Vous ne pouvez pas mettre à niveau directement un cluster Aurora MySQL 1.* vers 2.07.3. En revanche, vous pouvez restaurer son instantané sur Aurora MySQL 2.07.3.

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 ou de l'API RDS. AWS CLI

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.

Si vous avez des questions ou des préoccupations, le AWS support est disponible sur les forums communautaires et via le 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é.

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'une condition de concurrence dans le gestionnaire de verrous entre l'annulation d'une connexion/requête et la résiliation de la séance entraînant le redémarrage de la base de données.

  • Correction d'un problème entraînant le redémarrage de la base de données après l'exécution d'une instruction à plusieurs requêtes qui accède à plusieurs tables ou bases de données avec le cache de requête activé.

  • Correction d'un problème pouvant provoquer des redémarrages répétés en raison des mises à jour de colonne virtuelle avec des index secondaires.

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

  • InnoDB : les transactions XA simultanées exécutées avec succès pour la phase de préparation XA sur le maître étaient en conflit lorsqu'elles étaient réutilisées sur l'esclave, entraînant ainsi un délai d'attente de verrouillage dans le thread applicateur. Le conflit était dû à la plage de verrouillage d'écart qui variait lorsque les transactions étaient réutilisées en série sur l'esclave. Pour éviter ce type de conflit, les verrous d'écart acceptés par les transactions XA au niveau d'isolement READ COMMITTED sont désormais publiés (et ne sont plus hérités) lorsque les transactions XA atteignent l'étape de préparation. (Bogue n° 27189701, Bogue n° 25866046)

  • InnoDB : un verrou d'écart a été pris inutilement lors de la validation de clé étrangère et de l'utilisation du niveau d'isolement READ COMMITTED. (Bogue n° 25082593)

  • Réplication : lors de l'utilisation de transactions XA, si un délai d'attente de verrouillage ou un blocage se produisait pour le thread applicateur (SQL) sur un esclave de réplication, la nouvelle tentative automatique ne fonctionnait pas, car même si le thread SQL procédait à une restauration, il ne restaurait pas la transaction XA. Par conséquent, lorsque la transaction était relancée, le premier événement était XA START et n'était pas valide étant donné que la transaction XA était déjà en cours, entraînant une erreur XAER_RMFAIL. (Bogue n° 24764800)

  • Réplication : 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)

  • Réplication : la valeur renvoyée par une instruction SHOW SLAVE STATUS pour la taille combinée totale de tous les fichiers journaux relais existants (Relay_Log_Space) pouvait devenir beaucoup plus élevée que l'espace disque réel utilisé par les journaux relais. Le thread d'I/O ne verrouillait pas la variable lorsqu'il mettait à jour la valeur. Il pouvait donc supprimer automatiquement un fichier journal relais et écrire une valeur réduite avant de terminer la mise à jour de la valeur. Le thread d'I/O écrivait ensuite son calcul de taille d'origine, en ignorant la mise à jour du thread SQL et en rajoutant ainsi l'espace du fichier supprimé. La valeur Relay_Log_Space est désormais verrouillée pendant les mises à jour afin d'empêcher les mises à jour simultanées et de garantir un calcul précis. (Bogue n° 26997096, Bogue n° 87832)

  • Pour les instructions INSERT pour lesquelles la liste VALUES produisait des valeurs pour la deuxième ligne ou une ligne suivante à l'aide d'une sous-requête contenant une jointure, le serveur pouvait s'arrêter s'il n'avait pas réussi à résoudre les privilèges requis. (Bogue n° 23762382)

  • Pour les tables ayant une colonne TIMESTAMP ou DATETIME avec une valeur CURRENT_TIMESTAMP par défaut, la colonne pouvait être initialisée à 0000-00-00 00:00:00 si la table avait un déclencheur BEFORE INSERT. (Bogue n° 25209512, Bogue n° 84077)

  • Les tentatives simultanées de plusieurs threads pour enregistrer et annuler l'enregistrement des objets de schéma de performances de métadonnées pouvaient entraîner l'arrêt d'un serveur. (Bogue n° 26502135)

  • L'exécution d'une procédure stockée contenant une instruction qui avait créé une table à partir du contenu de certaines instructions SELECT pouvait entraîner une fuite de mémoire. (Bogue n° 25586773)

  • L'exécution d'une procédure stockée contenant une requête qui avait accédé à une vue pouvait allouer de la mémoire qui n'était pas libérée avant la fin de la séance. (Bogue n° 25053286)

  • Certains cas de matérialisation de sous-requête pouvaient provoquer l'arrêt d'un serveur. Ces requêtes produisent maintenant une erreur suggérant que la matérialisation doit être désactivée. (Bogue #26402045)

  • Les requêtes avec de nombreuses jointures gauches étaient lentes si la mise en mémoire tampon de jointure était utilisée (par exemple, à l'aide de l'algorithme de boucle imbriquée par bloc). (Bogue n° 18898433, Bogue n° 72854)

  • L'optimiseur ignorait la deuxième colonne d'un index composite lors de l'exécution d'une jointure interne avec une clause LIKE sur la deuxième colonne. (Bogue n° 28086754)

Comparaison avec Aurora MySQL Version 1

Les fonctions 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).

Compatibilité avec MySQL 5.7

Cette version d'Aurora MySQL est compatible réseau avec MySQL 5.7 et inclut des fonctions 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 fonctions 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