Mises à jour du moteur de base de données Aurora MySQL du 25/11/2019 (version 1.22.0) (obsolète)

Version : 1.22.0

Aurora MySQL 1.22.0 est en général disponible. Les versions 1.x d'Aurora MySQL sont compatibles avec MySQL 5.6 et les versions 2.x d'Aurora MySQL sont compatibles avec MySQL 5.7.

L'obsolescence de cette version du moteur est prévue pour le 28 février 2023. Pour plus d'informations, consultez Préparation à la fin de vie d'Amazon Aurora Édition compatible avec MySQL version 1.

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

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 l'API AWS CLI ou de l'API RDS. Vous avez la possibilité de mettre à niveau les clusters de bases de données Aurora MySQL 1.* existants vers Aurora MySQL 1.22.0.

Note

Cette version n'est actuellement pas disponible dans les AWS régions suivantes : AWS GovCloud (US-East) [us-gov-east-1], AWS GovCloud (US-West) [us-gov-west-1], Chine (Ningxia) [cn-northwest-1], Asie-Pacifique (Hong Kong) [ap-east-1], Moyen-Orient (Bahreïn) [me-south-1] et Amérique du Sud (São Paulo) [sa-east-1]. Sa disponibilité fera l'objet d'une annonce distincte.

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

La procédure de mise à niveau du cluster de bases de données a changé. Pour plus d'informations, 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

Nouvelles fonctions :

• Les clusters Aurora MySQL prennent désormais en charge les types d'instance db.r5.8xlarge, db.r5.16xlarge et db.r5.24xlarge.

• Nouvelles améliorations apportées aux journaux binaires (binlog) pour une meilleure latence de validation lorsque de très larges transactions sont impliquées.

• Aurora MySQL possède désormais un mécanisme pour réduire la fenêtre de temps pendant laquelle les événements d'une transaction volumineuse sont écrits sur les journaux binaires à la validation. Cette solution empêche les interminables récupérations hors connexion lorsque les arrêts de base de données se produisent pendant cette fenêtre temporelle. Cette fonctionnalité corrige aussi le problème où une transaction volumineuse bloque les petites transactions sur la validation des journaux binaires. Cette fonctionnalité est désactivée par défaut et peut être activée par l'équipe du service si nécessaire pour la charge de travail. Lorsqu'elle est activée, elle est déclenchée lorsqu'une taille de transaction est > 500 Mo.

• Ajout de la prise en charge pour le niveau d'isolation ANSI READ COMMITTED sur les réplicas en lecture. Ce niveau d'isolation permet aux requêtes de longue durée sur le réplica en lecture de s'exécuter sans impacter le haut débit des écritures sur le nœud d'écriture. Pour plus d'informations, veuillez consulter Niveaux d'isolation Aurora MySQL.

• Les bases de données mondiales permettent désormais d'ajouter des régions de réplication secondaires en lecture seule pour les clusters de bases de données déployés dans ces AWS régions : régions : USA Est (Virginie du Nord) [us-east-1], USA Est (Ohio) [us-east-2], USA Ouest (Californie du Nord) [us-west-1], USA Ouest (Oregon) [us-west-2], Europe (Irlande) [eu-west-2] 1], Europe (Londres) [eu-west-2], Europe (Paris) [eu-west-3], Asie-Pacifique (Tokyo) [ap-northeast-1], Asie-Pacifique (Séoul) [ap-northeast-2], Asie-Pacifique (Singapour) [ap-southeast-1] -southeast-1], Asie-Pacifique (Sydney) [ap-southeast-2], Canada (Centre) [ca-central-1], Europe (Francfort) [ eu-central-1] et Asie-Pacifique (Mumbai) [ap-south-1].

• La fonctionnalité de conflits entre lignes critiques est désormais disponible et ne nécessite pas que le mode lab Aurora soit activé (ON). Cette fonction améliore nettement le débit pour les charges où de nombreuses transactions sont en conflit pour les lignes d'une même page.

• Cette version possède des fichiers de fuseau horaire mis à jour pour prendre en charge la dernière mise à jour du fuseau du Brésil pour les nouveaux clusters.

Correctifs critiques :

• CVE-2019-2922

• CVE-2019-2923

