Comparaison entre Aurora My SQL version 3 et My SQL 8.0 Community Edition

Vous pouvez utiliser les informations suivantes pour en savoir plus sur les modifications à prendre en compte lors de la conversion d'un autre système SQL compatible avec My 8.0 vers Aurora My SQL version 3.

En général, la SQL version 3 d'Aurora My prend en charge l'ensemble des fonctionnalités de la communauté My SQL 8.0.23. Certaines nouvelles fonctionnalités de l'édition communautaire My SQL 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 fonctionnalités ne sont pas nécessaires car le service RDS de gestion Amazon fournit des fonctionnalités équivalentes. Les fonctionnalités suivantes de Community My SQL 8.0 ne sont pas prises en charge ou fonctionnent différemment dans Aurora My SQL version 3.

Pour les notes de publication relatives à toutes les versions d'Aurora My SQL version 3, consultez la section Mises à jour du moteur de base de données pour Amazon Aurora My SQL version 3 dans les notes de publication d'Aurora My SQL.

Les fonctionnalités de My SQL 8.0 ne sont pas disponibles dans la SQL version 3 d'Aurora My

Les fonctionnalités suivantes de community My SQL 8.0 ne sont pas disponibles ou fonctionnent différemment dans Aurora My SQL version 3.

Modèle de privilège basé sur les rôles

Avec Aurora My SQL version 3, vous ne pouvez pas modifier directement les tables de la mysql base de données. En particulier, vous ne pouvez pas configurer d'utilisateurs en les insérant dans la table mysql.user. Vous utilisez plutôt des SQL instructions pour octroyer des privilèges basés sur les 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 SQL base de données My Database externe, vous pouvez utiliser une commande My SQL 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'autorisation basé sur les rôles dans My SQL 8.0, consultez la section Utilisation des rôles dans le manuel My SQL Reference.

role de superutilisateur rds_

Aurora My SQL 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 pour effectuer la réplication des journaux binaires avec le SQL cluster Aurora My 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 My SQL 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 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 My SQL 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 My SQL 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 My SQL version 3, vous activez également le rôle à l'aide de l'SET ROLE ALLinstruction SET ROLE role_name or. 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 My SQL et Community MySQL.

Dans Community MySQL, l'ID du serveur est un numéro 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 community My SQL 8.0, le plugin d'authentification par défaut estcaching_sha2_password. Aurora My SQL version 3 utilise toujours le mysql_native_password plugin. Vous ne pouvez pas modifier le paramètre default_authentication_plugin.