Mises à jour du moteur SQL de base de données Aurora My 2024-06-04 (version 3.07.0, compatible avec My 8.0.36) SQL - 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 SQL de base de données Aurora My 2024-06-04 (version 3.07.0, compatible avec My 8.0.36) SQL

Version : 3.07.0

Aurora My SQL 3.07.0 est généralement disponible. Les versions SQL 3.07 d'Aurora My sont compatibles avec My SQL 8.0.36. Pour plus d'informations sur les modifications apportées à la communauté, consultez les notes de mise à jour de My SQL 8.0.

Pour plus de détails sur les nouvelles fonctionnalités d'Aurora My SQL version 3, voir Aurora My SQL version 3 compatible avec My SQL 8.0. Pour connaître les différences entre Aurora My SQL version 3 et Aurora My SQL version 2, voir Comparaison d'Aurora My SQL version 2 et Aurora My SQL version 3. Pour une comparaison entre Aurora My SQL version 3 et My SQL 8.0 Community Edition, consultez la section Comparaison entre Aurora My SQL version 3 et My SQL 8.0 Community Edition dans le guide de l'utilisateur Amazon Aurora.

Les SQL versions d'Aurora My actuellement prises en charge sont les suivantes : 2.07.9, 2.07.10, 2.11.*, 2.12.*, 3.03.*, 3.04.*, 3.05.*, 3.06.* et 3.07.*.

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.

Améliorations

Problèmes de sécurité corrigés et CVEs :

Cette version inclut tous les CVE correctifs communautaires, y compris My SQL 8.0.36. Les CVE correctifs suivants sont inclus :

Améliorations de la disponibilité :

  • Correction d'un problème qui pouvait provoquer le redémarrage d'une instance de base de données de lecteur lors de la lecture d'une table modifiée ou supprimée sur l'instance de base de données d'écriture.

  • Correction d'un problème qui pouvait provoquer le redémarrage d'une instance de base de données Aurora My SQL Writer lorsqu'une session de transfert d'écriture était fermée lors de l'exécution d'une requête transférée.

  • Correction d'un problème qui provoquait le redémarrage d'une instance de base de données lors de la gestion de grands GTID ensembles sur une instance activée pour le journal binaire.

  • Correction d'un problème lors du traitement des INSERT requêtes sur des tables partitionnées InnoDB qui pouvait entraîner une diminution progressive de la mémoire libre dans l'instance.

  • Correction d'un problème qui, dans de rares cas, pouvait entraîner le redémarrage des instances de base de données du lecteur.

  • Correction d'un problème qui provoquait le redémarrage d'une instance de base de données en cas SHOWSTATUSd'exécution simultanée d'PURGEBINARYLOGSinstructions. PURGE BINARY LOGSest une instruction gérée qui est exécutée pour respecter la période de conservation du journal binaire configurée par l'utilisateur.

  • Correction d'un problème qui pouvait provoquer la fermeture inattendue du serveur après l'exécution d'instructions Data Manipulation Language (DML) sur une table dont les colonnes non virtuelles étaient réorganisées avec une instruction MODIFY COLUMN orCHANGE COLUMN.

  • Correction d'un problème qui, lors du redémarrage d'une instance de base de données, pouvait entraîner un redémarrage supplémentaire.

  • Correction d'un problème qui pouvait provoquer le redémarrage d'une instance de base de données de lecteur utilisant le transfert d'écriture lorsqu'une instruction de validation implicite transférée rencontrait une erreur.

  • Correction d'un problème qui, dans de rares cas, pouvait provoquer le redémarrage d'une instance de lecteur lors de l'exécution de SELECT requêtes sur des tables soumises à une contrainte de clé étrangère.

  • Correction d'un problème selon lequel les instances de base de données utilisant des volumes de cluster Aurora de plusieurs To pouvaient subir des temps d'arrêt accrus lors du redémarrage en raison d'échecs de validation du pool de mémoire tampon InnoDB.

  • Correction d'un problème qui provoquait le redémarrage d'une base de données lorsqu'une contrainte de clé DELETE étrangère UPDATE ou en cascade était définie sur une table où une colonne virtuelle était impliquée soit en tant que colonne dans la contrainte de clé étrangère, soit en tant que membre de la table référencée.

  • Correction d'un problème qui pouvait interrompre la restauration de la base de données au démarrage si le redémarrage se produisait lors d'opérations d'insertion intensives impliquant des AUTO_INCREMENT colonnes.

  • Correction d'un problème Aurora Serverless v2 qui pouvait entraîner le redémarrage de la base de données lors de la mise à l'échelle.

