Mises à jour du moteur de base de données Aurora MySQL du 24/10/2017 (version 1.15) (obsolète) - Amazon Aurora

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 24/10/2017 (version 1.15) (obsolète)

Version : 1.15

Aurora MySQL 1.15 est en disponibilité générale. Tous les nouveaux clusters de bases de données, y compris ceux restaurés à partir d'instantanés, seront créés dans Aurora 1.15. Vous avez la possibilité, sans y être obligé, de mettre à niveau les clusters de bases de données existants vers Aurora 1.15. Vous pouvez créer de nouveaux clusters de bases de données dans Aurora 1.14.1. Vous pouvez le faire à l'aide de l'API AWS CLI ou de l'API Amazon RDS et en spécifiant la version du moteur.

Avec la version 1.15 d'Aurora, 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. Les mises à jour nécessitent un redémarrage de la base de données, si bien que vous rencontrerez 20 à 30 secondes d'indisponibilité, après quoi vous pourrez reprendre l'utilisation de votre ou de vos clusters de bases de données. Si vos clusters de bases de données exécutent actuellement Aurora 1.14 ou Aurora 1.14.1, la fonction d'application de correctifs sans temps d'arrêt d'Aurora MySQL peut permettre aux connexions client à votre instance principale Aurora MySQL de persister tout au long de la mise à niveau, en fonction de votre charge de travail.

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.

Application de correctifs sans temps d'arrêt

La fonction d'application de correctifs sans temps d'arrêt tente, dans un souci d'optimisation, de conserver les connexions client tout au long de la mise à jour corrective du moteur. Pour plus d'informations sur l'application de correctifs sans temps d'arrêt, consultez Utilisation des correctifs sans temps d'arrêt dans le Guide de l'utilisateur Amazon Aurora.

Nouvelles fonctionnalités

  • Lecture anticipée asynchrone des clés – la lecture anticipée asynchrone des clés (AKP) est une fonction qui vise à améliorer les performances des jointures d'index non mises en cache en récupérant au préalable les clés en mémoire avant qu'elles ne soient nécessaires. Le cas d'utilisation principale visé par AKP est une jointure d'index entre une petite table externe et une grande table interne, où l'index de la grande table est très sélectif. Lorsque l'interface Multi-Range Read (MRR) est activée, AKP sera exploité pour une recherche d'index secondaire vers principal. Les instances plus petites avec des contraintes de mémoire peuvent dans certains cas exploiter la fonction AKP selon la cardinalité de clé. Pour plus d'informations, consultez Optimisation des requêtes de jointure indexées Aurora MySQL avec lecture anticipée asynchrone des clés dans le Guide de l'utilisateur Amazon Aurora.

  • Fast DDL – nous avons étendu cette fonction publiée dans Aurora 1.13 aux opérations qui incluent des valeurs par défaut. Avec cette extension, FAST DLL est applicable pour les opérations qui ajoutent une colonne acceptant la valeur null à la fin d'une table, avec ou sans valeurs par défaut. Cette fonction reste sous le mode Lab d'Aurora. Pour plus d'informations, consultez Modification de tables dans Amazon Aurora à l'aide de Fast DDL dans le Guide de l'utilisateur Amazon Aurora.

Améliorations

  • Résolution d'une erreur de calcul pendant l'optimisation des requêtes spatiales WITHIN/CONTAINS qui provoquait précédemment un ensemble de résultats vide.

  • Résolution du problème associé à la commande SHOW VARIABLE afin d'afficher la valeur du paramètre innodb_buffer_pool_size mise à jour en cas de modification dans le groupe de paramètres.

  • Amélioration de la stabilité de l'instance principale pendant l'insertion en bloc dans une table modifiée avec Fast DDL lorsque l'indexation de hachage est désactivée et lorsque l'enregistrement à insérer est le premier d'une page.

  • Amélioration de la stabilité d'Aurora lorsque l'utilisateur tente de définir la valeur du paramètre de cluster de bases de données server_audit_events sur default.

  • Résolution d'un problème où une modification de jeu de caractères de base de données pour une instruction ALTER TABLE exécutée sur l'instance principale d'Aurora n'était pas répliquée sur les réplicas Aurora avant leur redémarrage.

  • Amélioration de la stabilité grâce à la correction d'une condition de concurrence sur l'instance principale qui permettait précédemment d'enregistrer un réplica Aurora même si l'instance principale avait fermé son propre volume.

  • Amélioration des performances de l'instance principale pendant la création d'index sur une table de grande taille en changeant le protocole de verrouillage pour permettre les instructions DML simultanées pendant la construction d'index.

  • Correction du problème d'incohérence des métadonnées InnoDB pendant la requête ALTER TABLE RENAME pour une meilleure stabilité. Exemple : lorsque les colonnes de la table t1(c1, c2) sont renommées cycliquement en t1(c2,c3) dans la même instruction ALTER.

  • Amélioration de la stabilité des réplicas Aurora lorsqu'un réplica Aurora n'a pas de charge de travail active et que l'instance principale ne répond pas.

  • Amélioration de la disponibilité des réplicas Aurora lorsqu'un réplica Aurora contient un verrou explicite sur une table et empêche le thread de réplication d'appliquer les modifications DDL reçues à partir de l'instance principale.

  • Amélioration de la stabilité de l'instance principale lorsqu'une clé étrangère et une colonne sont ajoutées simultanément à une table à partir de deux sessions séparées et que la fonction Fast DDL a été activée.

  • Amélioration de la stabilité du thread de purge sur l'instance principale pendant une lourde charge de travail en écriture en bloquant la troncature d'enregistrements d'annulation jusqu'à ce qu'ils soient purgés.

  • Amélioration de la stabilité en corrigeant l'ordre de libération du verrou pendant le processus d'engagement des transactions qui ignore des tables.

  • Correction d'un défaut lié aux réplicas Aurora dans lequel l'instance de base de données ne pouvait par terminer le démarrage et indiquait que le port 3306 était déjà utilisé.

  • Correction d'une condition de concurrence dans laquelle l'exécution d'une requête SELECT sur certaines tables information_schema (innodb_trx, innodb_lock, innodb_lock_waits) augmentait l'instabilité du cluster.

Intégration de correctifs de bogues MySQL.

  • CREATE USER accepte le plugin et le hachage du mot de passe, mais ignore le hachage du mot de passe (bogue n° 78033)

  • Le moteur de partitionnement ajoute des champs à l'ensemble de bits de lecture pour pouvoir retourner des entrées triées à partir d'un index partitionné. Par conséquent, le tampon de jointure essaie de lire des champs non nécessaires. Corrigé en n'ajoutant pas tous les champs de partitionnement à read_set, mais en triant uniquement les champs à préfixe déjà spécifié de read_set. Ajout d'un DBUG_ASSERT qui implique la lecture du premier champ en cas de key_cmp (bogue n° 16367691).

  • Ralentissement de l'instance MySQL « doing SYNC index » (bogue n° 73816)

  • Assertion RBT_EMPTY(INDEX_CACHE->WORDS) dans ALTER TABLE CHANGE COLUMN (bogue n° 17536995)

  • La recherche InnoDB Fulltext ne trouve pas d'enregistrements lorsque des points de sauvegarde sont impliqués (bogue n° 70333)