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

Bogues MySQL corrigés par les mises à jour du moteur de base de données Aurora MySQL

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

Corrections de bogues effectuées par les mises à jour du moteur de base de données d'Aurora MySQL 3.x

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

Mise à jour du moteur de base de données Version compatible avec MySQL Version Bogues MySQL corrigés
Mises à jour du moteur de base de données Aurora MySQL 2024-11-18 (version 3.08.0, compatible avec MySQL 8.0.39)

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 de base de données Aurora MySQL 2024-06-04 (version 3.07.0, compatible avec MySQL 8.0.36)

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 augmentation de l'utilisation du processeur en raison de la rotation des certificats TLS en 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 système MySQL dans les versions d'Aurora MySQL infé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 la version 3.05.0 d'Aurora MySQL. (Correctif de bogue communautaire #35625510).

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

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 l'utilisation du processeur en raison de la rotation des certificats TLS en 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 système MySQL dans les versions d'Aurora MySQL infé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 la version 3.05.0 d'Aurora MySQL. (Correctif de bogue Community n° 35625510)

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

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 table MySQL dans un schéma système entre les versions 3.01 à Aurora MySQL 3.04 et après la mise à niveau d'Aurora MySQL vers la version 3.05.0, le serveur se fermait de manière inattendue DMLs sur ces tables. (Correctif de bogue Community n° 35625510)

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

8,0,32

3,05,0

  • Correction d'un problème pouvant entraîner une utilisation accrue du processeur en raison de la rotation des certificats TLS en arrière-plan (correctif du bogue n° 34284186)

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

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, ayant comme sous-requête une instruction SELECT 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 de base de données Aurora MySQL 13/11/2023 (version 3.04.1, compatible avec MySQL 8.0.28)

8,0,28

3.04.1

  • Correction d'un problème pouvant entraîner une utilisation accrue du processeur en raison de la rotation des certificats TLS en arrière-plan (correctif du bogue n° 34284186)

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

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 opérations DDL 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'instructions SQL 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 de base de données Aurora MySQL 08/2023 (version 3.03.3) (obsolète)

8,0,26

3.03.3

  • Correction d'un problème pouvant entraîner une utilisation accrue du processeur en raison de la rotation des certificats TLS en arrière-plan (correctif du bogue n° 34284186)

