Comparar o Aurora MySQL versão 3 e o MySQL 8.0 Community Edition

Use as seguintes informações para saber mais sobre as alterações a serem observadas ao converter de um sistema compatível com MySQL 8.0 diferente para o Aurora MySQL versão 3.

Em geral, o Aurora MySQL versão 3 é compatível com o conjunto de recursos do MySQL 8.0.23 edição da comunidade. Alguns novos recursos do MySQL 8.0 edição da comunidade não se aplicam ao Aurora MySQL. Alguns desses recursos não são compatíveis com alguns aspectos do Aurora, como a arquitetura de armazenamento. Outros recursos não são necessários, pois o serviço de gerenciamento do Amazon RDS fornece funcionalidade equivalente. Os seguintes recursos no MySQL 8.0 edição da comunidade não têm suporte ou funcionam de maneira diferente no Aurora MySQL versão 3.

Para acessar as notas de lançamento de todas as versões do Aurora MySQL versão 3, consulte Atualizações no mecanismo de banco de dados do Amazon Aurora MySQL versão 3 em Notas de lançamento do Aurora MySQL.

Recursos do MySQL 8.0 que não estão disponíveis no Aurora MySQL versão 3

Os seguintes recursos no MySQL 8.0 edição da comunidade não estão disponíveis ou funcionam de maneira diferente no Aurora MySQL versão 3.

• Os grupos de recursos e as instruções SQL associadas não têm suporte no Aurora MySQL.

• O Aurora MySQL não é compatível com espaços de tabela undo definidos pelo usuário e instruções SQL associadas, como CREATE UNDO TABLESPACE, ALTER UNDO TABLESPACE ... SET INACTIVE e DROP UNDO TABLESPACE.

• O Aurora MySQL não é compatível com o truncamento de espaço de tabela undo para versões do Aurora MySQL anteriores a 3.06. No Aurora MySQL versão 3.06 e posterior, o truncamento automático do espaço de tabela undo é compatível.

• Não é possível modificar as configurações de nenhum dos plugins do MySQL.

• Não há suporte para o plugin X.

• Não há suporte à replicação em várias origens.

Modelo de privilégios baseados em funções

Com o Aurora MySQL versão 3, não é possível modificar as tabelas no banco de dados mysql diretamente. Em particular, não é possível configurar usuários inserindo-os na tabela mysql.user. Em vez disso, use instruções SQL para conceder privilégios baseados em funções. Você também não pode criar outros tipos de objeto, como procedimentos armazenados no banco de dados do mysql. Você ainda pode consultar as tabelas mysql. Se você utilizar a replicação de logs binários, as alterações feitas diretamente nas tabelas mysql no cluster de origem não serão replicadas no cluster de destino.

Em alguns casos, sua aplicação pode utilizar atalhos para criar usuários ou outros objetos inserindo-os nas tabelas mysql. Em caso afirmativo, altere o código da aplicação para utilizar as instruções correspondentes, como CREATE USER. Se a aplicação criar procedimentos armazenados ou outros objetos no banco de dados do mysql, use um banco de dados diferente.

Para exportar metadados para usuários de banco de dados durante a migração de um banco de dados externo do MySQL, é possível usar um comando do MySQL Shell em vez de mysqldump. Consulte mais informações em Instance Dump Utility, Schema Dump Utility, and Table Dump Utility.

Para simplificar o gerenciamento de permissões para vários usuários ou aplicações, é possível utilizar a instrução CREATE ROLE para criar uma função que tenha um conjunto de permissões. Em seguida, você pode utilizar as instruções GRANT e SET ROLE e a função current_role para atribuir funções a usuários ou aplicações, alternar a função atual e verificar quais funções estão em vigor. Para obter mais informações sobre o sistema de permissões baseadas em funções no MySQL 8.0, consulte o tópico sobre como Usar funções, no Guia de referência do MySQL.

Importante

