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.
Temas
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
yDROP 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
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.
Temas
rds_superuser_role
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
@'%';
Usuario de comprobaciones de privilegios para replicación de registros binarios
La versión 3 de Aurora MySQL incluye un usuario de comprobaciones de privilegios para la replicación de registros binarios (binlog), rdsrepladmin_priv_checks_user
. Además de los privilegios de rds_superuser_role
, este usuario tiene el privilegio replication_applier
.
Cuando se activa la replicación de binlog mediante una llamada al procedimiento almacenado mysql.rds_start_replication
, se crea rdsrepladmin_priv_checks_user
.
El usuario rdsrepladmin_priv_checks_user@localhost
es un usuario reservado. No lo modifique.
Roles para acceder a otros servicios de AWS
Aurora MySQL versión 3 también incluye roles que puede utilizar para acceder a otros servicios de AWS. Puede establecer muchos de estos roles como alternativa a la concesión de privilegios. Por ejemplo, especifica GRANT AWS_LAMBDA_ACCESS TO
en lugar de user
GRANT
INVOKE LAMBDA ON *.* TO
. 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:AWSuser
-
AWS_LAMBDA_ACCESS
: una alternativa al privilegioINVOKE LAMBDA
. Para obtener más información, consulte Invocación de una función de Lambda desde un clúster de base de datos de Amazon Aurora MySQL. -
AWS_LOAD_S3_ACCESS
: una alternativa al privilegioLOAD FROM S3
. Para obtener más información, consulte Carga de datos en un clúster de base de datos Amazon Aurora MySQL desde archivos de texto en un bucket de Amazon S3. -
AWS_SELECT_S3_ACCESS
: una alternativa al privilegioSELECT INTO S3
. Para obtener más información, consulte Grabación de datos desde un clúster de base de datos Amazon Aurora MySQL en archivos de texto de un bucket de Amazon S3. -
AWS_COMPREHEND_ACCESS
: una alternativa al privilegioINVOKE COMPREHEND
. Para obtener más información, consulte Concesión de acceso a los usuarios de bases de datos a machine learning de Aurora. -
AWS_SAGEMAKER_ACCESS
: una alternativa al privilegioINVOKE SAGEMAKER
. Para obtener más información, consulte Concesión de acceso a los usuarios de bases de datos a machine learning de Aurora. -
AWS_BEDROCK_ACCESS
: no hay un privilegio análogo aINVOKE
para Amazon Bedrock. Para obtener más información, consulte Concesión de acceso a los usuarios de bases de datos a machine learning de Aurora.
Cuando concede acceso mediante roles en Aurora MySQL versión 3, también activa el rol mediante la instrucción SET ROLE
o role_name
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 activemysql>
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
.