Mises à jour du moteur de base de données Aurora MySQL : 23/02/2017 (version 1.11) (obsolète)

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 dans le Guide de l'utilisateur Amazon Aurora.

Sinon, vous pouvez appliquer immédiatement le correctif dans AWS Management Console en choisissant un cluster de bases de données, puis Actions de clusters et Mettre à niveau maintenant.

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

• 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 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 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 dans le Guide de l'utilisateur Amazon Aurora.

Améliorations

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

• Résolution d'un problème de mémoire insuffisante pour 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.

• Résolution d'un problème où le cluster de bases de données redémarre lors de la suppression, la mise à jour ou la purge d'un grand nombre d'objets géospatiaux stockés en externe (comme les LOB).

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

• 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_SCHEMA qui utilisaient ORDER BY n'utilisaient pas d'optimisation filesort comme elles le faisaient auparavant. (Bogue n° 16423536)

• FOUND_ROWS () 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)