Mises à jour du moteur de base de données Aurora MySQL 29/08/2023 (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'instructions SQL 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 opérations DDL en ligne d'accéder à la out-of-bounds mémoire (Bug #34750489, Bug #108925)

Mises à jour du moteur de base de données Aurora MySQL 11/05/2023 (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 de base de données Aurora MySQL : 01/01 (version 3.03.0) (obsolète)

8,0,26

3,03,0

  • Correction d'un problème lors duquel certains types de colonnes, dont JSON et TEXT, épuisaient parfois la mémoire 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 de génération de valeurs incorrectes lorsque la valeur maximale de la colonne de type entier était dépassée. L'erreur était due à l'absence de prise en compte de la valeur maximale de colonne. La précédente valeur AUTO_INCREMENT valide aurait dû être renvoyée dans ce cas, ce qui a provoqué un doublon de clé. (Bogues n° 87926 et 26906787)

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

  • Correction d'un problème lors duquel une procédure stockée contenant une instruction IF utilisant EXISTS, 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 de base de données Aurora MySQL le 18 novembre 2018 (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 lors duquel une procédure stockée contenant une instruction IF utilisant EXISTS, 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 MySQL n° 32855634).

  • Correction d'un problème de génération de valeurs AUTO_INCREMENT incorrectes lorsque la valeur maximale de la colonne de type entier était dépassée. L'erreur était due à l'absence de prise en compte de la valeur maximale de colonne. La précédente valeur AUTO_INCREMENT valide aurait dû être renvoyée dans ce cas, ce qui a provoqué un doublon de clé. (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 MySQL version 1 (compatible avec MySQL 5.6) contenant une table créée par l'utilisateur avec une certaine table IDs. 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 MySQL version 2 (compatible avec MySQL 5.7) vers Aurora MySQL version 3 (compatible avec MySQL 8.0). (Bogue n° 33919635)

Mises à jour du moteur de base de données Aurora MySQL 20/04/2020 (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 de base de données Aurora MySQL 15/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)

Bogues MySQL corrigés par les mises à jour du moteur de base de données Aurora MySQL 2.x

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

Mise à jour du moteur de base de données Version Bogues MySQL corrigés
Mises à jour du moteur de base de données Aurora MySQL 2024-07-09 (version 2.12.3, compatible avec MySQL 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 base de données Aurora MySQL 2812/2023 (version 2.12.1, compatible avec MySQL 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 plug-in d'analyse de recherche en texte intégral (bogue n° 35432973)

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

2.12.0

  • Correction d'un problème susceptible d'entraîner une utilisation plus élevée du processeur en raison de la rotation des certificats TLS en arrière-plan. (Correctif du bogue #34284186)

Mises à jour du moteur de base de données Aurora MySQL 17/10/2023 (version 2.11.4, compatible avec MySQL 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 susceptible d'entraîner une utilisation plus élevée du processeur en raison de la rotation des certificats TLS en 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 base de données Aurora MySQL : 10-25 (version 2.11.0, compatible avec MySQL 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. Le jeu de caractères du texte des requêtes SQL pouvait alors être invalide, ce qui pouvait entraîner un arrêt du serveur. Avec ce correctif, un jeu de caractères non valide entraîne la troncature de la colonne SQL_TEXT et empêche l'arrêt du serveur. (Bogue n° 23540008)

  • InnoDB : rétroportage d'un correctif pour les bogues n° 25189192 et 84038. Correction d'un problème de mise à jour de la table du dictionnaire de données INNODB_SYS_DATAFILES par InnoDB après une opération RENAME TABLE qui déplaçait une table vers un autre schéma. 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 d'interblocage engendré par l'exécution simultanée par deux sessions d'une opération INSERT... ON DUPLICATE KEY UPDATE. 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 d'octroi inappoprié des privilèges EXECUTE et ALTER ROUTINE aux créateurs de routines, même lorsque automatic_sp_privileges est activé. (Bogue n° 27407480)

  • Rétroportage d'un correctif pour le bogue n°24671968 : correction d'un problème lors duquel une requête pouvait produire des résultats incorrects si la clause WHERE 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, et si GROUP BY ou DISTINCT autorisait la requête à utiliser un scan restreint d'index.

  • 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 de réplication d'une instruction SET PASSWORD à partir d'un maître MySQL 5.6 vers un esclave MySQL 5.7, ou à partir d'un maître MySQL 5.7 avec la variable système log_builtin_as_identified_by_password définie sur ON vers un esclave MySQL 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 lors duquel la sérialisation d'une valeur JSON consistant en un sous-document volumineux enveloppé dans plusieurs niveaux de tableaux JSON et/ou d'objets nécessitait parfois un temps d'exécution 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. Le jeu de caractères du texte des requêtes SQL pouvait alors être invalide, ce qui pouvait entraîner un arrêt du serveur. Avec ce correctif, un jeu de caractères non valide entraîne la troncature de la colonne SQL_TEXT et empêche l'arrêt du serveur. (Bogue n° 23540008)

  • Correction d'un problème d'arrêt du serveur lorsqu'une opération UPDATE nécessitait une table temporaire doté d'une clé primaire de plus de 1 024 octets et que cette table était créée à l'aide d'InnoDB. (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 sur NULL, nous générons cette valeur à partir de l'enregistrement d'index du cluster. (Bogue n°30556595)

  • ASSERTION « !OTHER_LOCK » IN LOCK_REC_ADD_TO_QUEUE (bogue n°29195848)

  • HANDLE_FATAL_SIGNAL (SIG=11) DANS __STRCHR_ (Bug #28653104) SSE2

  • 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éplica lorsque le niveau d'isolement 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 IN TRIGGER. (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éplica lorsque le niveau d'isolement des transactions était défini sur REPEATABLE READ. (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 fonction next_event(), appelée par le thread SQL d'un réplica pour lire l'événement suivant à partir du journal de relais, le thread SQL ne libérait pas le relaylog.log_lock acquis lorsqu'il rencontrait une erreur (par exemple, en raison d'un journal de relais fermé). Par conséquent, tous les autres threads devaient attendre d'obtenir un verrou sur le journal du relais à raccrocher. Avec ce correctif, le verrou est libéré avant que le thread SQL ne quitte la fonction concernée. (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éplique de réplication basée sur le GTID exécutée avec -GTID-Mode=ON, -LOG-bin=OFF et utilisant -, lorsqu'une erreur rencontrée, qui devait être ignorée, n'était pas correctement mise à jourslave-skip-errors, ce qui entraînait une perte de synchronisation avec. Exec_Master_Log_Pos Exec_Master_Log_Pos Read_master_log_pos Si un GTID_NEXT n'était pas spécifié, le réplica ne mettrait jamais à jour son état de GTID lors du retour à partir d'une transaction d'instruction unique. Le Exec_Master_Log_Pos ne serait pas mis à jour, car même si la transaction était terminée, son état GTID indiquerait le contraire. Le correctif supprime la restriction de la mise à jour de l'état GTID lorsqu'une transaction est annulée uniquement si GTID_NEXT est spécifié. (Bogue n° 22268777)

  • Réplication : une instruction partiellement échouée ne consommait pas correctement un GTID généré automatiquement ou spécifié lorsque la journalisation binaire était désactivée. Ce correctif garantit qu'un DROP TABLE, un DROP USER ou un DROP VIEW ayant partiellement échoué consomment respectivement le GTID correspondant et l'enregistrent dans les tables @@GLOBAL.GTID_EXECUTED et mysql.gtid_executed lorsque la journalisation binaire est désactivée. (Bogue n° 21686749)

  • Réplication : les réplicas exécutant MySQL 5.7 ne pouvaient pas se connecter à une source MySQL 5.5 en raison d'une erreur lors de la récupération de server_uuid, qui ne faisait pas partie de MySQL 5.5. 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 d'omission de transaction GTID ne fonctionnait pas correctement pour la transaction XA avant ce correctif. Le serveur dispose d'un mécanisme permettant d'ignorer (silencieusement) une transaction GTID s'il a déjà exécuté cette transaction particulière par le passé. (Bogue n° 25041920)

  • Les instructions XA ROLLBACK qui avaient échoué en raison d'un ID de transaction incorrect pouvaient être enregistrées dans le journal binaire avec le bon ID de transaction et donc être traitées par des réplicas 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 CHANGE MASTER TO qui ne spécifiait ni le nom du fichier journal source ni la position du journal source, puis qu'elle était arrêtée avant que START SLAVE ne soit é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 instruction RESET SLAVE é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 ensemble GTID 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 à l'origine d'une erreur d'analyse (ER_PARSE_ERROR) ne pouvaient pas être ignorées manuellement par la méthode recommandée consistant à injecter une transaction vide ou de remplacement avec le même GTID. Cette action doit permettre au réplica d'identifier le GTID comme déjà utilisé et donc d'ignorer la transaction indésirable qui a partagé son GTID. Toutefois, dans le cas d'une erreur d'analyse, parce que l'instruction a été analysée avant que le GTID ne soit vérifié pour voir s'il devait être ignoré, le thread qui a appliqué la réplication s'est arrêté en raison de l'erreur d'analyse, même si l'intention était d'ignorer la transaction malgré tout. Avec ce correctif, le thread qui a appliqué la réplication ignore désormais les erreurs d'analyse si la transaction concernée doit être ignorée, car le GTID était déjà utilisé. 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 : activez le thread SQL pour que GTID ignore 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'expiration négatif est rejetée avec une erreur si le serveur est en mode SQL strict. Si le serveur n'est pas en mode SQL strict, la valeur fait en sorte que la fonction renvoie NULL immédiatement et sans attendre, puis émette 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)

  • GTIDs Lorsque cette option est activée, XA COMMIT sur une transaction XA déconnectée dans le cadre d'une transaction à instructions multiples a généré une assertion. (Bogue n° 22173903)

  • Réplication : une assertion était déclenchée dans les builds de débogage si une instruction XA ROLLBACK était émise pour un identifiant de transaction inconnu lorsque la valeur gtid_next avait été définie manuellement. Le serveur ne tente plus de mettre à jour l'état du GTID si une instruction ROLLBACK 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 :* dans certaines circonstances, un problème de verrouillage dans la fonction WAIT_FOR_EXECUTED_GTID_SET () peut entraîner le blocage du serveur. 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'isolement des transactions était défini sur REPEATABLE READ. (Bogue n° 25040331)

  • Pour les tables ayant une colonne TIMESTAMP ou DATETIME avec une valeur CURRENT_TIMESTAMP par défaut, la colonne pouvait être initialisée à 0000-00-00 00:00:00 si la table avait un déclencheur BEFORE INSERT. (Bogue n° 25209512, Bogue n° 84077)

  • Pour les instructions INSERT pour lesquelles la liste VALUES produisait des valeurs pour la deuxième ligne ou une ligne suivante à l'aide d'une sous-requête contenant une jointure, le serveur pouvait s'arrêter s'il n'avait pas réussi à résoudre les privilèges requis. (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

  • Bogue n° 23762382 - INSERT VALUES QUERY WITH JOIN IN A SELECT CAUSES INCORRECT BEHAVIOR.

  • Bogue n° 25209512 - CURRENT_TIMESTAMP PRODUCES ZEROS IN TRIGGER.

Mises à jour du moteur de base de données Aurora MySQL du 06/02/2020 (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.

  • Bogue #29138644 : la modification manuelle de l'heure système pendant l'exécution du serveur MySQL a provoqué des retards du thread de nettoyage de page.

  • Bogue #25222337 : un nom de champ de colonne virtuelle NULL dans un index virtuel a provoqué une sortie du serveur lors d'une comparaison de noms de champ qui se produit 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.

  • Bogue #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 pouvait entraîner une fuite de mémoire.

  • Bogue #28834208 : au cours de l'application de journal, après une opération OPTIMISTIE TABLE, InnoDB n'a pas rempli de colonnes virtuelles avant de vérifier les mises à jour d'index de colonne virtuelle.

  • 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'une mise à jour nécessitait une table temporaire avec une clé primaire de plus de 1 024 octets et que cette table était créée à l'aide d'InnoDB, le serveur pouvait s'arrêter. (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

  • L'INSERTION D'ENREGISTREMENTS DE TAILLE 64K PREND TROP DE TEMPS. (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 index FTS si vous utilisez un analyseur n-gram. (Bogue n° 25873310)

  • Correction d'un problème qui pouvait entraîner le redémarrage du moteur pendant l'exécution de la requête avec des vues SQL 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 verrouillage d'écart qui variait lorsque les transactions étaient réutilisées en série sur l'esclave. Pour éviter ce type de conflit, les verrous d'écart acceptés par les transactions XA au niveau d'isolement READ COMMITTED sont désormais publié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é pris inutilement lors de la validation de clé étrangère et de l'utilisation du niveau d'isolement READ COMMITTED. (Bogue n° 25082593)

  • Réplication : lors de l'utilisation de transactions XA, si un délai d'attente de verrouillage ou un blocage se produisait pour le thread applicateur (SQL) sur un esclave de réplication, la nouvelle tentative automatique ne fonctionnait pas, car même si le thread SQL procédait à une restauration, il ne restaurait pas la transaction XA. Par conséquent, lorsque la transaction était relancée, le premier événement était XA START et n'était pas valide étant donné que la transaction XA était déjà en cours, entraînant une erreur XAER_RMFAIL. (Bogue n° 24764800)

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

  • Réplication : la valeur renvoyée par une instruction SHOW SLAVE STATUS pour la taille combinée totale de tous les fichiers journaux relais existants (Relay_Log_Space) pouvait devenir beaucoup plus élevée que l'espace disque réel utilisé par les journaux relais. Le thread d'I/O ne verrouillait pas la variable lorsqu'il mettait à jour la valeur. Il pouvait donc supprimer automatiquement un fichier journal relais et écrire une valeur réduite avant de terminer la mise à jour de la valeur. Le thread d'I/O écrivait ensuite son calcul de taille d'origine, en ignorant la mise à jour du thread SQL et en rajoutant ainsi l'espace du 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 les instructions INSERT pour lesquelles la liste VALUES produisait des valeurs pour la deuxième ligne ou une ligne suivante à l'aide d'une sous-requête contenant une jointure, le serveur pouvait s'arrêter s'il n'avait pas réussi à résoudre les privilèges requis. (Bogue n° 23762382)

  • Pour les tables ayant une colonne TIMESTAMP ou DATETIME avec une valeur CURRENT_TIMESTAMP par défaut, la colonne pouvait être initialisée à 0000-00-00 00:00:00 si la table avait un déclencheur BEFORE INSERT. (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 avait créé une table à partir du contenu de certaines instructions SELECT pouvait 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 de base de données Aurora MySQL du 17/04/2020 (version 2.07.2) (obsolète)

2.07.2

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

2.07.0

  • Bogue #26251621 : COMPORTEMENT INCORRECT DU DÉCLENCHEUR ET DE GCOL

  • Bug #22574695: ASSERTION `!TABLE || (!TABLE->READ_SET || BITMAP_IS_SET(TABLE->READ_SET, FIEL

  • Bogue #25966845 : LES INSERTIONS SUR CLÉ DUPLIQUÉE GÉNÈRENT UN VERROU

  • Bogue #23070734 : LES TABLES TRONQUÉES SIMULTANÉES PROVOQUENT UN ARRÊT

  • Bogue #26191879 : LES CASCADES DE CLÉS ÉTRANGÈRES UTILISENT TROP DE MÉMOIRE

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

Mises à jour du moteur de base de données Aurora MySQL du 11/11/2019 (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 un blocage

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

2.04.9

  • Bug #23070734, Bug #80060 : la fonction TRUNCATE simultanée TABLEs provoque des blocages

  • Bogue n° 23103937 : PS_TRUNCATE_ALL_TABLES() NE FONCTIONNE PAS EN MODE SUPER_READ_ONLY

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

  • Bogue n° 27082268 : synchronisation FTS non valide.

  • BOGUE n° 12589870 : correction d'un problème qui provoquait un redémarrage avec une instruction multi-requête lorsque le cache de requête est 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).

  • Bogue n° 25222337 : un nom de champ de colonne virtuelle NULL dans un index virtuel a provoqué une sortie du serveur lors d'une comparaison de noms de champ qui se produit 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)

  • Bogue n° 26666274 : BOUCLE INFINITE DANS LE CONTAINER DE MÉMOIRE TAMPON DE SCHÉMA DE PERFORMANCE.

  • Bogue n° 23550835, Bogue n° 23298025, Bogue n° 81464 : une table SELECT Performance Schema lorsqu'un tampon interne était plein pouvait provoquer la sortie d'un serveur.

Mises à jour du moteur de base de données Aurora MySQL du 19/09/2019 (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 un blocage

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

2.04.2

Bogue n°24829050 - INDEX_MERGE_INTERSECTION OPTIMIZATION CAUSES WRONG QUERY RESULTS

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

2.03

  • UNE ANALYSE EN ORDRE INVERSE SUR UNE TABLE PARTITIONNÉE DONNE UN CLASSEMENT ICP PAR DESCRIPTION (bogue n° 24929748).

  • JSON_OBJECT CRÉE UN CODE JSON NON VALIDE (bogue n° 26867509).

  • L'INSERTION D'UN GROS VOLUME DE DONNÉES JSON PREND UNE DURÉE INHABITUELLE (bogue n° 22843444).

  • LES TABLES PARTITIONNÉES UTILISENT DAVANTAGE DE MÉMOIRE DANS LA VERSION 5.7 QUE DANS LA VERSION 5.6 (bogue n° 25080442).

Mises à jour du moteur de base de données Aurora MySQL du 21/09/2018 (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 de base de données Aurora MySQL du 03/05/2018 (version 2.02) (obsolète)

2.02.0

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

Bogues MySQL corrigés par les mises à jour du moteur de base de données Aurora MySQL 1.x

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

Mise à jour du moteur de base de données Version Bogues MySQL 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é.

  • BOGUE #22350047 : SI LE CLIENT EST TUÉ APRÈS LA RESTAURATION AU POINT DE SAUVEGARDE PRÉCÉDENT STMTS VALIDÉ

  • Bogue #29915479 : L'EXÉCUTION DE COM_REGISTER_SLAVE SANS COM_BINLOG_DUMP PEUT GÉNÉRER L'ARRÊT DU SERVEUR

  • Bogue #30441969 : BOGUE #29723340 : INCIDENT MYSQL SERVER APRÈS REQUÊTE SQL AVEC ?AST DE DONNÉES

  • Bogue #30628268 : INCIDENT DE MÉMOIRE INSUFFISANTE

  • Bogue #27081349 : COMPORTEMENT INATTENDU LORS D'UNE SUPPRESSION AVEC FONCTION SPATIALE

  • Bogue #27230859 : COMPORTEMENT INATTENDU LORS DE LA GESTION D'UN POLYGONE NON VALIDE

  • Bogue #27081349 : COMPORTEMENT INATTENDU LORS DE LA SUPPRESSION AVEC FONCTION SPATIALE

  • Bogue #26935001 : AUTO_INCREMENT DE MODIFICATION DE TABLE TENTE DE LIRE L'INDEX À PARTIR D'UN ESPACE DE TABLE SUPPRIMÉ

  • Bogue #29770705 : INCIDENT SERVEUR PENDANT L'EXÉCUTION DE SELECT AVEC CLAUSE WHERE SPÉCIFIQUE

  • Bogue #27659490 : SELECT AVEC UTILISATION DE PLAGE DYNAMIQUE ET DE FUSION D'INDEX NÉCESSITE TROP DE MÉMOIRE (MÉMOIRE INSUFFISANTE)

  • Bogue #24786290 : INTERRUPTION DE LA RÉPLICATION LORSQUE LE BOGUE #74145 SE PRODUIT SUR LE PRINCIPAL

  • Bogue #27703912 : UTILISATION DE MÉMOIRE EXCESSIVE AVEC NOMBREUSES PRÉPARATIONS

  • Bug #20527363 : CRASH DE LA TABLE TEMPORAIRE TRUNCATE : ! TF2DICT_ _FLAG_IS_SET (TABLE, DICT_ _TEMPORAIRE) TF2

  • Bogue #23103937 : PS_TRUNCATE_ALL_TABLES() NE FONCTIONNE PAS EN MODE SUPER_READ_ONLY

  • Bogue #25053286 : L'UTILISATION DE VUE AVEC CONDITION DANS LA PROCÉDURE GÉNÈRE UN COMPORTEMENT INCORRECT (corrigé dans 5.6.36)

  • Bogue #25586773 : COMPORTEMENT INCORRECT POUR SÉLECTION DE TABLE DE CRÉATION DANS UNE BOUCLE DANS SP (corrigé dans 5.6.39)

  • Bogue #27407480 : AUTOMATIC_SP_PRIVILEGES NÉCESSITE LES PRIVILÈGES INSERT POUR LA TABLE MYSQL.USER

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

  • Bogue #15831300 SLAVE_TYPE_CONVERSIONS=ALL_NON_LOSSY NE FONCTIONNE PAS COMME PRÉVU

  • Bogue backport bogue SSL #17087862, bogue #20551271

  • Bogue #16894092 : RÉGRESSION DE PERFORMANCE DANS 5.6.6+ POUR INSERT INTO ... SELECT ... FROM (corrigé dans 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.

  • Bogue n° 15831300 : Par défaut, lors de la promotion de nombres entiers d'un type plus petit sur le maître à un type plus grand sur l'esclave (par exemple, d'une colonne SMALLINT sur le maître à une colonne BIGINT 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.

  • BOGUE n° 20768847 : Une opération ALTER TABLE ... Opération DROP INDEX sur une table avec des dépendances de clé étrangère déclenchait 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
  • Bogue #16346241 - ARRÊT DU SERVEUR DANS ITEM_PARAM::QUERY_VAL_STR

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

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

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

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

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

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_ _BACK FROM STRING : :COPY SSSE3

  • Bogue n° 17059925 : pour les instructions UNION, la valeur examinée par les lignes a été calculée de façon incorrecte. 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.

  • Bogue n° 16311231 : des résultats incorrects ont été renvoyés lorsqu'une requête contenait une sous-requête dans une clause IN qui contenait une opération XOR dans la clause WHERE.

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_ _BACK FROM STRING : :COPY SSSE3

  • Bogue n° 17059925 : pour les instructions UNION, la valeur examinée par les lignes a été calculée de façon incorrecte. 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.

  • Bogue n° 16311231 : des résultats incorrects ont été renvoyés lorsqu'une requête contenait une sous-requête dans une clause IN qui contenait une opération XOR dans la clause WHERE.

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_ _BACK FROM STRING : :COPY SSSE3

  • Bogue n° 17059925 : pour les instructions UNION, la valeur examinée par les lignes a été calculée de façon incorrecte. 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.

  • Bogue n° 16311231 : des résultats incorrects ont été renvoyés lorsqu'une requête contenait une sous-requête dans une clause IN qui contenait une opération XOR dans la clause WHERE.

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

  • Bogue n°63144 : CREATE TABLE IF NOT EXISTS METADATA LOCK IS 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
  • BOGUE 13418638 : CREATE TABLE IF NOT EXISTS METADATA LOCK IS 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 (consultez Index Merge Optimization) peuvent renvoyer des résultats non valides lorsqu'elles sont exécutées sur des tables qui ont été 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 instruction ALTER TABLE qui renommait ou modifiait la valeur par défaut d'une colonne BINARY, l'altération était effectuée en utilisant une copie de la table 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 n'est pas répliqué correctement si les filtres de réplication sont utilisés (bogue n° 69861)

  • La requête retourne différents résultats en fonction du paramètre INDEX_MERGE (bogue n° 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 (bogue n° 18079671)

  • Assertion RBT_EMPTY(INDEX_CACHE->WORDS) dans ALTER TABLE CHANGE COLUMN (bogue n° 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
  • Annulation — Ralentissement de l'instance MySQL « doing SYNC index » (bogue n° 73816)

  • Annulation — Assertion RBT_EMPTY(INDEX_CACHE->WORDS) dans ALTER TABLE CHANGE COLUMN (bogue n° 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
  • CREATE USER accepte le plugin et le hachage du mot de passe, mais ignore le hachage du mot de passe (bogue n° 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 qui implique la lecture du premier champ en cas de key_cmp (bogue n° 16367691).

  • Ralentissement de l'instance MySQL « doing SYNC index » (bogue n° 73816)

  • Assertion RBT_EMPTY(INDEX_CACHE->WORDS) dans ALTER TABLE CHANGE COLUMN (bogue n° 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' (Bug #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 quand elle était vide a provoqué la réinitialisation d'une valeur AUTO_INCREMENT. (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)

  • ALTER TABLE ajoute la colonne TIMESTAMP sur la mise à jour CURRENT_TIMESTAMP insère des données ZERO (Bogue n° 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 quand elle était vide a provoqué la réinitialisation d'une valeur AUTO_INCREMENT. (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)

  • ALTER TABLE ajoute la colonne TIMESTAMP sur la mise à jour CURRENT_TIMESTAMP insère des données ZERO (Bogue n° 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 d'une clé étrangère DROP de table ALTER simultanément avec une autre opération DROP fait disparaître la table. (Bogue n° 16095573)

  • Certaines requêtes INFORMATION_SCHEMA qui utilisaient ORDER BY n'utilisaient pas d'optimisation filesort comme elles le faisaient auparavant. (Bogue n° 16423536)

  • FOUND_ROWS () renvoie le mauvais nombre de lignes sur une table. (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
  • L'UNION de tables dérivées retourne 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 à la 2e exécution de la procédure stockée. (Bogue n° 20755389)

  • Empêchez les requêtes MySQL de caler trop longtemps au cours de la synchronisation du cache FTS sur le disque en déchargeant la tâche de synchronisation du cache sur un thread séparé, 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
  • OpenSSL 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 l'abandon de tous les index sur une colonne à index multiples, InnoDB ne parvenait pas à bloquer une opération INDEX DEPOSER lorsqu'une contrainte de clé étrangère avait besoin d'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 se produisant lorsqu'un utilisateur modifie une table pour changer la valeur AUTO_INCREMENT à moins de 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élioration de l'évolutivité par partitionnement du verrou LOCK_grant. (Port WL #8355)

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

  • MySQL donne un faux résultat dans certains cas d'utilisation. (Bogue n° 11751794)

  • Défaillance générale dans GET_SEL_ARG_FOR_KEYPART – causée par le correctif du bogue 11751794. (Bogue n° 16208709)

  • Mauvais résultats pour une requête simple 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 pourrait entraîner le renvoi de lignes en double. (Bogue n° 16308085)

  • Défaillance générale pour une requête avec balayage large pour GROUP BY, MySQL. (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)

  • Alors qu'elle ne devrait pas le faire, la fonction COUNT(DISTINCT) comptait les valeurs NULL lorsque l'optimiseur utilisait l'analyse d'index large. (Bogue n° 17222452)

  • Si une requête utilisait à la fois la fonction MIN()/MAX() et la fonction aggregate_function(DISTINCT) (par exemple, SUM(DISTINCT)) et était exécutée avec l'analyse d'index large, les valeurs produites par la fonction MIN()/MAX() étaient incorrectement définies. (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
  • BACKPORT Bug #18694052 FIX FOR ASSERTION `!M_ORDERED_REC_BUFFER' FAILED TO 5.6 (Port Bug #18305270)

  • SEGV IN MEMCPY(), HA_PARTITION::POSITION (Port Bug # 18383840)

  • WRONG RESULTS WITH PARTITIONING,INDEX_MERGE AND NO PK (Port Bug # 18167648)

  • FLUSH TABLES FOR EXPORT: ASSERTION IN HA_PARTITION::EXTRA (Port Bug # 16943907)

  • SERVER CRASH IN VIRTUAL HA_ROWS HANDLER::MULTI_RANGE_READ_INFO_CONST (Port Bug # 16164031)

  • RANGE OPTIMIZER CRASHES IN SEL_ARG::RB_INSERT() (Port Bug # 16241773)

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

1.5.0

  • Traitement d'un correctif incomplet dans la recherche en texte intégral MySQL affectant les tables dans lesquelles 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

  • SEGV dans FTSPARSE(). (Bogue n° 16446108)

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

  • Incident FTS après qu'une table a été renommée dans une autre base de données. (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 le champ UTF8 VARCHAR long. (Bogue n° 17566396)

  • Plan d'exécution médiocre pour ORDER BY avec la limite X. (Bogue n°16697792)

  • Bogue de rétroportage n° 11765744 pour 5.1, 5.5 et 5.6. (Bogue n° 17083851)

  • Problème de mutex dans SQL/SQL_SHOW.CC entraînant. SIG6 Source probable FILL_VARIABLES. (Bogue n° 20788853)

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

  • Adaptation d'un correctif pour une erreur de dépassement de capacité de pile dans MySQL 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 a changé la base de données par défaut alors que simultanément une autre connexion a exécuté SHOW PROCESSLIST, la seconde connexion a pu 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)

  • PURGE BINARY LOGS, par conception, ne supprime pas les fichiers journaux binaires qui sont utilisés ou actifs, mais n'a pas fourni aucun avis 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 qui utilisait GROUP_CONCAT() et une clause ORDER BY qui nommait plusieurs colonnes pouvait entraîner l'arrêt 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 SLAVE pouvait provoquer un blocage lorsqu'il était émis en même temps qu'une instruction telle que SHOW STATUS ayant extrait les valeurs pour une ou plusieurs des variables d'état Slave_retried_transactions, Slave_heartbeat_period, Slave_received_heartbeats, Slave_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, incident dans ITEM_SUM::CLEAN_UP_AFTER_REMOVAL. (Bogue n° 16347450)

  • Une tentative de remplacement de la liste de mots vides de recherche en texte intégral InnoDB par défaut en créant une table InnoDB avec la même structure que INFORMATION_SCHEMA.INNODB_FT_DEFAULT_STOPWORD générait une erreur. (Bogue n° 16373868)

  • Après que le thread client sur un travailleur a effectué une opération FLUSH TABLES WITH READ LOCK suivie de quelques mises à jour sur le maître, le travailleur restait bloqué lors de l'exécution de SHOW 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 à présent les mêmes délimiteurs de mot que MyISAM. (Bogue n° 16419661)

  • Incident dans FTS_AST_TERM_SET_WILDCARD. (Bogue n° 16429306)

  • SEGFAULT dans FTS_AST_VISIT() pour le test RQG de recherche en texte intégral. (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 d'une recherche en texte intégral InnoDB très étendue pouvaient consommer une quantité excessive de mémoire. (Bogue n° 16625973)

  • Dans les versions de débogage, une assertion pouvait survenir dans OPT_CHECK_ORDER_BY lors de l'utilisation de données binaires directement dans une chaîne de recherche, car les données binaires peuvent inclure des octets NULL 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 générer un interblocage après l'émission de FLUSH TABLES WITH READ LOCK en émettant STOP SLAVE dans une nouvelle connexion à l'esclave, puis en émettant SHOW SLAVE STATUS à l'aide de la connexion d'origine. (Bogue n° 16856735)

  • GROUP_CONCAT() avec un séparateur non valide pouvait causer un arrêt du serveur. (Bogue n° 16870783)

  • Le serveur a effectué un verrouillage excessif sur les mutex LOCK_active_mi et active_mi->rli->data_lock pour toute instruction SHOW STATUS LIKE 'modèle', même lorsque le modèle ne correspond pas aux variables d'état qui utilisent 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 utilisant le modificateur IN BOOLEAN MODE entraînait 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 thread SQL qui attendait un verrou de validation était supprimé et redémarré, une transaction était ignorée sur le travailleur. (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 pouvaient consommer beaucoup plus de mémoire lorsqu'elles étaient utilisées dans MySQL 5.6 ou 5.7 que la mémoire utilisée par les mêmes tables dans les versions précédentes du serveur MySQL. (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 relatives aux tables INFORMATION_SCHEMA TABLES et COLUMNS pouvaient entraîner une utilisation excessive de mémoire lorsque de nombreuses tables InnoDB étaient vides. (Bogue n° 18592390)

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

  • Si un thread client sur un travailleur exécutait FLUSH TABLES WITH READ LOCK alors que le maître exécutait une commande DML, l'exécution de SHOW SLAVE STATUS dans le même client se bloquait, entraînant un interblocage. (Bogue n° 19843808)

  • Le tri selon un résultat GROUP_CONCAT() pouvait causer l'arrêt 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 les noms commencent par un chiffre entraînent une erreur d'analyse de la recherche 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 d'objet de la recherche de texte intégral (FTS) n'est pas au format hexadécimal attendu. (Bogue n° 16559254)

  • Une régression de code présentée dans MySQL 5.6 a impacté de manière négative les performances DROP TABLE et ALTER TABLE. Cela pourrait entraîner une baisse des performances entre MySQL Server 5.5.x et 5.6.x. (Bogue n° 16864741)