Mises à jour du moteur de base de données Aurora MySQL : 14/12/2016 (version 1.10) (obsolète)

Version : 1.10

Nouvelles fonctions

• Application de correctifs sans temps d'arrêt – Cette fonction permet d'appliquer des correctifs à une instance de base de données sans aucun temps d'arrêt. Autrement dit, les mises à niveau de la base de données sont effectuées sans déconnecter les applications clientes ni redémarrer la base de données. Cette approche augmente la disponibilité de vos clusters de bases de données Aurora pendant la fenêtre de maintenance. Notez que les données temporaires comme celles dans le schéma de performances sont réinitialisées au cours du processus de mise à niveau. Cette fonction s'applique aux correctifs fournis par le service au cours d'une fenêtre de maintenance, ainsi qu'aux correctifs initiés par l'utilisateur.

  Lorsqu'un correctif est démarré, le service s'assure qu'il n'existe aucun verrou ouvert, aucune transaction ni aucune table temporaire, puis attend une fenêtre propice à la correction et au redémarrage de la base de données. Les sessions d'application sont conservées, même en cas de baisse de débit pendant l'application des correctifs (pendant environ 5 secondes). Si aucune fenêtre adaptée n'est disponible, l'application des correctifs correspond par défaut au comportement standard d'application des correctifs.

  L'application des correctifs sans temps d'arrêt se déroule autant que faire se peut, sous certaines restrictions, comme décrit ci-dessous :

  • Cette fonction est actuellement en vigueur pour l'application des correctifs aux clusters de bases de données à un seul nœud ou aux instances de l'enregistreur dans des clusters de bases de données à plusieurs nœuds.

  • Les connexions SSL ne sont pas prises en charge conjointement à cette fonction. S'il existe des connexions SSL actives, Amazon Aurora MySQL n'appliquera pas de correctif sans temps d'arrêt et, à la place, réessaiera régulièrement de voir si les connexions SSL ont pris fin. Si tel est le cas, l'application de correctifs sans temps d'arrêt a lieu. Si les connexions SSL persistent plus de quelques secondes, l'application de correctifs standard avec temps d'arrêt a lieu.

  • La fonction est disponible dans Aurora 1.10 et versions ultérieures. Nous allons désormais identifier toutes les versions ou correctifs qui ne peuvent pas être appliqués via l'application de correctifs sans temps d'arrêt.

  • Cette fonction n'est pas applicable si la réplication basée sur la journalisation binaire est active.

• Indexation spatiale – L'indexation spatiale améliore les performances des requêtes sur les jeux de données volumineux pour les requêtes qui utilisent des données spatiales. Pour plus d'informations sur l'utilisation de l'indexation spatiale, consultez Amazon Aurora MySQL et données spatiales dans le Guide de l'utilisateur Amazon Aurora.

  Cette fonction est désactivée par défaut et peut être activée en activant le mode Lab d'Aurora. Pour plus d'informations, consultez Mode Lab Amazon Aurora MySQL dans le Guide de l'utilisateur Amazon Aurora.

• Améliorations du pipeline de réplication – Aurora MySQL utilise désormais un mécanisme amélioré pour appliquer les mises à jour des flux de journaux au cache des tampons d'un réplica Aurora. Cette fonction améliore les performances en lecture et la stabilité sur les réplicas Aurora en cas de lourde charge en écriture sur le maître et d'une charge en lecture importante sur le réplica. Cette caractéristique est activée par défaut.

• Amélioration du débit pour les charges de travail avec des lectures mises en cache – Aurora MySQL utilise désormais un algorithme simultané sans verrou pour implémenter les vues en lecture, ce qui permet un meilleur débit pour les requêtes de lecture traitées par le cache de tampons. Grâce à ces améliorations et à d'autres, Amazon Aurora MySQL peut atteindre un débit de 625 000 lectures par seconde, contre 164 000 lectures par seconde pour MySQL 5.7 pour une charge de travail basée uniquement sur la sélection. SysBench

• Amélioration du débit pour les charges de travail avec des conflits entre les lignes critiques – Aurora MySQL utilise un nouvel algorithme de publication de verrou qui améliore les performances, en particulier en cas de conflit de page critique (c'est-à-dire lorsque de nombreuses transactions sont en conflit pour les lignes de la même page). Dans les tests de référence TPC-C, cela peut entraîner une amélioration du débit permettant de multiplier par 16 le nombre de transactions par minute par rapport à MySQL 5.7. Cette fonction est désactivée par défaut et peut être activée en activant le mode Lab d'Aurora. Pour plus d'informations, consultez Mode Lab Amazon Aurora MySQL dans le Guide de l'utilisateur Amazon Aurora.

Améliorations

• La vitesse de réplication du cache d'index de recherche en texte intégral a été augmentée en mettant à jour le cache uniquement après une demande de lecture adressée à un réplica Aurora. Cette approche évite les lectures du disque par le thread de réplication.

• Correction d'un problème où l'invalidation du cache de dictionnaire ne fonctionne pas sur un réplica Aurora pour les tables qui ont un caractère spécial dans le nom de base de données ou le nom de table.

• Correction d'un problème STUCK IO lors de la migration des données pour les nœuds de stockage distribués lorsque la gestion de la chaleur de stockage est activée.

• Correction d'un problème dans le gestionnaire de verrous, alors qu'une vérification d'assertion échoue pour le thread d'attente de verrouillage de transaction lors de la préparation de la restauration ou de la validation d'une transaction.

• Correction d'un problème lors de l'ouverture d'une table de dictionnaire endommagée en mettant à jour correctement le nombre de référence dans les entrées de la table de dictionnaire.

• Correction d'un bogue selon lequel le point de lecture minimal du cluster de bases de données peut être détenu par des réplicas Aurora lents.

• Correction d'une fuite de mémoire potentielle dans le cache de requête.

• Correction d'un bogue selon lequel un réplica Aurora place un verrou de niveau de ligne sur une table lorsqu'une requête est utilisée dans une instruction IF d'une procédure stockée.

Intégration de correctifs de bogues MySQL.

• 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. (Bogue n° 22516559, n° 73816)