Améliorations générales :

  • Réduction de l'utilisation des E/S et amélioration des performances pour un sous-ensemble de requêtes d'analyse par plage de clés primaires utilisant une requête parallèle.

  • SQLLa version 3.06.0 d'Aurora My a ajouté le support pour l'intégration d'Amazon Bedrock. Dans ce cadre, de nouveaux mots clés réservés (accept,aws_bedrock_invoke_model, aws_sagemaker_invoke_endpointcontent_type, ettimeout_ms) ont été ajoutés. Dans la SQL version 3.07.0 d'Aurora My, ces mots clés ont été remplacés par des mots clés non réservés, qui sont autorisés comme identifiants sans guillemets. Pour plus d'informations sur la façon dont My SQL gère les mots clés réservés et non réservés, consultez la section Mots clés et mots réservés dans la section Ma SQL documentation.

  • Correction d'un problème qui ne renvoyait pas clairement de message d'erreur au client lors de l'appel du service Amazon Bedrock depuis un cluster Aurora My SQL DB alors qu' Région AWS Amazon Bedrock n'était pas encore disponible.

  • Correction d'un problème qui pouvait entraîner une consommation de mémoire excessive lors de l'interrogation de BLOB colonnes à l'aide de la requête parallèle Aurora.

  • Ajout de la prise en charge connection_memory_limit des connection_memory_chunk_size paramètres et à définir au niveau de la session pour qu'ils se comportent de la même manière que dans My SQL Community Edition. Le connection_memory_limit est utilisé pour définir la quantité maximale de mémoire pouvant être utilisée par une connexion utilisateur unique. Le connection_memory_chunk_size paramètre peut être utilisé pour définir la taille de segmentation pour les mises à jour du compteur global d'utilisation de la mémoire.

  • Correction d'un problème empêchant l'utilisateur d'interrompre une requête ou de définir des délais d'expiration de session pour les performance_schema requêtes.

  • Problème résolu : la réplication du journal binaire (binlog) configurée pour utiliser des SSL certificats personnalisés (mysql.rds_import_binlog_ssl_material) pouvait échouer lorsque l'instance de réplication était en cours de remplacement d'hôte.

  • Ajout de la variable d'état Aurora_fts_cache_memory_used globale pour suivre l'utilisation de la mémoire par le système de recherche en texte intégral dans toutes les tables. Pour plus d'informations, consultez les variables d'état SQL globales d'Aurora My dans le guide de l'utilisateur Amazon Aurora.

  • Correction d'un problème à cause duquel un cluster Amazon Redshift configuré en tant que ETL destination zéro pouvait connaître une augmentation temporaire IntegrationLaglorsqu'un cluster Amazon Aurora My SQL DB était configuré en tant que réplique de journal binaire, avec Enhanced Binlog et Zero Integration activés. ETL

  • Correction d'un problème lié à la gestion des fichiers journaux d'audit qui pouvait rendre les fichiers journaux inaccessibles pour le téléchargement ou la rotation et, dans certains cas, augmenter leur CPU utilisation.

  • Restauration des AUTO_INCREMENT clés optimisée pour réduire le temps nécessaire à la restauration des instantanés, à la point-in-time restauration et au clonage de clusters de bases de données contenant un grand nombre de tables dans la base de données.

  • Problème résolu : l'événement wait/io/redo_log_flush n'apparaissait pas dans les tableaux récapitulatifs des événements d'attente du schéma de performance.

  • Correction d'un problème qui pouvait provoquer des erreurs clés dupliquées pour les AUTO_INCREMENT colonnes utilisant des index décroissants après une restauration instantanée, un retour en arrière ou une opération de clonage de base de données.

  • Correction d'un problème qui provoquait le redémarrage d'une instance de base de données d'écriture lorsqu'une instance de base de données de lecture utilisant le transfert d'écriture exécutait une instruction Data Manipulation Language (DML) contenant une valeur d'horodatage et que le paramètre de time_zone base de données était défini sur. UTC

  • Correction d'un problème selon lequel une SELECT requête sur une instance de lecteur Aurora pouvait échouer en raison de l'inexistence de la table d'erreurs lorsque la table contient au moins un index search (FTS) en texte intégral et qu'une TRUNCATE instruction est exécutée sur l'instance de base de données Aurora Writer.

  • Correction d'un problème qui, dans de rares cas, entraînait l'échec de l'application de correctifs (ZDP) sans interruption de service.

  • Correction d'un problème qui pouvait entraîner un ensemble de résultats incomplet lors de l'exécution de requêtes impliquant LEFT JOIN ou d'RIGHT JOINopérations utilisant l'algorithme de jointure par hachage avec requête parallèle.

