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. # Aurora MySQL version 3 compatible avec MySQL 8.0 Vous pouvez utiliser Aurora MySQL version 3 pour obtenir les dernières fonctionnalités compatibles avec MySQL, des améliorations de performances et des corrections de bugs. Vous trouverez ci-après des informations sur Aurora MySQL version 3 avec compatibilité MySQL 8.0. Vous pouvez apprendre à mettre à niveau les clusters et applications vers Aurora MySQL version 3. Certaines fonctionnalités d’Aurora, comme Aurora Serverless v2, nécessitent la version 3 d’Aurora MySQL. **Topics** + [Fonctions de MySQL 8.0 Community Edition](#AuroraMySQL.8.0-features-community) + [Prérequis Aurora MySQL version 3 pour Aurora MySQL sans serveur v2](#AuroraMySQL.serverless-v2-8.0-prereq) + [Notes de mise à jour d’Aurora MySQL version 3](#AuroraMySQL.mysql80-bugs-fixed) + [Nouvelles optimisations des requêtes parallèles](#AuroraMySQL.8.0-features-pq) + [Optimisations destinées à réduire le temps de redémarrage de la base de données](#ReducedRestartTime) + [Nouveau comportement de table temporaire dans Aurora MySQL version 3](ams3-temptable-behavior.md) + [Comparaison d’Aurora MySQL version 2 et Aurora MySQL version 3](AuroraMySQL.Compare-v2-v3.md) + [Comparaison d’Aurora MySQL version 3 et de MySQL 8.0 Community Edition](AuroraMySQL.Compare-80-v3.md) + [Mise à niveau vers Aurora MySQL version 3](AuroraMySQL.mysql80-upgrade-procedure.md) ## Fonctions de MySQL 8.0 Community Edition La version initiale d’Aurora MySQL version 3 est compatible avec MySQL 8.0.23 Community Edition. MySQL 8.0 introduit plusieurs nouvelles fonctions, dont les suivantes : + Prise en charge du langage de définition des données (DDL) atomiques. Pour plus d’informations, consultez [Prise en charge du langage de définition des données (DDL) atomiques](AuroraMySQL.Compare-v2-v3.md#AuroraMySQL.Compare-v2-v3-atomic-ddl). + Fonctions JSON Pour plus d’informations, consultez [Fonctions JSON](https://dev.mysql.com/doc/refman/8.0/en/json-functions.html) dans le *manuel de référence MySQL*. + Fonctions de fenêtrage. Pour plus d’informations, consultez [Fonctions de fenêtrage](https://dev.mysql.com/doc/refman/8.0/en/window-functions.html) dans le *manuel de référence MySQL*. + Expressions de table communes (CTE), à l’aide de la clause `WITH`. Pour plus d’informations, consultez [WITH (expressions de table communes)](https://dev.mysql.com/doc/refman/8.0/en/with.html) dans le *manuel de référence MySQL*. + Clauses `ADD COLUMN` et `RENAME COLUMN` optimisées pour l’instruction `ALTER TABLE`. Ces optimisations sont appelées « DDL instantané ». Aurora MySQL version 3 est compatible avec la fonctionnalité DDL instantané de MySQL version communautaire. L’ancienne fonction Aurora Fast DDL n’est pas utilisée. Pour plus d’informations sur l’utilisation du DDL instantané, consultez [Instant DDL (Aurora MySQL version 3)](AuroraMySQL.Managing.FastDDL.md#AuroraMySQL.mysql80-instant-ddl). + Index décroissants, fonctionnels et invisibles. Pour plus d’informations, consultez [Index Invisibles](https://dev.mysql.com/doc/refman/8.0/en/invisible-indexes.html), [Index décroissants](https://dev.mysql.com/doc/refman/8.0/en/descending-indexes.html) et [Instruction CREATE INDEX](https://dev.mysql.com/doc/refman/8.0/en/create-index.html#create-index-functional-key-parts) dans le *manuel de référence MySQL*. + Privilèges basés sur des rôles contrôlés par des instructions SQL. Pour plus d’informations sur les modifications apportées au modèle de privilèges, consultez [Modèle de privilège basé sur les rôles](AuroraMySQL.Compare-80-v3.md#AuroraMySQL.privilege-model). + Clauses `NOWAIT` et `SKIP LOCKED` avec l’instruction `SELECT ... FOR SHARE`. Ces clauses évitent d’attendre que d’autres transactions libèrent les verrous de ligne. Pour plus d’informations, consultez [Lectures de verrouillage](https://dev.mysql.com/doc/refman/8.0/en/innodb-locking-reads.html) dans le *manuel de référence MySQL*. + Améliorations apportées à la réplication des journaux binaires (binlog). Pour plus d’informations sur Aurora MySQL, consultez [Réplication de journaux binaires](AuroraMySQL.Compare-v2-v3.md#AuroraMySQL.mysql80-binlog). Vous pouvez notamment effectuer une réplication filtrée. Pour plus d’informations sur l’utilisation de la réplication filtrée, consultez [Comment les serveurs évaluent les règles de filtrage de réplication](https://dev.mysql.com/doc/refman/8.0/en/replication-rules.html) dans le *manuel de référence MySQL*. + Indicateurs. Certains indicateurs compatibles avec MySQL 8.0 ont déjà été rétroportés vers Aurora MySQL version 2. Pour obtenir des informations sur l’utilisation des indicateurs avec Aurora MySQL, consultez [Indicateurs Aurora MySQL](AuroraMySQL.Reference.Hints.md). Pour obtenir la liste complète des indicateurs dans MySQL 8.0 version communautaire, consultez [Indicateurs de l’optimiseur](https://dev.mysql.com/doc/refman/8.0/en/optimizer-hints.html) dans le *manuel de référence MySQL*. Pour obtenir la liste complète des fonctions ajoutées à MySQL 8.0 Community Edition, consultez l’article de blog [Liste complète des nouvelles fonctions de MySQL 8.0](https://dev.mysql.com/blog-archive/the-complete-list-of-new-features-in-mysql-8-0/). Aurora MySQL version 3 inclut également des modifications apportées aux mots-clés pour un langage inclusif, rétroportés depuis MySQL 8.0.26 version communautaire. Pour plus d’informations sur ces modifications, consultez [Changements linguistiques inclusifs pour Aurora MySQL version 3](AuroraMySQL.Compare-v2-v3.md#AuroraMySQL.8.0-inclusive-language). ## Prérequis Aurora MySQL version 3 pour Aurora MySQL sans serveur v2 Aurora MySQL version 3 est un prérequis pour toutes les instances de base de données dans un cluster Aurora MySQL sans serveur v2. Aurora MySQL sans serveur v2 prend en charge les instances de lecture dans un cluster de bases de données, ainsi que d’autres fonctionnalités Aurora qui ne sont pas disponibles pour Aurora MySQL sans serveur v1. Il offre également une mise à l’échelle plus rapide et plus granulaire qu’Aurora MySQL sans serveur v1. ## Notes de mise à jour d’Aurora MySQL version 3 Pour les notes de mise à jour de toutes les versions d’Aurora MySQL version 3, consultez [Mises à jour du moteur de base de données pour Amazon Aurora MySQL version 3](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraMySQLReleaseNotes/AuroraMySQL.Updates.30Updates.html) dans *Notes de mise à jour d’Aurora MySQL*. ## Nouvelles optimisations des requêtes parallèles L’optimisation des requêtes parallèles Aurora s’applique désormais à d’autres opérations SQL : + La requête parallèle s’applique désormais aux tables contenant les types de données `TEXT`, `BLOB`, `JSON`, `GEOMETRY` et `VARCHAR`, et `CHAR` de plus de 768 octets. + Les requêtes parallèles peuvent optimiser les requêtes impliquant des tables partitionnées. + Une requête parallèle permet d’optimiser les requêtes impliquant des appels de fonction agrégés dans la liste de sélection et la clause `HAVING`. Pour plus d’informations sur ces améliorations, consultez [Mise à niveau des clusters de requêtes parallèles vers Aurora MySQL version 3](aurora-mysql-parallel-query-optimizing.md#aurora-mysql-parallel-query-upgrade-pqv2). Pour obtenir des informations générales sur la requête parallèle Aurora, consultez [Requêtes parallèles pour Amazon Aurora MySQL](aurora-mysql-parallel-query.md). ## Optimisations destinées à réduire le temps de redémarrage de la base de données Votre cluster de bases de données Aurora MySQL doit être hautement disponible pendant les interruptions planifiées et imprévues. Les administrateurs de la base de données doivent effectuer une maintenance occasionnelle de celle-ci. Cette maintenance inclut l’application de correctifs, les mises à niveau, les modifications des paramètres de la base de données nécessitant un redémarrage manuel, le basculement pour réduire le temps nécessaire pour modifier la classe d’instance, etc. Ces actions planifiées nécessitent une durée d’indisponibilité. Cependant, les durées d’indisponibilité peuvent également être provoquées par des actions imprévues, telles qu’un basculement inattendu dû à une défaillance matérielle sous-jacente ou à une limitation des ressources de la base de données. Toutes ces actions planifiées et imprévues entraînent le redémarrage de la base de données. Dans Aurora MySQL 3.05 et versions ultérieures, nous avons introduit des optimisations qui réduisent le temps de redémarrage de la base de données. Ces optimisations permettent de réduire la durée d’indisponibilité de 65 % et atténuent les perturbations engendrées sur les charges de travail de votre base de données après un redémarrage. Lors du démarrage de la base de données, de nombreux composants de la mémoire interne sont initialisés. Le plus important d’entre eux est le [pool de mémoire tampon InnoDB](https://aws.amazon.com/blogs/database/best-practices-for-amazon-aurora-mysql-database-configuration/), qui, dans Aurora MySQL, représente 75 % de la taille de la mémoire de l’instance par défaut. Nos tests ont révélé que le temps d’initialisation est proportionnel à la taille du pool de mémoire tampon InnoDB et qu’il évolue donc en fonction de la taille de la classe d’instance de la base de données. Lors de cette phase d’initialisation, la base de données ne peut pas accepter de connexions, ce qui entraîne une durée d’indisponibilité plus longue lors des redémarrages. La première phase du redémarrage rapide d’Aurora MySQL optimise l’initialisation du pool de mémoire tampon, ce qui réduit le temps d’initialisation de la base de données et donc le temps de redémarrage global. Pour plus d’informations, consultez le blog [Reduce downtime with Amazon Aurora MySQL database restart time optimizations](https://aws.amazon.com/blogs/database/reduce-downtime-with-amazon-aurora-mysql-database-restart-time-optimizations/). # Nouveau comportement de table temporaire dans Aurora MySQL version 3 Aurora MySQL version 3 gère les tables temporaires différemment des versions précédentes d’Aurora MySQL. Ce nouveau comportement est hérité de MySQL 8.0 Community Edition. Il existe deux types de tables temporaires qui peuvent être créées avec Aurora MySQL version 3 : + Tables temporaires internes (ou *implicites*) : créées par le moteur Aurora MySQL pour gérer des opérations telles que le tri, l'agrégation, les tables dérivées ou les expressions de table communes (CTEs). + Tables temporaires créées par l’utilisateur (ou *explicites*) : créées par le moteur Aurora MySQL lorsque vous utilisez l’instruction `CREATE TEMPORARY TABLE`. Il existe des considérations supplémentaires pour les tables temporaires internes et créées par l’utilisateur sur les instances de base de données de lecteur Aurora. Ces modifications sont présentées dans les sections suivantes. **Topics** + [Moteur de stockage pour tables temporaires internes (implicites)](#ams3-temptable-behavior-engine) + [Limitation de la taille des tables temporaires internes en mémoire](#ams3-temptable-behavior-limit) + [Atténuation des problèmes de remplissage pour les tables temporaires internes sur les réplicas Aurora](#ams3-temptable-behavior-mitigate) + [Optimisation du paramètre temptable\$1max\$1mmap sur les instances de base de données Aurora MySQL](#ams-optimize-temptable_max_mmap) + [Tables temporaires (explicites) créées par l’utilisateur sur les instances de base de données de lecteur](#ams3-temptable-behavior.user) + [Erreurs de création d’une table temporaire et atténuation](#ams3-temptable-behavior.errors) ## Moteur de stockage pour tables temporaires internes (implicites) Lors de la génération de jeux de résultats intermédiaires, Aurora MySQL tente initialement d’écrire dans des tables temporaires en mémoire. Cela peut échouer, en raison de types de données incompatibles ou de limites configurées. Si c’est le cas, la table temporaire est convertie en table temporaire sur disque plutôt que d’être conservée en mémoire. Pour plus d’informations, consultez [Internal Temporary Table Use in MySQL](https://dev.mysql.com/doc/refman/8.0/en/internal-temporary-tables.html) dans la documentation MySQL. Dans Aurora MySQL version 3, le fonctionnement des tables temporaires internes est différent des versions précédentes d’Aurora MySQL. Pour ces tables temporaires, au lieu de choisir entre les moteurs de stockage InnoDB et MyISAM, vous avez maintenant le choix entre les moteurs de stockage `TempTable` et `MEMORY`. Avec le moteur de stockage `TempTable`, vous disposez d’un choix supplémentaire pour gérer certaines données. Les données affectées dépassent la capacité du groupe de mémoire qui contient toutes les tables temporaires internes de l’instance de base de données. Ces choix peuvent influencer les performances des requêtes qui génèrent des volumes élevés de données temporaires, par exemple lors de l’exécution d’agrégations telles que `GROUP BY` sur des tables volumineuses. **Astuce** Si votre charge de travail inclut des requêtes qui génèrent des tables temporaires internes, confirmez les performances de votre application avec cette modification en exécutant des définitions de points de référence et en surveillant les métriques liées aux performances. Dans certains cas, la quantité de données temporaires correspond à la capacité du groupe de mémoire `TempTable` ou est légèrement supérieure à cette dernière. Le cas échéant, nous vous recommandons d’utiliser le paramètre `TempTable` pour les tables temporaires internes et les fichiers mappés en mémoire pour conserver toutes les données excédentaires. Il s’agit de la valeur par défaut. Le moteur de stockage `TempTable` est le moteur par défaut. `TempTable` utilise un groupe de mémoire commun pour toutes les tables temporaires utilisant ce moteur, au lieu d’une limite de mémoire maximale par table. La taille de ce groupe de mémoire est spécifiée par le paramètre [temptable\$1max\$1ram](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_max_ram). Elle est par défaut de 1 Gio sur les instances de base de données de 16 Gio de mémoire ou plus, et de 16 Mo sur les instances de base de données de moins de 16 Gio de mémoire. La taille du groupe de mémoire influe sur la consommation de mémoire au niveau de la session. Dans certains cas, lorsque vous utilisez le moteur de stockage `TempTable`, les données temporaires peuvent dépasser la taille du groupe de mémoire. Si tel est le cas, Aurora MySQL stocke les données de débordement à l’aide d’un mécanisme secondaire. Vous pouvez définir le paramètre [temptable\$1max\$1mmap](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_max_mmap) pour choisir si les données dépassent la taille des fichiers temporaires mappés en mémoire ou des tables temporaires internes InnoDB sur le disque. Les différents formats de données et les critères de dépassement de ces mécanismes de dépassement peuvent affecter les performances des requêtes. Pour ce faire, Ils influencent la quantité de données écrites sur disque et la demande de débit de stockage sur le disque. Aurora MySQL version 3 stocke les données de débordement de la manière suivante : + Sur l’instance de base de données d’enregistreur, les données qui débordent vers des tables temporaires internes InnoDB ou des fichiers temporaires mappés en mémoire se trouvent sur le stockage local de l’instance. + Sur les instances de base de données de lecteur, les données excédentaires se trouvent toujours dans des fichiers temporaires mappés en mémoire sur le stockage local. Les instances en lecture seule ne peuvent stocker aucune donnée sur le volume de cluster Aurora. Les paramètres de configuration associés aux tables temporaires internes s’appliquent différemment aux instances de lecteur et d’enregistreur sur votre cluster. + Sur les instances de lecteur, Aurora MySQL utilise toujours le moteur de stockage `TempTable`. + La taille par défaut de `temptable_max_mmap` est de 1 Gio, pour les instances de lecteur et d’enregistreur, quelle que soit la taille de la mémoire de l’instance de base de données. Vous pouvez ajuster cette valeur à la fois sur les instances d’enregistreur et de lecteur. + Définir `temptable_max_mmap` sur `0` désactive l’utilisation des fichiers temporaires mappés en mémoire sur les instances d’enregistreur. + Vous ne pouvez pas définir `temptable_max_mmap` sur `0` sur les instances de lecteur. **Note** Nous déconseillons l’utilisation du paramètre [temptable\$1use\$1mmap](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_use_mmap). Il est devenu obsolète et sa prise en charge devrait être supprimée dans une future version de MySQL. ## Limitation de la taille des tables temporaires internes en mémoire Comme indiqué dans [Moteur de stockage pour tables temporaires internes (implicites)](#ams3-temptable-behavior-engine), vous pouvez contrôler les ressources de tables temporaires de manière globale en utilisant les paramètres [temptable\$1max\$1ram](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_max_ram) et [temptable\$1max\$1mmap](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_max_mmap). Vous pouvez également limiter la taille de n’importe quelle table temporaire interne en mémoire en utilisant le paramètre de base de données [tmp\$1table\$1size](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_tmp_table_size). Cette limite vise à empêcher les requêtes individuelles de consommer une quantité excessive de ressources de tables temporaires globales, ce qui peut affecter les performances de requêtes simultanées nécessitant ces ressources. Le paramètre `tmp_table_size` définit la taille maximale des tables temporaires créées par le moteur de stockage `MEMORY` dans Aurora MySQL version 3. Dans Aurora MySQL version 3.04 ou ultérieure, `tmp_table_size` définit également la taille maximale des tables temporaires créées par le moteur de stockage `TempTable` quand le paramètre de base de données `aurora_tmptable_enable_per_table_limit` a pour valeur `ON`. Ce comportement est désactivé par défaut (`OFF`), ce qui constitue le même comportement que dans Aurora MySQL version 3.03 et versions antérieures. + Quand `aurora_tmptable_enable_per_table_limit` a pour valeur `OFF`, `tmp_table_size` n’est pas pris en compte pour les tables temporaires internes en mémoire créées par le moteur de stockage `TempTable`. Cependant, la limite globale des ressources `TempTable` s’applique toujours. Aurora MySQL a le comportement suivant lorsque la limite globale des ressources `TempTable` est atteinte : + Instances de base de données d’enregistreur : Aurora MySQL convertit automatiquement la table temporaire en mémoire en une table temporaire InnoDB sur disque. + Instances de base de données de lecteur : la requête se termine par une erreur. ``` ERROR 1114 (HY000): The table '/rdsdbdata/tmp/#sqlxx_xxx' is full ``` + Quand `aurora_tmptable_enable_per_table_limit` a pour valeur `ON`, Aurora MySQL a le comportement suivant lorsque la limite `tmp_table_size` est atteinte : + Instances de base de données d’enregistreur : Aurora MySQL convertit automatiquement la table temporaire en mémoire en une table temporaire InnoDB sur disque. + Instances de base de données de lecteur : la requête se termine par une erreur. ``` ERROR 1114 (HY000): The table '/rdsdbdata/tmp/#sqlxx_xxx' is full ``` La limite globale des ressources `TempTable` et la limite par table s’appliquent toutes les deux dans ce cas. **Note** Le paramètre `aurora_tmptable_enable_per_table_limit` n’a aucun effet quand [internal\$1tmp\$1mem\$1storage\$1engine](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_internal_tmp_mem_storage_engine) a pour valeur `MEMORY`. Dans ce cas, la taille maximale d’une table temporaire en mémoire est définie par la valeur [tmp\$1table\$1size](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_tmp_table_size) ou [max\$1heap\$1table\$1size](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_max_heap_table_size), la plus petite de ces deux valeurs étant retenue. Les exemples suivants montrent le comportement du paramètre `aurora_tmptable_enable_per_table_limit` pour les instances de base de données d’enregistreur et de lecteur. **Example d’une instance de base de données d’enregistreur avec `aurora_tmptable_enable_per_table_limit` défini sur `OFF`** La table temporaire en mémoire n’est pas convertie en table temporaire InnoDB sur disque. ``` mysql> set aurora_tmptable_enable_per_table_limit=0; Query OK, 0 rows affected (0.00 sec) mysql> select @@innodb_read_only,@@aurora_version,@@aurora_tmptable_enable_per_table_limit,@@temptable_max_ram,@@temptable_max_mmap; +--------------------+------------------+------------------------------------------+---------------------+----------------------+ | @@innodb_read_only | @@aurora_version | @@aurora_tmptable_enable_per_table_limit | @@temptable_max_ram | @@temptable_max_mmap | +--------------------+------------------+------------------------------------------+---------------------+----------------------+ | 0 | 3.04.0 | 0 | 1073741824 | 1073741824 | +--------------------+------------------+------------------------------------------+---------------------+----------------------+ 1 row in set (0.00 sec) mysql> show status like '%created_tmp_disk%'; +-------------------------+-------+ | Variable_name | Value | +-------------------------+-------+ | Created_tmp_disk_tables | 0 | +-------------------------+-------+ 1 row in set (0.00 sec) mysql> set cte_max_recursion_depth=4294967295; Query OK, 0 rows affected (0.00 sec) mysql> WITH RECURSIVE cte (n) AS (SELECT 1 UNION ALL SELECT n + 1 FROM cte WHERE n < 60000000) SELECT max(n) FROM cte; +----------+ | max(n) | +----------+ | 60000000 | +----------+ 1 row in set (13.99 sec) mysql> show status like '%created_tmp_disk%'; +-------------------------+-------+ | Variable_name | Value | +-------------------------+-------+ | Created_tmp_disk_tables | 0 | +-------------------------+-------+ 1 row in set (0.00 sec) ``` **Example d’une instance de base de données d’enregistreur avec `aurora_tmptable_enable_per_table_limit` défini sur `ON`** La table temporaire en mémoire est convertie en table temporaire InnoDB sur disque. ``` mysql> set aurora_tmptable_enable_per_table_limit=1; Query OK, 0 rows affected (0.00 sec) mysql> select @@innodb_read_only,@@aurora_version,@@aurora_tmptable_enable_per_table_limit,@@tmp_table_size; +--------------------+------------------+------------------------------------------+------------------+ | @@innodb_read_only | @@aurora_version | @@aurora_tmptable_enable_per_table_limit | @@tmp_table_size | +--------------------+------------------+------------------------------------------+------------------+ | 0 | 3.04.0 | 1 | 16777216 | +--------------------+------------------+------------------------------------------+------------------+ 1 row in set (0.00 sec) mysql> set cte_max_recursion_depth=4294967295; Query OK, 0 rows affected (0.00 sec) mysql> show status like '%created_tmp_disk%'; +-------------------------+-------+ | Variable_name | Value | +-------------------------+-------+ | Created_tmp_disk_tables | 0 | +-------------------------+-------+ 1 row in set (0.00 sec) mysql> WITH RECURSIVE cte (n) AS (SELECT 1 UNION ALL SELECT n + 1 FROM cte WHERE n < 6000000) SELECT max(n) FROM cte; +---------+ | max(n) | +---------+ | 6000000 | +---------+ 1 row in set (4.10 sec) mysql> show status like '%created_tmp_disk%'; +-------------------------+-------+ | Variable_name | Value | +-------------------------+-------+ | Created_tmp_disk_tables | 1 | +-------------------------+-------+ 1 row in set (0.00 sec) ``` **Example d’une instance de base de données de lecteur avec `aurora_tmptable_enable_per_table_limit` défini sur `OFF`** La requête se termine sans erreur car `tmp_table_size` ne s’applique pas, et la limite globale des ressources `TempTable` n’a pas été atteinte. ``` mysql> set aurora_tmptable_enable_per_table_limit=0; Query OK, 0 rows affected (0.00 sec) mysql> select @@innodb_read_only,@@aurora_version,@@aurora_tmptable_enable_per_table_limit,@@temptable_max_ram,@@temptable_max_mmap; +--------------------+------------------+------------------------------------------+---------------------+----------------------+ | @@innodb_read_only | @@aurora_version | @@aurora_tmptable_enable_per_table_limit | @@temptable_max_ram | @@temptable_max_mmap | +--------------------+------------------+------------------------------------------+---------------------+----------------------+ | 1 | 3.04.0 | 0 | 1073741824 | 1073741824 | +--------------------+------------------+------------------------------------------+---------------------+----------------------+ 1 row in set (0.00 sec) mysql> set cte_max_recursion_depth=4294967295; Query OK, 0 rows affected (0.00 sec) mysql> WITH RECURSIVE cte (n) AS (SELECT 1 UNION ALL SELECT n + 1 FROM cte WHERE n < 60000000) SELECT max(n) FROM cte; +----------+ | max(n) | +----------+ | 60000000 | +----------+ 1 row in set (14.05 sec) ``` **Example d’une instance de base de données de lecteur avec `aurora_tmptable_enable_per_table_limit` défini sur `OFF`** Cette requête atteint la limite globale TempTable des ressources lorsqu'elle `aurora_tmptable_enable_per_table_limit` est définie sur OFF. La requête se termine avec une erreur sur les instances de lecteur. ``` mysql> set aurora_tmptable_enable_per_table_limit=0; Query OK, 0 rows affected (0.00 sec) mysql> select @@innodb_read_only,@@aurora_version,@@aurora_tmptable_enable_per_table_limit,@@temptable_max_ram,@@temptable_max_mmap; +--------------------+------------------+------------------------------------------+---------------------+----------------------+ | @@innodb_read_only | @@aurora_version | @@aurora_tmptable_enable_per_table_limit | @@temptable_max_ram | @@temptable_max_mmap | +--------------------+------------------+------------------------------------------+---------------------+----------------------+ | 1 | 3.04.0 | 0 | 1073741824 | 1073741824 | +--------------------+------------------+------------------------------------------+---------------------+----------------------+ 1 row in set (0.00 sec) mysql> set cte_max_recursion_depth=4294967295; Query OK, 0 rows affected (0.01 sec) mysql> WITH RECURSIVE cte (n) AS (SELECT 1 UNION ALL SELECT n + 1 FROM cte WHERE n < 120000000) SELECT max(n) FROM cte; ERROR 1114 (HY000): The table '/rdsdbdata/tmp/#sqlfd_1586_2' is full ``` **Example d’une instance de base de données de lecteur avec `aurora_tmptable_enable_per_table_limit` défini sur `ON`** La requête se termine avec une erreur lorsque la limite `tmp_table_size` est atteinte. ``` mysql> set aurora_tmptable_enable_per_table_limit=1; Query OK, 0 rows affected (0.00 sec) mysql> select @@innodb_read_only,@@aurora_version,@@aurora_tmptable_enable_per_table_limit,@@tmp_table_size; +--------------------+------------------+------------------------------------------+------------------+ | @@innodb_read_only | @@aurora_version | @@aurora_tmptable_enable_per_table_limit | @@tmp_table_size | +--------------------+------------------+------------------------------------------+------------------+ | 1 | 3.04.0 | 1 | 16777216 | +--------------------+------------------+------------------------------------------+------------------+ 1 row in set (0.00 sec) mysql> set cte_max_recursion_depth=4294967295; Query OK, 0 rows affected (0.00 sec) mysql> WITH RECURSIVE cte (n) AS (SELECT 1 UNION ALL SELECT n + 1 FROM cte WHERE n < 6000000) SELECT max(n) FROM cte; ERROR 1114 (HY000): The table '/rdsdbdata/tmp/#sqlfd_8_2' is full ``` ## Atténuation des problèmes de remplissage pour les tables temporaires internes sur les réplicas Aurora Pour éviter les problèmes de limite de taille pour les tables temporaires, définissez les paramètres `temptable_max_ram` et `temptable_max_mmap` sur une valeur combinée, adaptée aux exigences de votre charge de travail. Soyez vigilant lorsque vous définissez la valeur du paramètre `temptable_max_ram`. La définition d'une valeur trop élevée réduit la mémoire disponible sur l'instance de base de données, ce qui peut provoquer un out-of-memory problème. Surveillez la quantité moyenne de mémoire libérable sur l’instance de base de données. Déterminez ensuite une valeur appropriée pour `temptable_max_ram`, de sorte qu’il vous reste une quantité raisonnable de mémoire libre sur l’instance. Pour plus d’informations, consultez [Problèmes liés à la mémoire libérable dans Amazon Aurora](CHAP_Troubleshooting.md#Troubleshooting.FreeableMemory). Il est également important de surveiller la taille du stockage local et la consommation d’espace des tables temporaires. Vous pouvez surveiller le stockage temporaire disponible pour une instance de base de données spécifique à l'aide de la CloudWatch métrique `FreeLocalStorage` Amazon, décrite dans[CloudWatch Métriques Amazon pour Amazon Aurora](Aurora.AuroraMonitoring.Metrics.md). **Note** Cette procédure ne fonctionne pas quand le paramètre `aurora_tmptable_enable_per_table_limit` est défini sur `ON`. Pour plus d’informations, consultez [Limitation de la taille des tables temporaires internes en mémoire](#ams3-temptable-behavior-limit). **Example 1** Vous savez que vos tables temporaires atteignent une taille cumulée de 20 Gio. Vous souhaitez définir les tables temporaires en mémoire sur 2 Gio et atteindre une taille maximale de 20 Gio sur disque. Définissez `temptable_max_ram` sur **2,147,483,648** et `temptable_max_mmap` sur **21,474,836,480**. Ces valeurs sont exprimées en octets. Ces valeurs de paramètre garantissent que vos tables temporaires peuvent atteindre un total cumulé de 22 Gio. **Example 2** La taille actuelle de votre instance est 16xlarge ou supérieure. Vous ne connaissez pas la taille totale des tables temporaires dont vous pourriez avoir besoin. Vous souhaitez pouvoir utiliser jusqu’à 4 Gio en mémoire et jusqu’à la taille de stockage maximale disponible sur disque. Définissez `temptable_max_ram` sur **4,294,967,296** et `temptable_max_mmap` sur **1,099,511,627,776**. Ces valeurs sont exprimées en octets. Ici, vous êtes en train de définir `temptable_max_mmap` sur 1 Tio, ce qui est inférieur au stockage local maximal de 1,2 Tio sur une instance de base de données Aurora 16xlarge. Sur une taille d’instance plus petite, ajustez la valeur de `temptable_max_mmap` afin qu’elle ne remplisse pas le stockage local disponible. Par exemple, une instance 2xlarge ne dispose que de 160 Gio de stockage local disponible. Par conséquent, nous vous recommandons de définir la valeur sur 160 Gio au maximum. Pour plus d’informations sur le stockage local disponible pour les tailles d’instance de base de données, consultez [Limites de stockage temporaires pour Aurora MySQLLimites de stockage temporaire](AuroraMySQL.Managing.Performance.md#AuroraMySQL.Managing.TempStorage). ## Optimisation du paramètre temptable\$1max\$1mmap sur les instances de base de données Aurora MySQL Le paramètre `temptable_max_mmap` d’Aurora MySQL contrôle la quantité maximale d’espace disque local qui peut être utilisée par les fichiers mappés en mémoire avant de déborder vers les tables temporaires InnoDB sur disque (sur les instances de base de données d’enregistreur) ou de provoquer une erreur (sur les instances de base de données de lecteur). Une configuration appropriée de ce paramètre d’instance de base de données peut aider à optimiser les performances de vos instances de base de données. **Conditions préalables** 1. Assurez-vous que le schéma de performances est activé. Pour effectuer une vérification, exécutez la commande suivante. ``` SELECT @@performance_schema; ``` La valeur de sortie `1` indique qu’il est activé. 1. Vérifiez que l’instrumentation de mémoire de table temporaire est activée. Pour effectuer une vérification, exécutez la commande suivante. ``` SELECT name, enabled FROM performance_schema.setup_instruments WHERE name LIKE '%memory%temptable%'; ``` La colonne `enabled` indique `YES` pour les entrées d’instrumentation de mémoire de table temporaire pertinentes. **Surveillance de l’utilisation des tables temporaires** Lorsque vous définissez la valeur initiale pour `temptable_max_mmap`, nous vous recommandons de commencer par 80 % de la taille de stockage local pour la classe d’instance de base de données que vous utilisez. Les tables temporaires disposeront ainsi de suffisamment d’espace disque pour fonctionner efficacement, tout en laissant de la place à d’autres utilisations du disque sur l’instance. Pour connaître la taille de stockage local de votre classe d’instance de base de données, consultez [Limites de stockage temporaires pour Aurora MySQLLimites de stockage temporaire](AuroraMySQL.Managing.Performance.md#AuroraMySQL.Managing.TempStorage). Par exemple, si vous utilisez la classe d’instance de base de données db.r5.large, la taille du stockage local est de 32 Gio. Dans ce cas, vous devez initialement définir le paramètre `temptable_max_mmap` pour qu’il corresponde à 80 % de 32 Gio, soit 25,6 Gio. Après avoir défini la valeur `temptable_max_mmap` initiale, exécutez votre charge de travail maximale sur les instances Aurora MySQL. Surveillez l’utilisation actuelle et l’utilisation élevée du disque des tables temporaires à l’aide de la requête SQL suivante : ``` SELECT event_name, current_count, current_alloc, current_avg_alloc, high_count, high_alloc, high_avg_alloc FROM sys.memory_global_by_current_bytes WHERE event_name LIKE 'memory/temptable/%'; ``` Cette requête permet de récupérer les informations suivantes : + `event_name` — Nom de l’événement d’utilisation du disque ou de la mémoire de table temporaire. + `current_count` — Nombre actuel de blocs de disque ou de mémoire de table temporaire alloués. + `current_alloc` — Quantité actuelle de mémoire ou de disque allouée aux tables temporaires. + `current_avg_alloc` — Taille moyenne actuelle des blocs de disque ou de mémoire de table temporaire. + `high_count` — Nombre maximal de blocs disque ou de mémoire de table temporaire alloués. + `high_alloc` — Quantité maximale de mémoire ou de disque allouée aux tables temporaires. + `high_avg_alloc` — Taille moyenne maximale des blocs de disque ou de mémoire de table temporaire. Si vos requêtes échouent avec une erreur de type La table est pleine avec ce paramètre, cela indique que votre charge de travail nécessite plus d’espace disque pour les opérations des tables temporaires. Dans ce cas, envisagez d’augmenter la taille de votre instance de base de données pour qu’elle dispose d’un espace de stockage local plus important. **Configuration de la valeur `temptable_max_mmap` optimale** Utilisez la procédure suivante pour surveiller et définir la taille appropriée pour le paramètre `temptable_max_mmap`. 1. Passez en revue le résultat de la requête précédente et identifiez le pic d’utilisation du disque de table temporaire, comme indiqué dans la colonne `high_alloc`. 1. En fonction du pic d’utilisation du disque de table temporaire, ajustez le paramètre `temptable_max_mmap` dans le groupe de paramètres de base de données de vos instances de base de données Aurora MySQL. Définissez cette valeur pour qu’elle soit légèrement supérieure au pic d’utilisation du disque de table temporaire afin de tenir compte de la croissance future. 1. Appliquez les modifications du groupe de paramètres à vos instances de base de données. 1. Surveillez à nouveau l’utilisation du disque de table temporaire pendant votre charge de travail maximale pour vous assurer que la nouvelle valeur `temptable_max_mmap` est appropriée. 1. Répétez les étapes précédentes autant de fois que nécessaire pour optimiser le paramètre `temptable_max_mmap`. ## Tables temporaires (explicites) créées par l’utilisateur sur les instances de base de données de lecteur Vous pouvez créer des tables temporaires explicites en utilisant le mot-clé `TEMPORARY` dans votre instruction `CREATE TABLE`. Les tables temporaires explicites sont prises en charge sur l’instance de base de données d’enregistreur dans un cluster de bases de données Aurora. Vous pouvez également utiliser des tables temporaires explicites sur les instances de base de données de lecteur, mais les tables ne peuvent pas imposer l’utilisation du moteur de stockage InnoDB. Pour éviter les erreurs lors de la création de tables temporaires explicites sur les instances de base de données de lecture Aurora MySQL, assurez-vous d’exécuter toutes les instructions `CREATE TEMPORARY TABLE` de l’une ou l’autre des manières suivantes, ou des deux : + Ne spécifiez pas la clause `ENGINE=InnoDB`. + Ne définissez pas le mode SQL sur `NO_ENGINE_SUBSTITUTION`. ## Erreurs de création d’une table temporaire et atténuation L’erreur que vous recevez est différente selon que vous utilisez ou non une instruction `CREATE TEMPORARY TABLE` simple ou la variante `CREATE TEMPORARY TABLE AS SELECT`. Les exemples suivants montrent les différents types d’erreurs. Ce comportement de table temporaire s’applique uniquement aux instances en lecture seule. Ce premier exemple confirme que c’est le type d’instance à laquelle la session est connectée. ``` mysql> select @@innodb_read_only; +--------------------+ | @@innodb_read_only | +--------------------+ | 1 | +--------------------+ ``` Les instructions `CREATE TEMPORARY TABLE` simples échouent lorsque le mode SQL `NO_ENGINE_SUBSTITUTION` est activé. Lorsque `NO_ENGINE_SUBSTITUTION` est désactivé (par défaut), la substitution du moteur approprié est effectuée et la création de la table temporaire aboutit. ``` mysql> set sql_mode = 'NO_ENGINE_SUBSTITUTION'; mysql> CREATE TEMPORARY TABLE tt2 (id int) ENGINE=InnoDB; ERROR 3161 (HY000): Storage engine InnoDB is disabled (Table creation is disallowed). mysql> SET sql_mode = ''; mysql> CREATE TEMPORARY TABLE tt4 (id int) ENGINE=InnoDB; mysql> SHOW CREATE TABLE tt4\G *************************** 1. row *************************** Table: tt4 Create Table: CREATE TEMPORARY TABLE `tt4` ( `id` int DEFAULT NULL ) ENGINE=MyISAM DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci ``` Les instructions `CREATE TEMPORARY TABLE AS SELECT` échouent quand le mode SQL `NO_ENGINE_SUBSTITUTION` est activé. Lorsque `NO_ENGINE_SUBSTITUTION` est désactivé (par défaut), la substitution du moteur approprié est effectuée et la création de la table temporaire aboutit. ``` mysql> set sql_mode = 'NO_ENGINE_SUBSTITUTION'; mysql> CREATE TEMPORARY TABLE tt1 ENGINE=InnoDB AS SELECT * FROM t1; ERROR 3161 (HY000): Storage engine InnoDB is disabled (Table creation is disallowed). mysql> SET sql_mode = ''; mysql> show create table tt3; +-------+----------------------------------------------------------+ | Table | Create Table | +-------+----------------------------------------------------------+ | tt3 | CREATE TEMPORARY TABLE `tt3` ( `id` int DEFAULT NULL ) ENGINE=MyISAM DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci | +-------+----------------------------------------------------------+ 1 row in set (0.00 sec) ``` Pour plus d'informations sur les aspects liés au stockage et les implications en termes de performances des tables temporaires dans Aurora MySQL version 3, consultez le billet de blog [Utiliser le moteur de TempTable stockage sur Amazon RDS for MySQL et Amazon Aurora MySQL](https://aws.amazon.com/blogs/database/use-the-temptable-storage-engine-on-amazon-rds-for-mysql-and-amazon-aurora-mysql/). # Comparaison d’Aurora MySQL version 2 et Aurora MySQL version 3 Utilisez les éléments suivants pour en savoir plus sur les modifications à prendre en compte lorsque vous mettez à niveau le cluster Aurora MySQL version 2 vers la version 3. **Topics** + [Prise en charge du langage de définition des données (DDL) atomiques](#AuroraMySQL.Compare-v2-v3-atomic-ddl) + [Différences de fonctions entre Aurora MySQL version 2 et 3](#AuroraMySQL.Compare-v2-v3-features) + [Assistance pour les classes d’instance](#AuroraMySQL.mysql80-instance-classes) + [Modifications des paramètres d’Aurora MySQL version 3](#AuroraMySQL.mysql80-parameter-changes) + [Variables d’état](#AuroraMySQL.mysql80-status-vars) + [Changements linguistiques inclusifs pour Aurora MySQL version 3](#AuroraMySQL.8.0-inclusive-language) + [Valeurs AUTO\$1INCREMENT](#AuroraMySQL.mysql80-autoincrement) + [Réplication de journaux binaires](#AuroraMySQL.mysql80-binlog) ## Prise en charge du langage de définition des données (DDL) atomiques L’un des changements les plus importants entre MySQL 5.7 et 8.0 est l’introduction de l’[Atomic Data Dictionary](https://dev.mysql.com/doc/refman/8.0/en/data-dictionary-file-removal.html). Avant MySQL 8.0, le dictionnaire de données MySQL utilisait une approche basée sur des fichiers pour stocker les métadonnées telles que les définitions de tables (.frm), les déclencheurs (.trg) et les fonctions séparément des métadonnées du moteur de stockage (telles que celles d’InnoDB). Cela posait certains problèmes, y compris le risque que les tables deviennent « [orphelines](https://dev.mysql.com/doc/refman/5.7/en/innodb-troubleshooting-datadict.html) » si un événement inattendu se produisait au cours d’une opération DDL, entraînant une désynchronisation des métadonnées basées sur les fichiers et des métadonnées du moteur de stockage. Pour résoudre ce problème, MySQL 8.0 inclut l’Atomic Data Dictionary, qui stocke toutes les métadonnées dans un ensemble de tables InnoDB internes dans le schéma `mysql`. Cette nouvelle architecture fournit une méthode transactionnelle conforme à l’[ACID](https://en.wikipedia.org/wiki/ACID) pour gérer les métadonnées des bases de données, résolvant ainsi le problème de « DDL atomique » rencontré par l’ancienne approche basée sur les fichiers. Pour plus d’informations sur l’Atomic Data Dictionary, consultez [Suppression du stockage de métadonnées basé sur des fichiers](https://dev.mysql.com/doc/refman/8.0/en/data-dictionary-file-removal.html) et [Prise en charge des instructions de définition de données atomiques](https://dev.mysql.com/doc/refman/8.0/en/atomic-ddl.html) dans le *manuel de référence MySQL*. En raison de cette modification d’architecture, vous devez tenir compte des points suivants lors de la mise à niveau d’Aurora MySQL version 2 vers la version 3 : + Les métadonnées basées sur les fichiers dans la version 2 doivent être migrées vers les nouvelles tables du dictionnaire de données lors du processus de mise à niveau vers la version 3. Selon le nombre d’objets de base de données migrés, cela peut prendre un certain temps. + Les modifications ont également introduit de nouvelles incompatibilités qui devront peut-être être corrigées avant de pouvoir passer de MySQL 5.7 à 8.0. Par exemple, la version 8.0 contient de nouveaux mots clés réservés susceptibles d’entrer en conflit avec les noms d’objets de base de données existants. Pour vous aider à identifier ces incompatibilités avant de mettre à niveau le moteur, Aurora MySQL exécute une série de vérification de la compatibilité des mises à niveau (vérifications préalables) afin de déterminer s’il existe des objets incompatibles dans votre dictionnaire de base de données, avant d’effectuer la mise à niveau du dictionnaire de données. Pour plus d’informations sur ces vérifications préalables, consultez [Vérifications préalables aux mises à niveau de version majeure pour Aurora MySQL](AuroraMySQL.upgrade-prechecks.md). ## Différences de fonctions entre Aurora MySQL version 2 et 3 Les fonctions Amazon Aurora MySQL suivantes sont prises en charge dans Aurora MySQL pour MySQL 5.7, mais pas dans Aurora MySQL pour MySQL 8.0 : + Vous ne pouvez pas utiliser Aurora MySQL version 3 pour les clusters Aurora Serverless v1. Aurora MySQL version 3 fonctionne avec Aurora Serverless v2. + Le mode laboratoire ne s’applique pas à Aurora MySQL version 3. Il n’existe aucune fonctionnalité de mode laboratoire dans Aurora MySQL version 3. Le DDL instantané remplace la fonction DDL en ligne rapide qui était précédemment disponible en mode laboratoire. Pour obtenir un exemple, consultez [Instant DDL (Aurora MySQL version 3)](AuroraMySQL.Managing.FastDDL.md#AuroraMySQL.mysql80-instant-ddl). + Le cache de requêtes est supprimé de MySQL 8.0 version communautaire et d’Aurora MySQL version 3. + Aurora MySQL version 3 est compatible avec la fonction Joindre par hachage de MySQL version communautaire. L’implémentation spécifique à Aurora des jointures de hachage dans Aurora MySQL version 2 n’est pas utilisée. Pour plus d’informations sur l’utilisation des jointures de hachage avec une requête parallèle Aurora, consultez [Activation de la jointure par hachage pour les clusters de requête parallèle](aurora-mysql-parallel-query-enabling.md#aurora-mysql-parallel-query-enabling-hash-join) et [Indicateurs Aurora MySQL](AuroraMySQL.Reference.Hints.md). Pour obtenir des informations générales sur l’utilisation des jointures de hachage, consultez [Optimisation des jointures de hachage](https://dev.mysql.com/doc/refman/8.0/en/hash-joins.html) dans le *manuel de référence MySQL*. + La procédure `mysql.lambda_async` stockée rendue obsolète dans Aurora MySQL version 2 est supprimée dans la version 3. Pour la version 3, utilisez la fonction asynchrone `lambda_async` à la place. + Le jeu de caractères par défaut dans Aurora MySQL version 3 est `utf8mb4`. Dans Aurora MySQL version 2, le jeu de caractères par défaut était `latin1`. Pour plus d’informations sur ce jeu de caractères, consultez [Jeu de caractères utf8mb4 (encodage Unicode 4 octets en UTF-8)](https://dev.mysql.com/doc/refman/8.0/en/charset-unicode-utf8mb4.html) dans le *manuel de référence MySQL*. Certaines fonctions Aurora MySQL sont disponibles pour certaines combinaisons de région AWS et de version du moteur de base de données. Pour en savoir plus, consultez [Fonctionnalités prises en charge dans Amazon Aurora by Région AWS et dans le moteur de base de données Aurora](Concepts.AuroraFeaturesRegionsDBEngines.grids.md). ## Assistance pour les classes d’instance Aurora MySQL version 3 prend en charge un ensemble de classes d’instance différent de celui d’Aurora MySQL version 2 : + Pour les instances plus volumineuses, vous pouvez utiliser les classes d’instance modernes telles que `db.r5`, `db.r6g` et `db.x2g`. + Pour les instances plus petites, vous pouvez utiliser les classes d’instance modernes telles que `db.t3` et `db.t4g`. **Note** Nous recommandons d’utiliser les classes d’instance de base de données T uniquement pour les serveurs de développement et de test, ou pour d’autres serveurs non dédiés à la production. Pour plus de détails sur les classes d’instance T, consultez [Utilisation de classes d’instance T pour le développement et les tests](AuroraMySQL.BestPractices.Performance.md#AuroraMySQL.BestPractices.T2Medium). Les classes d’instance suivantes d’Aurora MySQL version 2 ne sont pas disponibles pour Aurora MySQL version 3 : + `db.r4` + `db.r3` + `db.t3.small` + `db.t2` Dans vos scripts d’administration, vérifiez les instructions CLI qui créent des instances de base de données Aurora MySQL. Codez en dur les noms de classes d’instance non disponibles pour Aurora MySQL version 3. Si nécessaire, modifiez les noms de classes d’instance par ceux pris en charge par Aurora MySQL version 3. **Astuce** Pour vérifier les classes d’instance que vous pouvez utiliser pour une combinaison spécifique de version Aurora MySQL et de région AWS, utilisez la commande `describe-orderable-db-instance-options` de l’AWS CLI. Pour plus d’informations sur les classes d’instance Aurora, consultez [Classes d'instances de base de données Amazon Aurora](Concepts.DBInstanceClass.md). ## Modifications des paramètres d’Aurora MySQL version 3 Aurora MySQL version 3 inclut de nouveaux paramètres de configuration au niveau du cluster et de l’instance. Aurora MySQL version 3 supprime également certains paramètres présents dans Aurora MySQL version 2. Certains noms de paramètres sont modifiés suite à l’initiative visant un langage inclusif. Pour des raisons de compatibilité ascendante, vous pouvez toujours récupérer les valeurs des paramètres à l’aide des anciens noms ou des nouveaux noms. Toutefois, vous devez utiliser les nouveaux noms pour spécifier des valeurs de paramètres dans un groupe de paramètres personnalisés. Dans Aurora MySQL version 3, la valeur du paramètre `lower_case_table_names` est définie de façon permanente au moment de la création du cluster. Si vous utilisez une autre valeur que la valeur par défaut pour cette option, configurez votre groupe de paramètres personnalisés Aurora MySQL version 3 avant la mise à niveau. Spécifiez ensuite le groupe de paramètres pendant l’opération de création de cluster ou de restauration d’instantanés. **Note** Avec une base de données globale Aurora basée sur Aurora MySQL, vous ne pouvez pas effectuer une mise à niveau sur place d’Aurora MySQL version 2 vers la version 3 si le paramètre `lower_case_table_names` est activé. Utilisez plutôt la méthode de restauration des instantanés. Dans Aurora MySQL version 3, les paramètres `init_connect` et `read_only` ne s’appliquent pas aux utilisateurs disposant du privilège `CONNECTION_ADMIN`. Cela inclut l’utilisateur principal d’Aurora. Pour plus d’informations, consultez [Modèle de privilège basé sur les rôles](AuroraMySQL.Compare-80-v3.md#AuroraMySQL.privilege-model). Pour obtenir la liste de tous les paramètres du cluster Aurora MySQL, consultez [Paramètres de niveau cluster](AuroraMySQL.Reference.ParameterGroups.md#AuroraMySQL.Reference.Parameters.Cluster). Le tableau couvre tous les paramètres d’Aurora MySQL versions 2 et 3. Le tableau contient des notes indiquant les nouveaux paramètres dans Aurora MySQL version 3 ou ceux qui ont été supprimés d’Aurora MySQL version 3. Pour obtenir la liste complète de tous les paramètres de l’instance Aurora MySQL, consultez [Paramètres de niveau instance](AuroraMySQL.Reference.ParameterGroups.md#AuroraMySQL.Reference.Parameters.Instance). Le tableau couvre tous les paramètres d’Aurora MySQL versions 2 et 3. Le tableau contient des notes indiquant les nouveaux paramètres dans Aurora MySQL version 3 et ceux qui ont été supprimés d’Aurora MySQL version 3. Il contient également des notes indiquant les paramètres modifiables dans les versions antérieures, mais pas Aurora MySQL version 3. Pour plus d’informations sur les noms de paramètres modifiés, consultez [Changements linguistiques inclusifs pour Aurora MySQL version 3](#AuroraMySQL.8.0-inclusive-language). ## Variables d’état Pour plus d’informations sur les variables d’état non applicables à Aurora MySQL, consultez [Variables d’état MySQL ne s’appliquant pas à Aurora MySQL](AuroraMySQL.Reference.GlobalStatusVars.md#AuroraMySQL.Reference.StatusVars.Inapplicable). ## Changements linguistiques inclusifs pour Aurora MySQL version 3 Aurora MySQL version 3 est compatible avec la version 8.0.23 de MySQL Community Edition. Aurora MySQL version 3 inclut également des modifications depuis MySQL 8.0.26 liées aux mots-clés et aux schémas de système pour un langage inclusif. Par exemple, il est préférable d’utiliser la commande `SHOW REPLICA STATUS` plutôt que la commande `SHOW SLAVE STATUS`. Les métriques Amazon CloudWatch suivantes portent de nouveaux noms dans Aurora MySQL version 3. Dans Aurora MySQL version 3, seuls les nouveaux noms de métriques sont disponibles. Assurez-vous de mettre à jour toutes les alarmes ou autres automatisations qui reposent sur des noms de métriques lorsque vous effectuez une mise à niveau vers Aurora MySQL version 3. | Ancien nom | Nouveau nom | | --- | --- | | ForwardingMasterDMLLatency | ForwardingWriterDMLLatency | | ForwardingMasterOpenSessions | ForwardingWriterOpenSessions | | AuroraDMLRejectedMasterFull | AuroraDMLRejectedWriterFull | | ForwardingMasterDMLThroughput | ForwardingWriterDMLThroughput | Les variables d’état suivantes portent de nouveaux noms dans Aurora MySQL version 3. Pour des raisons de compatibilité, vous pouvez utiliser l’un ou l’autre des noms dans la version initiale d’Aurora MySQL version 3. Les anciens noms de variables d’état seront supprimés dans une version ultérieure. | Nom à supprimer | Nom nouveau ou préféré | | --- | --- | | Aurora\$1fwd\$1master\$1dml\$1stmt\$1duration | Aurora\$1fwd\$1writer\$1dml\$1stmt\$1duration | | Aurora\$1fwd\$1master\$1dml\$1stmt\$1count | Aurora\$1fwd\$1writer\$1dml\$1stmt\$1count | | Aurora\$1fwd\$1master\$1select\$1stmt\$1duration | Aurora\$1fwd\$1writer\$1select\$1stmt\$1duration | | Aurora\$1fwd\$1master\$1select\$1stmt\$1count | Aurora\$1fwd\$1writer\$1select\$1stmt\$1count | | Aurora\$1fwd\$1master\$1errors\$1session\$1timeout | Aurora\$1fwd\$1writer\$1errors\$1session\$1timeout | | Aurora\$1fwd\$1master\$1open\$1sessions | Aurora\$1fwd\$1writer\$1open\$1sessions | | Aurora\$1fwd\$1master\$1errors\$1session\$1limit | Aurora\$1fwd\$1writer\$1errors\$1session\$1limit | | Aurora\$1fwd\$1master\$1errors\$1rpc\$1timeout | Aurora\$1fwd\$1writer\$1errors\$1rpc\$1timeout | Les paramètres de configuration suivants portent de nouveaux noms dans Aurora MySQL version 3. Pour des raisons de compatibilité, vous pouvez vérifier les valeurs des paramètres dans le client `mysql` en utilisant l’un ou l’autre des noms dans la version initiale d’Aurora MySQL version 3. Vous pouvez uniquement utiliser les nouveaux noms lorsque vous modifiez les valeurs dans un groupe de paramètres personnalisés. Les anciens noms de paramètres seront supprimés dans une version ultérieure. | Nom à supprimer | Nom nouveau ou préféré | | --- | --- | | aurora\$1fwd\$1master\$1idle\$1timeout | aurora\$1fwd\$1writer\$1idle\$1timeout | | aurora\$1fwd\$1master\$1max\$1connections\$1pct | aurora\$1fwd\$1writer\$1max\$1connections\$1pct | | master\$1verify\$1checksum | source\$1verify\$1checksum | | sync\$1master\$1info | sync\$1source\$1info | | init\$1slave | init\$1replica | | rpl\$1stop\$1slave\$1timeout | rpl\$1stop\$1replica\$1timeout | | log\$1slow\$1slave\$1statements | log\$1slow\$1replica\$1statements | | slave\$1max\$1allowed\$1packet | replica\$1max\$1allowed\$1packet | | slave\$1compressed\$1protocol | replica\$1compressed\$1protocol | | slave\$1exec\$1mode | replica\$1exec\$1mode | | slave\$1type\$1conversions | replica\$1type\$1conversions | | slave\$1sql\$1verify\$1checksum | replica\$1sql\$1verify\$1checksum | | slave\$1parallel\$1type | replica\$1parallel\$1type | | slave\$1preserve\$1commit\$1order | replica\$1preserve\$1commit\$1order | | log\$1slave\$1updates | log\$1replica\$1updates | | slave\$1allow\$1batching | replica\$1allow\$1batching | | slave\$1load\$1tmpdir | replica\$1load\$1tmpdir | | slave\$1net\$1timeout | replica\$1net\$1timeout | | sql\$1slave\$1skip\$1counter | sql\$1replica\$1skip\$1counter | | slave\$1skip\$1errors | replica\$1skip\$1errors | | slave\$1checkpoint\$1period | replica\$1checkpoint\$1period | | slave\$1checkpoint\$1group | replica\$1checkpoint\$1group | | slave\$1transaction\$1retries | replica\$1transaction\$1retries | | slave\$1parallel\$1workers | replica\$1parallel\$1workers | | slave\$1pending\$1jobs\$1size\$1max | replica\$1pending\$1jobs\$1size\$1max | | pseudo\$1slave\$1mode | pseudo\$1replica\$1mode | Les procédures enregistrées suivantes portent de nouveaux noms dans Aurora MySQL version 3. Pour des raisons de compatibilité, vous pouvez utiliser l’un ou l’autre des noms dans la version initiale d’Aurora MySQL version 3. Les anciens noms de procédures seront supprimés dans une version ultérieure. | Nom à supprimer | Nom nouveau ou préféré | | --- | --- | | mysql.rds\$1set\$1master\$1auto\$1position | mysql.rds\$1set\$1source\$1auto\$1position | | mysql.rds\$1set\$1external\$1master | mysql.rds\$1set\$1external\$1source | | mysql.rds\$1set\$1external\$1master\$1with\$1auto\$1position | mysql.rds\$1set\$1external\$1source\$1with\$1auto\$1position | | mysql.rds\$1reset\$1external\$1master | mysql.rds\$1reset\$1external\$1source | | mysql.rds\$1next\$1master\$1log | mysql.rds\$1next\$1source\$1log | ## Valeurs AUTO\$1INCREMENT Dans Aurora MySQL version 3, Aurora conserve la valeur `AUTO_INCREMENT` pour chaque table lorsqu’elle redémarre chaque instance de base de données. Dans Aurora MySQL version 2, la valeur `AUTO_INCREMENT` n’était pas conservée après un redémarrage. La valeur `AUTO_INCREMENT` n’est pas conservée lorsque vous configurez un nouveau cluster en effectuant une restauration à partir d’un instantané ou une reprise ponctuelle et en clonant un cluster. Le cas échéant, la valeur `AUTO_INCREMENT` est initialisée en fonction de la valeur reposant sur la plus grande valeur de colonne de la table au moment de la création de l’instantané. Ce comportement est différent de celui de RDS pour MySQL 8.0, où la valeur `AUTO_INCREMENT` est conservée pendant ces opérations. ## Réplication de journaux binaires Dans la version 8.0 de MySQL Community Edition, la réplication des journaux binaires est activée par défaut. Dans Aurora MySQL version 3, la réplication des journaux binaires est désactivée par défaut. **Astuce** Si vos exigences en matière de haute disponibilité sont satisfaites par les fonctions de réplication intégrées à Aurora, vous pouvez laisser la réplication des journaux binaires désactivée. De cette façon, vous pouvez éviter la surcharge de performances de la réplication des journaux binaires. Vous pouvez également éviter la surveillance et le dépannage associés nécessaires à la gestion de la réplication des journaux binaires. Aurora prend en charge la réplication de journaux binaires depuis une source compatible MySQL 5.7 vers Aurora MySQL version 3. Le système source peut être un cluster de bases de données Aurora MySQL, une instance de base de données RDS pour MySQL ou une instance MySQL sur site. Tout comme MySQL version communautaire, Aurora MySQL prend en charge la réplication depuis une source exécutant une version spécifique vers une cible exécutant la même version majeure ou une version majeure supérieure. Par exemple, la réplication depuis un système compatible MySQL 5.6 vers Aurora MySQL version 3 n’est pas prise en charge. La réplication depuis Aurora MySQL version 3 vers un système compatible MySQL 5.7 ou MySQL 5.6 n’est pas prise en charge. Pour plus d’informations sur l’utilisation de la réplication des journaux binaires, consultez [Réplication entre Aurora et MySQL ou entre Aurora et un autre cluster de bases de données Aurora (réplication de journaux binaires)](AuroraMySQL.Replication.MySQL.md). Aurora MySQL version 3 inclut des améliorations apportées à la réplication des journaux binaires dans MySQL 8.0 version communautaire, comme la réplication filtrée. Pour plus d’informations sur les améliorations apportées à MySQL 8.0 version communautaire, consultez [Comment les serveurs évaluent les règles de filtrage de réplication](https://dev.mysql.com/doc/refman/8.0/en/replication-rules.html) dans le *manuel de référence MySQL*. ### Compression des transactions pour la réplication des journaux binaires Pour plus d’informations sur l’utilisation de la compression des journaux binaires, consultez [Compression des transactions de journaux binaires](https://dev.mysql.com/doc/refman/8.0/en/binary-log-transaction-compression.html)dans le manuel de référence MySQL. Les limitations suivantes s’appliquent à la compression des journaux binaires dans Aurora MySQL version 3 : + Les transactions dont les données de journaux binaires sont supérieures à la taille de paquet maximale autorisée ne sont pas compressées. Ceci est vrai, que le paramètre de compression des journaux binaires Aurora MySQL soit activé ou non. Ces transactions sont répliquées sans être compressées. + Si vous utilisez un connecteur CDC (Change Data Capture) qui ne prend pas encore en charge MySQL 8.0, vous ne pouvez pas utiliser cette fonction. Nous vous recommandons de tester minutieusement tous les connecteurs tiers avec une compression de journaux binaires. Nous vous recommandons également de le faire avant d’activer la compression des journaux binaires sur les systèmes qui utilisent la réplication des journaux binaires pour CDC. # Comparaison d’Aurora MySQL version 3 et de MySQL 8.0 Community Edition Vous pouvez utiliser les informations suivantes pour en savoir plus sur les modifications à prendre en compte lorsque vous effectuez une conversion d’un autre système compatible MySQL 8.0 vers Aurora MySQL version 3. En général, Aurora MySQL version 3 prend en charge l’ensemble de fonctions de MySQL 8.0.23 version communautaire. Certaines nouvelles fonctions de l’édition communautaire MySQL 8.0 ne s’appliquent pas à Aurora MySQL. Certaines de ces fonctions ne sont pas compatibles avec certains aspects d’Aurora, tels que l’architecture de stockage Aurora. Les autres fonctions ne sont pas nécessaires car le service de gestion Amazon RDS offre des fonctions équivalentes. Les fonctions suivantes de MySQL 8.0 version communautaire ne sont pas prises en charge ou fonctionnent différemment dans Aurora MySQL version 3. Pour les notes de mise à jour de toutes les versions d’Aurora MySQL version 3, consultez [Mises à jour du moteur de base de données pour Amazon Aurora MySQL version 3](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraMySQLReleaseNotes/AuroraMySQL.Updates.30Updates.html) dans *Notes de mise à jour d’Aurora MySQL*. **Topics** + [Les fonctions MySQL 8.0 ne sont pas disponibles dans Aurora MySQL version 3](#AuroraMySQL.Compare-80-v3-features) + [Modèle de privilège basé sur les rôles](#AuroraMySQL.privilege-model) + [Localisation de l’ID du serveur de base de données](#AuroraMySQL.server-id) + [Authentification](#AuroraMySQL.mysql80-authentication) ## Les fonctions MySQL 8.0 ne sont pas disponibles dans Aurora MySQL version 3 Les fonctions suivantes de MySQL 8.0 version communautaire ne sont pas disponibles ou fonctionnent différemment dans Aurora MySQL version 3. + Les groupes de ressources et les instructions SQL associées ne sont pas pris en charge dans Aurora MySQL. + Aurora MySQL ne prend pas en charge les espaces de table d’annulation définis par l’utilisateur ni les instructions SQL associées, telles que `CREATE UNDO TABLESPACE`, `ALTER UNDO TABLESPACE ... SET INACTIVE` et `DROP UNDO TABLESPACE`. + Aurora MySQL ne prend pas en charge la troncature des espaces de table d’annulation pour les versions d’Aurora MySQL inférieures à 3.06. Dans Aurora MySQL 3.06 et versions ultérieures, la [troncature automatique des espaces de tables d’annulation](https://dev.mysql.com/doc/refman/8.0/en/innodb-undo-tablespaces.html#truncate-undo-tablespace) est prise en charge. + Le plug-in de validation de mot de passe est pris en charge. + Vous ne pouvez pas modifier les paramètres des plug-ins MySQL, y compris les plugins de validation de mot de passe. + Le plugin X n’est pas pris en charge. + La réplication multisource n’est pas prise en charge. ## Modèle de privilège basé sur les rôles Avec Aurora MySQL version 3, vous ne pouvez pas modifier les tables dans la base de données `mysql` directement. En particulier, vous ne pouvez pas configurer d’utilisateurs en les insérant dans la table `mysql.user`. Au lieu de cela, vous utilisez des instructions SQL pour accorder des privilèges basés sur des rôles. Vous ne pouvez pas non plus créer d’autres types d’objets tels que des procédures stockées dans la base de données `mysql`. Vous pouvez toujours interroger les tables `mysql`. Si vous utilisez la réplication des journaux binaires, les modifications apportées directement aux tables `mysql` du cluster source ne sont pas répliquées sur le cluster cible. Dans certains cas, votre application peut utiliser des raccourcis pour créer des utilisateurs ou d’autres objets en les insérant dans les tables `mysql`. Le cas échéant, modifiez le code de votre application pour utiliser les instructions correspondantes telles que `CREATE USER`. Si votre application crée des procédures stockées ou d’autres objets dans la base de données, utilisez plutôt une autre base de données `mysql`. Pour exporter des métadonnées pour les utilisateurs de bases de données pendant la migration à partir d’une base de données MySQL externe, vous pouvez utiliser une commande MySQL Shell à la place de `mysqldump`. Pour plus d’informations, consultez [Utilitaire de vidage d’instance, Utilitaire de vidage de schéma et Utilitaire de vidage de table](https://dev.mysql.com/doc/mysql-shell/8.0/en/mysql-shell-utilities-dump-instance-schema.html#mysql-shell-utilities-dump-about). Pour simplifier la gestion des autorisations pour de nombreux utilisateurs ou applications, vous pouvez utiliser l’instruction `CREATE ROLE` pour créer un rôle doté d’un ensemble d’autorisations. Vous pouvez ensuite utiliser les instructions `GRANT` et `SET ROLE`, et la fonction `current_role` pour attribuer des rôles à des utilisateurs ou des applications, changer le rôle actuel et vérifier les rôles en vigueur. Pour plus d’informations sur le système d’autorisations basé sur les rôles dans MySQL 8.0, consultez [Utilisation de rôles](https://dev.mysql.com/doc/refman/8.0/en/roles.html) dans le manuel de référence MySQL. **Important** Nous vous recommandons vivement de ne pas avoir recours au rôle d’utilisateur principal directement dans vos applications. Au lieu de cela, respectez la bonne pratique qui consiste à avoir recours à un utilisateur de base de données doté des privilèges minimum requis pour votre application. **Topics** + [rds\$1superuser\$1role](#AuroraMySQL.privilege-model.rds_superuser_role) + [Utilisateur de vérification des privilèges pour la réplication des journaux binaires](#AuroraMySQL.privilege-model.binlog) + [Rôles pour accéder à d'autres AWS services](#AuroraMySQL.privilege-model.other) ### rds\$1superuser\$1role Aurora MySQL version 3 inclut un rôle spécial doté de tous les privilèges suivants. Ce rôle est nommé `rds_superuser_role`. Ce rôle est déjà accordé à l’utilisateur administratif principal de chaque cluster. Le rôle `rds_superuser_role` inclut les privilèges suivants pour tous les objets de base de données : + `ALTER` + `APPLICATION_PASSWORD_ADMIN` + `ALTER ROUTINE` + `CONNECTION_ADMIN` + `CREATE` + `CREATE ROLE` + `CREATE ROUTINE` + `CREATE TEMPORARY TABLES` + `CREATE USER` + `CREATE VIEW` + `DELETE` + `DROP` + `DROP ROLE` + `EVENT` + `EXECUTE` + `FLUSH_OPTIMIZER_COSTS` (Aurora MySQL versions 3.09 et ultérieures) + `FLUSH_STATUS` (Aurora MySQL versions 3.09 et ultérieures) + `FLUSH_TABLES` (Aurora MySQL versions 3.09 et ultérieures) + `FLUSH_USER_RESOURCES` (Aurora MySQL versions 3.09 et ultérieures) + `INDEX` + `INSERT` + `LOCK TABLES` + `PROCESS` + `REFERENCES` + `RELOAD` + `REPLICATION CLIENT` + `REPLICATION SLAVE` + `ROLE_ADMIN` + `SET_USER_ID` + `SELECT` + `SHOW DATABASES` + `SHOW_ROUTINE` (Aurora MySQL versions 3.04 et ultérieures) + `SHOW VIEW` + `TRIGGER` + `UPDATE` + `XA_RECOVER_ADMIN` La définition du rôle inclut également `WITH GRANT OPTION` afin qu’un utilisateur administratif puisse accorder ce rôle à d’autres utilisateurs. En particulier, l’administrateur doit accorder tous les privilèges nécessaires à la réplication des journaux binaires avec le cluster Aurora MySQL comme cible. **Astuce** Pour voir tous les détails des autorisations, saisissez les instructions suivantes. ``` SHOW GRANTS FOR rds_superuser_role@'%'; SHOW GRANTS FOR name_of_administrative_user_for_your_cluster@'%'; ``` ### Utilisateur de vérification des privilèges pour la réplication des journaux binaires Aurora MySQL version 3 inclut un utilisateur de vérification des privilèges pour la réplication des journaux binaires (binlog), `rdsrepladmin_priv_checks_user`. Outre les privilèges de ce `rds_superuser_role`, cet utilisateur possède le privilège `replication_applier`. Lorsque vous activez la réplication des journaux binaires en appelant la procédure `mysql.rds_start_replication` stockée, la réplication `rdsrepladmin_priv_checks_user` est créée. L’utilisateur `rdsrepladmin_priv_checks_user@localhost` est un utilisateur réservé. Ne le modifiez pas. ### Rôles pour accéder à d'autres AWS services Aurora MySQL version 3 inclut des rôles que vous pouvez utiliser pour accéder à d'autres AWS services. Vous pouvez définir un grand nombre de ces rôles comme alternative à l’octroi de privilèges. Par exemple, vous définissez `GRANT AWS_LAMBDA_ACCESS TO user` plutôt que `GRANT INVOKE LAMBDA ON *.* TO user`. Pour les procédures d'accès à d'autres AWS services, voir[Intégration d'Amazon Aurora MySQL à d'autres AWS services](AuroraMySQL.Integrating.md). Aurora MySQL version 3 inclut les rôles suivants liés à l'accès à d'autres AWS services : + `AWS_LAMBDA_ACCESS` : alternative au privilège `INVOKE LAMBDA`. Pour plus d’informations, consultez [Appel d’une fonction Lambda à partir d’un cluster de bases de données Amazon Aurora MySQL](AuroraMySQL.Integrating.Lambda.md). + `AWS_LOAD_S3_ACCESS` : alternative au privilège `LOAD FROM S3`. Pour plus d’informations, consultez [Chargement de données dans un cluster de bases de données Amazon Aurora MySQL à partir de fichiers texte stockés dans un compartiment Amazon S3](AuroraMySQL.Integrating.LoadFromS3.md). + `AWS_SELECT_S3_ACCESS` : alternative au privilège `SELECT INTO S3`. Pour plus d’informations, consultez [Enregistrement de données d’un cluster de bases de données Amazon Aurora MySQL dans des fichiers texte stockés dans un compartiment Amazon S3](AuroraMySQL.Integrating.SaveIntoS3.md). + `AWS_COMPREHEND_ACCESS` : alternative au privilège `INVOKE COMPREHEND`. Pour plus d’informations, consultez [Autorisation d’accès aux utilisateurs de base de données pour le machine learning Aurora](mysql-ml.md#aurora-ml-sql-privileges). + `AWS_SAGEMAKER_ACCESS` : alternative au privilège `INVOKE SAGEMAKER`. Pour plus d’informations, consultez [Autorisation d’accès aux utilisateurs de base de données pour le machine learning Aurora](mysql-ml.md#aurora-ml-sql-privileges). + `AWS_BEDROCK_ACCESS` : il n’existe aucun privilège `INVOKE` analogue pour Amazon Bedrock. Pour plus d’informations, consultez [Autorisation d’accès aux utilisateurs de base de données pour le machine learning Aurora](mysql-ml.md#aurora-ml-sql-privileges). Lorsque vous accordez l’accès à l’aide de rôles dans Aurora MySQL version 3, vous activez également le rôle à l’aide de l’instruction `SET ROLE role_name` ou `SET ROLE ALL`. L’exemple suivant montre comment procéder. Remplacez le nom de rôle approprié par `AWS_SELECT_S3_ACCESS`. ``` # Grant role to user. mysql> GRANT AWS_SELECT_S3_ACCESS TO 'user'@'domain-or-ip-address' # Check the current roles for your user. In this case, the AWS_SELECT_S3_ACCESS role has not been activated. # Only the rds_superuser_role is currently in effect. mysql> SELECT CURRENT_ROLE(); +--------------------------+ | CURRENT_ROLE() | +--------------------------+ | `rds_superuser_role`@`%` | +--------------------------+ 1 row in set (0.00 sec) # Activate all roles associated with this user using SET ROLE. # You can activate specific roles or all roles. # In this case, the user only has 2 roles, so we specify ALL. mysql> SET ROLE ALL; Query OK, 0 rows affected (0.00 sec) # Verify role is now active mysql> SELECT CURRENT_ROLE(); +-----------------------------------------------------+ | CURRENT_ROLE() | +-----------------------------------------------------+ | `AWS_SELECT_S3_ACCESS`@`%`,`rds_superuser_role`@`%` | +-----------------------------------------------------+ ``` ## Localisation de l’ID du serveur de base de données L’ID du serveur de base de données (`server_id`) est requis pour la réplication des journaux binaires (binlog). La méthode permettant de trouver l’ID du serveur est différente dans Aurora MySQL et Community MySQL. Dans Community MySQL, l’ID du serveur est un nombre, que vous pouvez obtenir en utilisant la syntaxe suivante lorsque vous êtes connecté au serveur : ``` mysql> select @@server_id; +-------------+ | @@server_id | +-------------+ | 2 | +-------------+ 1 row in set (0.00 sec) ``` Dans Aurora MySQL, l’ID du serveur est l’ID de l’instance de base de données, que vous obtenez en utilisant la syntaxe suivante lorsque vous êtes connecté à l’instance de base de données : ``` mysql> select @@aurora_server_id; +------------------------+ | @@aurora_server_id | +------------------------+ | mydbcluster-instance-2 | +------------------------+ 1 row in set (0.00 sec) ``` Pour plus d’informations sur la réplication des journaux binaires, consultez [Réplication entre Aurora et MySQL ou entre Aurora et un autre cluster de bases de données Aurora (réplication de journaux binaires)](AuroraMySQL.Replication.MySQL.md). ## Authentification Dans MySQL 8.0 version communautaire, le plugin d’authentification par défaut est `caching_sha2_password`. Aurora MySQL version 3 utilise toujours le plugin `mysql_native_password`. Vous ne pouvez pas modifier le paramètre `default_authentication_plugin`. Vous pouvez toutefois créer des utilisateurs et modifier les utilisateurs actuels pour que leur mot de passe individuel utilise le nouveau plugin d’authentification. Voici un exemple. ``` mysql> CREATE USER 'testnewsha'@'%' IDENTIFIED WITH caching_sha2_password BY 'aNewShaPassword'; Query OK, 0 rows affected (0.74 sec) ``` # Mise à niveau vers Aurora MySQL version 3 Pour en savoir plus sur la mise à niveau de votre base de données Aurora MySQL version 2 vers la version 3, consultez [Mise à niveau de la version majeure d’un cluster de bases de données Amazon Aurora MySQL](AuroraMySQL.Updates.MajorVersionUpgrade.md).