Mises à jour du moteur SQL de base de données Aurora My 2024-03-07 (version 3.06.0, compatible avec My 8.0.34) SQL

SQLLa version 3.06.0 d'Aurora My prend en charge l'intégration d'Amazon Bedrock et introduit les nouveaux mots clés réservésaccept,, aws_bedrock_invoke_modelaws_sagemaker_invoke_endpoint, content_type et. timeout_ms Vérifiez les définitions des objets pour vérifier l'utilisation des nouveaux mots clés réservés avant de passer à la version 3.06.0. Pour atténuer le conflit avec les nouveaux mots clés réservés, citez les mots clés réservés utilisés dans les définitions des objets. Pour plus d'informations sur l'intégration d'Amazon Bedrock et la gestion des mots clés réservés, consultez Qu'est-ce qu'Amazon Bedrock ? dans le guide de l'utilisateur d'Amazon Aurora. Pour plus d'informations, consultez les sections Mots clés et mots réservés, The INFORMATION _ SCHEMA KEYWORDS Table et Schema Object Names dans la section Ma SQL documentation.

Performances améliorées pour les répliques de journaux binaires lors de la réplication de transactions pour de grandes tables comportant plusieurs index secondaires. Cette fonctionnalité introduit un pool de threads permettant d'appliquer des modifications d'index secondaires en parallèle sur une réplique binlog. La fonctionnalité est contrôlée par le paramètre de aurora_binlog_replication_sec_index_parallel_workers cluster de base de données, qui contrôle le nombre total de threads parallèles disponibles pour appliquer les modifications d'index secondaires. Pour plus d'informations, consultez Réplication avec Amazon Aurora MySQL dans le Guide de l'utilisateur Amazon Aurora.

Ajout d'une nouvelle procédure stockée mysql.rds_set_read_only qui permet de modifier la valeur de la variable système globale read_only sur les instances de base de données de votre SQL cluster Aurora My. Pour plus d'informations, consultez la section Réplication dans le guide de l'utilisateur Amazon Aurora.

Ajout d'une nouvelle procédure stockée mysql.rds_set_binlog_source_ssl qui permet de définir le chiffrement d'une réplique de journal binaire en spécifiant une valeur pourSOURCE_SSL. Pour plus d'informations, consultez la section Réplication dans le guide de l'utilisateur Amazon Aurora.

Amazon Aurora Machine Learning est une intégration optimisée entre la SQL base de données Aurora My et les services d'apprentissage AWS automatique (ML). Amazon Bedrock est désormais pris en charge, ce qui vous permet d'invoquer des modèles d'apprentissage automatique dans Amazon Bedrock directement depuis votre cluster Aurora My SQL DB à l'aide de. SQL Pour plus d'informations sur l'utilisation d'Amazon Bedrock avec votre cluster de base de SQL données Aurora My, consultez la section Utilisation d'Amazon Aurora machine learning avec Aurora My SQL dans le guide de l'utilisateur Amazon Aurora.

Aurora My SQL version 3.06 ajoute la prise en charge de l'annulation automatique de la troncature des tablespaces. Cette optimisation vous permet de récupérer l'espace inutilisé dans les tablespaces d'annulation une fois les journaux d'annulation purgés.

CVE-2020-11104

CVE-2020-11105

CVE-2023-38545

CVE-2023-38546

CVE-2023-39975

Correction d'un problème en raison duquel une instance de base de données de réplication en lecture ne pouvait pas être lancée correctement lorsque la charge de travail de l'instance de base de données d'écriture était élevée.

Correction d'un problème à cause duquel une instance de base de données Aurora My SQL Writer pouvait basculer en raison d'un défaut de communication avec le stockage Aurora. Le défaut est dû à une rupture de communication entre l'instance de base de données et le stockage sous-jacent suite à une mise à jour logicielle de l'instance de stockage Aurora.

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 pouvait provoquer le redémarrage ou le basculement d'une instance Aurora My SQL DB en raison d'une diminution de la mémoire disponible lorsque la jointure par hachage est utilisée lors de l'exécution de requêtes.

Correction d'un problème qui pouvait provoquer 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 provoquait le redémarrage de la 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.

Dans Aurora My SQL 2.10, nous avons ajouté la prise en charge du redémarrage d'un cluster de base de données Aurora avec disponibilité en lecture. Cette fonctionnalité permet aux instances de base de données de lecteur de rester en ligne pendant le redémarrage d'une instance de base de données d'écriture. Cette fonctionnalité est désormais prise en charge sur le secondaire Régions AWS dans les bases de données SQL globales Aurora My, ce qui garantit que vous pouvez toujours répondre aux demandes de lecture lors du redémarrage d'une instance d'écriture sur le cluster principal. Auparavant, lors du redémarrage d'une instance d'écriture, toutes les instances de lecteur d'un cluster SQL secondaire Aurora My redémarraient également. Avec cette version, les instances de lecteur de cluster secondaires continuent de traiter les demandes de lecture lors du redémarrage d'une instance d'écriture, ce qui améliore la disponibilité de lecture dans le cluster. Pour plus d'informations, voir Redémarrage d'un cluster Aurora avec disponibilité en lecture.

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 qui pouvait entraîner l'échec d'une requête parallel en raison de problèmes réseau transitoires lors de la lecture des données du volume du cluster Aurora.

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.

Les petites instances de base de données dont la mémoire est inférieure ou égale à 4 GiB ferment désormais les connexions les plus gourmandes en mémoire lorsque l'instance de base de données est soumise à une pression de mémoire. Vous pouvez également ajuster le pool de mémoire tampon pour réduire sa taille. Pour plus d'informations, consultez Amazon Aurora My SQL out-of-memory issues dans le guide de l'utilisateur Amazon Aurora.

Modification de la réponse par défaut pouraurora_oom_response, sur toutes les classes d'instance de base de données disposant de plus de 4 GiB de mémoire, de vide à. print Pour plus d'informations, consultez Amazon Aurora My SQL out-of-memory issues dans le guide de l'utilisateur Amazon Aurora.

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.

Correction d'un problème en raison duquel 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.

Ajout des Aurora_lockmgr_buffer_pool_memory_used métriques Aurora_lockmgr_memory_used et pour suivre l'utilisation de la mémoire par le gestionnaire de verrous. 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 les petites instances de répliques en lecture pouvaient subir un délai de réplication accru après la mise à niveau à partir de SQL versions d'Aurora My antérieures à la version 2.11.*.

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

Correction d'un problème qui pouvait entraîner l'échec des mises à niveau des versions majeures en cas de présence d'une FTS_DOC_ID colonne définie par l'utilisateur dans le schéma de table.

Correction d'un problème qui pouvait entraîner des échecs de mise à niveau d'Aurora M ySQLversion 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 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 toujours 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).