Sélectionner vos préférences de cookies

Nous utilisons des cookies essentiels et des outils similaires qui sont nécessaires au fonctionnement de notre site et à la fourniture de nos services. Nous utilisons des cookies de performance pour collecter des statistiques anonymes afin de comprendre comment les clients utilisent notre site et d’apporter des améliorations. Les cookies essentiels ne peuvent pas être désactivés, mais vous pouvez cliquer sur « Personnaliser » ou « Refuser » pour refuser les cookies de performance.

Si vous êtes d’accord, AWS et les tiers approuvés utiliseront également des cookies pour fournir des fonctionnalités utiles au site, mémoriser vos préférences et afficher du contenu pertinent, y compris des publicités pertinentes. Pour accepter ou refuser tous les cookies non essentiels, cliquez sur « Accepter » ou « Refuser ». Pour effectuer des choix plus détaillés, cliquez sur « Personnaliser ».

Mes SQL bogues corrigés par les mises à jour du moteur SQL de base de données Aurora My - 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.

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.

Mes SQL bogues corrigés par les mises à jour du moteur SQL de base de données Aurora My

Les sections suivantes identifient Mes SQL bogues qui ont été corrigés par les mises à jour du moteur SQL de base de données Aurora My.

Mes SQL bogues corrigés par les mises à jour du moteur de base de données Aurora My SQL 3.x

Ma version SQL compatible avec la version 8.0 Aurora contient toutes les corrections de SQL bogues associées à la version My SQL Compatibility correspondante. Le tableau suivant identifie les SQL bogues My supplémentaires qui ont été corrigés par les mises à jour du moteur de SQL base de données Aurora My, ainsi que la mise à jour dans laquelle ils ont été corrigés.

Mise à jour du moteur de base de données Ma version SQL compatible Version Mes SQL bugs corrigés
Mises à jour du moteur SQL de base de données Aurora My 2024-11-18 (version 3.08.0, compatible avec My 8.0.39) SQL

8,0,39

3,08,0
  • Correction d'un problème qui provoquait l'omission incorrecte de NULL valeurs dans le jeu de résultats pour certaines requêtes comportant JOIN les deux UNION opérations. (Correctif de bogue communautaire #114301)

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

8,0,36

3,07,0
  • 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).

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

8,0,34

3,06,0

  • 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 une instance de 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 augmentation de CPU l'utilisation en raison de la rotation des TLS certificats d'arrière-plan. (Correctif du bogue #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 Community n° 35625510)

Mises à jour du moteur SQL de base de données Aurora My 2024-01-31 (version 3.05.2, compatible avec My 8.0.32) Par défaut SQL

8,0,32

3,05.2

  • Correction d'un problème en raison duquel un nombre excessif de lectures de disque étaient records_in_range effectuées pour les INSERT opérations, ce qui entraînait une baisse progressive des performances. (Correctif de bogue communautaire #34976138)

Mises à jour du moteur de base de données Aurora MySQL 21/11/2023 (version 3.05.1, compatible avec MySQL 8.0.32)

8,0,32

3,05.1

  • Correction d'un problème dans InnoDB : si une INSTANT ADD colonne était ajoutée à une SQL table My dans un schéma système entre les SQL versions 3.01 à Aurora My 3.04 et après la mise à niveau d'Aurora My vers la version 3.05.0, le serveur se SQL fermait de manière inattendue DMLs sur ces tables. SQL (Correctif de bogue Community n° 35625510)

Mises à jour du moteur SQL de base de données Aurora My 25/10/2023 (version 3.05.0, compatible avec My 8.0.32) SQL

8,0,32

3,05,0

  • 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)

Mises à jour du moteur SQL de base de données Aurora My 2024-03-15 (version 3.04.2, compatible avec My 8.0.28) SQL

8,0,28

3.04.2

  • 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)

  • L'exécution répétée d'une routine stockée, comportant comme sous-requête une SELECT instruction contenant plusieurs ou XOR conditions ANDOR, a entraîné une consommation excessive et éventuellement un épuisement de la mémoire virtuelle. (Correctif de bogue communautaire #33852530)

Mises à jour du moteur SQL de base de données Aurora My 13/11/2013 (version 3.04.1, compatible avec My 8.0.28) SQL

8,0,28

3.04.1

  • 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)

Mises à jour du moteur SQL de base de données Aurora My 31/07/2023 (version 3.04.0, compatible avec My 8.0.28) SQL

8,0,28

3,04,0

  • Correction d'un problème de déplacement d'un bloc de mémoire tampon contenant une page de table temporaire intrinsèque lors du parcours d'une page, provoquant un échec d'assertion (Bogue n° 33715694)

  • InnoDB : empêcher les DDL opérations en ligne d'accéder à la out-of-bounds mémoire (bogue n° 34750489, bogue n° 108925)

  • Correction d'un problème qui pouvait parfois produire des résultats de requête incorrects lors du traitement d'SQLinstructions complexes composées de plusieurs expressions de table communes imbriquées (CTEs) (bogue n° 34572040, bogue n° 34634469, bogue n° 33856374)

Mises à jour du moteur SQL de base de données Aurora My 2023-12-08 (version 3.03.3) (obsolète)

8,0,26

3.03.3

  • 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)

Mises à jour du moteur SQL de base de données Aurora My 2023-08-29 (version 3.03.2) (obsolète)

8,0,26

