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 dans Notes de mise à jour d’Aurora MySQL.

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.

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.

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 dans le manuel de référence MySQL.

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 :

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.

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, voirIntégration d’Amazon Aurora MySQL avec d’autres services AWS. Aurora MySQL version 3 inclut les rôles suivants liés à l'accès à d'autres AWS services :

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

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)