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

Versions : 1.2, 1.3

Cette mise à jour inclut les améliorations suivantes :

Correctifs

• out-of-memory Problème résolu dans le nouveau gestionnaire de verrous avec des transactions de longue durée

• Résolution d'une faille de sécurité lors de la réplication avec des bases de données MySQL non-RDS

• Mise à jour pour garantir que les écritures de quorum sont réessayées correctement en cas de défaillances de stockage

• Mise à jour pour signaler plus précisément un retard du réplica

• Amélioration de la performance en réduisant les conflits lorsque de nombreuses transactions simultanées essaient de modifier une même ligne

• Résolution de l'invalidation du cache de requêtes pour les vues qui sont créées en joignant deux tables

• Désactivation du cache de requêtes pour les transactions avec isolation UNCOMMITTED_READ

Améliorations

• Meilleures performances pour les requêtes lentes de catalogue sur les caches à chaud

• Amélioration de la simultanéité dans les statistiques de dictionnaire

• Meilleure stabilité pour le nouveau gestionnaire de ressources du cache de requêtes, la gestion de l'extension, les fichiers stockés dans le stockage intelligent Amazon Aurora et les écritures par lots des enregistrements de journaux

Intégration de correctifs de bogues MySQL.

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