Mises à jour du moteur de base de données Aurora MySQL du 25/05/2021 (version 2.10.0) (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 25/05/2021 (version 2.10.0) (obsolète)

Version : 2.10.0

Aurora MySQL 2.10.0 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 supé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.

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.

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 CVE supplémentaires ci-dessous :

Nouvelles fonctions :

  • La classe d'instances db.t3.large est désormais prise en charge pour Aurora MySQL.

  • Réplication du journal binaire :

    • Introduction du cache d'I/O du journal binaire pour améliorer les performances des journaux binaires en réduisant la contention entre les threads de l'enregistreur et les threads de vidage. Pour plus d'informations, consultez Réplication avec Amazon Aurora MySQL dans le Guide de l'utilisateur Amazon Aurora.

    • Dans Aurora MySQL version 2.08, nous avons introduit l'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. Ces améliorations sont désormais prises en charge pour les clusters sur lesquels le GTID est activé.

  • Plus grande disponibilité des instances de lecteur :

    • Auparavant, lors du redémarrage d'une instance d'enregistreur, toutes les instances de lecteur d'un cluster Aurora MySQL ont également redémarré. Grâce au lancement du jour, les instances de lecteur dans la région continueront de traiter des demandes de lecture lors du redémarrage d'une instance d'enregistreur, ce qui améliore la disponibilité de lecture dans le cluster. Pour plus d'informations, consultez Redémarrage d'un cluster Aurora avec disponibilité en lecture (versions 2.10 et ultérieures) dans le Guide de l'utilisateur Amazon Aurora.

      Important

      Après la mise à niveau vers Aurora MySQL 2.10, le redémarrage de l'instance d'enregistreur n'effectue pas de redémarrage de l'ensemble du cluster. Si vous souhaitez redémarrer l'ensemble du cluster, vous réinitialisez maintenant toutes les instances de lecteur dans le cluster après avoir redémarré l'instance d'enregistreur.

  • Amélioration des performances de lecture de pages anticipée demandées par la technique de lecture anticipée logique (LRA). Cela a été fait en regroupant les lectures de plusieurs pages dans une seule requête envoyée au stockage Aurora. Par conséquent, les requêtes utilisant l'optimisation LRA s'exécutent jusqu'à trois fois plus vite.

  • Redémarrages sans interruption et application de correctifs sans temps d'arrêt :

    • Redémarrage sans interruption (ZDR) amélioré et application de correctifs sans temps d'arrêt (ZDP) pour activer ZDR et ZDP dans un plus large éventail de scénarios, y compris la prise en charge supplémentaire des cas où la journalisation binaire est activée. Aussi, une visibilité améliorée sur les événements de ZDR et de ZDP. Pour plus d'informations, consultez Redémarrage sans interruption (ZDR) pour Amazon Aurora MySQL et Utilisation des correctifs sans temps d'arrêt dans le Guide de l'utilisateur Amazon Aurora.

Améliorations de la disponibilité :

  • Améliorations pour un démarrage plus rapide lorsque la base de données comporte un grand nombre d'index temporaires et de tables créés lors d'une activité DDL interrompue antérieurement.

  • Correction de plusieurs problèmes liés aux redémarrages répétés lors de la récupération sur incident des opérations DDL interrompues, 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.

  • Correction d'un problème qui pouvait entraîner le redémarrage du serveur pendant le traitement du journal DAS (Database Activity Streams).

  • Correction d'un problème d'impression d'un message d'erreur lors du traitement d'une requête ALTER sur les tables système.

Améliorations générales :

  • Correction d'un problème dans lequel le cache de requête pouvait renvoyer des résultats obsolètes sur une instance de lecteur.

  • Correction d'un problème où certaines métriques de validation Aurora n'étaient pas mises à jour lorsque la variable système innodb_flush_log_at_trx_commit était définie sur 0 ou 2.

  • Correction d'un problème où un résultat de requête stocké dans le cache de requêtes n'était pas actualisé par des transactions à plusieurs instructions.

  • Correction d'un problème qui pouvait entraîner un défaut de mise à jour correcte de l'horodatage modifié pour la dernière fois des fichiers du journal binaire Cela pouvait entraîner la purge prématurée des fichiers du journal binaire, avant d'atteindre la période de rétention configurée par le client.

  • Correction du nom et de la position du fichier de journal binaire signalés incorrects depuis InnoDB après une récupération sur incident.

  • Correction d'un problème qui pouvait entraîner des transactions volumineuses à générer des événements de journal binaire incorrects si le paramètre binlog_checksum était défini sur NONE.

  • Correction d'un problème qui provoquait l'arrêt d'un réplica de journal binaire avec une erreur si la transaction répliquée contenait une instruction DDL et un grand nombre de modifications de ligne.

  • Correction d'un problème entraînant un redémarrage dans une instance de lecteur lors de la suppression d'une table.

  • Correction d'un problème qui entraînait la défaillance des connecteurs open source lors de la tentative d'utilisation d'un fichier journal binaire avec une transaction volumineuse.

  • Correction d'un problème qui pouvait entraîner des résultats de requête incorrects sur la colonne de géométrie volumineuse après avoir créé un index spatial sur la table avec les valeurs de géométrie volumineuse.

  • La base de données recrée désormais l'espace de table temporaire pendant le redémarrage, ce qui permet de libérer et de récupérer l'espace de stockage associé.

  • Correction d'un problème qui empêchait les tables performance_schema d'être tronquées sur les instances de lecteur Aurora.

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

  • Résolution d'un problème qui entraînait le redémarrage de la base de données lors de l'exécution de l'instruction FLUSH TABLES WITH READ LOCK.

  • Correction d'un problème qui empêchait l'utilisation de fonctions de verrouillage au niveau de l'utilisateur sur les instances de lecteur Aurora.

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

  • Les transactions entrelacées pouvaient parfois bloquer l'applicateur de réplica lorsque le niveau d'isolement des transactions était défini sur REPEATABLE READ. (Bogue n° 25040331)

  • Lorsqu'une procédure stockée contenait une instruction faisant référence à une vue qui, à son tour, faisait référence à une autre vue, la procédure n'a pas pu être invoquée avec succès plus d'une fois. (Bogue n° 87858 et n° 26864199)

  • Pour les requêtes comportant de nombreuses conditions OR, l'optimiseur est désormais plus efficace en mémoire et moins susceptible de dépasser la limite de mémoire imposée par la variable système range_optimizer_max_mem_size. En outre, la valeur par défaut de cette variable est passée de 1 536 000 à 8 388 608. (Bogue n° 79450 et n° 22283790)

  • Réplication : dans la fonction next_event(), appelée par le thread SQL d'un réplica pour lire l'événement suivant à partir du journal de relais, le thread SQL ne libérait pas le relaylog.log_lock acquis lorsqu'il rencontrait une erreur (par exemple, en raison d'un journal de relais fermé). Par conséquent, tous les autres threads devaient attendre d'obtenir un verrou sur le journal du relais à raccrocher. Avec ce correctif, le verrou est libéré avant que le thread SQL ne quitte la fonction concernée. (Bogue n° 21697821)

  • Correction d'une corruption de mémoire pour ALTER TABLE avec une colonne virtuelle. (Bogue n° 24961167 et n° 24960450)

  • Réplication : les réplicas multithreads ne pouvaient pas être configurés avec de petites files d'attente à l'aide de slave_pending_jobs_size_max s'ils avaient besoin de traiter des transactions supérieures à cette taille. Tout paquet plus grand que slave_pending_jobs_size_max était rejeté avec l'erreur ER_MTS_EVENT_BIGGER_PENDING_JOBS_SIZE_MAX, même si le paquet était inférieur à la limite fixée par slave_max_allowed_packet. Avec ce correctif, slave_pending_jobs_size_max devient une limite flexible plutôt qu'une limite stricte. Si la taille d'un paquet dépasse slave_pending_jobs_size_max, mais est inférieure à slave_max_allowed_packet, la transaction est conservée jusqu'à ce que tous les workers de réplica aient des files d'attente vides, puis traitées. Toutes les transactions suivantes sont conservées jusqu'à ce que la transaction volumineuse soit terminée. La taille de la file d'attente des workers de réplica peut donc être limitée tout en autorisant des transactions occasionnelles plus importantes. (Bogue n° 21280753 et n° 77406)

  • Réplication : lors de l'utilisation d'un réplica multithread, les erreurs d'application affichaient des données d'ID de worker incohérentes avec les données externalisées dans les tables de réplique Schéma de performances. (Bogue n° 25231367)

  • Réplication : Sur une réplique de réplication basée sur le GTID exécutée avec -GTID-Mode=ON, -LOG-bin=OFF et utilisant -, lorsqu'une erreur rencontrée, qui devait être ignorée, n'était pas correctement mise à jourslave-skip-errors, ce qui entraînait une perte de synchronisation avec. Exec_Master_Log_Pos Exec_Master_Log_Pos Read_master_log_pos Si un GTID_NEXT n'était pas spécifié, le réplica ne mettrait jamais à jour son état de GTID lors du retour à partir d'une transaction d'instruction unique. Le Exec_Master_Log_Pos ne serait pas mis à jour, car même si la transaction était terminée, son état GTID indiquerait le contraire. Le correctif supprime la restriction de la mise à jour de l'état GTID lorsqu'une transaction est annulée uniquement si GTID_NEXT est spécifié. (Bogue n° 22268777)

  • Réplication : une instruction partiellement échouée ne consommait pas correctement un GTID généré automatiquement ou spécifié lorsque la journalisation binaire était désactivée. Ce correctif garantit qu'un DROP TABLE, un DROP USER ou un DROP VIEW ayant partiellement échoué consomment respectivement le GTID correspondant et l'enregistrent dans les tables @@GLOBAL.GTID_EXECUTED et mysql.gtid_executed lorsque la journalisation binaire est désactivée. (Bogue n° 21686749)

  • Réplication : les réplicas exécutant MySQL 5.7 ne pouvaient pas se connecter à une source MySQL 5.5 en raison d'une erreur lors de la récupération de server_uuid, qui ne faisait pas partie de MySQL 5.5. Cela était causé par des changements dans la méthode de récupération du server_uuid. (Bogue n° 22748612)

  • Réplication : le mécanisme d'omission de transaction GTID, qui ignore silencieusement une transaction GTID précédemment exécutée, ne fonctionnait pas correctement pour les transactions XA. (Bogue n° 25041920)

  • Les instructions ">XA ROLLBACK qui avaient échoué en raison d'un ID de transaction incorrect pouvaient être enregistrées dans le journal binaire avec l'ID de transaction correct et pouvaient donc être traitées par des réplicas de réplication. Une vérification est maintenant effectuée pour la situation d'erreur avant que la journalisation binaire n'ait lieu et les instructions ROLLBACK XA échouées ne sont pas consignées. (Bogue n° 26618925)

  • Réplication : si une réplique a été configurée à l'aide d'une instruction CHANGE MASTER TO qui ne spécifiait ni le nom du fichier journal source ni la position du journal source, puis qu'elle était arrêtée avant que START SLAVE ne soit émise, puis redémarrée avec l'option - relay-log-recovery set, la réplication n'a pas démarré. Cela se produisait parce que le thread du récepteur n'avait pas été démarré avant la tentative de récupération du journal de relais. Par conséquent, aucun événement de rotation du journal n'était disponible dans le journal de relais pour fournir le nom du fichier journal source et la position du journal source. Dans ce cas, le réplica ignore désormais la récupération du journal de relais et consigne un avertissement, puis démarre la réplication. (Bogue n° 28996606 et n° 93397)

  • Réplication : dans la réplication basée sur les lignes, un message qui affichait mal les longueurs de champ était renvoyé lors de la réplication à partir d'une table comportant une colonne utf8mb3 vers une table de la même définition que celle où la colonne était définie avec un jeu de caractères utf8mb4. (Bogue n° 25135304 et n° 83918)

  • Réplication : lorsqu'une instruction RESET SLAVE avait été émise sur un réplica de réplication avec des GTID en cours d'utilisation, les fichiers journaux de relais existants avaient été purgés, mais le nouveau fichier journal de relais de remplacement avait été généré avant que l'ensemble des GTID reçus pour le canal n'ait été effacé. L'ancien jeu de GTID était donc écrit dans le nouveau fichier journal du relais en tant qu'événement PREVIOUS_GTIDS, provoquant une erreur fatale lors de la réplication indiquant que le réplica comportait plus de GTID que la source, même si le jeu gtid_executed des deux serveurs était vide. Maintenant, lorsque RESET SLAVE est émis, l'ensemble des GTID reçus est effacé avant que le nouveau fichier journal de relais ne soit généré, de sorte que cette situation ne se produise pas. (Bogue n° 27411175)

  • Réplication : en cas d'utilisation des GTID pour la réplication, les transactions, y compris les instructions qui avaient provoqué une erreur d'analyse (ER_PARSE_ERROR) ne pouvaient pas être ignorées manuellement par la méthode recommandée qui consiste à injecter une transaction vide ou de remplacement avec le même GTID. Cette action doit permettre au réplica d'identifier le GTID comme déjà utilisé et donc d'ignorer la transaction indésirable qui a partagé son GTID. Toutefois, dans le cas d'une erreur d'analyse, parce que l'instruction a été analysée avant que le GTID ne soit vérifié pour voir s'il devait être ignoré, le thread qui a appliqué la réplication s'est arrêté en raison de l'erreur d'analyse, même si l'intention était d'ignorer la transaction malgré tout. Avec ce correctif, le thread qui a appliqué la réplication ignore désormais les erreurs d'analyse si la transaction concernée doit être ignorée, car le GTID était déjà utilisé. Notez que ce changement de comportement ne s'applique pas dans le cas d'applications constituées d'une sortie de journal binaire produite par mysqlbinlog. Dans ce cas, il y aurait un risque qu'une transaction comportant une erreur d'analyse qui suit immédiatement une transaction ignorée soit également ignorée, alors qu'elle devrait générer une erreur. (Bogue n° 27638268)

  • Réplication : activez le thread SQL pour que GTID ignore une transaction partielle. (Bogue n° 25800025)

  • Réplication : lorsqu'un paramètre de délai d'expiration négatif ou fractionnaire avait été fourni à WAIT_UNTIL_SQL_THREAD_AFTER_GTIDS(), le serveur se comportait de manière inattendue. Avec ce correctif :

    • une valeur de délai d'expiration fractionnaire est lue telle quelle, sans arrondi ;

    • une valeur de délai d'expiration négatif est rejetée avec une erreur si le serveur est en mode SQL strict. Si le serveur n'est pas en mode SQL strict, la valeur fait en sorte que la fonction renvoie NULL immédiatement et sans attendre, puis émette un avertissement. (Bogue n° 24976304 et n° 83537)

  • Réplication : si la fonction WAIT_FOR_EXECUTED_GTID_SET() avait été utilisée avec une valeur de délai d'expiration incluant une partie fractionnée (par exemple, 1,5), une erreur dans la logique de conversion de types signifiait que le délai d'expiration était arrondi à la seconde entière la plus proche et à zéro pour les valeurs inférieures à 1 seconde (par exemple, 0,1). La logique de conversion de types a maintenant été corrigée de sorte que la valeur du délai d'expiration soit appliquée comme indiqué initialement sans arrondi. Merci à Dirkjan Bussink pour sa contribution. (Bogue n° 29324564 et n° 94247)

  • En cas d'activation des GTID, l'instruction XA COMMIT sur une transaction XA déconnectée au sein d'une transaction à plusieurs instructions déclenchait une assertion. (Bogue n° 22173903)

  • Réplication : une assertion était déclenchée dans les builds de débogage si une instruction XA ROLLBACK était émise pour un identifiant de transaction inconnu lorsque la valeur gtid_next avait été définie manuellement. Le serveur ne tente plus de mettre à jour l'état du GTID si une instruction ROLLBACK XA échoue avec une erreur. (Bogue n° 27928837 et n° 90640)

  • Correction d'un problème d'ordre de tri erroné lorsque plusieurs fonctions CASE sont utilisées dans la clause ORDER BY (Bogue n° 22810883).

  • Certaines requêtes utilisant le tri pouvaient accéder à une colonne non initialisée lors de l'optimisation et provoquer l'arrêt du serveur. (Bogue n° 27389294)

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