É altamente recomendável não usar o usuário mestre diretamente nas aplicações. Em vez disso, siga as práticas recomendadas de usar um usuário do banco de dados criado com os privilégios mínimos obrigatórios para a aplicação.

Tópicos

• rds_superuser_role
• Usuário de verificação de privilégios para replicação de logs binários.
• Perfis para acessar outros serviços da AWS

rds_superuser_role

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

• 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 (Aurora MySQL versão 3.04 e posterior)

• SHOW VIEW

• TRIGGER

• UPDATE

• XA_RECOVER_ADMIN

A definição da função também inclui WITH GRANT OPTION, permitindo que um usuário administrativo a conceda para outros usuários. Em particular, o administrador deve conceder quaisquer privilégios necessários para executar a replicação de logs binários com o cluster do Aurora MySQL como destino.

dica

Para visualizar os detalhes completos das permissões, insira as seguintes instruções.

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

Usuário de verificação de privilégios para replicação de logs binários.

O Aurora MySQL versão 3 inclui um usuário de verificação de privilégios para replicação de logs binários (binlog), rdsrepladmin_priv_checks_user. Além dos privilégios de rds_superuser_role, esse usuário tem o privilégio replication_applier.

Quando você ativa a replicação do log binário chamando o procedimento armazenado mysql.rds_start_replication, rdsrepladmin_priv_checks_user é criado.

O usuário rdsrepladmin_priv_checks_user@localhost é reservado. Não o modifique.

Perfis para acessar outros serviços da AWS

O Aurora MySQL versão 3 inclui perfis que podem ser usados para acessar outros serviços da AWS. É possível definir muitos desses perfis como uma alternativa à concessão de privilégios. Por exemplo, especifique GRANT AWS_LAMBDA_ACCESS TO user no lugar de GRANT INVOKE LAMBDA ON *.* TO user. Para conhecer os procedimentos para acessar outros serviços da AWS, consulte Integração do Amazon Aurora MySQL com outros produtos da AWS. O Aurora MySQL versão 3 inclui as seguintes funções relacionadas ao acesso a outros serviços da AWS:

• AWS_LAMBDA_ACCESS: alternativa ao privilégio INVOKE LAMBDA. Para ter mais informações, consulte Invocar uma função do Lambda a partir de um cluster de banco de dados do Amazon Aurora MySQL.

• AWS_LOAD_S3_ACCESS: alternativa ao privilégio LOAD FROM S3. Para ter mais informações, consulte Carregar dados em um cluster de banco de dados do Amazon Aurora MySQL a partir de arquivos de texto em um bucket do Amazon S3.

• AWS_SELECT_S3_ACCESS: alternativa ao privilégio SELECT INTO S3. Para ter mais informações, consulte Salvar dados a partir de um cluster de banco de dados do Amazon Aurora MySQL em arquivos de texto de um bucket do Amazon S3.

• AWS_COMPREHEND_ACCESS: alternativa ao privilégio INVOKE COMPREHEND. Para ter mais informações, consulte Conceder aos usuários de banco de dados acesso ao machine learning do Aurora.

• AWS_SAGEMAKER_ACCESS: alternativa ao privilégio INVOKE SAGEMAKER. Para ter mais informações, consulte Conceder aos usuários de banco de dados acesso ao machine learning do Aurora.

• AWS_BEDROCK_ACCESS: não há privilégio INVOKE análogo para o Amazon Bedrock. Para ter mais informações, consulte Conceder aos usuários de banco de dados acesso ao machine learning do Aurora.

Quando você concede acesso utilizando funções no Aurora MySQL versão 3, também ativa a função utilizando a instrução SET ROLE role_name ou SET ROLE ALL. O exemplo a seguir mostra como. Substitua o nome da função apropriado para 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`@`%` |
+-----------------------------------------------------+

Autenticação

No MySQL 8.0 edição da comunidade, o plugin de autenticação padrão é caching_sha2_password. O Aurora MySQL versão 3 ainda utiliza o plugin mysql_native_password. Você não pode alterar a configuração default_authentication_plugin.