Comparação do Aurora MySQL versão 2 e do Aurora MySQL versão 3
Use as seguintes informações para saber mais sobre as alterações a serem observadas ao fazer upgrade do cluster do Aurora MySQL versão 2 para a versão 3.
Tópicos
Diferenças de recursos entre as versões 2 e 3 do Aurora MySQL
Os recursos a seguir no Amazon Aurora MySQL têm suporte no Aurora MySQL para o MySQL 5.7, mas não têm suporte atualmente no Aurora MySQL para o MySQL 8.0:
-
Não é possível utilizar o Aurora MySQL versão 3 para clusters do Aurora Serverless v1. O Aurora MySQL versão 3 funciona com o Aurora Serverless v2.
-
O modo de laboratório não é aplicável ao Aurora MySQL versão 3. Não há recursos de modo de laboratório no Aurora MySQL versão 3. A DDL instantâneo substitui o recurso de DDL on-line rápida que estava disponível no modo de laboratório. Para ver um exemplo, consulte DDL instantânea (Aurora MySQL versão 3).
-
O cache de consulta foi removido do MySQL 8.0 edição da comunidade e também do Aurora MySQL versão 3.
-
O Aurora MySQL versão 3 tem compatibilidade com o recurso de junção de hash do MySQL da comunidade. A implementação específica do Aurora de junções de hash no Aurora MySQL versão 2 não é utilizada. Para obter informações sobre como utilizar junções de hash com a consulta paralela do Aurora, consulte Habilitar a junção de hash para clusters de consulta paralela e Dicas do Aurora MySQL. Para obter informações gerais de uso sobre junções de hash, consulte Otimização de junções de hash
, no Guia de referência do MySQL. -
No momento, não é possível restaurar um backup físico da ferramenta Percona XtraBackup para um cluster do Aurora MySQL versão 3. Planejamos oferecer suporte a esse recurso em uma versão secundária posterior.
-
O procedimento armazenado
mysql.lambda_asyncque foi marcado como defasado no Aurora MySQL versão 2 foi removido na versão 3. Para a versão 3, use a função assíncronalambda_asyncno lugar. -
O conjunto de caracteres padrão no Aurora MySQL versão 3 é
utf8mb4. No Aurora MySQL versão 2, o conjunto de caracteres padrão eralatin1. Para obter informações sobre esse conjunto de caracteres, consulte O conjunto de caracteres utf8mb4 (4-Byte UTF-8 Unicode Encoding), no Guia de referência do MySQL. -
O parâmetro de configuração
innodb_flush_log_at_trx_commitnão pode ser modificado. O valor padrão de 1 sempre é aplicável.
Determinados recursos do Aurora MySQL estão disponíveis para determinadas combinações de região da AWS e versão do mecanismo de banco de dados. Para obter mais detalhes, consulte Recursos compatíveis com o Amazon Aurora por Região da AWS e com o mecanismo de banco de dados do Aurora.
Suporte a classes de instâncias
O Aurora MySQL versão 3 oferece suporte a um conjunto diferente de classes de instâncias do que o Aurora MySQL versão 2:
-
Para instâncias maiores, é possível utilizar as classes de instâncias modernas, como
db.r5,db.r6gedb.x2g. -
Para instâncias menores, é possível utilizar as classes de instâncias modernas, como
db.t3edb.t4g.
As classes de instância a seguir do Aurora MySQL versão 2 não estão disponíveis para o Aurora MySQL versão 3:
-
db.r4 -
db.r3 -
db.t3.small -
db.t2
Confira se há declarações da CLI em seus scripts de administração que criem instâncias de banco de dados do Aurora MySQL. Nomes de classes de instâncias de código fixo que não estejam disponíveis para o Aurora MySQL versão 3. Se necessário, modifique os nomes das classes de instância para nomes que são compatíveis no Aurora MySQL versão 3.
Para verificar as classes de instância que podem ser utilizadas para uma combinação específica de versão do Aurora MySQL e região da AWS, use o comando describe-orderable-db-instance-options AWS CLI.
Para obter detalhes completos sobre classes de instâncias do Aurora, consulte Classes de instância de banco de dados Aurora.
Alterações de parâmetros do Aurora MySQL versão 3
O Aurora MySQL versão 3 inclui novos parâmetros de configuração em nível de cluster e de instância. O Aurora MySQL versão 3 também remove alguns parâmetros anteriormente presentes no Aurora MySQL versão 2. Alguns nomes de parâmetros foram modificados como resultado da iniciativa de linguagem inclusiva. Para compatibilidade com versões anteriores, ainda é possível recuperar valores de parâmetros utilizando os nomes antigos ou os novos. Porém, você deve utilizar os novos nomes para especificar valores de parâmetros em um grupo de parâmetros personalizado.
No Aurora MySQL versão 3, o valor do parâmetro lower_case_table_names é definido permanentemente no momento da criação do cluster. Se você utilizar um valor não padrão para essa opção, configure o grupo de parâmetros personalizado do Aurora MySQL versão 3 antes do upgrade. Em seguida, especifique o grupo de parâmetros durante a operação de criação de cluster ou restauração do snapshot.
Na versão 3 do Aurora MySQL, os parâmetros init_connect e read_only não se aplicam aos usuários que têm o privilégio CONNECTION_ADMIN. Isso inclui o usuário principal do Aurora. Para obter mais informações, consulte Modelo de privilégios baseados em funções.
Para obter a lista completa dos parâmetros de cluster do Aurora MySQL, consulte Parâmetros no nível do cluster. A tabela engloba todos os parâmetros do Aurora MySQL versões 1, 2 e 3. A tabela inclui observações mostrando quais parâmetros são novos no Aurora MySQL versão 3 ou foram removidos do Aurora MySQL versão 3.
Para obter a lista completa de parâmetros de instância do Aurora MySQL, consulte Parâmetros no nível da instância. A tabela engloba todos os parâmetros do Aurora MySQL versões 1, 2 e 3. A tabela inclui observações mostrando quais parâmetros são novos no Aurora MySQL versão 3 e quais parâmetros foram removidos do Aurora MySQL versão 3. Ela também inclui observações indicando quais parâmetros eram modificáveis em versões anteriores, mas não no Aurora MySQL versão 3.
Para obter informações sobre nomes de parâmetros modificados, consulte Alterações de linguagem inclusiva do Aurora MySQL versão 3.
Variáveis de status
Para obter informações sobre variáveis de status não aplicáveis ao Aurora MySQL, consulte Variáveis de status do MySQL não se aplicam ao Aurora MySQL.
Alterações de linguagem inclusiva do Aurora MySQL versão 3
O Aurora MySQL versão 3 tem compatibilidade com a versão 8.0.23 do MySQL edição da comunidade. O Aurora MySQL versão 3 também inclui alterações do MySQL 8.0.26 referentes a palavras-chave e esquemas de sistema para linguagem inclusiva. Por exemplo, o uso do comando SHOW REPLICA STATUS agora é preferencial ao do comando SHOW SLAVE STATUS.
As seguintes métricas do Amazon CloudWatch têm novos nomes no Aurora MySQL versão 3.
No Aurora MySQL versão 3, somente os nomes de métricas novos estão disponíveis. Certifique-se de atualizar alarmes ou qualquer outra automação que dependa de nomes de métricas ao fazer upgrade para o Aurora MySQL versão 3.
| Nome antigo | Novo nome |
|---|---|
ForwardingMasterDMLLatency
|
ForwardingWriterDMLLatency
|
ForwardingMasterOpenSessions
|
ForwardingWriterOpenSessions
|
AuroraDMLRejectedMasterFull
|
AuroraDMLRejectedWriterFull
|
ForwardingMasterDMLThroughput
|
ForwardingWriterDMLThroughput
|
As seguintes variáveis de status têm novos nomes no Aurora MySQL versão 3.
Para compatibilidade, é possível utilizar qualquer um dos nomes na versão inicial do Aurora MySQL versão 3. Os nomes de variáveis de status antigos serão removidos em um release futuro.
| Nome a ser removido | Nome novo ou preferencial |
|---|---|
Aurora_fwd_master_dml_stmt_duration
|
Aurora_fwd_writer_dml_stmt_duration
|
Aurora_fwd_master_dml_stmt_count
|
Aurora_fwd_writer_dml_stmt_count
|
Aurora_fwd_master_select_stmt_duration
|
Aurora_fwd_writer_select_stmt_duration
|
Aurora_fwd_master_select_stmt_count
|
Aurora_fwd_writer_select_stmt_count
|
Aurora_fwd_master_errors_session_timeout
|
Aurora_fwd_writer_errors_session_timeout
|
Aurora_fwd_master_open_sessions
|
Aurora_fwd_writer_open_sessions
|
Aurora_fwd_master_errors_session_limit
|
Aurora_fwd_writer_errors_session_limit
|
Aurora_fwd_master_errors_rpc_timeout
|
Aurora_fwd_writer_errors_rpc_timeout
|
Os seguintes parâmetros de configuração têm nomes novos no Aurora MySQL versão 3.
Para fins de compatibilidade, é possível verificar os valores dos parâmetros no cliente mysql utilizando qualquer nome no release inicial do Aurora MySQL versão 3. Você só pode usar os novos nomes ao modificar os valores em um grupo de parâmetros personalizado. Os nomes de parâmetros antigos serão removidos em um release futuro.
| Nome a ser removido | Nome novo ou preferencial |
|---|---|
aurora_fwd_master_idle_timeout
|
aurora_fwd_writer_idle_timeout
|
aurora_fwd_master_max_connections_pct
|
aurora_fwd_writer_max_connections_pct
|
master_verify_checksum
|
source_verify_checksum
|
sync_master_info
|
sync_source_info
|
init_slave
|
init_replica
|
rpl_stop_slave_timeout
|
rpl_stop_replica_timeout
|
log_slow_slave_statements
|
log_slow_replica_statements
|
slave_max_allowed_packet
|
replica_max_allowed_packet
|
slave_compressed_protocol
|
replica_compressed_protocol
|
slave_exec_mode
|
replica_exec_mode
|
slave_type_conversions
|
replica_type_conversions
|
slave_sql_verify_checksum
|
replica_sql_verify_checksum
|
slave_parallel_type
|
replica_parallel_type
|
slave_preserve_commit_order
|
replica_preserve_commit_order
|
log_slave_updates
|
log_replica_updates
|
slave_allow_batching
|
replica_allow_batching
|
slave_load_tmpdir
|
replica_load_tmpdir
|
slave_net_timeout
|
replica_net_timeout
|
sql_slave_skip_counter
|
sql_replica_skip_counter
|
slave_skip_errors
|
replica_skip_errors
|
slave_checkpoint_period
|
replica_checkpoint_period
|
slave_checkpoint_group
|
replica_checkpoint_group
|
slave_transaction_retries
|
replica_transaction_retries
|
slave_parallel_workers
|
replica_parallel_workers
|
slave_pending_jobs_size_max
|
replica_pending_jobs_size_max
|
pseudo_slave_mode
|
pseudo_replica_mode
|
Os seguintes procedimentos armazenados têm novos nomes no Aurora MySQL versão 3.
Para compatibilidade, é possível utilizar qualquer um dos nomes na versão inicial do Aurora MySQL versão 3. Os nomes de procedimentos antigos serão removidos em um release futuro.
| Nome a ser removido | Nome novo ou preferencial |
|---|---|
mysql.rds_set_master_auto_position
|
mysql.rds_set_source_auto_position
|
mysql.rds_set_external_master
|
mysql.rds_set_external_source
|
mysql.rds_set_external_master_with_auto_position
|
mysql.rds_set_external_source_with_auto_position
|
mysql.rds_reset_external_master
|
mysql.rds_reset_external_source
|
mysql.rds_next_master_log
|
mysql.rds_next_source_log
|
Valores de AUTO_INCREMENT
No Aurora MySQL versão 3, o Aurora preserva o valor AUTO_INCREMENT para cada tabela ao reiniciar cada instância de banco de dados. No Aurora MySQL versão 2, o valor AUTO_INCREMENT não era preservado após uma reinicialização.
O valor AUTO_INCREMENT não é preservado quando você configura um novo cluster por meio da restauração com um snapshot, aplicação de uma recuperação em um ponto anterior no tempo e clonagem de um cluster. Nesses casos, o valor AUTO_INCREMENT é inicializado para o valor com base no maior valor de coluna na tabela na ocasião em que o snapshot foi criado. Esse comportamento é diferente daquele no RDS para MySQL 8.0, em que o valor AUTO_INCREMENT é preservado durante essas operações.
Replicação de log binário
No MySQL 8.0 edição da comunidade, a replicação de logs binários está habilitada por padrão. No Aurora MySQL versão 3, a replicação de logs binários está desabilitada por padrão.
Se os seus requisitos de alta disponibilidade forem atendidos pelos recursos de replicação integrados do Aurora, será possível deixar a replicação de logs binários desabilitada. Dessa forma, é possível evitar a sobrecarga de performance da replicação de logs binários. Você também pode evitar os processos de monitoramento e solução de problemas associados que são necessários para gerenciar a replicação de logs binários.
O Aurora oferece suporte à replicação de logs binários de uma fonte compatível com MySQL 5.7 para o Aurora MySQL versão 3. O sistema de origem pode ser um cluster de banco de dados do Aurora MySQL, uma instância de banco de dados do RDS para MySQL ou uma instância do MySQL on-premises.
Assim como o MySQL edição da comunidade, o Aurora MySQL oferece suporte para replicação a partir de uma origem que executa uma versão específica para um destino que executa a mesma versão principal ou uma versão principal superior. Por exemplo, não há suporte para a replicação de um sistema compatível com MySQL 5.6 para o Aurora MySQL versão 3. Não há suporte para a replicação do Aurora MySQL versão 3 para um sistema compatível com o MySQL 5.7 ou MySQL 5.6. Para obter detalhes sobre como utilizar a replicação de logs binários, consulte Replicação entre Aurora e o MySQL ou entre Aurora e outro cluster de banco de dados do Aurora (replicação de log binário).
O Aurora MySQL versão 3 inclui melhorias na replicação de logs binários no MySQL 8.0 edição da comunidade, como a replicação filtrada. Para obter detalhes sobre as melhorias no MySQL 8.0 edição da comunidade, consulte Como servidores avaliam regras de filtragem de replicação
Replicação de vários threads
Com o Aurora MySQL versão 3, o Aurora MySQL oferece suporte para replicação de vários threads. Para obter mais informações, consulte Replicação de logs binários de versões posteriores (Aurora MySQL versão 3 e posteriores).
Ainda não recomendamos o uso da replicação de vários threads com o Aurora MySQL versões 1 e 2.
Compactação de transações para replicação de logs binários
Para obter informações de uso sobre a compactação de logs binários, consulte Compactação de transações de logs binários
As seguintes limitações aplicam-se à compactação de logs binários no Aurora MySQL versão 3:
-
Transações cujos dados de logs binários sejam maiores que o tamanho máximo permitido do pacote não são compactadas. Isso se aplica independentemente de a configuração de compactação de logs binários do Aurora MySQL estar ativada ou não. Essas transações são replicadas sem serem compactadas.
-
Se você utilizar um conector para captura de dados de alterações (CDC) que ainda não ofereça suporte ao MySQL 8.0, não será possível utilizar esse recurso. Recomendamos testar completamente todos os conectores de terceiros com a compactação de logs binários. Além disso, recomendamos fazer isso antes de ativar a compactação de binlog em sistemas que utilizam a replicação de binlog para CDC.
