View a markdown version of this page

Comparar o Aurora MySQL versão 8.4 e o MySQL 8.4 Community Edition - Amazon Aurora
AutenticaçãoUsuários reservadosrds_superuser_roleCompatibilidade com o componente de validação de senha no Aurora MySQL versão 8.4Alterações padrão nos parâmetros

Comparar o Aurora MySQL versão 8.4 e o MySQL 8.4 Community Edition

Este tópico descreve as diferenças entre o Aurora MySQL versão 8.4 e o MySQL 8.4 Community Edition.

Autenticação

O Aurora MySQL versão 8.4 permite somente os seguintes valores para o parâmetro authentication_policy:

  • *:caching_sha2_password (valor padrão; permite qualquer plug-in de autenticação de fator único, usando caching_sha2_password, se nenhum for especificado).

  • *:mysql_native_password (permite qualquer plug-in de autenticação de fator único, usando mysql_native_password, se nenhum for especificado).

nota

Não é possível usar configurações de autenticação multifator no Aurora MySQL.

Usuários reservados

O Aurora MySQL reserva determinados nomes de usuário para recursos internos. Esses nomes de usuário não podem ser usados nas contas de usuário do banco de dados. Para obter mais informações, consulte Usuários reservados no Aurora MySQL.

A partir do Aurora MySQL versão 8.4.7, o mecanismo protege rdsproxyadmin porque este é o usuário de monitoramento do RDS Proxy. O Aurora cria a conta rdsproxyadmin automaticamente quando um proxy de destino é registrado. Para ver detalhes sobre as operações rejeitadas e saídas de erro, consulte Usuários reservados no Aurora MySQL.

rds_superuser_role

O Aurora MySQL versão 8.4 inclui um perfil especial que tem todos os privilégios a seguir. Essa função se chama rds_superuser_role. O usuário principal de cada cluster já tem esse perfil concedido por padrão. A função rds_superuser_role inclui os seguintes privilégios para todos os objetos de banco de dados:

  • 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

Compatibilidade com o componente de validação de senha no Aurora MySQL versão 8.4

  • É possível usar o componente validate_password, bem como as respectivas personalizações. O componente é gerenciado por meio do parâmetro de banco de dados aurora_enable_validate_password_component, em vez dos comandos INSTALL COMPONENT e UNINSTALL COMPONENT.

  • O plug-in validate_password é parcialmente compatível para permitir a migração para o componente.

Para obter mais informações, consulte Políticas de senha e validação de senha no Aurora MySQL.

Alterações padrão nos parâmetros

temptable_max_mmap

No MySQL 8.4 Community Edition, o valor padrão de temptable_max_mmap é 0, que desabilita as tabelas temporárias mapeadas na memória.

O Aurora MySQL versão 8.4.7 e posterior substitui esse padrão. O Aurora define temptable_max_mmap com um valor calculado com base no armazenamento alocado do cluster, usando a seguinte fórmula:

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

Isso define o padrão como 3% do armazenamento alocado, com um limite máximo de 4 GiB. As tabelas temporárias mapeadas na memória permanecem habilitadas por padrão no Aurora MySQL versão 8.4.7 e posterior, diferentemente do MySQL 8.4 da comunidade.

Com relação à entrada de referência do parâmetro, consulte Parâmetros de configuração do Aurora MySQL.