3.03.2

  • Correction d'un problème qui pouvait parfois produire des résultats de requête incorrects lors du traitement d'SQLinstructions complexes composées de plusieurs expressions de table communes imbriquées (CTEs) (Bug #34572040, Bug #34634469, Bug #33856374)

  • InnoDB : échec d'assertion provoqué par une condition de concurrence entre des threads qui tentaient de désinitialiser et d'initialiser des statistiques pour une même table (bogue n° 33135425).

  • InnoDB : Empêcher les DDL opérations en ligne d'accéder à out-of-bounds la mémoire (Bug #34750489, Bug #108925)

Mises à jour du moteur SQL de base de données Aurora My 23/05/11 (version 3.03.1) (obsolète)

8,0,26

3.03.1

  • Correction d'un problème de relocalisation d'un bloc de mémoire tampon contenant une page de table temporaire intrinsèque lors du parcours d'une page, provoquant un échec d'assertion (bogue n° 33715694)

Mises à jour du moteur SQL de base de données Aurora My : 01/01 (version 3.03.0) (obsolète)

8,0,26

3,03,0

  • Correction d'un problème qui faisait que certains types de colonnes incluaient JSON et TEXT épuisaient parfois le tampon de tri si sa taille n'était pas au moins 15 fois supérieure à celle de la plus grande ligne du tri. Désormais, le tampon de tri ne doit être que 15 fois supérieur à la plus grande clé de tri. (Bogues n° 103325, 105532, 32738705 et 33501541)

  • Correction d'un problème lors duquel InnoDB ne gérait pas toujours correctement certains noms légaux de partitions de table. (Bogue n° 32208630)

  • Correction d'un problème susceptible, dans certaines conditions, de renvoyer des résultats incorrects en raison d'un calcul inexact de la propriété de nullabilité lors de l'exécution d'une requête avec une condition OR. (Bogue n° 34060289)

  • Correction d'un problème susceptible, dans certaines conditions, de renvoyer des résultats incorrects lorsque les deux conditions suivantes sont remplies :

    • une table dérivée est fusionnée dans le bloc de requête externe.

    • la requête comprend une jointure gauche et une sous-requête IN.

    (Bogue n° 34060289)

  • Correction d'un problème en raison duquel INCREMENT des valeurs AUTO _ incorrectes étaient générées lorsque la valeur maximale de la colonne entière était dépassée. L'erreur était due à l'absence de prise en compte de la valeur maximale de colonne. La INCREMENT valeur AUTO _ valide précédente aurait dû être renvoyée dans ce cas, ce qui a provoqué une erreur de clé dupliquée. (Bogues n° 87926 et 26906787)

  • Correction d'un problème en raison duquel il n'était pas possible de révoquer le DROP privilège sur le schéma de performance. (Bogue n° 33578113)

  • Correction d'un problème en raison duquel une procédure stockée contenant une instruction IF usingEXISTS, qui agissait sur une ou plusieurs tables supprimées et recréées entre les exécutions, ne s'exécutait pas correctement lors des invocations suivantes après la première. (Bogue n° 32855634).

  • Correction d'un problème lors duquel une requête référence une vue dans une sous-requête et un bloc de requête externe peut provoquer un redémarrage inattendu. (Bogue n° 32324234)

Mises à jour du moteur SQL de base de données Aurora My, 11/11 (version 3.02.2) (Obsolète)

8,0,23

3.02.2

  • Correction d'un problème susceptible, dans certaines conditions, de renvoyer des résultats incorrects en raison d'un calcul inexact de la propriété de nullabilité lors de l'exécution d'une requête avec une condition OR. (Bogue n° 34060289)

  • Correction d'un problème susceptible, dans certaines conditions, de renvoyer des résultats incorrects lorsque les deux conditions suivantes sont remplies :

    • Une table dérivée est fusionnée dans le bloc de requête externe.

    • La requête inclut une jointure gauche et une sous-requête IN. (Bogue n° 34060289)

  • Correction d'un problème de révocation du privilège DROP sur le schéma de performance. (Bogue n° 33578113)

  • Correction d'un problème en raison duquel une procédure stockée contenant une instruction IF usingEXISTS, qui agissait sur une ou plusieurs tables supprimées et recréées entre les exécutions, ne s'exécutait pas correctement lors des invocations suivantes après la première. (Mon SQL bug #32855634).

  • Des INCREMENT valeurs AUTO _ incorrectes ont été générées lorsque la valeur maximale de la colonne entière a été dépassée. L'erreur était due à l'absence de prise en compte de la valeur maximale de colonne. La INCREMENT valeur AUTO _ valide précédente aurait dû être renvoyée dans ce cas, ce qui a provoqué une erreur de clé dupliquée. (Bogues n° 87926 et 26906787)

  • Correction d'un problème qui pouvait entraîner un échec lors de la mise à niveau d'un cluster de base de données Aurora My SQL version 1 (compatible avec My SQL 5.6) contenant une table créée par l'utilisateur avec une certaine tableIDs. L'attribution de ces tables IDs peut entraîner un conflit entre les tables du dictionnaire de données IDs lors de la mise à niveau d'Aurora My SQL version 2 (compatible avec My SQL 5.7) vers Aurora My SQL version 3 (compatible avec My SQL 8.0). (Bogue n° 33919635)

Mises à jour du moteur SQL de base de données Aurora My 04-20 (version 3.02.0) (obsolète)

8,0,23

3,02,0

Correction d'une mauvaise gestion des tables temporaires utilisées pour les curseurs dans des procédures stockées qui pouvait entraîner un comportement inattendu du serveur. (Bogue n° 32416811)

Mises à jour du moteur SQL de base de données Aurora My 04-15 (version 3.01.1) (obsolète)

8,0,23

3.01.1

Correction d'une mauvaise gestion des tables temporaires utilisées pour les curseurs dans des procédures stockées qui pouvait entraîner un comportement inattendu du serveur. (Bogue n° 32416811)

Mes SQL bogues corrigés par les mises à jour du moteur de base de données Aurora My SQL 2.x

Ma version SQL compatible avec la version 5.7 Aurora contient toutes les corrections de SQL bogues de My 5.7.44. SQL Le tableau suivant identifie les SQL bogues My supplémentaires qui ont été corrigés par les mises à jour du moteur de SQL base de données Aurora My, ainsi que la mise à jour dans laquelle ils ont été corrigés.

Mise à jour du moteur de base de données Version Mes SQL bugs corrigés
Mises à jour du moteur SQL de base de données Aurora My 2024-07-09 (version 2.12.3, compatible avec My SQL 5.7.44) Cette version a atteint la fin du support standard.

2.12.3

  • Correction d'un problème en raison duquel les tables temporaires liées à des déclencheurs lors de l'exécution d'instructions pouvaient provoquer un redémarrage inattendu du moteur de base de données.

  • Correction d'un défaut qui pouvait entraîner la fermeture du serveur lorsque des instructions à table unique UPDATE et DELETE des instructions utilisant des expressions indexées étaient exécutées en tant qu'instructions préparées. (Insecte #29257254)

Mises à jour du moteur de SQL base de données Aurora My 28/12/2023 (version 2.12.1, compatible avec My SQL 5.7.40) Cette version a atteint la fin du support standard.

2.12.1

  • Correction d'un problème qui pouvait entraîner le blocage des connexions à distance existantes et nouvelles lorsqu'elles étaient exécutées simultanément avec l'instruction SHOW PROCESSLIST (bogue Community n° 34857411)

  • Réplication : certains événements de journal binaire n'étaient pas toujours gérés correctement (bogue n° 34617506).

  • Correction du traitement des jetons à caractère unique par un plugin d'analyse Full-Text Search (FTS) (Bug #35432973)

Mises à jour du moteur de SQL base de données Aurora My 25/07/2023 (version 2.12.0, compatible avec My SQL 5.7.40) Cette version a atteint la fin du support standard.

2.12.0

  • Correction d'un problème qui pouvait entraîner une augmentation de CPU l'utilisation en raison de la rotation des TLS certificats d'arrière-plan. (Correctif du bogue #34284186)

Mises à jour du moteur de SQL base de données Aurora My 17/10/2023 (version 2.11.4, compatible avec My SQL 5.7.12) Cette version a atteint la fin du support standard.

2.11.4

  • Réplication : certains événements du journal binaire n'étaient pas toujours gérés correctement. (Bogue n° 34617506)

  • Correction d'un problème qui pouvait entraîner une augmentation de CPU l'utilisation en raison de la rotation des TLS certificats d'arrière-plan. (Correctif du bogue #34284186)

  • Dans les instructions préparées, certains types de sous-requête pouvaient causer un arrêt du serveur. (Bogue n° 33100586)

Mises à jour du moteur de SQL base de données Aurora My : 10-25 (version 2.11.0, compatible avec My SQL 5.7.12) Cette version n'est pas disponible pour les nouvelles créations et a atteint la fin du support standard.

2.11.0

  • Correction d'un problème causé par le code de lecture des informations sur le jeu de caractères issues des tables d'événements d'une instruction du schéma de performance (par exemple, events_statements_current) qui n'empêche pas l'écriture simultanée de ces informations sur le jeu de caractères. Par conséquent, le jeu de caractères du texte de la SQL requête n'est peut-être pas valide, ce qui peut entraîner la fermeture du serveur. Avec ce correctif, un jeu de caractères non valide entraîne la troncature de TEXT la colonne SQL _ et empêche le serveur de quitter le serveur. (Bogue n° 23540008)

  • InnoDB : rétroportage d'un correctif pour les bogues n° 25189192 et 84038. Problème résolu : après une RENAME TABLE opération ayant déplacé une table vers un autre schéma, InnoDB ne parvenait pas à mettre à jour la table du dictionnaire de DATAFILES données INNODB SYS _ _. Une erreur au redémarrage indiquait alors que le fichier de données du tablespace était introuvable.

  • InnoDB: correction d'un problème lors duquel le serveur supprimait un index de clé étrangère défini en interne lors de l'ajout d'un nouvel index, et tentait d'utiliser un index secondaire défini sur une colonne virtuelle générée en tant qu'index de clé étrangère, provoquant ainsi l'arrêt du serveur. InnoDB permet désormais à une contrainte de clé étrangère de référencer un index secondaire défini sur une colonne générée virtuelle. (Bogue n° 23533396)

  • Correction d'un problème où deux sessions exécutaient simultanément un... INSERT DUPLICATEKEYUPDATEL'opération ON a généré un blocage. Lors de l'annulation partielle d'un tuple, une autre session pouvait le mettre à jour. La correction de ce bogue annule les correctifs des bogues n° 11758237, 17604730 et 20040791. (Bogue n° 25966845)

  • Correction d'un problème à cause duquel les ALTER ROUTINE privilèges EXECUTE et n'étaient pas correctement accordés aux créateurs de routine, même lorsque automatic_sp_privileges était activé. (Bogue n° 27407480)

  • Rétroportation du correctif pour le bogue communautaire #24671968 : correction d'un problème en raison duquel une requête pouvait produire des résultats incorrects si la WHERE clause contenait une sous-requête dépendante, si la table comportait un index secondaire sur les colonnes de la liste de sélection, suivi des colonnes de la sous-requête, GROUP BY ou si elle DISTINCT autorisait la requête à utiliser un Loose Index Scan.

  • Correction d'un problème d'interruption de la réplication si une instruction de suppression de plusieurs tables est émise sur plusieurs tables comportant des clés étrangères. (Bogue n° 80821)

  • Correction d'un problème lors duquel, dans des cas particuliers, certaines erreurs d'esclaves n'étaient pas ignorées même lorsque slave_skip_errors était activé. En cas d'échec de l'ouverture et du verrouillage d'une table ou en cas d'échec des conversions de champs sur un serveur exécutant une réplication basée sur des lignes, l'erreur est considérée comme critique et l'état de slave_skip_errors est ignoré. Le correctif garantit que, lorsque slave_skip_errors est activé, toutes les erreurs signalées lors de l'application d'une transaction sont correctement traitées. (Bogue n° 70640 et 17653275)

  • Correction d'un problème en raison duquel une SET PASSWORDinstruction était répliquée d'un maître My SQL 5.6 vers un esclave My SQL 5.7, ou d'un maître My SQL 5.7 avec la variable système log_builtin_as_identified_by_password définie sur ON sur un esclave My SQL 5.7. Le hachage du mot de passe était lui-même haché avant d'être stocké sur l'esclave. Le problème est maintenant résolu et le hachage du mot de passe répliqué est stocké tel qu'il a été initialement transmis à l'esclave. (Bogue n° 24687073)

  • Correction d'un problème en raison duquel la sérialisation d'une JSON valeur constituée d'un sous-document volumineux enveloppé dans de nombreux niveaux de JSON tableaux, d'objets, ou les deux, nécessitait parfois un temps excessif. (Bogue n° 23031146)

  • Les instructions qui ne peuvent pas être analysées (en raison, par exemple, d'erreurs de syntaxe) ne sont plus écrites dans le journal des requêtes lentes. (Bogue n° 33732907)

Mises à jour du moteur de base de données Aurora MySQL du 01/11/2021 (version 2.10.3) (obsolète)

2.10.3

  • Correction d'un problème causé par le code de lecture des informations sur le jeu de caractères issues des tables d'événements d'une instruction du schéma de performance (par exemple, events_statements_current) qui n'empêche pas l'écriture simultanée de ces informations sur le jeu de caractères. Par conséquent, le jeu de caractères du texte de la SQL requête n'est peut-être pas valide, ce qui peut entraîner la fermeture du serveur. Avec ce correctif, un jeu de caractères non valide entraîne la troncature de TEXT la colonne SQL _ et empêche le serveur de quitter le serveur. (Bogue n° 23540008)

  • Correction d'un problème lorsqu'une table temporaire ayant une clé primaire de plus de 1024 octets était UPDATE requise et que cette table avait été créée à l'aide d'InnoDB, le serveur pouvait se fermer. (Bogue n° 25153670)

Mises à jour du moteur de base de données Aurora MySQL du 21/01/2022 (version 2.10.2) (obsolète)

2.10.2

  • Correction d'un problème dans InnoDB où une erreur de code liée aux statistiques de table déclenchait une assertion dans le fichier source dict0stats.cc (http://dict0stats.cc/). (Bogue n°24585978)

  • Un index secondaire sur une colonne virtuelle a été corrompu lorsque l'index a été créé en ligne. Pour les instructions UPDATE (https://dev.mysql.com/doc/refman/5.7/en/update.html), nous corrigeons ce problème comme suit : si la valeur de la colonne virtuelle de l'enregistrement d'index est définie surNULL, nous générons cette valeur à partir de l'enregistrement d'index du cluster. (Bogue n°30556595)

  • ASSERTION« ! OTHER_ LOCK "DANS LOCK _ REC _ ADD _À_ QUEUE (Bug #29195848)

  • HANDLE_ FATAL _ SIGNAL (SIG=11) DANS __ STRCHR _ SSE2 (Bug #28653104)

  • Correction d'un problème pour lequel une interruption de requête pendant un temps d'attente de verrouillage pouvait entraîner une erreur dans InnoDB. (bogue n°28068293)

  • Les transactions entrelacées pouvaient parfois bloquer l'applicateur de répliques lorsque le niveau d'isolation des transactions était défini sur. REPEATABLE READ (Bogue n° 25040331)

  • Correction d'un problème qui pouvait entraîner le blocage des réplicas de journaux binaires en raison du délai d'attente du verrouillage. (bogue n°27189701)

Mises à jour du moteur de base de données Aurora MySQL du 21/10/2021 (version 2.10.1) (obsolète)

2.10.1

CURRENT_ TIMESTAMP PRODUCES ZEROS DANSTRIGGER. (Bogue n° 25209512)

Mises à jour du moteur de base de données Aurora MySQL du 25/05/2021 (version 2.10.0) (obsolète)

2.10.0

  • Les transactions entrelacées pouvaient parfois bloquer l'applicateur de répliques lorsque le niveau d'isolation des transactions était défini sur. REPEATABLEREAD (Bogue n° 25040331)

  • Lorsqu'une procédure stockée contenait une instruction faisant référence à une vue qui, à son tour, faisait référence à une autre vue, la procédure n'a pas pu être invoquée avec succès plus d'une fois. (Bogue n° 87858 et n° 26864199)

  • Pour les requêtes comportant de nombreuses conditions OR, l'optimiseur est désormais plus efficace en mémoire et moins susceptible de dépasser la limite de mémoire imposée par la variable système range_optimizer_max_mem_size. En outre, la valeur par défaut de cette variable est passée de 1 536 000 à 8 388 608. (Bogue n° 79450 et n° 22283790)

  • Réplication : dans la next_event() fonction, qui est appelée par le SQL thread d'une réplique pour lire l'événement suivant dans le journal du relais, le SQL thread n'a pas libéré le message acquis lorsqu'relaylog.log_lockil a rencontré une erreur (par exemple, à cause d'un journal de relais fermé), ce qui a entraîné le blocage de tous les autres threads en attente d'un verrou sur le journal du relais. Avec ce correctif, le verrou est relâché avant que le SQL fil ne quitte la fonction dans la situation. (Bogue n° 21697821)

  • Correction d'une corruption de mémoire pour ALTER TABLE avec une colonne virtuelle. (Bogue n° 24961167 et n° 24960450)

  • Réplication : les réplicas multithreads ne pouvaient pas être configurés avec de petites files d'attente à l'aide de slave_pending_jobs_size_max s'ils avaient besoin de traiter des transactions supérieures à cette taille. Tout paquet plus grand que slave_pending_jobs_size_max était rejeté avec l'erreur ER_MTS_EVENT_BIGGER_PENDING_JOBS_SIZE_MAX, même si le paquet était inférieur à la limite fixée par slave_max_allowed_packet. Avec ce correctif, slave_pending_jobs_size_max devient une limite flexible plutôt qu'une limite stricte. Si la taille d'un paquet dépasse slave_pending_jobs_size_max, mais est inférieure à slave_max_allowed_packet, la transaction est conservée jusqu'à ce que tous les workers de réplica aient des files d'attente vides, puis traitées. Toutes les transactions suivantes sont conservées jusqu'à ce que la transaction volumineuse soit terminée. La taille de la file d'attente des workers de réplica peut donc être limitée tout en autorisant des transactions occasionnelles plus importantes. (Bogue n° 21280753 et n° 77406)

  • Réplication : lors de l'utilisation d'un réplica multithread, les erreurs d'application affichaient des données d'ID de worker incohérentes avec les données externalisées dans les tables de réplique Schéma de performances. (Bogue n° 25231367)

  • Réplication : Sur une réplication GTID basée sur une réplication exécutée avec -GTID-Mode=ON, -log-bin= et utilisant -, lorsqu'une erreur rencontréeOFF, qui devait être ignoréeslave-skip-errors, n'était pas correctement mise à jour, ce qui Exec_Master_Log_Pos entraînait une perte de synchronisation avec. Exec_Master_Log_Pos Read_master_log_pos Si a n'GTID_NEXTétait pas spécifié, le réplica ne mettrait jamais à jour son GTID état lors de l'annulation d'une seule transaction de relevé. Le ne Exec_Master_Log_Pos serait pas mis à jour car même si la transaction était terminée, son GTID état indiquerait le contraire. Le correctif supprime la contrainte de mise à jour de l'GTIDétat lorsqu'une transaction est annulée uniquement si cela GTID_NEXT est spécifié. (Bogue n° 22268777)

  • Réplication : une instruction partiellement échouée ne consommait pas correctement une instruction générée ou spécifiée automatiquement GTID lorsque la journalisation binaire était désactivée. Le correctif garantit qu'un échec partiel DROPTABLE, un échec partiel ou un échec DROPUSERpartiel DROPVIEWconsomme respectivement le contenu pertinent GTID et l'enregistre dans @@GLOBAL.GTID_EXECUTED une mysql.gtid_executed table lorsque la journalisation binaire est désactivée. (Bogue n° 21686749)

  • Réplication : les répliques exécutant My SQL 5.7 n'ont pas pu se connecter à une source My SQL 5.5 en raison d'une erreur lors de la récupération du server_uuid, qui ne fait pas partie de My 5.5. SQL Cela était causé par des changements dans la méthode de récupération du server_uuid. (Bogue n° 22748612)

  • Réplication du journal binaire : le mécanisme de saut de GTID transaction ne fonctionnait pas correctement pour la transaction XA avant ce correctif. Le serveur dispose d'un mécanisme permettant d'ignorer (silencieusement) une GTID transaction s'il a déjà été exécutée par le passé. (BUG#25041920)

  • ROLLBACKLes instructions XA qui échouaient en raison d'un identifiant de transaction incorrect pouvaient être enregistrées dans le journal binaire avec l'identifiant de transaction correct et pouvaient donc être exécutées par des répliques de réplication. Une vérification est maintenant effectuée pour la situation d'erreur avant que la journalisation binaire n'ait lieu et les instructions ROLLBACK XA échouées ne sont pas consignées. (Bogue n° 26618925)

  • Réplication : si une réplique a été configurée à l'aide d'une instruction CHANGEMASTERTO qui ne spécifiait ni le nom du fichier journal source ni la position du journal source, puis STARTSLAVEarrêtée avant d'être émise, puis redémarrée avec l'option - relay-log-recovery set, la réplication n'a pas démarré. Cela se produisait parce que le thread du récepteur n'avait pas été démarré avant la tentative de récupération du journal de relais. Par conséquent, aucun événement de rotation du journal n'était disponible dans le journal de relais pour fournir le nom du fichier journal source et la position du journal source. Dans ce cas, le réplica ignore désormais la récupération du journal de relais et consigne un avertissement, puis démarre la réplication. (Bogue n° 28996606 et n° 93397)

  • Réplication : dans la réplication basée sur les lignes, un message qui affichait mal les longueurs de champ était renvoyé lors de la réplication à partir d'une table comportant une colonne utf8mb3 vers une table de la même définition que celle où la colonne était définie avec un jeu de caractères utf8mb4. (Bogue n° 25135304 et n° 83918)

  • Réplication : lorsqu'une RESETSLAVEinstruction était émise sur une réplique de réplication GTIDs en cours d'utilisation, les fichiers journaux de relais existants étaient purgés, mais le nouveau fichier journal de relais de remplacement était généré avant que l'ensemble des fichiers reçus GTIDs pour le canal n'ait été effacé. L'ancien GTID ensemble a donc été écrit dans le nouveau fichier journal du relais en tant qu'PREVIOUS_GTIDSévénement, provoquant une erreur fatale lors de la réplication indiquant que la réplique contenait GTIDs plus que la source, même si l'ensemble gtid_executed pour les deux serveurs était vide. Désormais, lorsqu'il RESET SLAVE est émis, l'ensemble des données reçues GTIDs est effacé avant que le nouveau fichier journal de relais ne soit généré, de sorte que cette situation ne se produise pas. (Bogue n° 27411175)

  • Réplication : GTIDs lors de l'utilisation pour la réplication, les transactions comprenant des instructions ayant provoqué une erreur d'analyse (ER_ PARSE _ ERROR) ne pouvaient pas être ignorées manuellement selon la méthode recommandée consistant à injecter une transaction vide ou de remplacement par celle-ci. GTID Cette action doit permettre à la réplique d'identifier le GTID comme étant déjà utilisé, et donc d'ignorer la transaction indésirable qui a partagé sonGTID. Cependant, dans le cas d'une erreur d'analyse, l'instruction ayant été analysée avant d'être vérifiée pour voir si elle devait être ignorée, le thread d'application de réplication s'est arrêté en raison de l'erreur d'analyse, même si l'intention était que la transaction soit ignorée de toute façon. GTID Avec ce correctif, le thread d'application de réplication ignore désormais les erreurs d'analyse si la transaction concernée doit être ignorée parce qu'elle a déjà été utilisée. GTID Notez que ce changement de comportement ne s'applique pas dans le cas d'applications constituées d'une sortie de journal binaire produite par mysqlbinlog. Dans ce cas, il y aurait un risque qu'une transaction comportant une erreur d'analyse qui suit immédiatement une transaction ignorée soit également ignorée, alors qu'elle devrait générer une erreur. (Bogue n° 27638268)

  • Réplication : permet au SQL thread d'GTIDignorer une transaction partielle. (Bogue n° 25800025)

  • Réplication : lorsqu'un paramètre de délai d'expiration négatif ou fractionnaire avait été fourni à WAIT_UNTIL_SQL_THREAD_AFTER_GTIDS(), le serveur se comportait de manière inattendue. Avec ce correctif :

    • une valeur de délai d'expiration fractionnaire est lue telle quelle, sans arrondi ;

    • Une valeur de délai d'attente négative est rejetée avec une erreur si le serveur est SQL en mode strict ; si le serveur n'est pas SQL en mode strict, la valeur fait revenir la fonction NULL immédiatement sans attente, puis émet un avertissement. (Bogue n° 24976304 et n° 83537)

  • Réplication : si la fonction WAIT_FOR_EXECUTED_GTID_SET() avait été utilisée avec une valeur de délai d'expiration incluant une partie fractionnée (par exemple, 1,5), une erreur dans la logique de conversion de types signifiait que le délai d'expiration était arrondi à la seconde entière la plus proche et à zéro pour les valeurs inférieures à 1 seconde (par exemple, 0,1). La logique de conversion de types a maintenant été corrigée de sorte que la valeur du délai d'expiration soit appliquée comme indiqué initialement sans arrondi. Merci à Dirkjan Bussink pour sa contribution. (Bogue n° 29324564 et n° 94247)

  • GTIDsLorsque cette option est activée, XA COMMIT sur une transaction XA déconnectée dans le cadre d'une transaction à déclarations multiples a émis une assertion. (Bogue n° 22173903)

  • Réplication : une assertion était émise dans les versions de débogage si une ROLLBACK instruction XA était émise pour un identifiant de transaction inconnu alors que la valeur gtid_next avait été définie manuellement. Le serveur ne tente désormais pas de mettre à jour l'GTIDétat si une ROLLBACK instruction XA échoue avec une erreur. (Bogue n° 27928837 et n° 90640)

  • Correction d'un problème d'ordre de tri erroné lorsque plusieurs fonctions CASE sont utilisées dans la clause ORDER BY. (Bogue n° 22810883)

  • Certaines requêtes utilisant le tri pouvaient accéder à une colonne non initialisée lors de l'optimisation et provoquer la fermeture du serveur. (Bogue n° 27389294)

Mises à jour du moteur de base de données Aurora MySQL du 12/11/2022 (version 2.09.3) (obsolète)

2,09.3

  • ASSERTION! M_ PREBUILT -> TRX -> CHECK _FOREIGNS. (Bogue n° 23533396)

  • Réplication :* Un problème de verrouillage dans la fonction WAIT FOR EXECUTED GTID _ _ _ _ SET () peut entraîner le blocage du serveur dans certaines circonstances. Ce problème a été corrigé. (Bogue n° 29550513)

Mises à jour du moteur de base de données Aurora MySQL du 11/12/2020 (version 2.09.1) (obsolète)

2.09.1

  • Réplication : les transactions entrelacées pouvaient parfois bloquer l'applicateur esclave lorsque le niveau d'isolation des transactions était défini sur. REPEATABLEREAD (Bogue n° 25040331)

  • Pour une table ayant une DATETIMEcolonne TIMESTAMPou dont la valeur par défaut est CURRENT_ TIMESTAMP, la colonne peut être initialisée 0000-00-00 00:00:00 si la table possède un BEFORE INSERT déclencheur. (Bogue n° 25209512, Bogue n° 84077)

  • Pour une INSERTinstruction pour laquelle la VALUES liste produisait des valeurs pour la deuxième ligne ou les lignes suivantes à l'aide d'une sous-requête contenant une jointure, le serveur pouvait se fermer si les privilèges requis n'avaient pas été résolus. (Bogue n° 23762382)

Mises à jour du moteur de base de données Aurora MySQL du 12/11/2022 (version 2.08.3) (obsolète)

2.08.3

  • Bug #23762382 - INSERT VALUES QUERY WITH JOIN EN SELECT CAUSES INCORRECT BEHAVIOR A.

  • Bug #25209512 - CURRENT _ TIMESTAMP PRODUCES ZEROS INTRIGGER.

Mises à jour du moteur SQL de base de données Aurora My 2020-06-02 (version 2.08.0) (obsolète)

2.08.0

  • Bogue #25289359 : un verrou de cache de texte intégral pris lors de la synchronisation des données n'était pas libéré si la taille du cache de texte intégral dépassait la limite de taille du cache de texte intégral.

  • Bug #29138644 : La modification manuelle de l'heure du système alors que Mon SQL serveur était en cours d'exécution entraînait des retards dans le thread de nettoyage des pages.

  • Bug #25222337 : Un nom de champ de colonne NULL virtuelle dans un index virtuel a provoqué la fermeture du serveur lors d'une comparaison de noms de champ qui a lieu lors du remplissage de colonnes virtuelles affectées par une contrainte de clé étrangère.

  • Bogue #25053286 : l'exécution d'une procédure stockée contenant une requête qui a accédé à une vue pouvait allouer de la mémoire qui n'était pas libérée jusqu'à la fin de la session.

  • Bug #25586773 : L'exécution d'une procédure stockée contenant une instruction qui a créé une table à partir du contenu de certaines SELECTinstructions peut entraîner une fuite de mémoire.

  • Bug #28834208 : Pendant l'application du journal, après une OPTIMIZETABLEopération, InnoDB ne remplissait pas les colonnes virtuelles avant de vérifier les mises à jour de l'index des colonnes virtuelles.

  • Bogue #26666274 : boucle infinie dans le conteneur de mémoire tampon de schéma de performance en raison d'un dépassement d'entier non signé 32 bits.

Mises à jour du moteur de base de données Aurora MySQL du 16/06/2022 (version 2.07.8) (obsolète)

2,07.8

Lorsqu'un avait UPDATE besoin d'une table temporaire ayant une clé primaire supérieure à 1024 octets et que cette table était créée à l'aide d'InnoDB, le serveur pouvait se fermer. (Bogue n° 25153670)

Mises à jour du moteur de base de données Aurora MySQL du 02/09/2021 (version 2.07.6) (obsolète)

2,07.6

  • INSERTING64 Ko. SIZE RECORDS TAKE TOO MUCH TIME (Bogue n° 23031146)

Mises à jour du moteur de base de données Aurora MySQL du 04/03/2021 (version 2.07.) (obsolète)

2.07.4

  • Correction d'un problème dans l'analyseur n-gram de texte intégral lors de la gestion de jetons contenant « » (espace), « % » ou « , ». Les clients doivent reconstruire leurs FTS index s'ils utilisent l'analyseur ngram. (Bogue n° 25873310)

  • Correction d'un problème qui pouvait provoquer le redémarrage du moteur lors de l'exécution d'une requête avec des SQL vues imbriquées. (Bogue n° 27214153, Bogue n° 26864199)

Mises à jour du moteur de base de données Aurora MySQL du 10/11/2020 (version 2.07.3) (obsolète)

2.07.3

  • InnoDB : les transactions XA simultanées exécutées avec succès pour la phase de préparation XA sur le maître étaient en conflit lorsqu'elles étaient réutilisées sur l'esclave, entraînant ainsi un délai d'attente de verrouillage dans le thread applicateur. Le conflit était dû à la plage de GAP verrouillage qui différait lorsque les transactions étaient rejouées en série sur l'esclave. Pour éviter ce type de conflit, les GAP verrous pris par les transactions XA au niveau READCOMMITTEDd'isolement sont désormais libérés (et ne sont plus hérités) lorsque les transactions XA atteignent l'étape de préparation. (Bogue n° 27189701, Bogue n° 25866046)

  • InnoDB : Un verrou d'écart a été bloqué inutilement lors de la validation de la clé étrangère lors de l'utilisation du READCOMMITTEDniveau d'isolation. (Bogue n° 25082593)

  • Réplication : lors de l'utilisation de transactions XA, si un délai d'attente ou un blocage se produisait pour le thread applicateur (SQL) sur un esclave de réplication, la nouvelle tentative automatique ne fonctionnait pas. La cause était que même si le SQL thread effectuait une annulation, il n'annulait pas la transaction XA. Cela signifie que lorsque la transaction a été réessayée, le premier événement était XA, START qui n'était pas valide car la transaction XA était déjà en cours, ce qui a entraîné une RMFAIL erreur XAER _. (Bogue n° 24764800)

  • Réplication : les transactions entrelacées pouvaient parfois bloquer l'applicateur esclave lorsque le niveau d'isolation des transactions était défini sur. REPEATABLEREAD (Bogue n° 25040331)

  • Réplication : la valeur renvoyée par une SHOWSLAVESTATUSinstruction pour la taille totale combinée de tous les fichiers journaux de relais existants (Relay_Log_Space) peut devenir bien supérieure à l'espace disque réellement utilisé par les fichiers journaux de relais. Le thread d'E/S ne verrouillait pas la variable lors de la mise à jour de la valeur, de sorte qu'il pouvait automatiquement supprimer un fichier journal de relais et écrire une valeur réduite avant que le thread d'E/S n'ait fini de mettre à jour la valeur. SQL Le thread d'E/S a ensuite écrit son calcul de taille d'origine, en ignorant la mise à jour du SQL thread et en ajoutant ainsi de l'espace pour le fichier supprimé. La valeur Relay_Log_Space est désormais verrouillée pendant les mises à jour afin d'empêcher les mises à jour simultanées et de garantir un calcul précis. (Bogue n° 26997096, Bogue n° 87832)

  • Pour une INSERTinstruction pour laquelle la VALUES liste produisait des valeurs pour la deuxième ligne ou les lignes suivantes à l'aide d'une sous-requête contenant une jointure, le serveur pouvait se fermer si les privilèges requis n'avaient pas été résolus. (Bogue n° 23762382)

  • Pour une table ayant une DATETIMEcolonne TIMESTAMPou dont la valeur par défaut est CURRENT_ TIMESTAMP, la colonne peut être initialisée 0000-00-00 00:00:00 si la table possède un BEFORE INSERT déclencheur. (Bogue n° 25209512, Bogue n° 84077)

  • Les tentatives simultanées de plusieurs threads pour enregistrer et annuler l'enregistrement des objets de schéma de performances de métadonnées pouvaient entraîner l'arrêt d'un serveur. (Bogue n° 26502135)

  • L'exécution d'une procédure stockée contenant une instruction qui a créé une table à partir du contenu de certaines SELECTinstructions peut entraîner une fuite de mémoire. (Bogue n° 25586773)

  • L'exécution d'une procédure stockée contenant une requête qui avait accédé à une vue pouvait allouer de la mémoire qui n'était pas libérée avant la fin de la séance. (Bogue n° 25053286)

  • Certains cas de matérialisation de sous-requête pouvaient provoquer l'arrêt d'un serveur. Ces requêtes produisent maintenant une erreur suggérant que la matérialisation doit être désactivée. (Bogue #26402045)

  • Les requêtes avec de nombreuses jointures gauches étaient lentes si la mise en mémoire tampon de jointure était utilisée (par exemple, à l'aide de l'algorithme de boucle imbriquée par bloc). (Bogue n° 18898433, Bogue n° 72854)

  • L'optimiseur ignorait la deuxième colonne d'un index composite lors de l'exécution d'une jointure interne avec une clause LIKE sur la deuxième colonne. (Bogue n° 28086754)

Mises à jour du moteur SQL de base de données Aurora My 2020-04-17 (version 2.07.2) (obsolète)

2.07.2

Mises à jour du moteur SQL de base de données Aurora My 2019-11-25 (version 2.07.0) (obsolète)

2.07.0

  • Insecte #26251621 : INCORRECT BEHAVIOR WITH TRIGGER AND GCOL

  • Bug #22574695 : ASSERTION `! TABLE || (! TABLE-> READ _ SET || BITMAP _EST_ SET (TABLE-> READ _, SET FIEL

  • Bug #25966845 : INSERT SUR DUPLICATE KEY GENERATE A DEADLOCK

  • Insecte #23070734 : CONCURRENT TRUNCATE TABLES CAUSE STALL

  • Insecte #26191879 : FOREIGN KEY CASCADES USE EXCESSIVE MEMORY

  • Insecte #20989615 : INNODB AUTO _ INCREMENT PRODUCES SAME VALUE TWICE

Mises à jour du moteur SQL de base de données Aurora My 2019-11-11 (version 2.05.0) (obsolète)

2.05.0

  • Bug #23054591 : PURGE BINARY LOGS TO lit l'intégralité du fichier binlog et provoque MySql le blocage

Mises à jour du moteur SQL de base de données Aurora My 2020-08-14 (version 2.04.9) (obsolète)

2.04.9

  • Bug #23070734, Bug #80060 : TRUNCATE TABLEs causes simultanées bloquant

  • Bug #23103937 : PS_ TRUNCATE _ ALL _ TABLES () DOES NOT WORK DANS SUPER _ _ READ ONLY MODE

  • Bogue n° #22551677 : lorsque vous mettez le serveur hors connexion, une condition de concurrence dans le schéma de performances peut entraîner la sortie du serveur.

  • Bug #27082268 : synchronisation de FTS synchronisation non valide.

  • BUG#12589870 : Correction d'un problème qui provoquait un redémarrage avec une instruction multi-requêtes lorsque le cache de requêtes était activé.

  • Bogue n° 26402045 : certains cas de matérialisation de sous-requête peuvent provoquer la sortie d'un serveur. Ces requêtes produisent maintenant une erreur suggérant que la matérialisation doit être désactivée.

  • Bogue n° 18898433 : les requêtes avec de nombreuses jointures gauche étaient lentes si la mise en mémoire tampon de jointure était utilisée (par exemple, en utilisant l'algorithme de boucle imbriquée par bloc).

  • Bug #25222337 : Un nom de champ de colonne NULL virtuelle dans un index virtuel a provoqué la fermeture du serveur lors d'une comparaison de noms de champ qui a lieu lors du remplissage de colonnes virtuelles affectées par une contrainte de clé étrangère. (https://github.com/mysql/mysql-server/commit/273d5c9d7072c63b6c47dbef6963d7dc491d5131)

  • Bogue n° 25053286 : l'exécution d'une procédure stockée contenant une requête qui a accédé à une vue pouvait allouer de la mémoire qui n'était pas libérée jusqu'à la fin de la session. (https://github.com/mysql/mysql-server/commit/d7b37d4d141a95f577916448650c429f0d6e193d)

  • Bug #25586773 : L'exécution d'une procédure stockée contenant une instruction qui a créé une table à partir du contenu de certaines instructions SELECT (https://dev.mysql.com/doc/refman/5.7/en/select.html) peut entraîner une fuite de mémoire. (https://github.com/mysql/mysql-server/commit/88301e5adab65f6750f66af284be410c4369d0c1)

  • Bug #26666274 : INFINITE LOOP OK PERFORMANCE SCHEMA BUFFERCONTAINER.

  • Bug #23550835, Bug #23298025, Bug #81464 : un schéma de SELECT performance table lorsqu'une mémoire tampon interne est pleine peut entraîner la fermeture du serveur.

Mises à jour du moteur SQL de base de données Aurora My 2019-09-19 (version 2.04.6) (obsolète)

2.04.6

  • Bug #23054591 : PURGE BINARY LOGS TO lit l'intégralité du fichier binlog et provoque MySql le blocage

Mises à jour du moteur SQL de base de données Aurora My 2019-05-02 (version 2.04.2) (obsolète)

2.04.2

Insecte #24829050 - INDEX _ MERGE _ INTERSECTION OPTIMIZATION CAUSES WRONG QUERY RESULTS

Mises à jour du moteur SQL de base de données Aurora My 2018-10-11 (version 2.03) (obsolète)

2.03

  • REVERSESCANSUR A PARTITIONED TABLE DOES ICP - ORDER BY DESC (Bug #24929748).

  • JSON_ OBJECT CREATES INVALID JSON CODE (Bug #26867509).

  • INSERTINGLARGEJSONDATATAKESUN INORDINATE AMOUNT OF TIME (Bug #22843444).

  • PARTITIONEDTABLESUSEMOREMEMORYIN 5.7 THAN 5.6 (Bug #25080442).

Mises à jour du moteur SQL de base de données Aurora My 2018-09-21 (version 2.02.4) (obsolète)

2.02.4

  • BUG#13651665 INNODB MAY BE UNABLE TO LOAD TABLE DEFINITION AFTER RENAME

  • BUG#21371070 INNODB: CANNOT ALLOCATE 0 BYTES.

  • BUG#21378944 FTS ASSERT ENC.SRC_ILIST_PTR != NULL, FTS_OPTIMIZE_WORD(), OPTIMIZE TABLE

  • BUG#21508537 ASSERTION FAILURE UT_A(!VICTIM_TRX->READ_ONLY)

  • BUG#21983865 UNEXPECTED DEADLOCK WITH INNODB_AUTOINC_LOCK_MODE=0

  • BUG#22679185 INVALID INNODB FTS DOC ID DURING INSERT

  • BUG#22899305 GCOLS: ASSERTION: !(COL->PRTYPE & 256).

  • BUG#22956469 MEMORY LEAK INTRODUCED IN 5.7.8 IN MEMORY/INNODB/OS0FILE

  • BUG#22996488 CRASH IN FTS_SYNC_INDEX WHEN DOING DDL IN A LOOP

  • BUG#23014521 GCOL:INNODB: ASSERTION: !IS_V

  • BUG#23021168 REPLICATION STOPS AFTER TRX IS ROLLED BACK ASYNC

  • BUG#23052231 ASSERTION: ADD_AUTOINC < DICT_TABLE_GET_N_USER_COLS

  • BUG#23149683 ROTATE INNODB MASTER KEY WITH KEYRING_OKV_CONF_DIR MISSING: SIGSEGV; SIGNAL 11

  • BUG#23762382 INSERT VALUES QUERY WITH JOIN IN A SELECT CAUSES INCORRECT BEHAVIOR

  • BUG#25209512 CURRENT_TIMESTAMP PRODUCES ZEROS IN TRIGGER

  • BUG#26626277 BUG IN "INSERT... ON DUPLICATE KEY UPDATE" QUERY

  • BUG#26734162 INCORRECT BEHAVIOR WITH INSERT OF BLOB + ON DUPLICATE KEY UPDATE

  • BUG#27460607 INCORRECT WHEN INSERT SELECT's SOURCE TABLE IS EMPTY

Mises à jour du moteur SQL de base de données Aurora My 2018-05-03 (version 2.02) (obsolète)

2.02.0

La jointure gauche retourne des résultats incorrects du côté extérieur (Bogue n° 22833364)

Mes SQL bogues corrigés par les mises à jour du moteur de base de données Aurora My SQL 1.x

Ma version SQL compatible avec la version 5.6 Aurora contient toutes les corrections de SQL bogues de My 5.6.10. SQL Le tableau suivant identifie les SQL bogues My supplémentaires qui ont été corrigés par les mises à jour du moteur de SQL base de données Aurora My, ainsi que la mise à jour dans laquelle ils ont été corrigés.

Mise à jour du moteur de base de données Version Mes SQL bugs corrigés
Mises à jour du moteur de base de données Aurora MySQL du 18/03/2021 (version 1.23.2) (obsolète) 1.23.2
  • Réplication : pendant l'exécution d'une instruction SHOW BINLOG EVENTS, toute transaction parallèle a été bloquée. Le correctif garantit que le processus SHOW BINLOG EVENTS n'acquiert désormais un verrou que pendant la durée du calcul de la position finale du fichier ; par conséquent, les transactions parallèles ne sont pas bloquées pendant de longues durées. (Bogue n° 76618, Bogue n° 20928790)

Mises à jour du moteur de base de données Aurora MySQL du 02/09/2020 (version 1.23.0) (obsolète) 1.23.0
  • Les événements Binlog avec ALTER TABLE ADD COLUMN ALGORITHM=QUICK seront réécrits en tant que ALGORITHM=DEFAULT de manière à être compatibles avec l'édition de la communauté.

  • BUG#22350047 : SI C'EST CLIENT KILLED AFTER ROLLBACK LE CAS SAVEPOINT PREVIOUS STMTS COMMITTED

  • Bug #29915479 : RUNNING COM _ REGISTER _ SLAVE WITHOUT COM _ BINLOG _ DUMP CAN RESULTS IN SERVER EXIT

  • Bug #30441969 : BUG #29723340 : MYSQL SERVER CRASH AFTER SQL QUERY WITH DATA ? AST

  • Bug #30628268 : OUT FR MEMORY CRASH

  • Insecte #27081349 : UNEXPECTED BEHAVIOUR WHEN DELETE WITH SPATIAL FUNCTION

  • Insecte #27230859 : UNEXPECTED BEHAVIOUR WHILE HANDLING INVALID POLYGON »

  • Insecte #27081349 : UNEXPECTED BEHAVIOUR WHEN DELETE WITH SPATIAL »

  • Bug #26935001 : ALTER TABLE AUTO _ INCREMENT TRIES TO READ INDEX FROM DISCARDED TABLESPACE

  • Insecte #29770705 : SERVER CRASHED WHILE EXECUTING SELECT WITH SPECIFIC WHERE CLAUSE

  • Insecte #27659490 : SELECT USING DYNAMIC RANGE AND INDEX MERGE USE TOO MUCH MEMORY (OOM)

  • Bug #24786290 : REPLICATION BREAKS AFTER BUG #74145 HAPPENS IN MASTER

  • Insecte #27703912 : EXCESSIVE MEMORY USAGE WITH MANY PREPARE

  • Bug #20527363 TRUNCATE TEMPORARY TABLE CRASH : ! DICT_ TF2 _ FLAG _EST_ SET (TABLE, _ DICT _TF2) TEMPORARY

  • Bug #23103937 PS_ TRUNCATE _ ALL _ TABLES () DOES NOT WORK DANS SUPER _ _ READ ONLY MODE

  • Bug #25053286 : USE VIEW WITH CONDITION IN PROCEDURE CAUSES INCORRECT BEHAVIOR (corrigé dans la version 5.6.36)

  • Bug #25586773 : INCORRECT BEHAVIOR FOR CREATE TABLE SELECT IN A LOOP IN SP (corrigé dans la version 5.6.39)

  • Bug #27407480 : AUTOMATIC _SP_ PRIVILEGES REQUIRES NEED THE INSERT PRIVILEGES FORMYSQL. USERTABLE

  • Bogue #26997096 : la valeur de relay_log_space n'est pas mise à jour de manière synchronisée, de sorte qu'elle est parfois beaucoup plus élevée que l'espace disque réel utilisé par les journaux relais.

  • Bug #15831300 SLAVE TYPE _ _ CONVERSIONS = ALL _ NON _ LOSSY NOT WORKING AS EXPECTED

  • SSLRétroportage du bogue Bug #17087862, Bug #20551271

  • Bug #16894092 : PERFORMANCE REGRESSION IN 5.6.6+... FOR INSERT INTO SELECT... FROM(corrigé dans la version 5.6.15).

  • Porter un correctif de bogue lié à SLAVE_TYPE_CONVERSIONS.

Mises à jour du moteur de base de données Aurora MySQL du 19/11/2020 (version 1.22.3) (obsolète) 1.22.3
  • Bogue n° 26654685 : Un ID d'index corrompu rencontré lors d'une vérification de clé étrangère déclenchait une assertion.

  • Bug #15831300 : Par défaut, lors de la promotion d'entiers d'un type plus petit sur le maître vers un type plus grand sur l'esclave (par exemple, d'une SMALLINTcolonne sur le maître vers une BIGINTcolonne sur l'esclave), les valeurs promues sont traitées comme si elles étaient signées. Dans de tels cas, il est possible de modifier ou de remplacer ce comportement à l'aide de ALL_SIGNED, de ALL_UNSIGNED ou des deux dans l'ensemble des valeurs spécifiées pour la variable système serveur slave_type_conversions. Pour en savoir plus, consultez la section Row-based replication: attribute promotion and demotion, ainsi que la description de la variable.

  • Bogue n° 17449901 : Avec foreign_key_checks=0, InnoDB permettait de supprimer un index requis par une contrainte de clé étrangère, plaçant la table dans une incohérence et provoquant l'échec de la vérification de la clé étrangère lors du chargement de la table. InnoDB empêche désormais de supprimer un index requis par une contrainte de clé étrangère, même avec foreign_key_checks=0. La contrainte de clé étrangère doit être supprimée avant de supprimer l'index de clé étrangère.

  • BUG#20768847 : Un ALTERTABLE... DROPINDEXune opération sur une table avec des dépendances de clé étrangère a généré une assertion.

Mises à jour du moteur de base de données Aurora MySQL du 25/11/2019 (version 1.22.0) (obsolète) 1.22.0
  • Bug #16346241 - SERVER CRASH DANS ITEM _ PARAM : : QUERY _ VAL _ STR

  • Bug #17733850 - NAME _ CONST () CRASH DANS ITEM _ NAME _ CONST : : ITEM _ NAME _ CONST ()

  • Insecte #20989615 - INNODB AUTO _ INCREMENT PRODUCES SAME VALUE TWICE

  • Bug #20181776 - ACCESS CONTROL DOESN PAS MATCH MOST SPECIFIC HOST WHEN ÇA CONTAINS WILDCARD

  • Bug #27326796 - MYSQL CRASH WITH INNODB ASSERTION FAILURE IN FILE PARS 0 PARS .CC

  • Bug #20590013 - SI YOU HAVE FULLTEXT INDEX AND DROP C'EST YOU CAN NON LONGER PERFORM ONLINE DDL

Mises à jour du moteur de base de données Aurora MySQL du 25/11/2019 (version 1.21.0) (obsolète) 1.21.0
  • Bug #19929406 : HANDLE FATAL _ _ SIGNAL (SIG=11) DANS __ MEMMOVE _ SSSE3 _ BACK FROM STRING : COPY

  • Bug #17059925 : Pour les UNIONinstructions, la valeur des lignes examinées n'a pas été calculée correctement. Cela a donné des valeurs trop importantes pour la colonne ROWS_EXAMINED des tables de l'instruction Schéma des performances (par exemple, events_statements_current).

  • Bogue n° 11827369 : certaines requêtes avec des sous-requêtes imbriquées SELECT ... FROM DUAL ont généré une assertion.

  • Bug #16311231 : Des résultats incorrects étaient renvoyés si une requête contenait une sous-requête dans une IN clause contenant une XORopération dans la WHERE clause.

Mises à jour du moteur de base de données Aurora MySQL du 11/11/2019 (version 1.20.0) (obsolète) 1.20.0
  • Bug #19929406 : HANDLE FATAL _ _ SIGNAL (SIG=11) DANS __ MEMMOVE _ SSSE3 _ BACK FROM STRING : COPY

  • Bug #17059925 : Pour les UNIONinstructions, la valeur des lignes examinées n'a pas été calculée correctement. Cela a donné des valeurs trop importantes pour la colonne ROWS_EXAMINED des tables de l'instruction Schéma des performances (par exemple, events_statements_current).

  • Bogue n° 11827369 : certaines requêtes avec des sous-requêtes imbriquées SELECT ... FROM DUAL ont généré une assertion.

  • Bug #16311231 : Des résultats incorrects étaient renvoyés si une requête contenait une sous-requête dans une IN clause contenant une XORopération dans la WHERE clause.

Mises à jour du moteur de base de données Aurora MySQL du 19/09/2019 (version 1.19.5) (obsolète) 1.19.5
  • CVE-2018-2696

  • CVE-2015-4737

  • Bug #19929406 : HANDLE FATAL _ _ SIGNAL (SIG=11) DANS __ MEMMOVE _ SSSE3 _ BACK FROM STRING : COPY

  • Bug #17059925 : Pour les UNIONinstructions, la valeur des lignes examinées n'a pas été calculée correctement. Cela a donné des valeurs trop importantes pour la colonne ROWS_EXAMINED des tables de l'instruction Schéma des performances (par exemple, events_statements_current).

  • Bogue n° 11827369 : certaines requêtes avec des sous-requêtes imbriquées SELECT ... FROM DUAL ont généré une assertion.

  • Bug #16311231 : Des résultats incorrects étaient renvoyés si une requête contenait une sous-requête dans une IN clause contenant une XORopération dans la WHERE clause.

Mises à jour du moteur de base de données Aurora MySQL du 07/02/2019 (version 1.19.0) (obsolète) 1.19.0
  • BUG#32917 : DETECT ORPHAN TEMP - POOLFILES, AND HANDLE GRACEFULLY

  • BUG#63144 CREATE TABLE SI NOT EXISTS METADATA LOCK C'EST LE CAS TOO RESTRICTIVE

Mises à jour du moteur de base de données Aurora MySQL du 17/01/2019 (version 1.17.8) (obsolète) 1.17.8
  • BUG#13418638 : CREATE TABLE SI NOT EXISTS METADATA LOCK C'EST LE CAS TOO RESTRICTIVE

Mises à jour du moteur de base de données Aurora MySQL du 08/10/2018 (version 1.17.7) (obsolète) 1.17.7
  • Une opération Drop Index sur une colonne de clé étrangère entraîne un problème de table manquante. (Bogue n° 16208542)

  • Fuite de mémoire dans add_derived_key(). (Bogue n° 76349)

  • Pour les tables partitionnées, les requêtes peuvent renvoyer différents résultats en fonction de l'utilisation ou non de la fusion d'index. (Bogue n° 16862316)

  • Les requêtes utilisant l'optimisation index_merge (voir Optimisation de fusion d'index) pouvaient renvoyer des résultats non valides lorsqu'elles étaient exécutées sur des tables partitionnées par. HASH (Bogue n° 17588348)

Mises à jour du moteur de base de données Aurora MySQL du 06/09/2018 (version 1.17.6) (obsolète) 1.17.6
  • Pour une ALTERTABLEinstruction qui a renommé ou modifié la valeur par défaut d'une BINARYcolonne, la modification a été effectuée à l'aide d'une copie de tableau et non sur place. (Bogues n° 67141, 14735373, 69580 et 17024290)

  • Une jointure externe entre une table standard et une table dérivée qu'elle regroupe implicitement peut entraîner l'arrêt du serveur. (Bogue n° 16177639)

Mises à jour du moteur de base de données Aurora MySQL du 13/03/2018 (version 1.17) (obsolète) 1.17.0
  • LAST_ INSERT _ID est mal répliqué si des filtres de réplication sont utilisés (Bug #69861)

  • La requête renvoie des résultats différents selon que INDEX _ MERGE setting est ou non (Bug #16862316)

  • Réexécution de la routine stockée du traitement de requête, plan de requête inefficace (bogue n° 16346367)

  • InnoDB FTS : Assertion dans FTS _ _ CACHE _ APPEND _ DELETED DOC _ IDS (Bug #18079671)

  • Affirmer RBT _ EMPTY (INDEX_ CACHE ->WORDS) dans ALTER TABLE CHANGE COLUMN (Bug #17536995)

  • La recherche InnoDB en texte intégral ne trouve pas d'enregistrements lorsque des points de sauvegarde sont impliqués (bogue n° 70333, bogue n° 17458835)

Mises à jour du moteur de base de données Aurora MySQL du 20/11/2017 (version 1.15.1) (obsolète) 1.15.1
  • Annulé — Mon SQL instance bloque « doing SYNC index » (Bug #73816)

  • Inversé — RBT Affirme _ EMPTY (INDEX_ CACHE ->WORDS) dans ALTER TABLE CHANGE COLUMN (Bug #17536995)

  • Annulation — La recherche InnoDB en texte intégral ne trouve pas d'enregistrements lorsque des points de sauvegarde sont impliqués (bogue n° 70333)

Mises à jour du moteur de base de données Aurora MySQL du 24/10/2017 (version 1.15) (obsolète) 1.15.0
  • CREATEUSERaccepte le hachage du plugin et du mot de passe, mais ignore le hachage du mot de passe (Bug #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 indiquant que si vous utilisez key_cmp, au moins le premier champ doit être lu (Bug #16367691).

  • Mon SQL instance bloque « doing SYNC index » (Bug #73816)

  • Affirmer RBT _ EMPTY (INDEX_ CACHE ->WORDS) dans ALTER TABLE CHANGE COLUMN (Bug #17536995)

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

Mises à jour du moteur de base de données Aurora MySQL : 13/03/2018 (version 1.14.4) (obsolète) 1.14.4
  • Les événements pouvant être ignorés ne fonctionnent pas et ne sont pas testés (bogue n° 74683)

  • NEW-> OLD ASSERT FAILURE 'GTID_ MODE > 0' (Erreur #20436436)

Mises à jour du moteur de base de données Aurora MySQL : 07/08/2017 (version 1.14) (obsolète) 1.14.0

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)

Mises à jour du moteur de base de données Aurora MySQL : 15/05/2017 (version 1.13) (obsolète) 1.13.0
  • Le rechargement d'une table qui a été expulsée alors qu'elle était vide a entraîné la réinitialisation de INCREMENT la valeur AUTO _. (Bogues n° 21454472 et 77743)

  • Un enregistrement d'index a été introuvable à la restauration en raison d'incohérences dans la structure purge_node_t. Celles-ci ont entraîné des messages d'avertissement et d'erreur tels que « erreur dans la mise à jour de l'entrée d'index secondaire », « impossible de purger un enregistrement » et « tentative de purge de l'entrée d'index secondaire non marquée pour la suppression ». (Bogues n° 19138298, 70214, 21126772 et 21065746)

  • Le calcul incorrect de la taille de la pile de l'opération qsort entraîne un dépassement de la pile. (Bogue n° 73979)

  • Enregistrement introuvable dans un index à la restauration. (Bogues n° 70214 et 72419)

  • ALTERTABLEajouter une colonne TIMESTAMP lors de la mise à jour CURRENT _ TIMESTAMP insère ZERO -datas (Bug #17392)

Mises à jour du moteur de base de données Aurora MySQL : 05/04/2017 (version 1.12) (obsolète) 1.12.0
  • Le rechargement d'une table qui a été expulsée alors qu'elle était vide a entraîné la réinitialisation de INCREMENT la valeur AUTO _. (Bogues n° 21454472 et 77743)

  • Un enregistrement d'index a été introuvable à la restauration en raison d'incohérences dans la structure purge_node_t. Celles-ci ont entraîné des messages d'avertissement et d'erreur tels que « erreur dans la mise à jour de l'entrée d'index secondaire », « impossible de purger un enregistrement » et « tentative de purge de l'entrée d'index secondaire non marquée pour la suppression ». (Bogues n° 19138298, 70214, 21126772 et 21065746)

  • Le calcul incorrect de la taille de la pile de l'opération qsort entraîne un dépassement de la pile. (Bogue n° 73979)

  • Enregistrement introuvable dans un index à la restauration. (Bogues n° 70214 et 72419)

  • ALTERTABLEajouter une colonne TIMESTAMP lors de la mise à jour CURRENT _ TIMESTAMP insère ZERO -datas (Bug #17392)

Mises à jour du moteur de base de données Aurora MySQL : 23/02/2017 (version 1.11) (obsolète) 1.11.0
  • L'exécution de la clé DROP étrangère de la ALTER table en même temps qu'une autre DROP opération entraîne la disparition de la table. (Bogue n° 16095573)

  • Certaines SCHEMA requêtes INFORMATION _ qui utilisaient ORDER BY n'utilisaient pas d'optimisation de tri de fichiers comme c'était le cas auparavant. (Bogue n° 16423536)

  • FOUND_ ROWS () renvoie le mauvais nombre de lignes d'un tableau. (Bogue n° 68458)

  • Le serveur échoue au lieu d'indiquer une erreur lorsque trop de tables temporaires sont ouvertes. (Bogue n° 18948649)

Mises à jour du moteur de base de données Aurora MySQL : 14/12/2016 (version 1.10) (obsolète) 1.10.0
  • UNIONdes tables dérivées renvoie des résultats erronés avec des clauses « 1=0/false ». (Bogue n° 69471)

  • Le serveur se bloque dans ITEM _ _ FUNC GROUP _ CONCAT : : FIX _ FIELDS lors de la deuxième exécution de la procédure stockée. (Bogue n° 20755389)

  • Évitez que Mes SQL requêtes ne s'arrêtent trop longtemps pendant la synchronisation du FTS cache avec le disque en transférant la tâche de synchronisation du cache vers un thread distinct, dès que la taille du cache dépasse 10 % de la taille totale. (Bogues n° 22516559, n° 73816)

Mises à jour du moteur de base de données Aurora MySQL : 26/10/2016 (version 1.8.1) (obsolète) 1.8.1
  • Open SSL a modifié les paramètres de longueur de clé Diffie-Hellman en raison de ce problème. LogJam (Bogue n° 18367167)

Mises à jour du moteur de base de données Aurora MySQL : 18/10/2016 (version 1.8) (obsolète) 1.8.0
  • Lors de la suppression de tous les index sur une colonne contenant plusieurs index, InnoDB n'a pas réussi à bloquer une DROP INDEX opération lorsqu'une contrainte de clé étrangère nécessite un index. (Bogue n° 16896810)

  • Résoudre l'incident lié à l'ajout d'une contrainte de clé étrangère. (Bogue n° 16413976)

  • Correction d'un incident se produisant lors de la récupération d'un curseur dans une procédure stockée pendant l'analyse ou du vidage de la table. (Bogue n° 18158639)

  • Correction d'un bogue d'incrémentation automatique lorsqu'un utilisateur modifiait une table pour que la INCREMENT valeur AUTO _ soit inférieure à la valeur maximale de la colonne d'incrémentation automatique. (Bogue n° 16310273)

Mises à jour du moteur de base de données Aurora MySQL : 30/08/2016 (version 1.7.0) (obsolète) 1.7.0
  • Améliorez l'évolutivité en partitionnant LOCK _grant lock. (Port WL #8355)

  • L'ouverture du curseur SELECT dans une procédure stockée entraîne une erreur de segmentation. (Bogue de port n° 16499751)

  • Cela SQL donne un mauvais résultat avec un usage spécial. (Bogue n° 11751794)

  • Crash dans GET _ SEL _ ARG _ FOR _ KEYPART — causé par le correctif pour le bogue #11751794. (Bogue n° 16208709)

  • Résultats erronés pour une simple requête avec GROUP BY. (Bogue n° 17909656)

  • Lignes supplémentaires sur requête semi-jointure avec prédicats de plage. (Bogue n° 16221623)

  • L'ajout d'une clause ORDER BY à la suite d'une sous-requête IN peut entraîner le renvoi de lignes dupliquées. (Bogue n° 16308085)

  • Crash avec explication pour une requête avec scan lâche pour GROUP BY, MyISAM. (Bogue n° 16222245)

  • L'analyse d'index large avec prédicat d'entier à quota renvoie des données aléatoires. (Bogue n° 16394084)

  • Si l'optimiseur utilisait une analyse d'index large, le serveur pouvait quitter pendant la tentative de création d'une table temporaire. (Bogue n° 16436567)

  • COUNT(DISTINCT) ne doit pas compter NULL les valeurs, mais elles ont été comptées lorsque l'optimiseur a utilisé un scan indiciel lâche. (Bogue n° 17222452)

  • Si une requête contenait à la fois MIN ()/MAX() et aggregate_function (DISTINCT) (par exemple, SUM ()DISTINCT) et était exécutée à l'aide d'un scan d'index lâche, les valeurs de résultat de MIN ()/MAX() n'étaient pas définies correctement. (Bogue n° 17217128)

Mises à jour du moteur de base de données Aurora MySQL : 01/06/2016 (version 1.6.5) (obsolète) 1.6.5
  • SLAVE CAN'T CONTINUE REPLICATION AFTER MASTER'S CRASH RECOVERY (Port Bug #17632285)

Mises à jour du moteur de base de données Aurora MySQL : 06/04/2016 (version 1.6) (obsolète) 1.6.0
  • BACKPORTBug #18694052 FIX FOR ASSERTION `! M_ _ ORDERED REC _ BUFFER 'FAILEDTO 5.6 (bogue de port #18305270)

  • SEGVIN MEMCPY (), HA_ PARTITION : : POSITION (bogue de port numéro 18383840)

  • WRONGRESULTSWITHPARTITIONING, INDEX _ MERGE AND AUCUN PK (bogue de port n° 18167648)

  • FLUSHTABLESFOREXPORT: ASSERTION IN HA_ PARTITION : : EXTRA (bogue de port n° 16943907)

  • SERVERCRASHDANS VIRTUAL HA_ ROWS HANDLER : _ _ MULTI _ _ RANGE READ INFO _ CONST (bogue de port n° 16164031)

  • RANGEOPTIMIZERCRASHESIN SEL _ ARG : :RB_ INSERT () (bogue de port n° 16241773)

Mises à jour du moteur de base de données Aurora MySQL : 11/01/2016 (version 1.5) (obsolète)

1.5.0

  • Résolution d'un correctif SQL incomplet dans Ma recherche en texte intégral affectant les tables dont le nom de base de données commence par un chiffre. (Bogue de port n° 17607956)

Mises à jour du moteur de base de données Aurora MySQL : 03/12/2015 (version 1.4) (obsolète)

1.4

  • SEGVdans FTSPARSE (). (Bogue n° 16446108)

  • Le dictionnaire de données InnoDB n'est pas mis à jour lorsque la colonne est renommée. (Bogue n° 19465984)

  • FTScrash après avoir renommé la table en une base de données différente. (Bogue n° 16834860)

  • L'échec de la préparation du déclenchement sur les tables tronquées entraîne l'erreur 1054. (Bogue n° 18596756)

  • Des modifications des métadonnées peuvent entraîner des problèmes de déclenchement d'exécution. (Bogue n° 18684393)

  • La matérialisation n'est pas choisie pour un UTF8 VARCHAR champ long. (Bogue n° 17566396)

  • Mauvais plan d'exécution lorsque ORDER BY est limité à X. (Bug #16697792)

  • Bug de rétroportage #11765744 vers 5.1, 5.5 AND 5.6. (Bogue n° 17083851)

  • Problème de mutex dansSQL/SQL_ SHOW .CC entraînant. SIG6 Source probablement FILL _VARIABLES. (Bogue n° 20788853)

  • Bogue de rétroportage n° 18008907 pour les versions 5.5+. (Bogue n° 18903155)

  • Adaptez le correctif pour une erreur de dépassement de pile dans My SQL 5.7. (Bogue n° 19678930)

Mises à jour du moteur de base de données Aurora MySQL : 16/10/2015 (versions 1.2, 1.3) (obsolète)

1.2, 1.3

  • L'arrêt d'une requête dans innodb entraîne finalement un incident avec une assertion. (Bogue n° 1608883)

  • Pour un échec lors de la création d'un nouveau thread pour le planificateur d'événement, l'exécution d'un événement ou une nouvelle connexion, aucun message n'a été consigné dans le journal des erreurs. (Bogue n° 16865959)

  • Si une connexion modifiait sa base de données par défaut et qu'une autre connexion était exécutée simultanément SHOWPROCESSLIST, la seconde connexion pourrait accéder à de la mémoire non valide lors de la tentative d'affichage de la mémoire de base de données par défaut de la première connexion. (Bogue n° 11765252)

  • PURGEBINARYLOGSde par sa conception, ne supprime pas les fichiers journaux binaires en cours d'utilisation ou actifs, mais n'a fourni aucune notification lorsque cela s'est produit. (Bogue n° 13727933)

  • Pour certaines instructions, des fuites de mémoire pouvaient être générées lorsque l'optimiseur supprimait des clauses de sous-requête superflues. (Bogue n° 15875919)

  • Pendant l'arrêt, le serveur pouvait essayer de verrouiller un mutex non initialisé. (Bogue n° 16016493)

  • Une instruction préparée utilisant GROUP _ CONCAT () et une clause ORDER BY nommant plusieurs colonnes pouvaient entraîner la fermeture du serveur. (Bogue n° 16075310)

  • L'instrumentation du schéma de performance était manquante pour les threads de travailleur de réplicas. (Bogue n° 16083949)

  • STOP SLAVEpouvait provoquer un blocage lorsqu'elle était émise simultanément avec une instruction telle que SHOW STATUS celle qui récupérait les valeurs d'une ou de plusieurs variables d'étatSlave_retried_transactions,, Slave_heartbeat_period Slave_received_heartbeatsSlave_last_heartbeat, ou. Slave_running (Bogue n° 16088188)

  • Une requête en texte intégral utilisant le mode booléen pouvait ne retourner aucun résultat dans certains cas où le terme recherché était une phrase entre guillemets. (Bogue n° 16206253)

  • La tentative de l'optimiseur de supprimer les clauses de sous-requête redondantes générait une assertion lors de l'exécution d'une instruction préparée avec une sous-requête dans la clause ON d'une jointure dans une sous-requête. (Bogue n° 16318585)

  • GROUP_ CONCAT instable, crash dans ITEM _ SUM : : CLEAN _UP_ _AFTER. REMOVAL (Bogue n° 16347450)

  • Tentative de remplacement de la liste de mots clés de recherche en texte intégral (FTS) par défaut d'InnoDB en créant une table InnoDB ayant la même structure que _. INFORMATION SCHEMA INNODB_FT_ DEFAULT _ STOPWORD provoquerait une erreur. (Bogue n° 16373868)

  • Une fois que le thread client d'un worker a effectué un FLUSH TABLES WITH READ LOCK et a été suivi de quelques mises à jour sur le master, le worker s'est bloqué lors de l'exécutionSHOW SLAVE STATUS. (Bogue n° 16387720)

  • Lors de l'analyse d'une chaîne de recherche délimitée telle que « abc-def » dans une recherche en texte intégral, InnoDB utilise désormais les mêmes délimiteurs de mots que My. ISAM (Bogue n° 16419661)

  • S'écraser dans FTS _ AST _ TERM _ SET _WILDCARD. (Bogue n° 16429306)

  • SEGFAULTdans FTS _ AST _ VISIT () pour le FTS RQG test. (Bogue n° 16435855)

  • Pour les versions de débogage, lorsque l'optimiseur supprimait un Item_ref pointant sur une sous-requête, il entraînait un arrêt du serveur. (Bogue n° 16509874)

  • La recherche en texte intégral sur des tables InnoDB échouait lors de recherches d'expressions littérales combinées aux opérateurs + ou -. (Bogue n° 16516193)

  • START SLAVEa échoué lorsque le serveur a été démarré avec les options --master-info-repository=TABLE relay-log-info-repository = TABLE et avec autocommit défini sur 0, ainsi que. --skip-slave-start (Bogue n° 16533802)

  • Les résultats de recherche en texte intégral InnoDB (FTS) très volumineux peuvent consommer une quantité excessive de mémoire. (Bogue n° 16625973)

  • Dans les versions de débogage, une assertion peut se produire dans OPT _ CHECK _ ORDER _BY lorsque le binaire est utilisé directement dans une chaîne de recherche, car le binaire peut inclure des NULL octets et d'autres caractères non significatifs. (Bogue n° 16766016)

  • Pour certaines instructions, des fuites de mémoire pouvaient être générées lorsque l'optimiseur supprimait des clauses de sous-requête superflues. (Bogue n° 16807641)

  • Il était possible de provoquer un blocage après l'émission STOP SLAVE en FLUSH TABLES WITH READ LOCK émettant une nouvelle connexion au travailleur, puis SHOW SLAVE STATUS en utilisant la connexion d'origine. (Bogue n° 16856735)

  • GROUP_ CONCAT () avec un séparateur non valide peut entraîner la fermeture du serveur. (Bogue n° 16870783)

  • Le serveur a verrouillé de manière excessive les mutex LOCK _active_mi et active_mi->rli->data_lock pour toute instruction SHOW STATUS LIKE « pattern », même lorsque le modèle ne correspondait pas aux variables d'état utilisant ces mutex (,,,,). Slave_heartbeat_period Slave_last_heartbeat Slave_received_heartbeats Slave_retried_transactions Slave_running (Bogue n° 16904035)

  • Une recherche en texte intégral à l'aide du BOOLEAN MODE modificateur IN provoquerait un échec d'assertion. (Bogue n° 16927092)

  • Une recherche en texte intégral sur les tables InnoDB échouait pour les recherches qui utilisaient l'opérateur booléen +. (Bogue n° 17280122)

  • Interblocage quadridirectionnel : zombies, purge des journaux binaires, show processlist, show binlogs. (Bogue n° 17283409)

  • Lorsqu'un SQL thread qui attendait un verrou de validation était tué et redémarré, une transaction était ignorée sur le worker. (Bogue n° 17450876)

  • Un échec de recherche en texte intégral InnoDB survenait en raison d'un jeton « non terminé ». La chaîne et la longueur de chaîne devaient être transmises pour la comparaison de chaîne. (Bogue n° 17659310)

  • Un grand nombre de tables InnoDB partitionnées peuvent consommer beaucoup plus de mémoire lorsqu'elles sont utilisées dans SQL My 5.6 ou 5.7 que la mémoire utilisée par les mêmes tables utilisées dans les SQL versions précédentes de My Server. (Bogue n° 17780517)

  • Pour les requêtes en texte intégral, ne pas vérifier si num_token était inférieur à max_proximity_item pouvait entraîner une assertion. (Bogue n° 18233051)

  • Certaines requêtes pour le INFORMATION _ SCHEMA TABLES et les COLUMNS tables pouvaient entraîner une utilisation excessive de la mémoire lorsqu'il y avait un grand nombre de tables InnoDB vides. (Bogue n° 18592390)

  • Lors de la validation d'une transaction, un drapeau est désormais utilisé pour vérifier si un thread a été créé, plutôt que de vérifier le thread lui-même, qui utilise plus de ressources, en particulier lors de l'exécution du serveur avec TABLE master_info_repository=. (Bogue n° 18684222)

  • Si un thread client sur un worker s'exécutait FLUSH TABLES WITH READ LOCK alors que le maître exécutait unDML, SHOW SLAVE STATUS l'exécution sur le même client était bloquée, provoquant un blocage. (Bogue n° 19843808)

  • Le tri par un résultat GROUP _ CONCAT () peut entraîner la fermeture du serveur. (Bogue n° 19880368)

Mises à jour du moteur de base de données Aurora MySQL : 24/08/2015 (version 1.1) (obsolète)

1.1

  • Les bases de données InnoDB dont le nom commence par un chiffre provoquent une erreur d'analyse de texte intégral (FTS). (Bogue n° 17607956)

  • Les recherches de texte intégral InnoDB échouent dans les bases de données dont les noms commencent par un chiffre. (Bogue n° 17161372)

  • Pour les bases de données InnoDB sous Windows, l'ID de l'objet search (FTS) en texte intégral n'est pas au format hexadécimal attendu. (Bogue n° 16559254)

  • Une régression du code introduite dans My SQL 5.6 a eu un impact négatif sur DROP TABLE les ALTER TABLE performances. Cela pourrait entraîner une baisse des performances entre My SQL Server 5.5.x et 5.6.x. (Bogue n° 16864741)

ConfidentialitéConditions d'utilisation du sitePréférences de cookies
© 2025, Amazon Web Services, Inc. ou ses affiliés. Tous droits réservés.