Comparación de Aurora MySQL versión 3 y MySQL 8.0 Community Edition - Amazon Aurora

Comparación de Aurora MySQL versión 3 y MySQL 8.0 Community Edition

Puede utilizar la siguiente información para obtener información sobre los cambios que debe tener en cuenta al convertir de otro sistema compatible con MySQL 8.0 a Aurora MySQL versión 3.

En general, Aurora MySQL versión 3 admite el conjunto de características de la comunidad MySQL 8.0.23. Algunas características nuevas de la edición de la comunidad MySQL 8.0 no se aplican a Aurora MySQL. Algunas de esas funciones no son compatibles con algún aspecto de Aurora, como la arquitectura de almacenamiento Aurora. No se necesitan otras funciones porque el servicio de administración de Amazon RDS proporciona una funcionalidad equivalente. Las siguientes características de la comunidad MySQL 8.0 no son compatibles o funcionan de forma diferente en Aurora MySQL versión 3.

Para ver las notas de todas las versiones de Aurora MySQL versión 3, consulte el tema sobre actualizaciones del motor de base de datos de Amazon Aurora MySQL versión 3 en las notas de la versión de Aurora MySQL.

Las funciones de MySQL 8.0 no están disponibles en Aurora MySQL versión 3

Las siguientes características de la comunidad MySQL 8.0 no son compatibles o funcionan de forma diferente en Aurora MySQL versión 3.

  • Los grupos de recursos y las instrucciones SQL asociadas no son compatibles con Aurora MySQL.

  • Aurora MySQL no admite los espacios de tabla de deshacer definidos por el usuario ni las instrucciones SQL asociadas, como CREATE UNDO TABLESPACE, ALTER UNDO TABLESPACE ... SET INACTIVE y DROP UNDO TABLESPACE.

  • Aurora MySQL no admite deshacer el truncado de espacios de tablas de deshacer en las versiones de Aurora MySQL anteriores a la 3.06. En la versión 3.06 y posteriores de Aurora MySQL, se admite el truncado automático de espacios de tablas de deshacer.

  • No puede modificar la configuración de ningún complemento de MySQL.

  • El complemento X no es compatible.

  • No se admite la replicación automática.

Modelo de privilegios basado en roles

Con Aurora MySQL versión 3, no se pueden modificar las tablas de base de datos de mysql directamente. En particular, no se pueden configurar usuarios insertándolos en la tabla de mysql.user. En su lugar, se utilizan sentencias SQL para otorgar privilegios basados en roles. Tampoco puede crear otros tipos de objetos, como procedimientos almacenados en la base de datos mysql. Aún puede consultar las tablas de mysql. Si utiliza la replicación de registros binarios, los cambios realizados directamente en la tabla de mysql del clúster de origen no se replican en el clúster destino.

En algunos casos, la aplicación puede utilizar accesos directos para crear usuarios u otros objetos insertándolos en las tablas de mysql. Si es así, cambie el código de la aplicación para utilizar las declaraciones correspondientes, como CREATE USER. Si la aplicación crea procedimientos almacenados u otros objetos en la base de datos mysql, utilice otra base de datos en su lugar.

Para exportar metadatos para usuarios de bases de datos durante la migración desde una base de datos MySQL externa, puede utilizar el comando del intérprete de comandos de MySQL en lugar de mysqldump. Para obtener más información, consulte Instance Dump Utility, Schema Dump Utility, and Table Dump Utility.

Para simplificar la administración de permisos para muchos usuarios o aplicaciones, puede utilizar la instrucción CREATE ROLE para crear un rol que tenga un conjunto de permisos. A continuación, puede utilizar las instrucciones GRANT y SET ROLE y la función current_role para asignar roles a usuarios o aplicaciones, cambiar el rol actual y verificar qué roles están en vigor. Para obtener más información sobre el sistema de permisos basado en roles de MySQL 8.0, consulte Uso de roles en el Manual de referencia de MySQL.

importante

Le recomendamos encarecidamente que no utilice el usuario maestro directamente en sus aplicaciones. En lugar de ello, es mejor ceñirse a la práctica recomendada de utilizar un usuario de base de datos creado con los privilegios mínimos necesarios para su aplicación.

Aurora MySQL versión 3 incluye un rol especial que tiene todos los siguientes privilegios. El rol se denomina rds_superuser_role. El usuario administrativo principal de cada clúster ya tiene asignada este rol. El rol rds_superuser_role incluye los siguientes privilegios para todos los objetos de base de datos:

  • 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

  • INDEX

  • INSERT

  • LOCK TABLES

  • PROCESS

  • REFERENCES

  • RELOAD

  • REPLICATION CLIENT

  • REPLICATION SLAVE

  • ROLE_ADMIN

  • SET_USER_ID

  • SELECT

  • SHOW DATABASES

  • SHOW_ROUTINE (versión 3.04 y posteriores de Aurora MySQL)

  • SHOW VIEW

  • TRIGGER

  • UPDATE

  • XA_RECOVER_ADMIN

La definición de rol también incluye WITH GRANT OPTION para que un usuario administrativo pueda conceder ese rol a otros usuarios. En particular, el administrador debe conceder los privilegios necesarios para realizar la replicación de registros binarios con el clúster Aurora MySQL como destino.

sugerencia

Para ver todos los detalles de los permisos, ingrese las siguientes instrucciones.

SHOW GRANTS FOR rds_superuser_role@'%'; SHOW GRANTS FOR name_of_administrative_user_for_your_cluster@'%';

Aurora MySQL versión 3 también incluye roles que puede utilizar para acceder a otros servicios de AWS. Puede establecer estos roles como alternativa a las instrucciones GRANT. Por ejemplo, especifica GRANT AWS_LAMBDA_ACCESS TO user en lugar de GRANT INVOKE LAMBDA ON *.* TO user. Para ver los procedimientos de acceso a otros servicios de AWS, consulte Integración de Amazon Aurora MySQL con otros servicios de AWS. Aurora MySQL versión 3 incluye los siguientes roles relacionados con el acceso a otros servicios de AWS:

Cuando concede acceso mediante roles en Aurora MySQL versión 3, también activa el rol mediante la instrucción SET ROLE role_name o SET ROLE ALL. El siguiente ejemplo muestra cómo. Sustituya el nombre de rol apropiado por 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`@`%` | +-----------------------------------------------------+

Autenticación

En la comunidad MySQL 8.0, el complemento de autenticación predeterminado es caching_sha2_password. Aurora MySQL versión 3 sigue utilizando el complemento mysql_native_password. No se puede cambiar la configuración de default_authentication_plugin.