Mises à niveau et migrations :

  • Correction d'un problème qui pouvait provoquer des échecs de mise à niveau d'Aurora My SQL version 2 vers Aurora My SQL version 3 lorsqu'une FTS_DOC_ID colonne définie par l'utilisateur était présente dans le schéma de table.

  • Correction d'un problème qui pouvait entraîner des échecs de mise à niveau d'Aurora My SQL version 2 vers Aurora My SQL version 3 en raison d'un problème de synchronisation lors du traitement des tablespaces InnoDB.

  • Correction d'un problème qui pouvait entraîner l'échec des mises à niveau majeures vers Aurora My SQL version 3 en raison de la présence d'entrées orphelines pour des espaces disque logiques déjà supprimés dans les tables système InnoDB d'Aurora My version 2. SQL

  • Correction d'un problème en raison duquel la valeur SERVER_ID n'était pas mise à jour après le passage d'Amazon RDS Blue/Green Deployment. Cela a entraîné des problèmes où les pilotes intelligents tels que le JDBCpilote Amazon Web Services (AWS) n'ont pas pu découvrir la topologie du cluster de bases de données après une commutation bleu/vert. Avec ce correctif, les clusters de base de données Aurora renommés dans le cadre d'un déploiement RDS bleu/vert, qui s'exécutent sur Aurora My SQL version 3.07 ou ultérieure, verront leur SERVER_ID valeur mise à jour dans le cadre du passage au numérique. Pour les versions antérieures, les instances de base de données des clusters bleu et vert peuvent être redémarrées pour mettre à jour la SERVER_ID valeur.

Intégration des corrections de bogues de My SQL Community Edition

Cette version inclut toutes les corrections de bogues communautaires jusqu'à la version 8.0.36 incluse, en plus des suivantes. Pour plus d'informations, voir Mes SQL bogues corrigés par les mises à jour du moteur de base de données Aurora My SQL 3.x.

  • Correction d'un problème en raison duquel la valeur de la ligne de cache pouvait être calculée de manière incorrecte, ce qui provoquait un échec lors du redémarrage de la base de données sur les instances basées sur Graviton. (Correctif de bogue communautaire #35479763)

  • Correction d'un problème en raison duquel certaines instances de sous-requêtes dans les routines stockées n'étaient pas traitées correctement. (Correctif de bogue communautaire #35377192)

  • Correction d'un problème qui pouvait entraîner une CPU utilisation accrue en raison de la rotation des TLS certificats d'arrière-plan (Community Bug Fix #34284186).

  • Correction d'un problème en raison duquel InnoDB autorisait l'ajout de INSTANT colonnes aux tables dans le schéma My SQL system dans les SQL versions d'Aurora My antérieures à 3.05, ce qui pouvait entraîner la fermeture inattendue du serveur (redémarrage de l'instance de base de données) après la mise à niveau vers Aurora My version 3.05.0. SQL (Correctif de bogue communautaire #35625510).