• CVE-2019-2924

• CVE-2019-2910

Correctifs à priorité élevée :

• CVE-2019-2805

• CVE-2019-2730

• CVE-2019-2740

• CVE-2018-3064

• CVE-2018-3058

• CVE-2017-3653

• CVE-2017-3464

• CVE-2017-3244

• CVE-2016-5612

• CVE-2016-5439

• CVE-2016-0606

• CVE-2015-4904

• CVE-2015-4879

• CVE-2015-4864

• CVE-2015-4830

• CVE-2015-4826

• CVE-2015-2620

• CVE-2015-0382

• CVE-2015-0381

• CVE-2014-6555

• CVE-2014-4258

• CVE-2014-4260

• CVE-2014-2444

• CVE-2014-2436

• CVE-2013-5881

• CVE-2014-0393

• CVE-2013-5908

• CVE-2013-5807

• CVE-2013-3806

• CVE-2013-3811

• CVE-2013-3804

• CVE-2013-3807

• CVE-2013-2378

• CVE-2013-2375

• CVE-2013-1523

• CVE-2013-2381

• CVE-2012-5615

• CVE-2014-6489

• Correction du problème du composant de récupération de DLL qui entraînait un arrêt prolongé de la base de données. Les clusters devenus indisponibles après l'exécution d'une requête TRUNCATE TABLE sur une table avec une colonne AUTO_INCREMENT doivent être mis à jour.

• Correction du problème du composant de récupération de DLL qui entraînait un arrêt prolongé de la base de données. Les clusters devenus indisponibles après l'exécution d'une requête DROP TABLE sur plusieurs tables en parallèle doivent être mis à jour.

Correctifs de stabilité générale :

• Correction d'un problème qui provoquait le redémarrage de réplicas en lecture pendant une transaction de longue durée. Les clients confrontés à des démarrages de réplicas coïncidant avec une suppression accélérée dans la mémoire libérable doivent envisager de mettre cette version à niveau.

• Correction d'un problème signalant à tort une erreur ERROR 1836 lorsqu'une requête imbriquée est exécutée sur une table temporaire sur le réplica en lecture.

• Résolution d'une erreur d'annulation de requête sur les instances de lecteur Aurora pendant l'exécution d'une charge de travail intense en écriture sur l'instance d'écriture Aurora.

• Correction du problème qui entraîne le redémarrage d'une base de données configurée comme « journal binaire principal (binlog) » tandis qu'une charge massive de travail en écriture est en cours d'exécution.

• Correction du problème d'indisponibilité prolongée lors du redémarrage du moteur. La correction concerne un problème d'initialisation du pool de mémoires tampon. Ce problème se produit rarement, mais peut éventuellement impacter toute version prise en charge.

• Correction d'un problème qui générait des données non cohérentes dans la table information_schema.replica_host_status.

• Correction d'une condition de course entre la requête parallèle et les chemins d'exécution standard qui entraînait le redémarrage intermittent des nœuds en lecture.

• Amélioration de la stabilité de la base de données lorsque le nombre de connexions clients dépasse la valeur du paramètre max_connections.

• Amélioration de la stabilité des instances en lecture grâce au blocage des DLL non prises en charge et des requêtes LOAD FROM S3.

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

• Bogue #16346241 - ARRÊT DU SERVEUR DANS ITEM_PARAM::QUERY_VAL_STR

• Bogue #17733850 - ARRÊT DE NAME_CONST() DANS ITEM_NAME_CONST::ITEM_NAME_CONST()

• Bogue #20989615: INNODB AUTO_INCREMENT GÉNÈRE DEUX FOIS LA MÊME VALEUR

• Bogue #20181776 - LE CONTRÔLE D'ACCÈS NE CORRESPOND PAS À L'HÔTE LE PLUS SPÉCIFIQUE QUAND IL CONTIENT DES CARACTÈRES GÉNÉRIQUES

• Bogue #27326796 - ARRÊT DE MYSQL AVEC ÉCHEC DE L'ASSERTION INNODB DANS LE FICHIER PARS0PARS.CC

• Bug #20590013 - IF YOU HAVE A FULLTEXT INDEX AND DROP IT YOU CAN NO LONGER PERFORM ONLINE DDL