View a markdown version of this page

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

Comparación de Aurora MySQL versión 8.4 y MySQL 8.4 Community Edition

En este tema, se describen las diferencias entre la versión 8.4 de Aurora MySQL y MySQL 8.4 Community Edition.

Autenticación

La versión 8.4 de Aurora MySQL solo admite los siguientes valores para el parámetro authentication_policy:

  • *:caching_sha2_password (valor predeterminado: permite utilizar cualquier complemento de autenticación de un solo factor mediante el uso de caching_sha2_password si no se especifica ningún otro valor).

  • *:mysql_native_password (permite cualquier complemento de autenticación de un solo factor mediante el uso de mysql_native_password si no se especifica ningún otro valor).

nota

Aurora MySQL no admite configuraciones de autenticación multifactor.

Usuarios reservados

Aurora MySQL reserva determinados nombres de usuario para características internas. Estos nombres de usuario no se pueden usar para las cuentas de usuarios de la base de datos. Para obtener más información, consulte Usuarios reservados en Aurora MySQL.

A partir de la versión 8.4.7 de Aurora MySQL, el motor protege rdsproxyadmin, ya que es el usuario que supervisa el RDS Proxy. Aurora crea la cuenta de rdsproxyadmin automáticamente cuando registra un destino de proxy. Para obtener más información sobre las operaciones rechazadas y los resultados de errores, consulte Usuarios reservados en Aurora MySQL.

rds_superuser_role

La versión 8.4 de Aurora MySQL incluye un rol especial que tiene todos los privilegios que se indican a continuación. El rol se denomina rds_superuser_role. El usuario maestro de cada clúster ya tiene asignado este rol. El rol rds_superuser_role incluye los siguientes privilegios para todos los objetos de base de datos:

  • ALTER

  • ALLOW_NONEXISTENT_DEFINER

  • 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

  • FLUSH_OPTIMIZER_COSTS

  • FLUSH_PRIVILEGES

  • FLUSH_STATUS

  • FLUSH_TABLES

  • FLUSH_USER_RESOURCES

  • INDEX

  • INSERT

  • LOCK TABLES

  • OPTIMIZE_LOCAL_TABLE

  • PROCESS

  • REFERENCES

  • RELOAD

  • REPLICATION CLIENT

  • REPLICATION SLAVE

  • ROLE_ADMIN

  • SELECT

  • SET_ANY_DEFINER

  • SHOW DATABASES

  • SHOW_ROUTINE

  • SHOW VIEW

  • TRIGGER

  • UPDATE

  • XA_RECOVER_ADMIN

Compatibilidad con el componente de validación de contraseñas en la versión 8.4 de Aurora MySQL

  • Se admite el componente validate_password, incluidas sus personalizaciones. El componente se administra mediante el parámetro de la base de datos aurora_enable_validate_password_component en lugar de utilizar los comandos INSTALL COMPONENT y UNINSTALL COMPONENT.

  • El complemento validate_password es parcialmente compatible para permitir la migración al componente.

Para obtener más información, consulte Políticas de contraseñas y validación de contraseñas en Aurora MySQL.

Cambios predeterminados en los parámetros

temptable_max_mmap

En MySQL 8.4 Community Edition, el valor predeterminado de temptable_max_mmap es 0, que deshabilita las tablas temporales asignadas a la memoria.

La versión 8.4.7 y versiones posteriores de Aurora MySQL anulan este valor predeterminado. Aurora establece temptable_max_mmap en un valor calculado a partir del almacenamiento asignado al clúster mediante la siguiente fórmula:

LEAST(4294967296, {AllocatedStorage*3/100})

Esto establece el valor predeterminado en el 3 % del almacenamiento asignado, con un límite máximo de 4 GiB. Las tablas temporales asignadas a la memoria permanecen habilitadas de forma predeterminada en la versión 8.4.7 y versiones posteriores de Aurora MySQL, a diferencia de lo que ocurre con MySQL 8.4. Community Edition.

Para obtener más información sobre la entrada de referencia de parámetros, consulte Parámetros de configuración de Aurora MySQL.