Comparaison entre Aurora MySQL version 3 et 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 de Aurora MySQL version 3, consultez Database engine updates for Amazon Aurora MySQL version 3 (Mises à jour du moteur de base de données pour Amazon Aurora MySQL version 3) dans Release Notes for Aurora MySQL (Notes de mise à jour de 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 destinées aux utilisateurs de la base de données lors de la migration depuis une base de données MySQL externe, vous pouvez utiliser une commande MySQL Shell au lieu demysqldump. Pour plus d'informations, consultez les rubriques Utilitaire de vidage d'instance, Utilitaire de transfert 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.

role de superutilisateur rds_

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@'%';

Privilege vérifie la réplication des journaux binaires par l'utilisateur

Aurora MySQL version 3 inclut un utilisateur de vérification des privilèges pour la réplication du journal binaire (binlog),rdsrepladmin_priv_checks_user. Outre les privilèges derds_superuser_role, cet utilisateur possède le replication_applier privilège.

Lorsque vous activez le binlog, la réplication rdsrepladmin_priv_checks_user est créée en appelant la procédure mysql.rds_start_replication stockée.

L'rdsrepladmin_priv_checks_user@localhostutilisateur 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 au lieu d'octroyer des 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 My SQL à d'autres AWS services. 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`@`%` |
+-----------------------------------------------------+

Trouver 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 de journalisation binaire (binlog). La méthode pour 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, consultezRéplication entre Aurora et My SQL ou entre Aurora et un autre cluster de base 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 de nouveaux utilisateurs et modifier les utilisateurs actuels, et leurs mots de passe individuels utilisent 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)