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. # 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) + [Role-based modèle de privilège](#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. ## Role-based modèle de privilège 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\_superuser\_role](#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\_superuser\_role 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) ```