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.
Temas
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 decaching_sha2_passwordsi no se especifica ningún otro valor). -
*:mysql_native_password(permite cualquier complemento de autenticación de un solo factor mediante el uso demysql_native_passwordsi 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:
ALTERALLOW_NONEXISTENT_DEFINERAPPLICATION_PASSWORD_ADMINALTER ROUTINECONNECTION_ADMINCREATECREATE ROLECREATE ROUTINECREATE TEMPORARY TABLESCREATE USERCREATE VIEWDELETEDROPDROP ROLEEVENTEXECUTEFLUSH_OPTIMIZER_COSTSFLUSH_PRIVILEGESFLUSH_STATUSFLUSH_TABLESFLUSH_USER_RESOURCESINDEXINSERTLOCK TABLESOPTIMIZE_LOCAL_TABLEPROCESSREFERENCESRELOADREPLICATION CLIENTREPLICATION SLAVEROLE_ADMINSELECTSET_ANY_DEFINERSHOW DATABASESSHOW_ROUTINESHOW VIEWTRIGGERUPDATEXA_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 datosaurora_enable_validate_password_componenten lugar de utilizar los comandosINSTALL COMPONENTyUNINSTALL COMPONENT. -
El complemento
validate_passwordes 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.