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 : 07/08/2017 (version 1.14) (obsolète)
Version : 1.14
Aurora MySQL 1.14 est en général disponible. Tous les nouveaux clusters de bases de données, y compris ceux restaurés à partir d'instantanés, seront créés dans Aurora MySQL 1.14. Aurora MySQL 1.14 est également une mise à niveau obligatoire pour les clusters de bases de données Aurora MySQL existants. Nous enverrons une annonce séparée avec le calendrier de prise en charge des versions précédentes d'Aurora MySQL.
Avec la version 1.14 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. 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 la version 1.13, la fonction d'application de correctifs sans temps d'arrêt d'Aurora peut permettre aux connexions client à votre instance principale Aurora 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
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.
Améliorations
-
Correction d'une erreur incorrecte « Enregistrement introuvable » lorsqu'un enregistrement est trouvé dans l'index secondaire, mais pas dans l'index principal.
-
Correction d'un problème de stabilité susceptible de se produire suite à une assertion de défense (ajoutée dans la version 1.12) qui était trop forte dans le cas où une écriture individuelle s'étend sur 32 pages. Une telle situation peut se produire, par exemple, avec des valeurs BLOB élevées.
-
Correction d'un problème de stabilité à cause des incohérences entre le cache de l'espace disque logique et le cache de dictionnaire.
-
Correction d'un problème au cours duquel le réplica Aurora cesse de réagir après avoir dépassé le nombre maximal de tentatives de connexion à l'instance principale. Un réplica Aurora redémarre maintenant si la période d'inactivité est supérieure à la période de pulsation utilisée pour la vérification de l'état par l'instance principale.
-
Correction d'un blocage opérationnel susceptible de se produire à la suite d'actions simultanées lorsqu'une connexion tente d'acquérir un blocage de métadonnées exclusif au moment de l'émission d'une commande, telle que
ALTER TABLE. -
Correction d'un problème de stabilité dans un réplica en lecture Aurora en présence de lecture anticipée logique/parallèle.
-
Amélioration de
LOAD FROM S3de deux façons :-
Meilleure gestion des erreurs de délai d'attente Amazon S3 à l'aide de la nouvelle tentative du kit SDK en plus de la tentative existante.
-
Optimisation des performances lors de la charge de très gros fichiers ou de grands nombres de fichiers par la mise en cache et la réutilisation de l'état du client.
-
-
Correction des problèmes de stabilité suivants avec Fast DDL pour les opérations
ALTER TABLE:-
Lorsque l'instruction
ALTER TABLEcomporte plusieurs commandesADD COLUMNet que les noms de colonne ne sont pas dans l'ordre croissant. -
Lorsque la chaîne de nom de la colonne à mettre à jour et sa chaîne de nom correspondante, extraites à partir de la table système interne, varient en fonction d'un caractère de fin null (/0).
-
Sous certaines opérations de fractionnement de l'arbre B (B-tree).
-
Lorsque la table comporte une clé primaire de longueur variable.
-
-
Correction d'un problème de stabilité avec les réplicas Aurora lorsqu'il faut trop de temps pour rendre le cache d'index de recherche en texte intégral cohérent avec celui de l'instance principale. Cela peut se produire si une grande partie des entrées d'index de recherche en texte intégral récemment créées sur l'instance principale n'a pas encore été vidée sur le disque.
-
Correction d'un problème de stabilité susceptible de se produire pendant la création de l'index.
-
La nouvelle infrastructure qui suit la consommation de mémoire par connexion et la télémétrie associée qui seront utilisées pour la création de politiques d'évitement de mémoire insuffisante.
-
Correction d'un problème où
ANALYZE TABLEétait incorrectement autorisé sur les réplicas Aurora. Ceci est maintenant bloqué. -
Correction d'un problème de stabilité causé par un blocage rare suite à une condition rare entre la lecture anticipée logique et la purge.
Intégration de correctifs de bogues MySQL.
-
Une recherche en texte intégral associée aux tables dérivées (sous-requêtes de la clause
FROM) entraînait un arrêt du serveur. Maintenant, si une opération de texte intégral dépend d'une table dérivée, le serveur produit une erreur indiquant qu'une recherche en texte intégral ne peut pas être effectuée sur une table matérialisée. (Bogues n° 68751 et 16539903)
