# Amazon RDS para MySQL O Amazon RDS comporta várias versões do MySQL para instâncias de banco de dados. Para ter informações completas sobre as versões compatíveis, consulte [MySQL em versões do Amazon RDS](MySQL.Concepts.VersionMgmt.md). Para criar uma instância de banco de dados do Amazon RDS para MySQL, use as ferramentas de gerenciamento ou interfaces do Amazon RDS. Você pode, então, fazer o seguinte: + Redimensionar sua instância de banco de dados + Autorizar conexões com sua instância de banco de dados + Criar e restaurar a partir de backups ou snapshots + Criar secundários de multi-AZ + Criar réplicas de leitura + Monitorar a performance de sua instância de banco de dados Para armazenar e acessar os dados em sua instância de banco de dados, use utilitários e aplicações padrão do MySQL. O Amazon RDS para MySQL é compatível com vários padrões do setor. Por exemplo, você pode usar bancos de dados do RDS for MySQL para criar aplicações em conformidade com a norma HIPAA. É possível usar bancos de dados do RDS for MySQL para armazenar informações relacionadas à saúde, inclusive informações de saúde protegidas (PHI), segundo um Acordo de Associação Comercial (BAA) com a AWS. O Amazon RDS para MySQL também atende aos requisitos de segurança do Federal Risk and Authorization Management Program (FedRAMP). Além disso, o Amazon RDS para MySQL recebeu uma autoridade provisória da Joint Authorization Board (JAB) da FedRAMP para operar (P-ATO) na linha de base ALTA da FedRAMP nas regiões AWS GovCloud (US). Para obter mais informações sobre padrões de conformidade com suporte, consulte [Conformidade da nuvem AWS](https://aws.amazon.com/compliance/). Para obter informações sobre os recursos em cada versão do MySQL, consulte [Principais recursos do MySQL](https://dev.mysql.com/doc/refman/8.0/en/features.html) na documentação do MySQL. Antes de criar uma instância de banco de dados, conclua as etapas em [Configuração do ambiente do Amazon RDS](CHAP_SettingUp.md). Ao criar uma instância de banco de dados, o usuário principal do RDS obtém privilégios de DBA, com algumas limitações. Use essa conta para tarefas administrativas, como a criação de contas de banco de dados adicionais. Você pode criar o seguinte: + Instâncias de banco de dados + DB snapshots + Restaurações point-in-time + Backups automatizados + Backups manuais Você pode usar instâncias de banco de dados executando o MySQL em uma nuvem privada virtual (VPC) com base na Amazon VPC. Também é possível adicionar recursos à sua instância de banco de dados do MySQL ativando várias opções. O Amazon RDS é compatível com implantações multi-AZ para MySQL como uma solução de failover de alta disponibilidade. **Importante** Para oferecer uma experiência de serviço gerenciada, o Amazon RDS não fornece acesso ao shell para as instâncias de banco de dados. Também restringe o acesso a determinados procedimentos e tabelas do sistema que necessitam de privilégios avançados. É possível acessar seu banco de dados usando clientes SQL padrão, como o cliente mysql. No entanto, não é possível acessar o host diretamente usando Telnet ou Secure Shell (SSH). **Topics** + [ # Compatibilidade de recursos do MySQL no Amazon RDS ](MySQL.Concepts.FeatureSupport.md) + [ # MySQL em versões do Amazon RDS ](MySQL.Concepts.VersionMgmt.md) + [ # Conectar-se à instância de banco de dados do MySQL ](USER_ConnectToInstance.md) + [ # Proteger as conexões de instância de banco de dados do MySQL ](securing-mysql-connections.md) + [ # Melhorar a performance das consultas para o RDS para MySQL com leituras otimizadas do Amazon RDS ](rds-optimized-reads.md) + [ # Melhorar a performance das gravações com gravações otimizadas pelo RDS para MySQL ](rds-optimized-writes.md) + [ # Atualizações do mecanismo de banco de dados do RDS para MySQL ](USER_UpgradeDBInstance.MySQL.md) + [ # Atualizar uma versão do mecanismo de snapshot de banco de dados do MySQL ](mysql-upgrade-snapshot.md) + [ # Importar dados para uma instância de banco de dados do Amazon RDS para MySQL. ](MySQL.Procedural.Importing.Other.md) + [ # Trabalhar com a replicação do MySQL no Amazon RDS ](USER_MySQL.Replication.md) + [ # Configurar clusters ativos-ativos para RDS para MySQL ](mysql-active-active-clusters.md) + [ # Exportar dados de uma instância de banco de dados MySQL usando replicação ](MySQL.Procedural.Exporting.NonRDSRepl.md) + [ # Opções para instâncias de bancos de dados MySQL ](Appendix.MySQL.Options.md) + [ # Parâmetros do MySQL ](Appendix.MySQL.Parameters.md) + [ # Tarefas comuns de DBA para instâncias de banco de dados MySQL ](Appendix.MySQL.CommonDBATasks.md) + [ # Fuso horário local para instâncias de banco de dados MySQL ](MySQL.Concepts.LocalTimeZone.md) + [ # Problemas conhecidos e limitações do Amazon RDS para MySQL ](MySQL.KnownIssuesAndLimitations.md) + [ # Referência de procedimentos armazenados do RDS para MySQL ](Appendix.MySQL.SQLRef.md) # Compatibilidade de recursos do MySQL no Amazon RDS O RDS para MySQL é compatível com a maioria dos recursos do MySQL. Alguns recursos podem ter suporte limitado ou privilégios restritos. Você pode filtrar novos recursos do Amazon RDS na página [What's New with Database? (Novidades sobre bancos de dados)](https://aws.amazon.com/about-aws/whats-new/database/). Em **Products** (Produtos), escolha **Amazon RDS**. Em seguida, pesquise usando palavras-chave como **MySQL 2022**. **nota** As listas a seguir não são completas. **Topics** + [ ## Suporte a recursos do MySQL nas versões principais do Amazon RDS para MySQL ](#MySQL.Concepts.FeatureSupport.MajorVersions) + [ ## Suporte aos mecanismos de armazenamento no RDS para MySQL ](#MySQL.Concepts.Storage) + [ ## Usar memcached e outras opções com o MySQL no Amazon RDS ](#MySQL.Concepts.General.Options) + [ ## Aquecimento de cache do InnoDB para o MySQL no Amazon RDS ](#MySQL.Concepts.InnoDBCacheWarming) + [ ## Alterações de linguagem inclusiva para RDS para MySQL 8.4 ](#mysql-8-4-inclusive-language-changes) + [ ## Recursos do MySQL sem suporte pelo Amazon RDS ](#MySQL.Concepts.Features) ## Suporte a recursos do MySQL nas versões principais do Amazon RDS para MySQL Nas seções a seguir, localize informações sobre compatibilidade de recursos do MySQL nas versões principais do Amazon RDS para MySQL: **Topics** + [ ### Suporte ao MySQL 8.4 no Amazon RDS ](#MySQL.Concepts.FeatureSupport.8-4) Para obter informações sobre versões secundárias compatíveis do Amazon RDS para MySQL, consulte [Versões secundárias do MySQL compatíveis com o Amazon RDS](MySQL.Concepts.VersionMgmt.md#MySQL.Concepts.VersionMgmt.Supported). ### Suporte ao MySQL 8.4 no Amazon RDS O Amazon RDS oferece suporte aos novos recursos descritos a seguir para instâncias de banco de dados que executam o MySQL versão 8.4 ou posterior. + **Biblioteca criptográfica**: o RDS para MySQL substituiu o OpenSSL pelo AWS Libcrypto (AWS-LC), que tem certificação da norma FIPS 140-3. Para obter mais informações, consulte o repositório do GitHub AWS-LC em [https://github.com/aws/aws-lc](https://github.com/aws/aws-lc). + **Alterações do TLS**: o RDS para MySQL é compatível somente com o TLS 1.2 e o TLS 1.3. Para obter mais informações, consulte [Suporte do SSL/TLS para instâncias de banco de dados do MySQL no Amazon RDS](MySQL.Concepts.SSLSupport.md). + **Suporte ao memcached**: a interface do memcached não está mais disponível no MySQL 8.4. Para obter mais informações, consulte [Suporte a memcached MySQL](Appendix.MySQL.Options.memcached.md). + **Plugin de autenticação padrão**: o plugin de autenticação padrão é `caching_sha2_password`. Para obter mais informações, consulte [Plug-in de autenticação padrão do MySQL](MySQL.KnownIssuesAndLimitations.md#MySQL.Concepts.KnownIssuesAndLimitations.authentication-plugin). + **Utilitário cliente `mysqlpump`**: o utilitário cliente `mysqlpump` não está mais disponível no MySQL 8.4. Para obter mais informações, consulte [Modelo de privilégios baseados em perfis para o RDS para MySQL](Appendix.MySQL.CommonDBATasks.privilege-model.md) e [mysqldump e mysqlpump](https://docs.aws.amazon.com/prescriptive-guidance/latest/migration-large-mysql-mariadb-databases/mysqldump-and-mysqlpump.html) na *Orientação prescritiva da AWS*. + **Procedimentos armazenados de replicação gerenciada**: ao usar procedimentos armazenados para gerenciar a replicação com um usuário de replicação configurado com `caching_sha2_password`, você deve configurar o TLS especificando `SOURCE_SSL=1`. `caching_sha2_password` é o plugin de autenticação padrão para o RDS para MySQL 8.4. + **Mudanças no comportamento dos parâmetros**: os seguintes parâmetros foram alterados para o MySQL 8.4. + `innodb_dedicated_server`: por padrão, esse parâmetro está ativado. Para obter mais informações, consulte [Configuração do tamanho do pool de buffer e a capacidade de log redo no MySQL 8.4](Appendix.MySQL.CommonDBATasks.Config.Size.8.4.md). + `innodb_buffer_pool`: o mecanismo do banco de dados agora calcula esse parâmetro, mas você pode substituir essa configuração. Para obter mais informações, consulte [Configuração do tamanho do pool de buffer e a capacidade de log redo no MySQL 8.4](Appendix.MySQL.CommonDBATasks.Config.Size.8.4.md). + `innodb_redo_log_capacity`: esse parâmetro agora controla o tamanho dos arquivos de log de refazer. O mecanismo do banco de dados agora calcula esse parâmetro, mas você pode substituir essa configuração. Para obter mais informações, consulte [Configuração do tamanho do pool de buffer e a capacidade de log redo no MySQL 8.4](Appendix.MySQL.CommonDBATasks.Config.Size.8.4.md). + **Parâmetros obsoletos ou removidos**: o RDS for MySQL removeu os seguintes parâmetros dos grupos de parâmetros para instâncias de banco de dados MySQL 8.4. O parâmetro `innodb_redo_log_capacity` agora controla o tamanho dos arquivos de log de refazer. + `innodb_log_file_size` + `innodb_log_files_in_group` + **Novos valores padrão para parâmetros**: os seguintes parâmetros têm novos valores padrão para instâncias de banco de dados MySQL versão 8.4: + Vários parâmetros da comunidade MySQL relacionados ao desempenho foram alterados. Para obter mais informações, consulte [O que há de novo no MySQL 8.4 desde o MySQL 8.0](https://dev.mysql.com/doc/refman/8.4/en/mysql-nutshell.html). Recomendamos que você teste o desempenho da aplicação no RDS for MySQL 8.4 antes de migrar uma instância de produção. + `innodb_purge_threads`: o valor padrão é definido como a fórmula `LEAST({DBInstanceVCPU/2},4)` para evitar que o comprimento da lista de histórico do InnoDB cresça demais. + `group_replication_exit_state_action`: o valor padrão é `OFFLINE_MODE`, que se alinha ao padrão no MySQL Community. Para obter mais informações, consulte [Considerações e práticas recomendadas para cluster ativo-ativo do RDS para MySQL](mysql-active-active-clusters-considerations-limitations.md#mysql-active-active-clusters-considerations). + `binlog_format`: o valor padrão é `ROW`, que se alinha ao padrão no MySQL Community. Você pode modificar o parâmetro para instâncias de banco de dados single-AZ ou multi-AZ, mas não para clusters de banco de dados multi-AZ. Os clusters de banco de dados multi-AZ usam replicação semissíncrona e, quando `binlog_format` é configurado como `MIXED` ou `STATEMENT`, a replicação falha. + **Alterações de linguagem inclusiva**: o RDS para MySQL 8.4 inclui alterações do RDS para MySQL 8.0 relacionadas a palavras-chave e esquemas de sistema para linguagem inclusiva. Para obter mais informações, consulte [Alterações de linguagem inclusiva para RDS para MySQL 8.4](#mysql-8-4-inclusive-language-changes). Para obter uma lista de todos os recursos e alterações do MySQL 8.4, consulte [O que há de novo no MySQL 8.4 desde o MySQL 8.0](https://dev.mysql.com/doc/refman/8.4/en/mysql-nutshell.html) na documentação do MySQL. Para conferir uma lista de recursos não compatíveis, consulte [Recursos do MySQL sem suporte pelo Amazon RDS](#MySQL.Concepts.Features). ## Suporte aos mecanismos de armazenamento no RDS para MySQL Embora o MySQL ofereça suporte a vários mecanismos de armazenamento com recursos variados, nem todos eles são otimizados para durabilidade e recuperação de dados. O Amazon RDS oferece suporte total ao mecanismo de armazenamento do InnoDB para instâncias de banco de dados do MySQL. Os recursos de restauração point-in-time e de snapshot do Amazon RDS exigem um mecanismo de armazenamento recuperável e são compatíveis somente com o mecanismo de armazenamento do InnoDB. Para obter mais informações, consulte [Suporte a memcached MySQL](Appendix.MySQL.Options.memcached.md). O Federated Storage Engine atualmente não é compatível com o Amazon RDS para MySQL. Para esquemas criados pelo usuário, o mecanismo de armazenamento MyISAM não oferece suporte para recuperação confiável e pode resultar em dados perdidos ou corrompidos quando o MySQL é reiniciado após uma recuperação, impedindo que uma restauração pontual ou uma restauração de snapshot funcione conforme pretendido. No entanto, se você ainda optar por usar o MyISAM com o Amazon RDS, snapshots podem ser úteis em algumas condições. **nota** As tabelas do sistema no esquema `mysql` podem estar no armazenamento MyISAM. Se você deseja converter tabelas do MyISAM em tabelas do InnoDB, pode usar o comando `ALTER TABLE` (por exemplo, `alter table TABLE_NAME engine=innodb;`). Lembre-se de que o MyISAM e o InnoDB têm pontos fortes e fracos diferentes. Portanto, é necessário que você avalie totalmente o impacto que essas alterações terão em seus aplicativos antes de fazê-las. Os MySQL 5.1, 5.5 e 5.6 não são mais compatíveis com o Amazon RDS. No entanto, é possível restaurar snapshots do MySQL 5.1, 5.5 e 5.6 existentes. Ao restaurar um snapshot do MySQL 5.1, 5.5 ou 5.6, a instância de banco de dados é automaticamente atualizada para o MySQL 5.7. ## Usar memcached e outras opções com o MySQL no Amazon RDS A maioria dos mecanismos de banco de dados do Amazon RDS oferece suporte a grupos de opções que permitem selecionar recursos adicionais para a sua instância de banco de dados. As instâncias de banco de dados do RDS para MySQL são compatíveis com a opção `memcached`, um cache simples baseado em chaves. Para obter mais informações sobre `memcached` e outras opções, consulte [Opções para instâncias de bancos de dados MySQL](Appendix.MySQL.Options.md). Para mais informações sobre como trabalhar com grupos de opções, consulte [Trabalhar com grupos de opções](USER_WorkingWithOptionGroups.md). ## Aquecimento de cache do InnoDB para o MySQL no Amazon RDS O aquecimento de cache do InnoDB pode fornecer ganhos de performance para sua instância de banco de dados do MySQL salvando o estado atual do grupo de buffer quando a instância de banco de dados é desativada e, em seguida, recarregando o grupo de buffer a partir das informações salvas quando a instância do banco de dados for iniciada. Isso dispensa a necessidade de o grupo de buffer "aquecer" do uso normal de banco de dados e, em vez disso, pré-carrega o grupo de buffer com as páginas para consultas comuns conhecidas. O arquivo que armazena as informações do pool de buffer salvo armazena apenas os metadados para as páginas que estão no pool de buffer, e não as páginas propriamente ditas. Como resultado, o arquivo não requer muito espaço de armazenamento. O tamanho do arquivo é de aproximadamente 0,2 por cento do tamanho do cache. Por exemplo, para um cache de 64 GiB, o tamanho do arquivo de aquecimento do cache é de 128 MiB. Para obter mais informações sobre o aquecimento de cache do InnoDB, consulte [Saving and restoring the buffer pool state](https://dev.mysql.com/doc/refman/8.0/en/innodb-preload-buffer-pool.html) na documentação do MySQL. As instâncias de banco de dados do RDS para MySQL são compatíveis com o aquecimento de cache InnoDB. Para habilitar o aquecimento de cache do InnoDB, defina os parâmetros `innodb_buffer_pool_dump_at_shutdown` e `innodb_buffer_pool_load_at_startup` como 1 no grupo de parâmetros da sua instância de banco de dados. Mudar esses valores de parâmetro em um grupo de parâmetros afetará todas as instâncias de banco de dados MySQL que usam esse grupo de parâmetros. Para habilitar o aquecimento de cache do InnoDB para instâncias específicas de banco de dados MySQL, talvez você precise criar um grupo de parâmetros nessas instâncias. Para obter informações sobre grupos de parâmetros, consulte [Grupos de parâmetros para Amazon RDS](USER_WorkingWithParamGroups.md). O aquecimento de cache do InnoDB fornece principalmente um benefício de performance para instâncias de banco de dados que usam armazenamento padrão. Se você usar o armazenamento PIOPS, não perceberá um benefício significativo de performance normalmente. **Importante** Se sua instância de banco de dados MySQL não for encerrada normalmente, como durante um failover, o estado do pool de buffers não será salvo no disco. Nesse caso, o MySQL carrega qualquer arquivo de grupo de buffer disponível quando a instância de banco de dados for reiniciada. Não há problema, mas o grupo de buffer restaurado pode não refletir o estado mais recente do grupo de buffer antes do reinício. Para garantir que você tenha um estado recente do grupo de buffer disponível para aquecer o cache do InnoDB na inicialização, recomendamos que você descarte periodicamente o grupo de buffer "sob demanda". Você pode criar um evento para descartar o grupo de buffer automaticamente e em um intervalo regular. Por exemplo, a seguinte declaração cria um evento chamado `periodic_buffer_pool_dump` que descarta o grupo de buffer de hora em hora. ``` 1. CREATE EVENT periodic_buffer_pool_dump 2. ON SCHEDULE EVERY 1 HOUR 3. DO CALL mysql.rds_innodb_buffer_pool_dump_now(); ``` Para obter mais informações sobre eventos do MySQL, consulte [Event syntax](https://dev.mysql.com/doc/refman/8.0/en/events-syntax.html) na documentação do MySQL. ### Como descartar e carregar o grupo de buffer sob demanda É possível salvar e carregar o cache InnoDB “sob demanda”. + Para descartar o estado atual do grupo de buffer para o disco, chame o procedimento armazenado [mysql.rds\$1innodb\$1buffer\$1pool\$1dump\$1now](mysql-stored-proc-warming.md#mysql_rds_innodb_buffer_pool_dump_now). + Para carregar o estado salvo do grupo de buffer a partir do disco, chame o procedimento armazenado [mysql.rds\$1innodb\$1buffer\$1pool\$1load\$1now](mysql-stored-proc-warming.md#mysql_rds_innodb_buffer_pool_load_now). + Para cancelar uma operação de carregamento em andamento, chame o procedimento armazenado [mysql.rds\$1innodb\$1buffer\$1pool\$1load\$1abort](mysql-stored-proc-warming.md#mysql_rds_innodb_buffer_pool_load_abort). ## Alterações de linguagem inclusiva para RDS para MySQL 8.4 O RDS para MySQL versão 8.4 também inclui alterações da edição da comunidade do MySQL 8.4 referentes a palavras-chave e esquemas de sistema para linguagem inclusiva. Por exemplo, o comando `SHOW REPLICA STATUS` substitui `SHOW SLAVE STATUS`. **Topics** + [ ### Alterações do nome do parâmetro de configuração ](#mysql-8-4-inclusive-language-changes-params) + [ ### Alterações do nome dos procedimentos armazenados ](#mysql-8-4-inclusive-language-changes-sp) ### Alterações do nome do parâmetro de configuração Os seguintes parâmetros de configuração têm nomes novos no RDS para MySQL 8.4. Para fins de compatibilidade, é possível verificar os nomes dos parâmetros no cliente `mysql` utilizando qualquer nome. Você só pode usar os novos nomes ao modificar os valores em um grupo de parâmetros personalizado do MySQL 8.4. Para obter mais informações, consulte [Grupos de parâmetros padrão e personalizados](parameter-groups-overview.md#parameter-groups-overview.custom). | Nome a ser removido | Nome novo ou preferencial | | --- | --- | | `init_slave` | `init_replica` | | `log_slave_updates` | `log_replica_updates` | | `log_slow_slave_statements` | `log_slow_replica_statements` | | `rpl_stop_slave_timeout` | `rpl_stop_replica_timeout` | | `skip_slave_start` | `skip_replica_start` | | `slave_checkpoint_group` | `replica_checkpoint_group` | | `slave_checkpoint_period` | `replica_checkpoint_period` | | `slave_compressed_protocol` | `replica_compressed_protocol` | | `slave_exec_mode` | `replica_exec_mode` | | `slave_load_tmpdir` | `replica_load_tmpdir` | | `slave_max_allowed_packet` | `replica_max_allowed_packet` | | `slave_net_timeout` | `replica_net_timeout` | | `slave_parallel_type` | `replica_parallel_type` | | `slave_parallel_workers` | `replica_parallel_workers` | | `slave_pending_jobs_size_max` | `replica_pending_jobs_size_max` | | `slave_preserve_commit_order` | `replica_preserve_commit_order` | | `slave_skip_errors` | `replica_skip_errors` | | `slave_sql_verify_checksum` | `replica_sql_verify_checksum` | | `slave_transaction_retries` | `replica_transaction_retries` | | `slave_type_conversions` | `replica_type_conversions` | | `sql_slave_skip_counter` | `sql_replica_skip_counter` | **nota** O parâmetro `replica_allow_batching` não está disponível porque o Amazon RDS não é compatível com clusters do NDB. ### Alterações do nome dos procedimentos armazenados Os seguintes procedimentos armazenados têm novos nomes no RDS para MySQL 8.4. Para compatibilidade, é possível utilizar qualquer um dos nomes na versão inicial do RDS para MySQL versão 8.4. Os nomes de procedimentos antigos serão removidos em um release futuro. Para obter mais informações, consulte [Configurar, iniciar e interromper a replicação de logs binários (binlogs)](mysql-stored-proc-replicating.md). | Nome a ser removido | Nome novo ou preferencial | | --- | --- | | `mysql.rds_next_master_log` | `mysql.rds_next_source_log ` | | `mysql.rds_reset_external_master` | `mysql.rds_reset_external_source` | | `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_set_external_master_with_delay` | `mysql.rds_set_external_source_with_delay` | | `mysql.rds_set_master_auto_position` | `mysql.rds_set_source_auto_position` | ## Recursos do MySQL sem suporte pelo Amazon RDS Atualmente, o Amazon RDS não oferece suporte aos seguintes recursos do MySQL: + Plugin de autenticação + Registro de erros no log do sistema + Criptografia de espaço de tabela do InnoDB + Clusters do NDB + Plugin de intensidade da senha + Variáveis de sistema mantidas + Plugin de regravação de consulta de regravador + Replicação semissíncrona, exceto para clusters de banco de dados multi-AZ + Espaço de tabela transportável + Plug-in X Para oferecer uma experiência de serviço gerenciada, o Amazon RDS não fornece acesso ao shell para as instâncias de banco de dados. Ele também restringe o acesso a determinados procedimentos e tabelas do sistema que exigem privilégios avançados. O Amazon RDS oferece suporte a acesso a bancos de dados em uma instância de banco de dados que usa qualquer aplicação de cliente SQL padrão. O Amazon RDS não permite o acesso direto do host a uma instância de banco de dados usando Telnet, Secure Shell (SSH) ou Windows Remote Desktop Connection. Ao criar uma instância de banco de dados, você recebe a função *db\$1owner* para todos os bancos de dados nessa instância e tem todas as permissões em nível de banco de dados, exceto aquelas usadas para backups. O Amazon RDS gerencia backups para você. # MySQL em versões do Amazon RDS No MySQL, os números de versão são organizados como versão = X.Y.Z. Na terminologia do Amazon RDS, X.Y representa a versão principal, e Z é o número da versão secundária. Para implementações do Amazon RDS, uma alteração da versão é considerada primária se o número da versão primária for alterado—, por exemplo, da versão 5.7 para a 8.0. Uma alteração da versão será considerada secundária se apenas o número da versão secundária for alterado; por exemplo, da versão 8.0.32 para 8.0.34. **Topics** + [ ## Versões secundárias do MySQL compatíveis com o Amazon RDS ](#MySQL.Concepts.VersionMgmt.Supported) + [ ## Versões principais do MySQL compatíveis com o Amazon RDS ](#MySQL.Concepts.VersionMgmt.ReleaseCalendar) + [ ## Versões do Suporte estendido do Amazon RDS para RDS para MySQL ](#mysql-extended-support-releases) + [ ## Trabalhar com o ambiente de visualização de banco de dados ](#mysql-working-with-the-database-preview-environment) + [ ## MySQL versão 9.5 no Ambiente de Pré-visualização do Banco de Dados ](#mysql-preview-environment-version-9-5) + [ ## MySQL versão 9.4 no Ambiente de Pré-visualização do Banco de Dados ](#mysql-preview-environment-version-9-4) + [ ## MySQL versão 9.3 no Ambiente de Pré-visualização do Banco de Dados ](#mysql-preview-environment-version-9-3) + [ ## Versões obsoletas do Amazon RDS para MySQL ](#MySQL.Concepts.DeprecatedVersions) ## Versões secundárias do MySQL compatíveis com o Amazon RDS No momento, o Amazon RDS é compatível com as versões secundárias do MySQL a seguir. **nota** O Suporte estendido do Amazon RDS não está disponível para versões secundárias. No momento, a tabela a seguir mostra as versões secundárias do MySQL 8.4 compatíveis com o Amazon RDS. | Versão do mecanismo do MySQL | Data de lançamento para a comunidade | Data de lançamento do RDS | Data do fim do suporte padrão para o RDS | | --- | --- | --- | --- | | 8.4.8 | 20 de janeiro de 2026 | 3 de fevereiro de 2026 | 3 de fevereiro de 2027 | | 8.4.7 | 21 de outubro de 2025 | 13 de novembro de 2025 | 30 de novembro de 2026 | | 8.4.6 | 22 de julho de 2025 | 1.º de agosto de 2025 | 30 de setembro de 2026 | | 8.4.5 | 15 de abril de 2025 | 29 de abril de 2025 | 30 de setembro de 2026 | | 8.4.4 | 21 de janeiro de 2025 | 19 de fevereiro de 2025 | 31 de maio de 2026 | | 8.4.3 | 15 de outubro de 2024 | 21 de novembro de 2024 | 31 de maio de 2026 | No momento, a tabela a seguir mostra as versões secundárias do MySQL 8.0 compatíveis com o Amazon RDS. **nota** As versões secundárias podem chegar ao fim do suporte padrão antes das versões principais. Por exemplo, a versão secundária 8.0.28 atingiu a data de fim do suporte padrão em 28 de março de 2024, enquanto a versão principal 8.0 alcançará essa data em 31 de julho de 2026. O RDS comportará versões secundárias 8.0.\$1 adicionais que a comunidade do MySQL lançará entre essas datas. Recomendamos atualizar todas as versões principais para a versão secundária mais recente disponível assim que possível. | Versão do mecanismo do MySQL | Data de lançamento para a comunidade | Data de lançamento do RDS | Data do fim do suporte padrão para o RDS | | --- | --- | --- | --- | | 8.0.45 | 20 de janeiro de 2026 | 3 de fevereiro de 2026 | 31 de julho de 2026 | | 8.0.44 | 21 de outubro de 2025 | 13 de novembro de 2025 | 31 de julho de 2026 | | 8.0.43 | 22 de julho de 2025 | 1.º de agosto de 2025 | 31 de julho de 2026 | | 8.0.42 | 15 de abril de 2025 | 29 de abril de 2025 | 31 de julho de 2026 | | 8.0.41 | 21 de janeiro de 2025 | 19 de fevereiro de 2025 | 31 de maio de 2026 | | 8.0.40 | 15 de outubro de 2024 | 13 de novembro de 2024 | 31 de maio de 2026 | No momento, a tabela a seguir mostra as versões secundárias do MySQL 5.7 compatíveis com o Amazon RDS Extended Support. **nota** As versões secundárias podem chegar ao fim do suporte estendido antes das versões principais. Por exemplo, a versão secundária 5.7.44-RDS.20240529 chega ao fim da data de suporte estendido em setembro de 2025, enquanto a versão principal 5.7 chega a essa data em 28 de fevereiro de 2027. O RDS gerará e lançará versões secundárias adicionais 5.7.44-RDS.xxyyzz entre essas datas. Recomendamos atualizar todas as versões principais para a versão secundária mais recente disponível assim que possível. | Versão do mecanismo do MySQL | Data de lançamento para a comunidade | Data de lançamento do RDS | Data de término do suporte estendido para o RDS | | --- | --- | --- | --- | | 5.7.44-RDS.20260212\$1 | Não aplicável | 26 de fevereiro de 2026 | 28 de fevereiro de 2027 | | 5.7.44-RDS.20251212\$1 | Não aplicável | 12 de dezembro de 2025 | 30 de dezembro de 2026 | | 5.7.44-RDS.20250818\$1 | Não aplicável | 15 de setembro de 2025 | 30 de setembro de 2026 | | 5,7.44-RDS.20250508\$1 | Não aplicável | 20 de maio de 2025 | 30 de setembro de 2026 | | 5.7.44-RDS.20250213\$1 | Não aplicável | 12 de março de 2025 | 30 de setembro de 2026 | | 5.7.44-RDS.20250103\$1 | Não aplicável | 13 de fevereiro de 2025 | 31 de maio de 2026 | \$1 O MySQL Community retirou a versão principal 5.7 e não lançará novas versões secundárias. Essa é uma versão secundária que o Amazon RDS lançou com patches de segurança e correções de erros críticos para bancos de dados do MySQL 5.7 que são cobertos pelo Suporte estendido do RDS. Para ter mais informações sobre essas versões secundárias, consulte [Versões do Suporte estendido do Amazon RDS para RDS para MySQL](#mysql-extended-support-releases). Para ter mais informações sobre o Suporte estendido do RDS, consulte [Suporte estendido do Amazon RDS com Amazon RDS](extended-support.md). Você pode especificar qualquer versão atualmente com suporte do MySQL ao criar uma nova instância de banco de dados. Você pode especificar a versão principal (como o MySQL 5.7) e qualquer versão secundária com suporte para a versão principal especificada. Se nenhuma versão for especificada, o Amazon RDS usará uma versão compatível por padrão, geralmente a versão mais recente. Se uma versão principal for especificada, mas uma versão secundária não, o Amazon RDS usará por padrão um lançamento recente da versão principal que você especificou. Para ver uma lista de versões com suporte, bem como os padrões para instâncias de banco de dados recém-criadas, execute o comando da `describe-db-engine-versions` [AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-engine-versions.html). Por exemplo, para listar as versões de mecanismo compatíveis com o RDS para MySQL, execute o comando da CLI a seguir: ``` aws rds describe-db-engine-versions --engine mysql --query "*[].{Engine:Engine,EngineVersion:EngineVersion}" --output text ``` A versão padrão do MySQL pode variar de acordo com a Região da AWS. Para criar uma instância de banco de dados com uma versão secundária específica, especifique a versão secundária durante a criação da instância de banco de dados. É possível determinar a versão secundária padrão para uma Região da AWS executando o seguinte comando da AWS CLI: ``` aws rds describe-db-engine-versions --default-only --engine mysql --engine-version major_engine_version --region region --query "*[].{Engine:Engine,EngineVersion:EngineVersion}" --output text ``` Substitua *major-engine-version* pela versão principal do mecanismo e substitua *region* pela Região da AWS. Por exemplo, o comando da AWS CLI a seguir retorna a versão secundária padrão do mecanismo do MySQL para a versão principal 5.7 e a Região da AWS Oeste dos EUA (Oregon) (us-west-2): ``` aws rds describe-db-engine-versions --default-only --engine mysql --engine-version 5.7 --region us-west-2 --query "*[].{Engine:Engine,EngineVersion:EngineVersion}" --output text ``` Com o Amazon RDS, você controla quando vai atualizar a instância do MySQL para uma nova versão principal compatível com o Amazon RDS. É possível manter a compatibilidade com versões específicas do MySQL, testar novas versões com o aplicativo antes de implantar na produção e realizar atualizações da versão principal no período que melhor se adequar à sua programação. Com a atualização automática de versão secundária habilitada, a instância de banco de dados é atualizada automaticamente para novas versões secundárias do MySQL, pois elas são compatíveis com o Amazon RDS. Essa correção ocorre durante a janela de manutenção programada. É possível modificar uma instância de banco de dados para habilitar ou desabilitar atualizações automáticas de versões secundárias. Se você cancelar os upgrades automaticamente agendados, poderá fazer upgrade manualmente para um lançamento de versão secundária com suporte seguindo o mesmo procedimento de um upgrade de versão principal. Para ter mais informações, consulte [Atualizar a versão de mecanismo de uma instância de banco de dados ](USER_UpgradeDBInstance.Upgrading.md). O Amazon RDS atualmente oferece suporte para as seguintes atualizações para versões principais do mecanismo de banco de dados MySQL: + MySQL 5.7 a MySQL 8.0 + MySQL 8.0 a MySQL 8.4 Como as atualizações da versão primária envolvem um certo risco de compatibilidade, elas não ocorrem automaticamente; é necessário fazer uma solicitação para modificar a instância de banco de dados. Você deve testar completamente qualquer atualização antes de atualizar suas instâncias de produção. Para ter mais informações sobre como atualizar uma instância de banco de dados MySQL, consulte [Atualizações do mecanismo de banco de dados do RDS para MySQL](USER_UpgradeDBInstance.MySQL.md). Você pode testar uma instância de banco de dados em relação a uma nova versão antes de atualizar, criando um snapshot de banco de dados da sua instância de banco de dados atual, restaurando do snapshot de banco de dados para criar uma nova instância de banco de dados e, depois, iniciando uma atualização de versão para a nova instância de banco de dados. Isso permite que você teste com segurança o clone atualizado de sua instância de banco de dados antes de decidir se deseja ou não atualizar sua instância de banco de dados original. ### Versões secundárias do MySQL no Amazon RDS Com relação às alterações que a comunidade do MySQL fez nas versões secundárias, consulte [Critical Patch Updates, Security Alerts and Bulletins](https://www.oracle.com/security-alerts/) no site da Oracle. Em **Critical Patch Update**, escolha o mês em que a Oracle lançou a versão secundária. Em seguida, escolha a versão secundária do MySQL em **Affected Products and Versions**. **Topics** + [ #### MySQL versão 8.4.8 ](#MySQL.Concepts.VersionMgmt.Supported.Minor.8.4.8) + [ #### MySQL versão 8.4.7 ](#MySQL.Concepts.VersionMgmt.Supported.Minor.8.4.7) + [ #### MySQL versão 8.4.6 ](#MySQL.Concepts.VersionMgmt.Supported.Minor.8.4.6) + [ #### MySQL versão 8.4.5 ](#MySQL.Concepts.VersionMgmt.Supported.Minor.8.4.5) + [ #### MySQL versão 8.4.4 ](#MySQL.Concepts.VersionMgmt.Supported.Minor.8.4.4) + [ #### MySQL versão 8.0.45 ](#MySQL.Concepts.VersionMgmt.Supported.Minor.8.0.45) + [ #### MySQL versão 8.0.44 ](#MySQL.Concepts.VersionMgmt.Supported.Minor.8.0.44) + [ #### MySQL versão 8.0.43 ](#MySQL.Concepts.VersionMgmt.Supported.Minor.8.0.43) + [ #### MySQL versão 8.0.42 ](#MySQL.Concepts.VersionMgmt.Supported.Minor.8.0.42) + [ #### MySQL versão 8.0.41 ](#MySQL.Concepts.VersionMgmt.Supported.Minor.8.0.41) + [ #### MySQL versão 8.0.40 ](#MySQL.Concepts.VersionMgmt.Supported.Minor.8.0.40) + [ #### MySQL versão 8.0.39 ](#MySQL.Concepts.VersionMgmt.Supported.Minor.8.0.39) + [ #### MySQL versão 8.0.37 ](#MySQL.Concepts.VersionMgmt.Supported.Minor.8.0.37) #### MySQL versão 8.4.8 O MySQL versão 8.4.8 já está disponível no Amazon RDS. Essa versão contém correções e melhorias adicionadas pela comunidade do MySQL e pelo Amazon RDS. **Novos recursos e aprimoramentos** + Atualização das informações de fuso horário para usar como base `tzdata2025c`. + Corrigido um problema que pode fazer com que algumas instruções SQL não sejam registradas no log de auditoria. #### MySQL versão 8.4.7 O MySQL versão 8.4.7 já está disponível no Amazon RDS. Essa versão contém correções e melhorias adicionadas pela comunidade do MySQL e pelo Amazon RDS. #### MySQL versão 8.4.6 O MySQL versão 8.4.6 já está disponível no Amazon RDS. Essa versão contém correções e melhorias adicionadas pela comunidade do MySQL e pelo Amazon RDS. #### MySQL versão 8.4.5 O MySQL versão 8.4.5 já está disponível no Amazon RDS. Essa versão contém correções e melhorias adicionadas pela comunidade do MySQL e pelo Amazon RDS. **Novos recursos e aprimoramentos** + Atualização das informações de fuso horário para usar como base `tzdata2025b`. #### MySQL versão 8.4.4 O MySQL versão 8.4.4 já está disponível no Amazon RDS. Essa versão contém correções e melhorias adicionadas pela comunidade do MySQL e pelo Amazon RDS. **Novos recursos e aprimoramentos** + Atualização das informações de fuso horário para usar `tzdata2025a` como base. + Correção de um bug que causava um erro de agrupamento ao executar os procedimentos armazenados `mysql.rds_set_configuration` e `mysql.rds_kill` do Amazon RDS. #### MySQL versão 8.0.45 O MySQL versão 8.0.45 já está disponível no Amazon RDS. Essa versão contém correções e melhorias adicionadas pela comunidade do MySQL e pelo Amazon RDS. **Novos recursos e aprimoramentos** + Atualização das informações de fuso horário para usar como base `tzdata2025c`. + Corrigido um problema que pode fazer com que algumas instruções SQL não sejam registradas no log de auditoria. #### MySQL versão 8.0.44 O MySQL versão 8.0.44 já está disponível no Amazon RDS. Essa versão contém correções e melhorias adicionadas pela comunidade do MySQL e pelo Amazon RDS. #### MySQL versão 8.0.43 O MySQL versão 8.0.43 já está disponível no Amazon RDS. Essa versão contém correções e melhorias adicionadas pela comunidade do MySQL e pelo Amazon RDS. #### MySQL versão 8.0.42 O MySQL versão 8.0.42 já está disponível no Amazon RDS. Essa versão contém correções e melhorias adicionadas pela comunidade do MySQL e pelo Amazon RDS. **Novos recursos e aprimoramentos** + Atualização das informações de fuso horário para usar como base `tzdata2025b`. #### MySQL versão 8.0.41 O MySQL versão 8.0.41 já está disponível no Amazon RDS. Essa versão contém correções e melhorias adicionadas pela comunidade do MySQL e pelo Amazon RDS. **Novos recursos e aprimoramentos** + Atualização das informações de fuso horário para usar `tzdata2025a` como base. + Correção de um bug que causava um erro de agrupamento ao executar os procedimentos armazenados `mysql.rds_set_configuration` e `mysql.rds_kill` do Amazon RDS. #### MySQL versão 8.0.40 O MySQL versão 8.0.40 já está disponível no Amazon RDS. Essa versão contém correções e melhorias adicionadas pela comunidade do MySQL e pelo Amazon RDS. **Novos recursos e aprimoramentos** + Correção de um erro que causava falhas de incompatibilidade de conjuntos de caracteres durante atualizações do banco de dados. #### MySQL versão 8.0.39 O MySQL versão 8.0.39 já está disponível no Amazon RDS. Essa versão contém correções e melhorias adicionadas pela comunidade do MySQL e pelo Amazon RDS. **Novos recursos e aprimoramentos** + Corrigimos um erro que impedia que `sql_log_off` funcionasse corretamente com o privilégio `SESSION_VARIABLES_ADMIN`. + Corrigimos um erro que impedia o usuário principal de conceder o privilégio `SESSION_VARIABLE_ADMIN` a outros usuários do banco de dados. + Corrigimos um erro que causava uma combinação ilegal de agrupamento ao executar procedimentos armazenados fornecidos pelo RDS. #### MySQL versão 8.0.37 O MySQL versão 8.0.37 já está disponível no Amazon RDS. Essa versão contém correções e melhorias adicionadas pela comunidade do MySQL e pelo Amazon RDS. **Novos recursos e aprimoramentos** + Correção de um bug referente à execução de uma instrução de DDL instantânea após uma ATUALIZAÇÃO que causava uma falha na declaração. ## Versões principais do MySQL compatíveis com o Amazon RDS As versões principais do RDS para MySQL estarão disponíveis pelo suporte padrão pelo menos até o fim da vida útil da comunidade para a versão da comunidade correspondente. Você pode continuar executando uma versão principal após a data de término do suporte padrão do RDS mediante o pagamento de uma taxa. Para acessar mais informações, consulte [Suporte estendido do Amazon RDS com Amazon RDS](extended-support.md) e [Preço do Amazon RDS para MySQL](https://aws.amazon.com/rds/mysql/pricing/). É possível usar as seguintes datas para planejar seus ciclos de teste e atualização. **nota** Você também pode visualizar informações sobre datas de suporte para as principais versões do mecanismo usando a AWS CLI ou a API do RDS. Para obter mais informações, consulte [Visualizar datas de suporte de versões de mecanismo no Suporte estendido do Amazon RDS](extended-support-viewing-support-dates.md). | Versão principal do MySQL | Data de lançamento para a comunidade | Data de lançamento do RDS | Data do fim da vida útil para a comunidade | Data do fim do suporte padrão para o RDS | Data de definição de preço do início do suporte estendido para o RDS no primeiro ano | Data de definição de preço do início do suporte estendido para o RDS no terceiro ano | Data de término do suporte estendido para o RDS | | --- | --- | --- | --- | --- | --- | --- | --- | | MySQL 8.4 | 30 de abril de 2024 | 21 de novembro de 2024 | 30 de abril de 2029 | 31 de julho de 2029 | 1.º de agosto de 2029 | 1.º de agosto de 2031 | 31 de julho de 2032 | | MySQL 8.0 | 19 de abril de 2018 | 23 de outubro de 2018 | 30.º de abril de 2026 | 31 de julho de 2026 | 1.º de agosto de 2026 | 1.º de agosto de 2028 | 31 de julho de 2029 | | MySQL 5.7\$1 | 21 de outubro de 2015 | 22 de fevereiro de 2016 | 31 de outubro de 2023 | 23 de fevereiro de 2024 | 1.º de março de 2024 | 1.º de março de 2026 | 28 de fevereiro de 2027 | \$1 O MySQL 5.7 agora só está disponível no Suporte estendido do RDS. Para obter mais informações, consulte [Suporte estendido do Amazon RDS com Amazon RDS](extended-support.md). ## Versões do Suporte estendido do Amazon RDS para RDS para MySQL O conteúdo a seguir lista todas as versões do Suporte estendido do RDS para as versões do RDS para MySQL. **Topics** + [ ### RDS Extended Support para RDS para MySQL versão 5.7.44-RDS.20260212 ](#mysql-extended-support-releases-version-5.7.44-RDS.20260212) + [ ### RDS Extended Support para RDS para MySQL versão 5.7.44-RDS.20251212 ](#mysql-extended-support-releases-version-5.7.44-RDS.20251212) + [ ### RDS Extended Support para RDS para MySQL versão 5.7.44-RDS.20250818 ](#mysql-extended-support-releases-version-5.7.44-RDS.20250818) + [ ### Suporte estendido do RDS para RDS para MySQL versão 5.7.44-RDS.20250508 ](#mysql-extended-support-releases-version-5.7.44-20250508) + [ ### Suporte estendido do RDS para RDS para MySQL versão 5.7.44-RDS.20250213 ](#mysql-extended-support-releases-version-5.7.44-20250213) + [ ### Suporte estendido do RDS para RDS para MySQL versão 5.7.44-RDS.20250103 ](#mysql-extended-support-releases-version-5.7.44-20250103) + [ ### Suporte estendido do RDS para RDS para MySQL versão 5.7.44-RDS.20240808 ](#mysql-extended-support-releases-version-5.7.44-20240808) + [ ### Suporte estendido do RDS para RDS para MySQL versão 5.7.44-RDS.20240529 ](#mysql-extended-support-releases-version-5.7.44-20240529) + [ ### Suporte estendido do RDS para RDS para MySQL versão 5.7.44-RDS.20240408 ](#mysql-extended-support-releases-version-5.7.44-20240408) ### RDS Extended Support para RDS para MySQL versão 5.7.44-RDS.20260212 Suporte estendido do RDS para RDS para MySQL versão 5.7.44-RDS.20260212 está disponível. **Erros corrigidos:** + Atualização do certificado de teste usado para testar a correção do erro 22295186. + Correção de um vazamento de memória com índice de prefixo nas colunas do blob. **CVEs corrigidos:** + [CVE-2026-21936](https://nvd.nist.gov/vuln/detail/CVE-2026-21936) + [CVE-2026-21968](https://nvd.nist.gov/vuln/detail/CVE-2026-21968) + [CVE-2026-21941](https://nvd.nist.gov/vuln/detail/CVE-2026-21941) + [CVE-2026-21948](https://nvd.nist.gov/vuln/detail/CVE-2026-21948) ### RDS Extended Support para RDS para MySQL versão 5.7.44-RDS.20251212 Suporte estendido do RDS para RDS para MySQL versão 5.7.44-RDS.20251212 está disponível. **Erros corrigidos:** + Correção de um problema com a inicialização do servidor quando o tamanho do pool de buffer excedia o limite superior. + Correção da leitura de `INFORMATION_SCHEMA.INNODB_LOCKS` que fazia com que o servidor saísse de forma anormal. + Correção de um problema com o suporte a relatórios JUnit no MySQL Test Run (MTR). + Correção dos problemas de compilação que surgiam durante a criação com a opção `-DWITH_INNODB_MEMCACHED=ON`. + Correção de um problema com a execução do MySQL Test Run (MTR) para o bug 25182306. **CVEs corrigidos:** + [CVE-2025-53054](https://nvd.nist.gov/vuln/detail/CVE-2025-53054) + [CVE-2025-53044](https://nvd.nist.gov/vuln/detail/CVE-2025-53044) + [CVE-2025-53045](https://nvd.nist.gov/vuln/detail/CVE-2025-53045) + [CVE-2025-53062](https://nvd.nist.gov/vuln/detail/CVE-2025-53062) + [CVE-2025-53040](https://nvd.nist.gov/vuln/detail/CVE-2025-53040) + [CVE-2025-53042](https://nvd.nist.gov/vuln/detail/CVE-2025-53042) + [CVE-2025-53067](https://nvd.nist.gov/vuln/detail/CVE-2025-53067) ### RDS Extended Support para RDS para MySQL versão 5.7.44-RDS.20250818 Suporte estendido do RDS para RDS para MySQL versão 5.7.44-RDS.20250818 está disponível. **Erros corrigidos:** + Correção de um problema em que o plug-in de regravação de consultas falhava quando o servidor operava com `autocommit=OFF`. + Correção de um problema de permissão que impedia que as compilações do Debian e do Ubuntu fossem executadas no modo sem raiz. + Correção da falta de atualização para o bug 30875669. **CVEs corrigidos:** + [CVE-2025-50082](https://nvd.nist.gov/vuln/detail/CVE-2025-50082) + [CVE-2025-50083](https://nvd.nist.gov/vuln/detail/CVE-2025-50083) + [CVE-2025-50079](https://nvd.nist.gov/vuln/detail/CVE-2025-50079) + [CVE-2025-50084](https://nvd.nist.gov/vuln/detail/CVE-2025-50084) + [CVE-2025-50087](https://nvd.nist.gov/vuln/detail/CVE-2025-50087) + [CVE-2025-50091](https://nvd.nist.gov/vuln/detail/CVE-2025-50091) + [CVE-2025-50101](https://nvd.nist.gov/vuln/detail/CVE-2025-50101) + [CVE-2025-50102](https://nvd.nist.gov/vuln/detail/CVE-2025-50102) + [CVE-2025-50098](https://nvd.nist.gov/vuln/detail/CVE-2025-50098) + [CVE-2025-53023](hhttps://nvd.nist.gov/vuln/detail/CVE-2025-53023) + [CVE-2025-50081](https://nvd.nist.gov/vuln/detail/CVE-2025-50081) + [CVE-2025-50085](https://nvd.nist.gov/vuln/detail/CVE-2025-50085) + [CVE-2025-50077](https://nvd.nist.gov/vuln/detail/CVE-2025-50077) + [CVE-2025-50088](https://nvd.nist.gov/vuln/detail/CVE-2025-50088) + [CVE-2025-50092](https://nvd.nist.gov/vuln/detail/CVE-2025-50092) + [CVE-2025-50099](https://nvd.nist.gov/vuln/detail/CVE-2025-50099) + [CVE-2025-50096](https://nvd.nist.gov/vuln/detail/CVE-2025-50096) ### Suporte estendido do RDS para RDS para MySQL versão 5.7.44-RDS.20250508 Suporte estendido do RDS para RDS para MySQL versão 5.7.44-RDS.20250508 está disponível. **Erros corrigidos:** + Correção do índice virtual instável após a reversão quando `index_id` é maior que o máximo `uint32`. + Correção de falhas de teste com problema de memória. + Correção de `` está vazio para `Execute`. + Correção da compilação do MySQL com GCC 14 [noclose 5.7]. **CVEs corrigidos:** + [CVE-2025-30682](https://nvd.nist.gov/vuln/detail/CVE-2025-30682) + [CVE-2025-30687](https://nvd.nist.gov/vuln/detail/CVE-2025-30687) + [CVE-2025-30688](https://nvd.nist.gov/vuln/detail/CVE-2025-30688) + [CVE-2025-21581](https://nvd.nist.gov/vuln/detail/CVE-2025-21581) + [CVE-2025-21585](https://nvd.nist.gov/vuln/detail/CVE-2025-21585) + [CVE-2025-30689](https://nvd.nist.gov/vuln/detail/CVE-2025-30689) + [CVE-2025-30722](https://nvd.nist.gov/vuln/detail/CVE-2025-30722) + [CVE-2025-21577](https://nvd.nist.gov/vuln/detail/CVE-2025-21577) + [CVE-2025-30693](https://nvd.nist.gov/vuln/detail/CVE-2025-30693) + [CVE-2025-30695](https://nvd.nist.gov/vuln/detail/CVE-2025-30695) + [CVE-2025-30703](https://nvd.nist.gov/vuln/detail/CVE-2025-30703) ### Suporte estendido do RDS para RDS para MySQL versão 5.7.44-RDS.20250213 Suporte estendido do RDS para RDS para MySQL versão 5.7.44-RDS.20250213 está disponível. **Erros corrigidos:** + Correção da falha de declaração do InnoDB `result != FTS_INVALID`. + Correção da falha e corrupção generalizada de índices espaciais após a operação `ALTER TABLE` reconstruir a tabela do InnoDB usando o algoritmo `INPLACE`. + Correção de `ON DELETE CASCADE` com falhas de coluna geradas em `innobase_get_computed_value`. + Correção da falha de declaração em `row_MySQL_pad_col`. + Correção de um problema em que o DDL on-line causava o seguinte erro: `ERROR 1712 (HY000): Index PRIMARY is corrupted`. + Correção de falhas em `Item_rollup_sum_switcher::current_arg`. + Correção de um problema no qual o cache do banco de dados não era liberado em `DROP USER`. + Correção do estouro de buffer em `my_print_help`. + Correção de um problema do InnoDB em que o índice `FULLTEXT` limitava `FTS_DOC_ID` ao valor máximo de 32 bits não assinado. **CVEs corrigidos:** + [CVE-2025-21497](https://nvd.nist.gov/vuln/detail/CVE-2025-21497) + [CVE-2025-21555](https://nvd.nist.gov/vuln/detail/CVE-2025-21555) + [CVE-2025-21559](https://nvd.nist.gov/vuln/detail/CVE-2025-21559) + [CVE-2025-21490](https://nvd.nist.gov/vuln/detail/CVE-2025-21490) + [CVE-2025-21491](https://nvd.nist.gov/vuln/detail/CVE-2025-21491) + [CVE-2025-21500](https://nvd.nist.gov/vuln/detail/CVE-2025-21500) + [CVE-2025-21501](https://nvd.nist.gov/vuln/detail/CVE-2025-21501) + [CVE-2025-21540](https://nvd.nist.gov/vuln/detail/CVE-2025-21540) + [CVE-2025-21543](https://nvd.nist.gov/vuln/detail/CVE-2025-21543) + [CVE-2025-21520](https://nvd.nist.gov/vuln/detail/CVE-2025-21520) ### Suporte estendido do RDS para RDS para MySQL versão 5.7.44-RDS.20250103 O Suporte estendido do RDS para RDS para MySQL versão 5.7.44-RDS.20250103 está disponível. **Erros corrigidos:** + Correção do problema de limpeza de FTS ao descartar e adicionar um índice `FULLTEXT` na mesma transação. + Otimização do tempo de alocação de memória em clientes do MySQL para evitar possíveis vazamentos. + Correção do truncamento dos resultados em 34 bytes ao usar o operador `UNION`. + Correção da possibilidade de acesso fora dos limites devido a `ulong bitmask` no código de autorização. **CVEs corrigidos:** + [CVE-2024-21230](https://nvd.nist.gov/vuln/detail/CVE-2024-21230) + [CVE-2024-21201](https://nvd.nist.gov/vuln/detail/CVE-2024-21201) + [CVE-2024-21241](https://nvd.nist.gov/vuln/detail/CVE-2024-21241) + [CVE-2024-21203](https://nvd.nist.gov/vuln/detail/CVE-2024-21203) ### Suporte estendido do RDS para RDS para MySQL versão 5.7.44-RDS.20240808 Suporte estendido do RDS para RDS para MySQL versão 5.7.44-RDS.20240808 está disponível. **Erros corrigidos:** + Falha de afirmação corrigida relacionada ao índice da coluna do dicionário. + Problema corrigido com a função `is_binlog_cache_empty()`. + Erros `heap-use-after-free` corrigidos nos arquivos `sql/item.cc`. + Vários problemas de índice espacial foram corrigidos ao desativá-los para leituras `index-only`. + Problema de instrumentação corrigido com o plug-in `LOCK_ORDER: CONNECTION_CONTROL`. + Segmentos corrigidos que ficavam presos no plug-in `CONNECTION_CONTROL`. + Falta de atualização de `PSI_THREAD_INFO` para `PREPARED STATEMENTS` corrigida. + Processamento duplo corrigido de palavras-índice FTS com `innodb_optimize_fulltext_only`. **CVEs corrigidos:** + [CVE-2024-21177](https://nvd.nist.gov/vuln/detail/CVE-2024-21177) ### Suporte estendido do RDS para RDS para MySQL versão 5.7.44-RDS.20240529 O Suporte estendido do RDS para RDS para MySQL versão 5.7.44-RDS.20240529 está disponível. **Erros corrigidos:** + Correção de uma falha na declaração de `field.cc` implementando `fix_after_pullout`. + Correção de uma falha de ponteiro nulo ao retornar metadados ao cliente para determinadas consultas SQL. Essas consultas continham parâmetros dinâmicos e subconsultas em cláusulas `SELECT`. + Correção de resultados incorretos ao usar `GROUP BY` para varreduras de índice soltas ou varreduras de intervalos não contíguos de um índice. + Correção da perda de informações do GTID no MySQL durante a persistência. + Correção de uma condição de corrida que poderia fazer com que uma transação do InnoDB fosse interrompida indefinidamente. + Correção de uma condição de corrida na limpeza das informações de certificação do Group Replication. + Correção do problema de verificação reversa do índice com operações simultâneas de página. + Correção de um problema de estado de pesquisa de texto completo (FTS) inconsistente em cenários simultâneos. + Correção do problema de declaração com o buffer de alteração na exclusão de tabelas. + Comportamento unificado para chamar a função `deinit` em todos os tipos de plug-in. **CVEs corrigidos:** + [CVE-2024-20963](https://nvd.nist.gov/vuln/detail/CVE-2024-20963) + [CVE-2024-20993](https://nvd.nist.gov/vuln/detail/CVE-2024-20993) + [CVE-2024-20998](https://nvd.nist.gov/vuln/detail/CVE-2024-20998) + [CVE-2024-21009](https://nvd.nist.gov/vuln/detail/CVE-2024-21009) + [CVE-2024-21054](https://nvd.nist.gov/vuln/detail/CVE-2024-21054) + [CVE-2024-21055](https://nvd.nist.gov/vuln/detail/CVE-2024-21055) + [CVE-2024-21057](https://nvd.nist.gov/vuln/detail/CVE-2024-21057) + [CVE-2024-21062](https://nvd.nist.gov/vuln/detail/CVE-2024-21062) + [CVE-2024-21008](https://nvd.nist.gov/vuln/detail/CVE-2024-21008) + [CVE-2024-21013](https://nvd.nist.gov/vuln/detail/CVE-2024-21013) + [CVE-2024-21047](https://nvd.nist.gov/vuln/detail/CVE-2024-21047) + [CVE-2024-21087](https://nvd.nist.gov/vuln/detail/CVE-2024-21087) + [CVE-2024-21096](https://nvd.nist.gov/vuln/detail/CVE-2024-21096) ### Suporte estendido do RDS para RDS para MySQL versão 5.7.44-RDS.20240408 O Suporte estendido do RDS para RDS para MySQL versão 5.7.44-RDS.20240408 está disponível. Esta versão contém patches para os seguintes CVEs: + [CVE-2024-20963](https://nvd.nist.gov/vuln/detail/CVE-2024-20963) ## Trabalhar com o ambiente de visualização de banco de dados Em julho de 2023, a Oracle anunciou um novo modelo de lançamento para o MySQL. Esse modelo inclui dois tipos de lançamentos: lançamentos de inovação e lançamentos de LTS. O Amazon RDS disponibiliza lançamentos inovadores do MySQL no ambiente RDS Preview. Para saber mais sobre as versões do MySQL Innovation, consulte Apresentando as versões [MySQL Innovation e Long-Term Support (](https://blogs.oracle.com/mysql/post/introducing-mysql-innovation-and-longterm-support-lts-versions)LTS). As instâncias de banco de dados do RDS para PostgreSQL no Database Preview Environment são semelhantes às outras instâncias do RDS para PostgreSQL em termos de funcionalidade. No entanto, você não pode usar o ambiente Database Preview para cargas de trabalho de produção. Os ambientes prévios têm as seguintes limitações: + Todas as instâncias de banco de dados são excluídas 60 dias após serem criadas, juntamente com backups e snapshots. + Você só pode usar o SSD de uso geral e o armazenamento em SSD IOPS provisionadas. + Você não pode obter ajuda do Suporte para instâncias de banco de dados. Em vez disso, você pode postar suas perguntas na comunidade de perguntas e respostas gerenciadas pela AWS, o [AWS re:Post](https://repost.aws/tags/TAsibBK6ZeQYihN9as4S_psg/amazon-relational-database-service). + Não é possível copiar um snapshot de uma instância de banco de dados para um ambiente de produção. As opções a seguir são compatíveis com a visualização. + Você pode criar instâncias de banco de dados usando as classes de instância de banco de dados db.m6i, db.r6i, db.m6g, db.m5, db.t3, db.r6g e db.r5. Para obter mais informações sobre as classes de instância do RDS, consulte [Classes de instâncias de banco de dados do ](Concepts.DBInstanceClass.md). + Você pode usar implantações single-AZ e multi-AZ. + Você pode usar funções padrão de despejo e carregamento do PostgreSQL para exportar ou importar bancos de dados para o Database Preview Environment. ### Atributos não compatíveis com o ambiente de visualização de banco de dados Os atributos a seguir não estão disponíveis no ambiente de visualização de banco de dados: + Cópia de snapshots entre regiões + Réplicas de leitura entre regiões + RDS Proxy ### Criar uma nova instância de banco de dados no ambiente de visualização de banco de dados Você pode criar uma instância de banco de dados no ambiente Database Preview usando o Console de gerenciamento da AWSAWS CLI, a ou a API do RDS. #### Console **Para criar uma instância de banco de dados no ambiente de visualização de banco de dados** 1. Faça login no Console de gerenciamento da AWS e abra o console do Amazon RDS em [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/). 1. Escolha **Dashboard** (Painel) no painel de navegação. 1. Na página **Painel**, localize a seção **Ambiente de versão prévia do banco de dados**, conforme mostrado na imagem a seguir. ![\[A seção Ambiente de versão prévia do banco de dados com link no console do Amazon RDS.\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/UserGuide/images/preview-environment-dashboard.png) Você também pode navegar diretamente para o [Ambiente de visualização do banco de dados](https://us-east-2.console.aws.amazon.com/rds-preview/home?region=us-east-2#). Antes de continuar, você deve reconhecer e aceitar as limitações. ![\[A caixa de diálogo Acordo de Serviço do Ambiente de Versão Prévia do Banco de Dados para reconhecer as limitações.\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/UserGuide/images/preview-environment-console.png) 1. Para criar a instância de banco de dados do RDS para PostgreSQL, siga o mesmo processo de criação de qualquer instância de banco de dados do Amazon RDS. Para obter mais informações, consulte o procedimento [Console](USER_CreateDBInstance.md#USER_CreateDBInstance.CON) em [Criar uma instância de banco de dados](USER_CreateDBInstance.md#USER_CreateDBInstance.Creating). #### AWS CLI Para criar uma instância no ambiente de visualização do banco de dados usando a API do RDS ou a AWS CLI, use o endpoint a seguir. ``` rds-preview.us-east-2.amazonaws.com ``` Para criar a instância de banco de dados do RDS para PostgreSQL, siga o mesmo processo de criação de qualquer instância de banco de dados do Amazon RDS. Para obter mais informações, consulte o procedimento [AWS CLI](USER_CreateDBInstance.md#USER_CreateDBInstance.CLI) em [Criar uma instância de banco de dados](USER_CreateDBInstance.md#USER_CreateDBInstance.Creating). #### API do RDS Para criar uma instância no ambiente de visualização do banco de dados usando a API do RDS ou a , use o endpoint a seguir. ``` rds-preview.us-east-2.amazonaws.com ``` Para criar a instância de banco de dados do RDS para PostgreSQL, siga o mesmo processo de criação de qualquer instância de banco de dados do Amazon RDS. Para obter mais informações, consulte o procedimento [API do RDS](USER_CreateDBInstance.md#USER_CreateDBInstance.API) em [Criar uma instância de banco de dados](USER_CreateDBInstance.md#USER_CreateDBInstance.Creating). ## MySQL versão 9.5 no Ambiente de Pré-visualização do Banco de Dados O MySQL versão 9.5 já está disponível no Ambiente de Pré-visualização do Banco de Dados do Amazon RDS. A versão 9.5 contém várias melhorias descritas em [Alterações no MySQL 9.5.0](https://dev.mysql.com/doc/relnotes/mysql/9.5/en/news-9-5-0.html). Para obter informações sobre o ambiente de visualização de banco de dados, consulte [Trabalhar com o ambiente de visualização de banco de dados](#mysql-working-with-the-database-preview-environment). Para acessar o ambiente de visualização do console, selecione [https://console.aws.amazon.com/rds-preview/](https://console.aws.amazon.com/rds-preview/). ## MySQL versão 9.4 no Ambiente de Pré-visualização do Banco de Dados O MySQL versão 9.4 já está disponível no Ambiente de Pré-visualização do Banco de Dados do Amazon RDS. A versão 9.4 contém várias melhorias descritas em [Alterações no MySQL 9.4.0](https://dev.mysql.com/doc/relnotes/mysql/9.4/en/news-9-4-0.html). Para obter informações sobre o ambiente de visualização de banco de dados, consulte [Trabalhar com o ambiente de visualização de banco de dados](#mysql-working-with-the-database-preview-environment). Para acessar o ambiente de visualização do console, selecione [https://console.aws.amazon.com/rds-preview/](https://console.aws.amazon.com/rds-preview/). ## MySQL versão 9.3 no Ambiente de Pré-visualização do Banco de Dados O MySQL versão 9.3 já está disponível no Ambiente de Pré-visualização do Banco de Dados do Amazon RDS. O MySQL versão 9.3 contém várias melhorias descritas em [Alterações no MySQL 9.3.0](https://dev.mysql.com/doc/relnotes/mysql/9.3/en/news-9-3-0.html). Para obter informações sobre o ambiente de visualização de banco de dados, consulte [Trabalhar com o ambiente de visualização de banco de dados](#mysql-working-with-the-database-preview-environment). Para acessar o ambiente de visualização do console, selecione [https://console.aws.amazon.com/rds-preview/](https://console.aws.amazon.com/rds-preview/). ## Versões obsoletas do Amazon RDS para MySQL As versões 5.1, 5.5 e 5.6 do Amazon RDS para MySQL estão obsoletas. As versões 9.1 e 9.2 do Amazon RDS para MySQL foram descontinuadas no Ambiente de versão prévia do banco de dados. Para obter informações sobre a política de defasagem do Amazon RDS para MySQL, consulte [Perguntas frequentes sobre o Amazon RDS](https://aws.amazon.com/rds/faqs/). # Conectar-se à instância de banco de dados do MySQL Antes de poder se conectar a uma instância de banco de dados executando o mecanismo de banco de dados do MySQL, você deve criar uma instância de banco de dados. Para ter mais informações, consulte [Criar uma instância de banco de dados do Amazon RDS](USER_CreateDBInstance.md). Depois que o Amazon RDS provisionar a sua instância de banco de dados, será possível usar qualquer aplicativo ou utilitário cliente MySQL padrão para se conectar à instância. Na string de conexão, você especifica o endereço DNS do endpoint da instância de banco de dados como o parâmetro de host e especifica o número da porta a partir desse endpoint como o parâmetro de porta. Para autenticar-se na instância de banco de dados do RDS, você pode usar um dos métodos para autenticação do MySQL e a autenticação de banco de dados do AWS Identity and Access Management (IAM): + Para saber como fazer a autenticação no MySQL usando um dos métodos de autenticação do MySQL, consulte [ Método de autenticação](https://dev.mysql.com/doc/internals/en/authentication-method.html) na documentação do MySQL. + Para saber como fazer a autenticação no MySQL usando a autenticação de banco de dados do IAM, consulte [Autenticação do banco de dados do IAMpara MariaDB, MySQL e PostgreSQL](UsingWithRDS.IAMDBAuth.md). Você pode se conectar a uma instância de banco de dados MySQL com ferramentas como o cliente MySQL de linha de comando do . Para ter mais informações sobre como usar o cliente MySQL de linha de comando, acesse [mysql - the MySQL command-line client](https://dev.mysql.com/doc/refman/8.0/en/mysql.html) na documentação do MySQL. O MySQL Workbench é um aplicativo baseado em GUI que você pode usar para se conectar. Para ter mais informações, consulte a página [Download MySQL Workbench](http://dev.mysql.com/downloads/workbench/). Para obter informações sobre como instalar o MySQL (incluindo o cliente MySQL de linha de comando), consulte [Installing and upgrading MySQL](https://dev.mysql.com/doc/refman/8.0/en/installing.html) (Instalar e atualizar o MySQL). Para se conectar a uma instância de banco de dados de fora de sua Amazon VPC, a instância de banco de dados deve ser acessível ao público geral, o acesso deve ser concedido usando as regras de entrada do grupo de segurança da instância de banco de dados e outros requisitos devem ser atendidos. Para ter mais informações, consulte [Não é possível conectar-se à instância de banco de dados do Amazon RDS](CHAP_Troubleshooting.md#CHAP_Troubleshooting.Connecting). Você pode usar a criptografia Secure Sockets Layer (SSL) ou Transport Layer Security (TLS) em conexões com uma instância de banco de dados do MySQL. Para ter mais informações, consulte [Suporte do SSL/TLS para instâncias de banco de dados do MySQL no Amazon RDS](MySQL.Concepts.SSLSupport.md). Se você estiver usando a autenticação de banco de dados do AWS Identity and Access Management (IAM), use uma conexão SSL/TLS. Para ter mais informações, consulte [Autenticação do banco de dados do IAMpara MariaDB, MySQL e PostgreSQL](UsingWithRDS.IAMDBAuth.md). Também é possível se conectar a uma instância de banco de dados a partir de um servidor web. Para ter mais informações, consulte [Tutorial: crie um servidor Web e uma instância de banco de dados do Amazon RDS](TUT_WebAppWithRDS.md). **nota** Para obter informações sobre a conexão a uma instância de banco de dados MariaDB, consulte [Conectar-se à instância de banco de dados do MariaDB](USER_ConnectToMariaDBInstance.md). Para encontrar uma instância de banco de dados do RDS para MySQL e conectar-se a ela, consulte os tópicos a seguir. **Topics** + [ # Localizar as informações de conexão para uma instância de banco de dados do RDS para MySQL ](USER_ConnectToInstance.EndpointAndPort.md) + [ # Instalar o cliente de linha de comando do MySQL ](mysql-install-cli.md) + [ # Conectar-se pelo cliente de linha de comandos do MySQL (não criptografado) ](USER_ConnectToInstance.CLI.md) + [ # Conexão pelo MySQL Workbench ](USER_ConnectToInstance.MySQLWorkbench.md) + [ # Conectar-se ao RDS para MySQL com o driver JDBC da AWS, o driver Python da AWS e o driver ODBC da AWS para MySQL ](MySQL.Connecting.Drivers.md) + [ # Solução de problemas de conexões com a instância de banco de dados MySQL ](USER_ConnectToInstance.Troubleshooting.md) # Localizar as informações de conexão para uma instância de banco de dados do RDS para MySQL As informações de conexão de uma instância de banco de dados incluem seu endpoint, porta e um usuário de banco de dados válido, como o usuário mestre. Por exemplo, suponha que um valor de endpoint seja `mydb.123456789012.us-east-1.rds.amazonaws.com`. Nesse caso, o valor da porta é `3306`, e o usuário do banco de dados é `admin`. Com essas informações, você especifica os seguintes valores em uma string de conexão: + Para o host, nome de host ou nome DNS, especifique `mydb.123456789012.us-east-1.rds.amazonaws.com`. + Para a porta, especifique `3306`. + Para usuário, especifique `admin`. Para se conectar a uma instância de banco de dados, use qualquer cliente para um mecanismo de banco de dados do MySQL. Por exemplo, você pode usar o cliente MySQL de linha de comando ou o MySQL Workbench. Para localizar as informações de conexão de uma instância de banco de dados, você pode usar o Console de gerenciamento da AWS, comando da AWS CLI [describe-db-instances](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-instances.html) ou a operação da API do Amazon RDS [DescribeDBInstances](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBInstances.html) para listar seus detalhes. ## Console **Para encontrar as informações de conexão de uma instância de banco de dados no Console de gerenciamento da AWS** 1. Faça login no Console de gerenciamento da AWS e abra o console do Amazon RDS em [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/). 1. No painel de navegação, escolha **Bancos de dados** para exibir uma lista de suas instâncias de banco de dados. 1. Escolha o nome da instância de banco de dados MySQL para exibir os detalhes. 1. Na guia **Connectivity & security (Conectividade e segurança)**, copie o endpoint. Além disso, anote o número da porta. Você precisará do endpoint e do número da porta para conectar-se à instância de banco de dados. ![\[O endpoint e a porta de uma instância de banco de dados no console do Amazon RDS.\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/UserGuide/images/endpoint-port.png) 1. Se você precisar encontrar o nome de usuário mestre, escolha a guia **Configuração** e visualize o valor do nome de **usuário mestre** . ## AWS CLI Para localizar as informações de conexão de uma instância de banco de dados MySQL usando a AWS CLI, execute o comando [describe-db-instances](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-instances.html). Na chamada, consulte o ID da instância de banco de dados, o endpoint, a porta e o nome de usuário mestre. Para Linux, macOS ou Unix: ``` aws rds describe-db-instances \ --filters "Name=engine,Values=mysql" \ --query "*[].[DBInstanceIdentifier,Endpoint.Address,Endpoint.Port,MasterUsername]" ``` Para Windows: ``` aws rds describe-db-instances ^ --filters "Name=engine,Values=mysql" ^ --query "*[].[DBInstanceIdentifier,Endpoint.Address,Endpoint.Port,MasterUsername]" ``` Sua saída deve ser similar à seguinte. ``` [ [ "mydb1", "mydb1.123456789012.us-east-1.rds.amazonaws.com", 3306, "admin" ], [ "mydb2", "mydb2.123456789012.us-east-1.rds.amazonaws.com", 3306, "admin" ] ] ``` ## API do RDS Para localizar as informações de conexão de uma instância de banco de dados usando a Amazon RDS API, chame a operação [DescribeDBInstances](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBInstances.html) . Na saída, encontre os valores para o endereço do endpoint, a porta do endpoint e o nome do usuário mestre. # Instalar o cliente de linha de comando do MySQL A maioria das distribuições do Linux inclui o cliente MariaDB em vez do cliente Oracle MySQL. Para instalar o cliente da linha de comando do MySQL no Amazon Linux 2023, execute o seguinte comando: ``` sudo dnf install mariadb105 ``` Para instalar o cliente da linha de comando do MySQL no Amazon Linux 2, execute o seguinte comando: ``` sudo yum install mariadb ``` Para instalar o cliente MySQL de linha de comando na maioria das distribuições do Linux baseadas em DEB, execute o seguinte comando: ``` apt-get install mariadb-client ``` Para verificar a versão do cliente MySQL de linha de comando, execute o seguinte comando: ``` mysql --version ``` Para ler a documentação da versão atual do cliente MySQL, execute o seguinte comando: ``` man mysql ``` # Conectar-se pelo cliente de linha de comandos do MySQL (não criptografado) **Importante** Use uma conexão MySQL não criptografada apenas quando o cliente e o servidor estiverem na mesma VPC e a rede for confiável. Para obter informações sobre como usar conexões criptografadas, consulte [Conectar-se à instância de banco de dados do MySQL no Amazon RDS com SSL/TLS por meio do cliente de linha de comandos do MySQL (criptografado)](USER_ConnectToInstanceSSL.CLI.md). Para se conectar a uma instância de banco de dados usando o cliente de linha de comando MySQL, insira o comando a seguir no prompt de comando. Para o parâmetro -h, substitua o nome do DNS (endpoint) da instância de banco de dados. Para o parâmetro -P, substitua a porta para sua instância de banco de dados. Para o parâmetro -u, substitua o nome de usuário de um usuário de banco de dados válido, como o usuário mestre. Digite a senha do usuário mestre quando lhe for solicitado. ``` mysql -h mysql–instance1.123456789012.us-east-1.rds.amazonaws.com -P 3306 -u mymasteruser -p ``` Depois de inserir a senha do usuário, você deverá ver uma saída semelhante à seguinte. ``` Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 9738 Server version: 8.0.28 Source distribution Type 'help;' or '\h' for help. Type '\c' to clear the buffer. mysql> ``` # Conexão pelo MySQL Workbench **Para se conectar pelo MySQL Workbench** 1. Faça download do MySQL Workbench em [Download do MySQL Workbench](http://dev.mysql.com/downloads/workbench/) e instale-o em seguida. 1. Abra o MySQL Workbench. ![\[A tela de boas-vindas no MySQL Workbench.\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/UserGuide/images/mysql-workbench-main.png) 1. Em **Banco de dados**, escolha **Gerenciar conexões**. 1. Na janela **Gerenciar conexões de servidor**, escolha **Novo**. 1. Na janela **Conectar-se ao banco de dados**, insira as seguintes informações: + **Conexão armazenada** – insira um nome para a conexão, como **MyDB**. + **Nome do host** – insira o endpoint da instância de banco de dados. + **Porta** – insira a porta usada pela instância de banco de dados. + **Nome de usuário ** – insira o nome de usuário de um usuário de banco de dados válido, como o usuário mestre. + **Senha** – opcionalmente, escolha **Armazenar no cofre** e depois insira e salve a senha do usuário. A janela é semelhante à seguinte: ![\[A janela Gerenciar conexões do servidor no MySQL Workbench.\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/UserGuide/images/mysql-workbench-connect.png) É possível usar os recursos do MySQL Workbench para personalizar conexões. Por exemplo, é possível usar a guia **SSL** para configurar conexões SSL/TLS. Para obter informações sobre como usar o MySQL Workbench, consulte a [Documentação do MySQL Workbench](https://dev.mysql.com/doc/workbench/en/). Para criptografar conexões de clientes com instâncias de banco de dados do MySQL com SSL/TLS, consulte [Criptografar conexões de clientes com SSL/TLS para instâncias de banco de dados do MySQL no Amazon RDS](mysql-ssl-connections.md). 1. Opcionalmente, escolha **Testar conexão** para confirmar se a conexão com a instância de banco de dados foi bem-sucedida. 1. Escolha **Fechar**. 1. Em **Banco de dados**, escolha **Conectar-se ao banco de dados**. 1. Em **Conexão armazenada**, escolha sua conexão. 1. Escolha **OK**. # Conectar-se ao RDS para MySQL com o driver JDBC da AWS, o driver Python da AWS e o driver ODBC da AWS para MySQL Conecte-se a instâncias de banco de dados do RDS para MySQL com o driver JDBC da AWS, o driver Python da AWS e o driver ODBC da AWS para MySQL. Para obter mais informações, consulte os tópicos a seguir. **Topics** + [ ## Conectar-se ao RDS para MySQL com o driver JDBC da Amazon Web Services (AWS) ](#MySQL.Connecting.JDBCDriver) + [ ## Conectar-se ao RDS para MySQL com o driver Python da Amazon Web Services (AWS) ](#MySQL.Connecting.PythonDriver) + [ ## Conectar-se ao RDS para MySQL com o Driver ODBC da Amazon Web Services (AWS) para MySQL ](#USER_ConnectToInstance.ODBCDriverMySQL) ## Conectar-se ao RDS para MySQL com o driver JDBC da Amazon Web Services (AWS) O driver JDBC da Amazon Web Services (AWS) foi projetado como um wrapper JDBC avançado. Esse wrapper é complementar e amplia a funcionalidade do driver JDBC existente. O driver é compatível de forma intercambiável com os drivers MySQL Connector/J e MariaDB Connector/J da comunidade. Para instalar o driver JDBC da AWS, anexe o arquivo .jar do driver JDBC da AWS (localizado na aplicação `CLASSPATH`) e mantenha referências ao respectivo driver da comunidade. Atualize o respectivo prefixo do URL de conexão da seguinte forma: + `jdbc:mysql://` para `jdbc:aws-wrapper:mysql://` + `jdbc:mariadb://` para `jdbc:aws-wrapper:mariadb://` Consulte mais informações sobre o driver JDBC da AWS e siga as instruções para usá-lo em [Amazon Web Services (AWS) JDBC Driver GitHub repository](https://github.com/awslabs/aws-advanced-jdbc-wrapper). ## Conectar-se ao RDS para MySQL com o driver Python da Amazon Web Services (AWS) O driver Python da Amazon Web Services (AWS) foi projetado como um wrapper Python avançado. Esse wrapper é complementar e amplia a funcionalidade do driver Psycopg de código aberto. O driver Python da AWS é compatível com as versões 3.8 e posterior do Python. É possível instalar o pacote `aws-advanced-python-wrapper` usando o comando `pip`, bem como os pacotes de código aberto `psycopg`. Para ter mais informações sobre o driver Python da AWS e instruções completas para usá-lo, consulte [Amazon Web Services (AWS) Python Driver GitHub repository](https://github.com/awslabs/aws-advanced-python-wrapper). ## Conectar-se ao RDS para MySQL com o Driver ODBC da Amazon Web Services (AWS) para MySQL O Driver ODBC da AWS para MySQL é um driver de cliente projetado para a alta disponibilidade do RDS para MySQL. O driver pode existir junto com o driver MySQL Connector/ODBC e é compatível com os mesmos fluxos de trabalho. Para ter mais informações sobre o driver ODBC da AWS para MySQL e instruções completas de uso e instalação, consulte o diretório do GitHub [Amazon Web Services (AWS) ODBC Driver for MySQL](https://github.com/aws/aws-mysql-odbc). # Solução de problemas de conexões com a instância de banco de dados MySQL Duas causas comuns de falhas de conexão a uma nova instância de banco de dados são: + A instância de banco de dados foi criada usando um grupo de segurança que não autoriza conexões do dispositivo ou da instância do Amazon EC2 em que o aplicativo ou utilitário do MySQL está sendo executado. A instância de banco de dados deve ter um grupo de segurança de VPC que autorize as conexões. Para ter mais informações, consulte [Amazon VPC e Amazon RDS](USER_VPC.md). É possível adicionar ou editar uma regra de entrada no grupo de segurança. Em **Source (Origem)**, selecione **My IP (Meu IP)**. Isso concede acesso à instância de banco de dados do endereço IP detectado no navegador. + A instância de banco de dados foi criada usando a porta padrão 3306 e sua empresa emprega regras de firewall bloqueando conexões a essa porta a partir de dispositivos na rede de sua empresa. Para corrigir essa falha, recrie a instância com uma porta diferente. Para ter mais informações sobre problemas de conexão, consulte [Não é possível conectar-se à instância de banco de dados do Amazon RDS](CHAP_Troubleshooting.md#CHAP_Troubleshooting.Connecting). # Proteger as conexões de instância de banco de dados do MySQL Você pode implementar medidas robustas de segurança para proteger as instâncias de banco de dados do MySQL contra acesso não autorizado e possíveis ameaças. Grupos de segurança, criptografia SSL/TLS e autenticação de banco de dados do IAM funcionam juntos para criar várias camadas de segurança de conexão para instâncias de banco de dados do MySQL. Esses controles de segurança ajudam você a atender aos requisitos de conformidade, evitar violações de dados e manter canais de comunicação seguros entre aplicações e bancos de dados. Você pode proteger suas instâncias de banco de dados do MySQL criptografando dados em trânsito, restringindo o acesso a intervalos de IP específicos e gerenciando a autenticação de usuários por meio de perfis do IAM em vez de senhas de banco de dados. A segurança de instâncias de bancos de dados MySQL é gerenciada em três níveis: + O AWS Identity and Access Management controla quem pode executar ações de gerenciamento do Amazon RDS em instâncias de banco de dados. Ao se conectar à AWS usando credenciais do IAM, sua conta do IAM deve ter políticas do IAM que concedam as permissões necessárias para executar operações de gerenciamento do Amazon RDS. Para ter mais informações, consulte [Gerenciamento de identidade e acesso no Amazon RDS](UsingWithRDS.IAM.md). + Quando você cria uma instância de banco de dados, é necessário usar um grupo de segurança da VPC para controlar quais dispositivos e instâncias do Amazon EC2 podem abrir conexões com o endpoint e a porta da instância de banco de dados. É possível estabelecer essas conexões usando o Transport Layer Security (TLS) e o Secure Sockets Layer (SSL). Além disso, as regras de firewall em sua empresa podem controlar se dispositivos sendo executados nela podem abrir conexões na instância de banco de dados. + Para autenticar o login e as permissões para uma instância de banco de dados do MySQL, você pode adotar uma das seguintes abordagens ou uma combinação delas: + Você pode seguir a mesma abordagem de uma instância autônoma do MySQL. Comandos, como `CREATE USER`, `RENAME USER`, `GRANT`, `REVOKE` e `SET PASSWORD` funcionam exatamente como em bancos de dados locais, assim como modificando diretamente tabelas de esquema de banco de dados. No entanto, modificar diretamente as tabelas do esquema do banco de dados não é prática recomendada e, desde o RDS para MySQL versão 8.0.36, isso não é aceito. Para obter informações, consulte [ Access control and account management](https://dev.mysql.com/doc/refman/8.0/en/access-control.html) na documentação do MySQL. + Você também pode usar a autenticação de banco de dados do IAM. Com a autenticação de banco de dados do IAM, é possível autenticar sua instância de banco de dados usando um usuário do IAM ou um perfil do IAM e um token de autenticação. Um *token de autenticação* é um valor exclusivo, gerado usando o processo de assinatura Signature Version 4. Ao usar a autenticação de banco de dados do IAM, você pode usar as mesmas credenciais para controlar o acesso aos seus recursos e bancos de dados da AWS. Para ter mais informações, consulte [Autenticação do banco de dados do IAMpara MariaDB, MySQL e PostgreSQL](UsingWithRDS.IAMDBAuth.md). + Outra opção é a autenticação Kerberos para RDS para MySQL. A instância de banco de dados funciona com o AWS Directory Service for Microsoft Active Directory (AWS Managed Microsoft AD) para habilitar a autenticação Kerberos. Quando os usuários são autenticados por uma instância de banco de dados MySQL associada ao domínio de confiança, as solicitações de autenticação são encaminhadas. As solicitações encaminhadas vão para o diretório de domínio que você cria com o Directory Service. Para ter mais informações, consulte [Uso da autenticação do Kerberos para o Amazon RDS para MySQL](mysql-kerberos.md). Quando você cria uma instância de banco de dados do Amazon RDS, o usuário mestre apresenta os seguintes privilégios padrão: | Versão do mecanismo | Privilégio do sistema | Função do banco de dados | | --- | --- | --- | | RDS para MySQL versão 8.4.3 e posterior | `GRANT SELECT`, `INSERT`, `UPDATE`, `DELETE`, `CREATE`, `DROP`, `RELOAD`, `PROCESS`, `REFERENCES`,`INDEX`, `ALTER`, `SHOW DATABASES`, `CREATE TEMPORARY TABLES`, `LOCK TABLES`, `EXECUTE`, `REPLICATION SLAVE`, `REPLICATION CLIENT`, `CREATE VIEW`, `SHOW VIEW`, `CREATE ROUTINE`, `ALTER ROUTINE`, `CREATE USER`, `EVENT`, `TRIGGER`, `CREATE ROLE`, `DROP ROLE`, `APPLICATION_PASSWORD_ADMIN`, `FLUSH_OPTIMIZER_COSTS`, `FLUSH_PRIVILEGES`, `FLUSH_STATUS`, `FLUSH_TABLES`, `FLUSH_USER_RESOURCES`, `ROLE_ADMIN`, `SENSITIVE_VARIABLES_OBSERVER`, `SESSION_VARIABLES_ADMIN`, `SET_ANY_DEFINER`, `SHOW_ROUTINE`, `XA_RECOVER_ADMIN` | `rds_superuser_role` Para obter mais informações sobre o `rds_superuser_role`, consulte [Modelo de privilégios baseados em perfis para o RDS para MySQL](Appendix.MySQL.CommonDBATasks.privilege-model.md). | | RDS para MySQL versão 8.0.36 e posterior | `SELECT`, `INSERT`, `UPDATE`, `DELETE`, `CREATE`, `DROP`, `RELOAD`, `PROCESS`, `REFERENCES`, `INDEX`, `ALTER`, `SHOW DATABASES`, `CREATE TEMPORARY TABLES`, `LOCK TABLES`, `EXECUTE`, `REPLICATION SLAVE`, `REPLICATION CLIENT`, `CREATE VIEW`, `SHOW VIEW`, `CREATE ROUTINE`, `ALTER ROUTINE`, `CREATE USER`, `EVENT`, `TRIGGER`, `CREATE ROLE`, `DROP ROLE`, `APPLICATION_PASSWORD_ADMIN`, `ROLE_ADMIN`, `SET_USER_ID`, `XA_RECOVER_ADMIN` | `rds_superuser_role` Para obter mais informações sobre o `rds_superuser_role`, consulte [Modelo de privilégios baseados em perfis para o RDS para MySQL](Appendix.MySQL.CommonDBATasks.privilege-model.md). | | Versões do RDS para MySQL anteriores à 8.0.36 | `SELECT`, `INSERT`, `UPDATE`, `DELETE`, `CREATE`, `DROP`, `RELOAD`, `PROCESS`, `REFERENCES`, `INDEX`, `ALTER`, `SHOW DATABASES`, `CREATE TEMPORARY TABLES`, `LOCK TABLES`, `EXECUTE`, `REPLICATION CLIENT`, `CREATE VIEW`, `SHOW VIEW`, `CREATE ROUTINE`, `ALTER ROUTINE`, `CREATE USER`, `EVENT`, `TRIGGER`, `REPLICATION SLAVE` | Nenhum | **nota** Embora seja possível excluir o usuário mestre na instância de banco de dados, isso não é recomendado. Para recriar o usuário mestre, use a operação da API do RDS [ModifyDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html) ou execute o comando da AWS CLI [modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html) e especifique uma nova senha de usuário mestre com o parâmetro apropriado. Se o usuário mestre não existir na instância, ele será criado com a senha especificada. Para fornecer serviços de gerenciamento para cada instância de banco de dados, o usuário `rdsadmin` é criado quando a instância de banco de dados é criada. Tentar descartar, renomear ou alterar a senha, ou alterar os privilégios da conta `rdsadmin` resultará em um erro. Para permitir o gerenciamento da instância de banco de dados, os comandos `kill` e `kill_query` padrão foram restritos. Os comandos do Amazon RDS `rds_kill` e `rds_kill_query` são fornecidos para permitir encerrar sessões ou consultas de usuários em instâncias de banco de dados. # Validação de senhas do RDS para MySQL O MySQL fornece o plugin `validate_password` para maior segurança. O plugin impõe políticas de senha usando parâmetros no grupo de parâmetro de banco de dados para sua instância de banco de dados do MySQL. O plugin tem suporte para instâncias de banco de dados que executam o MySQL versão 5.7, 8.0 e 8.4. Para obter mais informações sobre o plugin `validate_password`, consulte [The Password Validation Plugin](https://dev.mysql.com/doc/refman/5.7/en/validate-password.html) na documentação do MySQL. **Para habilitar o plugin `validate_password` para uma instância de banco de dados do MySQL** 1. Conecte-se à instância de banco de dados do MySQL e execute o comando a seguir. ``` INSTALL PLUGIN validate_password SONAME 'validate_password.so'; ``` 1. Configure os parâmetros para o plugin no grupo de parâmetros de banco de dados usado pela instância de banco de dados. Para obter mais informações sobre os parâmetros, consulte [Opções e variáveis do plug-in de validação de senha](https://dev.mysql.com/doc/refman/5.7/en/validate-password-options-variables.html) na documentação do MySQL. Para obter informações sobre como modificar parâmetros de instâncias de banco de dados, consulte [Modificar parâmetros em um grupo de parâmetros de banco de dados no Amazon RDS](USER_WorkingWithParamGroups.Modifying.md). 1. Reinicie a instância de banco de dados. Depois de habilitar o plugin `validate_password`, redefina as senhas existentes para que elas estejam em conformidade com suas novas políticas de validação. Sua instância de banco de dados do MySQL gerencia a validação de senha para o Amazon RDS. Para alterar uma senha, primeiro envie uma solicitação de atualização de senha por meio do Console de Gerenciamento da AWS, do comando da CLI `modify-db-instance` ou da operação de API `ModifyDBInstance`. Inicialmente, o RDS aceita sua solicitação, mesmo que a senha não atenda às suas políticas. Depois, o RDS processa a solicitação de forma assíncrona. Ele atualizará a senha na sua instância de banco de dados do MySQL somente se a senha atender às suas políticas definidas. Se a senha não atender a essas políticas, o RDS manterá a senha existente e registrará em log um evento de erro. ``` Unable to reset your password. Error information: Password failed to meet validation rules. ``` Para obter mais informações sobre eventos do Amazon RDS, consulte [Trabalhar com a notificação de eventos do Amazon RDS](USER_Events.md). # Criptografar conexões de clientes com SSL/TLS para instâncias de banco de dados do MySQL no Amazon RDS O Secure Sockets Layer (SSL) é um protocolo padrão do setor para proteger as conexões de rede entre o cliente e o servidor. Após o SSL versão 3.0, o nome mudou para Transport Layer Security (TLS). O Amazon RDS é compatível com criptografia SSL/TLS para instâncias de banco de dados do MySQL. Usando o SSL/TLS, você pode criptografar uma conexão entre seu cliente de aplicação e sua instância de banco de dados do MySQL. A compatibilidade com SSL/TLS está disponível em todas as Regiões da AWS para MySQL. Com o Amazon RDS, é possível proteger dados em trânsito criptografando conexões de clientes com instâncias de banco de dados do MySQL por meio de SSL/TLS, exigindo SSL/TLS para todas as conexões com uma instância de banco de dados do MySQL e conectando-se pelo cliente da linha de comandos do MySQL com SSL/TLS (criptografado). As seções a seguir fornecem orientações sobre como configurar e utilizar a criptografia SSL/TLS para instâncias de banco de dados do MySQL no Amazon RDS. **Topics** + [ # Suporte do SSL/TLS para instâncias de banco de dados do MySQL no Amazon RDS ](MySQL.Concepts.SSLSupport.md) + [ # Exigir SSL/TLS para contas de usuário específicas em uma instância de banco de dados do MySQL no Amazon RDS ](mysql-ssl-connections.require-ssl-users.md) + [ # Exigir SSL/TLS para todas as conexões com uma instância de banco de dados do MySQL no Amazon RDS ](mysql-ssl-connections.require-ssl.md) + [ # Conectar-se à instância de banco de dados do MySQL no Amazon RDS com SSL/TLS por meio do cliente de linha de comandos do MySQL (criptografado) ](USER_ConnectToInstanceSSL.CLI.md) # Suporte do SSL/TLS para instâncias de banco de dados do MySQL no Amazon RDS O Amazon RDS cria um certificado SSL/TLS e instala o certificado na instância de banco de dados quando o Amazon RDS provisionar a instância. Esses certificados são assinados por uma autoridade de certificado. O certificado SSL/TLS inclui o endpoint da instância de banco de dados como o nome comum (CN) do certificado SSL/TLS para se proteger contra ataques de falsificação. Um certificado SSL/TLS criado pelo Amazon RDS é a entidade raiz confiável e deve funcionar na maioria dos casos, mas poderá falhar se a aplicação não aceitar cadeias de certificados. Se a aplicação não aceitar cadeias de certificados, tente usar um certificado intermediário para se conectar à Região da AWS. Por exemplo, é necessário usar um certificado intermediário para se conectar às regiões AWS GovCloud (US) com SSL/TLS. Para obter informações sobre como baixar certificados, consulte [Usar SSL/TLS para criptografar uma conexão com uma instância ou um cluster de banco de dados](UsingWithRDS.SSL.md). Para obter mais informações sobre como usar o SSL/TLS com o MySQL, consulte [Atualizar aplicações para conexão com instâncias de banco de dados MySQL usando novos certificados SSL/TLS](ssl-certificate-rotation-mysql.md). Para o MySQL versão 8.0 e anteriores, o Amazon RDS para MySQL usa o OpenSSL para conexões seguras. Para o MySQL versão 8.4 e posterior, o Amazon RDS para MySQL usa a AWS-LC. O suporte ao TLS depende da versão do MySQL. A tabela a seguir mostra o suporte a TLS para as versões do MySQL. | Versão do MySQL | TLS 1.0 | TLS 1.1 | TLS 1.2 | TLS 1.3 | | --- | --- | --- | --- | --- | | MySQL 8.4 | Não suportado | Não suportado | Compatível | Compatível | | MySQL 8.0 | Não suportado | Não suportado | Compatível | Compatível | | MySQL 5.7 | Compatível | Compatível | Compatível | Não compatível | # Exigir SSL/TLS para contas de usuário específicas em uma instância de banco de dados do MySQL no Amazon RDS É possível exigir criptografia SSL/TLS para conexões de contas de usuário especificadas com as instâncias de banco de dados do MySQL no Amazon RDS. Proteger informações confidenciais contra acesso não autorizado ou interceptação é crucial para aplicar políticas de segurança nas quais a confidencialidade dos dados é uma questão importante. Se deseja exigir conexões SSL/TLS para contas de usuários específicos, siga uma das instruções abaixo (dependendo da versão do MySQL) para exigir conexões SSL/TLS na conta de usuário `encrypted_user`. Para fazer isso, use a instrução a seguir. ``` ALTER USER 'encrypted_user'@'%' REQUIRE SSL; ``` Para obter mais informações sobre conexões SSL/TLS com MySQL, consulte [ Using encrypted connections](https://dev.mysql.com/doc/refman/8.0/en/encrypted-connections.html) (Usar conexões criptografadas) na documentação do MySQL. # Exigir SSL/TLS para todas as conexões com uma instância de banco de dados do MySQL no Amazon RDS Use o parâmetro `require_secure_transport` para exigir que todas as conexões de usuários à sua instância de banco de dados do MySQL usem SSL/TLS. Por padrão, o parâmetro `require_secure_transport` é definido como `OFF`. Você pode definir o parâmetro `require_secure_transport` como `ON` para exigir SSL/TLS para conexões com a sua instância de banco de dados. Você pode definir o valor de parâmetro `require_secure_transport` atualizando o grupo de parâmetros do banco de dados de sua instância de banco de dados. Você não precisa reinicializar sua instância de banco de dados para que a alteração entre em vigor. Quando o parâmetro `require_secure_transport` é definido como `ON` para uma instância de banco de dados, um cliente de banco de dados poderá se conectar a ela se puder estabelecer uma conexão criptografada. Caso contrário, uma mensagem de erro semelhante à seguinte é retornada para o cliente: ``` MySQL Error 3159 (HY000): Connections using insecure transport are prohibited while --require_secure_transport=ON. ``` Para obter informações sobre como configurar parâmetros, consulte [Modificar parâmetros em um grupo de parâmetros de banco de dados no Amazon RDS](USER_WorkingWithParamGroups.Modifying.md). Para obter mais informações sobre o parâmetro `require_secure_transport`, consulte a [documentação do MySQL](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_require_secure_transport). # Conectar-se à instância de banco de dados do MySQL no Amazon RDS com SSL/TLS por meio do cliente de linha de comandos do MySQL (criptografado) Os parâmetros do programa cliente `mysql` são ligeiramente diferentes, dependendo da versão do MySQL ou do MariaDB que você está usando. Para descobrir qual versão você tem, execute o comando `mysql` com a opção `--version`. No exemplo a seguir, a saída mostra que o programa cliente é do MariaDB. ``` $ mysql --version mysql Ver 15.1 Distrib 10.5.15-MariaDB, for osx10.15 (x86_64) using readline 5.1 ``` A maioria das distribuições Linux, como o Amazon Linux, CentOS, SUSE e Debian, substituiu o MySQL pelo MariaDB, e a versão do `mysql` neles é de MariaDB. Para conectar-se à sua instância de banco de dados usando o SSL/TLS, siga estas etapas: **Como conectar-se a uma instância de banco de dados com o SSL/TLS usando o cliente de linha de comando do MySQL** 1. Você pode baixar um certificado raiz que funciona para todas as Regiões da AWS. Para obter informações sobre como baixar certificados, consulte [Usar SSL/TLS para criptografar uma conexão com uma instância ou um cluster de banco de dados](UsingWithRDS.SSL.md). 1. Use um cliente da linha de comando do MySQL para conectar-se a uma instância de banco de dados com criptografia SSL/TLS. Para o parâmetro `-h`, substitua o nome de DNS (endpoint) da instância de banco de dados. Para o parâmetro `--ssl-ca`, substitua o nome do arquivo de certificado SSL/TLS. Para o parâmetro `-P`, substitua a porta da sua instância de banco de dados. Para o parâmetro `-u`, substitua o nome de usuário de um usuário de banco de dados válido, como o usuário principal. Digite a senha do usuário mestre quando lhe for solicitado. O exemplo a seguir mostra como iniciar o cliente usando o parâmetro `--ssl-ca` com o MySQL 5.7 e versões posteriores. ``` mysql -h mysql–instance1.123456789012.us-east-1.rds.amazonaws.com --ssl-ca=global-bundle.pem --ssl-mode=REQUIRED -P 3306 -u myadmin -p ``` Para exigir que a conexão SSL/TLS verifique o endpoint da instância de banco de dados em relação ao endpoint no certificado SSL/TLS, insira o seguinte comando: ``` mysql -h mysql–instance1.123456789012.us-east-1.rds.amazonaws.com --ssl-ca=global-bundle.pem --ssl-mode=VERIFY_IDENTITY -P 3306 -u myadmin -p ``` O exemplo a seguir mostra como iniciar o cliente usando o parâmetro `--ssl-ca` usando o cliente MariaDB: ``` mysql -h mysql–instance1.123456789012.us-east-1.rds.amazonaws.com --ssl-ca=global-bundle.pem --ssl -P 3306 -u myadmin -p ``` 1. Digite a senha do usuário mestre quando lhe for solicitado. Você verá uma saída semelhante à seguinte. ``` Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 9738 Server version: 8.0.28 Source distribution Type 'help;' or '\h' for help. Type '\c' to clear the buffer. mysql> ``` # Atualizar aplicações para conexão com instâncias de banco de dados MySQL usando novos certificados SSL/TLS Em 13 de janeiro de 2023, o Amazon RDS publicou novos certificados de autoridade de certificação (CA) para se conectar às suas instâncias de banco de dados do RDS via Secure Socket Layer ou Transport Layer Security (SSL/TLS). A seguir, você pode encontrar informações sobre como atualizar seus aplicativos para usar os novos certificados. Este tópico pode ajudá-lo a determinar se algum aplicativo cliente usa SSL/TLS para conectar-se às suas instâncias de banco de dados. Em caso positivo, examine mais a fundo se esse aplicativo exige verificação de certificado para se conectar. **nota** Alguns aplicativos são configurados para se conectar a instâncias de banco de dados MySQL apenas quando podem verificar com sucesso o certificado no servidor. Para esses aplicativos, você deve atualizar os repositórios confiáveis de aplicativos cliente para incluir os novos certificados de CA. É possível especificar os seguintes modos SSL: `disabled`, `preferred` e `required`. Ao usar o modo `preferred` do SSL, e o certificado de CA não existe ou não está atualizado, a conexão volta a não usar SSL e se conecta com êxito. Recomendamos evitar o modo `preferred` No modo `preferred`, se a conexão encontrar um certificado inválido, ele para de usar criptografia e continua sem criptografia. Depois de atualizar seus certificados de CA nos armazenamentos confiáveis do aplicativo cliente, você pode fazer o rodízio dos certificados nas suas instâncias de banco de dados. É altamente recomendável testar esses procedimentos em um ambiente de desenvolvimento ou teste antes de implementá-los em seus ambientes de produção. Para obter mais informações sobre a mudança de certificados, consulte [Alternar o certificado SSL/TLS](UsingWithRDS.SSL-certificate-rotation.md). Para obter mais informações sobre como fazer download de certificados, consulte [Usar SSL/TLS para criptografar uma conexão com uma instância ou um cluster de banco de dados](UsingWithRDS.SSL.md). Para obter informações sobre o uso de SSL/TLS com instâncias de bancos de dados MySQL, consulte [Suporte do SSL/TLS para instâncias de banco de dados do MySQL no Amazon RDS](MySQL.Concepts.SSLSupport.md). **Topics** + [ ## Determinar se alguma aplicação está se conectando à instância de banco de dados MySQL usando SSL ](#ssl-certificate-rotation-mysql.determining-server) + [ ## Determinar se um cliente requer verificação de certificado para se conectar ](#ssl-certificate-rotation-mysql.determining-client) + [ ## Atualizar o armazenamento confiável de aplicações ](#ssl-certificate-rotation-mysql.updating-trust-store) + [ ## Exemplo de código Java para estabelecer conexões SSL ](#ssl-certificate-rotation-mysql.java-example) ## Determinar se alguma aplicação está se conectando à instância de banco de dados MySQL usando SSL Se você estiver usando o Amazon RDS para MySQL versão 5.7, 8.0 ou 8.4 e o Esquema de desempenho estiver habilitado, execute a seguinte consulta para verificar se as conexões estão usando SSL/TLS. Para obter informações sobre como habilitar o Esquema de performance, consulte [Performance Schema quick start](https://dev.mysql.com/doc/refman/8.0/en/performance-schema-quick-start.html) na documentação do MySQL. ``` mysql> SELECT id, user, host, connection_type FROM performance_schema.threads pst INNER JOIN information_schema.processlist isp ON pst.processlist_id = isp.id; ``` Nesta saída de exemplo, é possível ver que a sua própria sessão (`admin`) e um aplicativo conectado como `webapp1` estão usando SSL. ``` +----+-----------------+------------------+-----------------+ | id | user | host | connection_type | +----+-----------------+------------------+-----------------+ | 8 | admin | 10.0.4.249:42590 | SSL/TLS | | 4 | event_scheduler | localhost | NULL | | 10 | webapp1 | 159.28.1.1:42189 | SSL/TLS | +----+-----------------+------------------+-----------------+ 3 rows in set (0.00 sec) ``` ## Determinar se um cliente requer verificação de certificado para se conectar É possível verificar se os clientes JDBC e MySQL exigem verificação de certificado para se conectarem. ### JDBC O exemplo a seguir com o MySQL Connector/J 8.0 mostra uma maneira de verificar as propriedades da conexão JDBC de um aplicativo para determinar se conexões bem-sucedidas exigem um certificado válido. Para obter mais informações sobre todas as opções de conexão JDBC para MySQL, consulte [Propriedades da configuração](https://dev.mysql.com/doc/connector-j/en/connector-j-reference-configuration-properties.html) na documentação do MySQL. Ao usar o MySQL Connector/J 8.0, uma conexão SSL exigirá verificação com base no certificado do servidor de banco de dados se as propriedades da sua conexão tiverem `sslMode` definido como `VERIFY_CA` ou `VERIFY_IDENTITY`, como no exemplo a seguir. ``` Properties properties = new Properties(); properties.setProperty("sslMode", "VERIFY_IDENTITY"); properties.put("user", DB_USER); properties.put("password", DB_PASSWORD); ``` **nota** Se você usar o MySQL Java Connector v5.1.38 ou posterior, ou o MySQL Java Connector v8.0.9 ou posterior para se conectar a seus bancos de dados, mesmo que você não tenha configurado explicitamente seus aplicativos para usar SSL/TLS ao se conectar a seus bancos de dados, esses drivers cliente usam SSL/TLS como padrão. Além disso, ao usar SSL/TLS, eles executam a verificação parcial do certificado e haverá falha na conexão se o certificado do servidor de banco de dados tiver expirado. ### MySQL Os exemplos a seguir com o cliente MySQL mostram duas maneiras de verificar a conexão MySQL de um script para determinar se conexões bem-sucedidas exigem um certificado válido. Para obter mais informações sobre todas as opções de conexão com o cliente MySQL, consulte [Configuração no lado do cliente para conexões criptografadas](https://dev.mysql.com/doc/refman/8.0/en/using-encrypted-connections.html#using-encrypted-connections-client-side-configuration) na documentação do MySQL. Ao usar o Cliente MySQL 5.7 e posterior, uma conexão SSL requer verificação com base no certificado de CA de servidor se, para a opção `--ssl-mode`, você especificar `VERIFY_CA` ou `VERIFY_IDENTITY`, como no exemplo a seguir. ``` mysql -h mysql-database.rds.amazonaws.com -uadmin -ppassword --ssl-ca=/tmp/ssl-cert.pem --ssl-mode=VERIFY_CA ``` ## Atualizar o armazenamento confiável de aplicações Para obter informações sobre como atualizar o armazenamento confiável para aplicações MySQL, consulte [Installing SSL certificates](https://dev.mysql.com/doc/mysql-monitor/8.0/en/mem-ssl-installation.html) na documentação do MySQL. Para obter informações sobre como baixar o certificado raiz, consulte [Usar SSL/TLS para criptografar uma conexão com uma instância ou um cluster de banco de dados](UsingWithRDS.SSL.md). Para obter exemplos de scripts que importam certificados, consulte [Script de exemplo para importar certificados para o seu armazenamento confiável](UsingWithRDS.SSL-certificate-rotation.md#UsingWithRDS.SSL-certificate-rotation-sample-script). **nota** Ao atualizar o armazenamento confiável, é possível reter certificados mais antigos, além de adicionar os novos certificados. Se você estiver usando o driver JDBC mysql em um aplicativo, defina as seguintes propriedades nesse aplicativo. ``` System.setProperty("javax.net.ssl.trustStore", certs); System.setProperty("javax.net.ssl.trustStorePassword", "password"); ``` Ao iniciar o aplicativo, defina as seguintes propriedades. ``` java -Djavax.net.ssl.trustStore=/path_to_trust_store/MyTruststore.jks -Djavax.net.ssl.trustStorePassword=my_trust_store_password com.companyName.MyApplication ``` **nota** Especifique uma senha diferente do prompt mostrado aqui como prática recomendada de segurança. ## Exemplo de código Java para estabelecer conexões SSL O exemplo de código a seguir mostra como configurar a conexão SSL que valida o certificado de servidor usando JDBC. ``` public class MySQLSSLTest { private static final String DB_USER = "username"; private static final String DB_PASSWORD = "password"; // This trust store has only the prod root ca. private static final String TRUST_STORE_FILE_PATH = "file-path-to-trust-store"; private static final String TRUST_STORE_PASS = "trust-store-password"; public static void test(String[] args) throws Exception { Class.forName("com.mysql.jdbc.Driver"); System.setProperty("javax.net.ssl.trustStore", TRUST_STORE_FILE_PATH); System.setProperty("javax.net.ssl.trustStorePassword", TRUST_STORE_PASS); Properties properties = new Properties(); properties.setProperty("sslMode", "VERIFY_IDENTITY"); properties.put("user", DB_USER); properties.put("password", DB_PASSWORD); Connection connection = null; Statement stmt = null; ResultSet rs = null; try { connection = DriverManager.getConnection("jdbc:mysql://mydatabase.123456789012.us-east-1.rds.amazonaws.com:3306",properties); stmt = connection.createStatement(); rs=stmt.executeQuery("SELECT 1 from dual"); } finally { if (rs != null) { try { rs.close(); } catch (SQLException e) { } } if (stmt != null) { try { stmt.close(); } catch (SQLException e) { } } if (connection != null) { try { connection.close(); } catch (SQLException e) { e.printStackTrace(); } } } return; } } ``` **Importante** Depois de determinar que suas conexões com o banco de dados usam SSL/TLS e ter atualizado o armazenamento confiável de aplicações, você poderá atualizar o banco de dados para usar os certificados rds-ca-rsa2048-g1. Para obter instruções, consulte a etapa 3 em [Atualizar o certificado CA modificando a instância ou o cluster de banco de dados](UsingWithRDS.SSL-certificate-rotation.md#UsingWithRDS.SSL-certificate-rotation-updating). Especifique uma senha diferente do prompt mostrado aqui como prática recomendada de segurança. # Uso da autenticação do Kerberos para o Amazon RDS para MySQL É possível usar a autenticação Kerberos para autenticar usuários quando se conectam a sua instância de banco de dados do MySQL. A instância de banco de dados funciona com o AWS Directory Service for Microsoft Active Directory (AWS Managed Microsoft AD) para habilitar a autenticação Kerberos. Quando os usuários são autenticados por uma instância de banco de dados MySQL associada ao domínio de confiança, as solicitações de autenticação são encaminhadas. As solicitações encaminhadas vão para o diretório de domínio que você cria com o Directory Service. Manter todas as suas credenciais no mesmo diretório pode economizar tempo e esforço. Com essa abordagem, você tem um lugar centralizado para armazenar e gerenciar credenciais para várias instâncias de banco de dados. O uso de um diretório também pode melhorar o perfil de segurança geral. ## Disponibilidade de região e versão A disponibilidade e a compatibilidade de recursos varia entre versões específicas de cada mecanismo de banco de dados e entre Regiões da AWS. Para ter mais informações sobre a disponibilidade de versões e regiões do Amazon RDS com autenticação de Kerberos, consulte [Regiões e mecanismos de banco de dados compatíveis com a autenticação Kerberos no Amazon RDS](Concepts.RDS_Fea_Regions_DB-eng.Feature.KerberosAuthentication.md). ## Visão geral da configuração da autenticação Kerberos para instâncias de banco de dados MySQL Para configurar a autenticação Kerberos para uma instância de banco de dados MySQL, conclua as seguintes etapas gerais, descritas em mais detalhes posteriormente: 1. Use AWS Managed Microsoft AD para criar um diretório do AWS Managed Microsoft AD. É possível usar o Console de gerenciamento da AWS, o AWS CLI ou o Directory Service para criar o diretório. Para obter detalhes sobre como fazer isso, consulte o tópico sobre como [Criar seu diretório AWS Managed Microsoft AD](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_getting_started_create_directory.html), no *Guia de administração do AWS Directory Service*. 1. Crie uma função do AWS Identity and Access Management (IAM) que use a politica gerenciada `AmazonRDSDirectoryServiceAccess` do IAM. A função permite ao Amazon RDS fazer chamadas para seu diretório. Para o perfil permitir o acesso, o endpoint do AWS Security Token Service (AWS STS) deve estar ativado na Região da AWS de sua conta da AWS. Os endpoints do AWS STS são ativados por padrão em todas as Regiões da AWS e você pode usá-los sem precisar tomar medidas adicionais. Para ter mais informações, consulte [ Ativar e desativar o AWS STS em uma Região da AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_enable-regions.html#sts-regions-activate-deactivate) no *Guia do usuário do IAM*. 1. Crie e configure usuários no diretório AWS Managed Microsoft AD usando as ferramentas do Microsoft Active Directory. Para ter mais informações sobre como criar usuários em seu Active Directory, consulte [Gerenciar usuários e grupos no Microsoft AD](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_manage_users_groups.html) gerenciado pela AWS no *Guia de administração doAWS Directory Service*. 1. Crie ou modifique uma instância de banco de dados MySQL. Se você usar a CLI ou a API do RDS na solicitação de criação, especifique um identificador de domínio com o parâmetro `Domain`. Use o identificador `d-*` que foi gerado quando você criou o diretório e o nome da função que você criou. Se você modificar uma instância de banco de dados MySQL existente para usar a autenticação Kerberos, defina os parâmetros de domínio e função do IAM para a instância de banco de dados. Localize a instância de banco de dados na mesma VPC que o diretório de domínio. 1. Use as credenciais de usuário mestre do Amazon RDS para conectar-se à instância de banco de dados MySQL. Crie o usuário no MySQL usando a cláusula `CREATE USER` `IDENTIFIED WITH 'auth_pam'`. Os usuários que você cria dessa maneira podem fazer login na instância de banco de dados MySQL usando a autenticação Kerberos. ## Configurar a autenticação Kerberos para instâncias de banco de dados MySQL Use o AWS Managed Microsoft AD para configurar a autenticação Kerberos para uma instância de banco de dados MySQL. Para configurar a autenticação Kerberos, você executa as seguintes etapas. ### Etapa 1: Criar um diretório usando o AWS Managed Microsoft AD O Directory Service cria um Active Directory totalmente gerenciado na Nuvem AWS. Ao criar um diretório do AWS Managed Microsoft AD, o Directory Service cria dois controladores de domínio e servidores do Domain Name System (DNS) em seu nome. Os servidores do diretório são criados em sub-redes diferentes em uma VPC. Essa redundância ajuda a garantir que o diretório permaneça acessível mesmo se ocorrer uma falha. Ao criar um diretório do AWS Managed Microsoft AD, o Directory Service executa as seguintes tarefas em seu nome: + Configura um Active Directory dentro da VPC. + Cria uma conta de administrador do diretório com o nome de usuário Admin e a senha especificada. Use essa conta para gerenciar seu diretório. **nota** Salve essa senha. O Directory Service não a armazena. Você pode redefini-la, mas não recuperá-la. + Cria um grupo de segurança para os controladores do diretório. Quando você inicia o AWS Managed Microsoft AD, o AWS cria uma Unidade organizacional (UO) que contém todos os objetos do diretório. Essa OU, que tem o nome NetBIOS que você digitou quando criou o diretório, está localizada na raiz do domínio. A raiz do domínio é controlada e de propriedade da AWS. A conta admin que foi criada com o diretório do AWS Managed Microsoft AD tem permissões para as atividades administrativas mais comuns de sua OU: + Criar, atualizar ou excluir usuários + Adicionar recursos ao domínio, como servidores de arquivos ou de impressão, e atribuir permissões para esses recursos aos usuários na UO + Criar OUs adicionais e contêineres + Delegar autoridade + Restaurar objetos excluídos da Lixeira do Active Directory + Execute os módulos AD e DNS do Windows PowerShell no Active Directory Web Service A conta admin também tem direitos para executar as seguintes atividades em todo o domínio: + Gerenciar configurações de DNS (adicionar, remover ou atualizar registros, zonas e encaminhadores) + Visualizar logs de eventos de DNS + Visualizar logs de eventos de segurança **Como criar um diretório com AWS Managed Microsoft AD** 1. Faça login no Console de gerenciamento da AWS e abra o console do Directory Service em [https://console.aws.amazon.com/directoryservicev2/](https://console.aws.amazon.com/directoryservicev2/). 1. No painel de navegação, escolha **Directories (Diretórios)** e escolha **Set up directory (Configurar diretório)**. 1. Escolha **AWS Managed Microsoft AD**. O AWS Managed Microsoft AD é a única opção que você pode usar atualmente com o Amazon RDS. 1. Insira as seguintes informações: **Nome do DNS do diretório** O nome completo do diretório, como **corp.example.com**. **Nome de NetBIOS do diretório** O nome curto do diretório, como **CORP**. **Descrição do diretório** (Opcional) Uma descrição do diretório. **Senha do Admin** A senha do administrador do diretório. O processo de criação do diretório cria uma conta de administrador com o nome de usuário Admin e essa senha. A senha do administrador do diretório e não pode incluir a palavra "admin". A senha diferencia letras maiúsculas de minúsculas e deve ter entre 8 e 64 caracteres. Ela também precisa conter pelo menos um caractere de três das quatro categorias a seguir: + Letras minúsculas (a–z) + Letras maiúsculas (A–Z) + Números (0–9) + Caracteres não alfanuméricos (\$1\$1@\$1\$1%^&\$1\$1-\$1=`\$1\$1()\$1\$1[]:;"'<>,.?/) **Confirmar senha** A senha do administrador digitada novamente. 1. Escolha **Next (Próximo)**. 1. Insira as seguintes informações na seção **Networking (Rede)** e escolha **Next (Próximo)**: **VPC** A VPC do diretório. Crie a instância de banco de dados MySQL nesta mesma VPC. **Sub-redes** Sub-redes para os servidores do diretório. As duas sub-redes deve estar em diferentes zonas de disponibilidade. 1. Revise as informações do diretório e faça as alterações necessárias. Quando as informações estiverem corretas, selecione **Create directory (Criar diretório)**. ![\[A janela Revisar e criar durante a criação do diretório no console do Directory Service.\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/UserGuide/images/WinAuth2.png) A criação do diretório leva vários minutos. Depois que o diretório tiver sido criado com sucesso, o valor de **Status** muda para **Active (Ativo)**. Para ver informações sobre o diretório, selecione o nome do diretório na listagem de diretórios. Anote o valor do **Directory ID (ID do diretório)** porque você precisará desse valor ao criar ou modificar sua instância de banco de dados MySQL. ![\[A seção Detalhes do diretório com ID do diretório no console do Directory Service.\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/UserGuide/images/WinAuth3.png) ### Etapa 2: Criar a função do IAM para ser usada pelo Amazon RDS Para que o Amazon RDS chame o Directory Service para você, é necessária uma função do IAM que use a política gerenciada do IAM `AmazonRDSDirectoryServiceAccess`. Esta função permite que o Amazon RDS faça chamadas ao Directory Service. Quando uma instância de banco de dados é criada usando o Console de gerenciamento da AWS e o usuário do console tem a permissão `iam:CreateRole`, o console cria essa função automaticamente. Nesse caso, o nome da função é `rds-directoryservice-kerberos-access-role`. Caso contrário, é necessário criar a função do IAM manualmente. Ao criar essa função do IAM, escolha `Directory Service` e associe a AWS política gerenciada da `AmazonRDSDirectoryServiceAccess` a ela. Para ter mais informações sobre como criar funções do IAM para um serviço, consulte o tópico sobre como [Criar uma função para delegar permissões a um serviço da AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html), no *Guia do usuário do IAM*. **nota** O perfil do IAM usado para a autenticação do Windows para RDS para o SQL Server não pode ser usado para o RDS para MySQL. Se preferir, você poderá criar políticas com as permissões exigidas em vez de usar a política gerenciada do IAM `AmazonRDSDirectoryServiceAccess`. Nesse caso, o perfil do IAM deve ter a política de confiança do IAM a seguir. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "", "Effect": "Allow", "Principal": { "Service": [ "directoryservice.rds.amazonaws.com", "rds.amazonaws.com" ] }, "Action": "sts:AssumeRole" } ] } ``` ------ A função também deve ter a política de função do IAM a seguir. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Action": [ "ds:DescribeDirectories", "ds:AuthorizeApplication", "ds:UnauthorizeApplication", "ds:GetAuthorizedApplicationDetails" ], "Effect": "Allow", "Resource": "*" } ] } ``` ------ ### Etapa 3: Criar e configurar usuários Você pode criar usuários com a ferramenta Usuários e computadores do Active Directory. Essa ferramenta faz parte das ferramentas do Active Directory Domain Services e do Active Directory Lightweight Directory Services. Os usuários representam pessoas ou entidades individuais que têm acesso ao seu diretório. Para criar usuários em um diretório do Directory Service, você deve estar conectado a uma instância do Amazon EC2 baseada no Microsoft Windows. Essa instância deve ser membro do diretório do Directory Service e estar conectada como um usuário com privilégios para criar usuários. Para ter mais informações, consulte o tópico sobre como [Gerenciar usuários e grupos AWS Managed Microsoft AD](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/creating_ad_users_and_groups.html), no *Guia de administração do AWS Directory Service*. ### Etapa 4: Criar ou modificar uma instância de banco de dados MySQL Crie ou modifique uma instância de banco de dados MySQL para usar com o diretório. É possível usar o console, a CLI ou a API do RDS para associar uma instância de banco de dados a um diretório. Você pode fazer isso por meio de uma das seguintes maneiras: + Crie uma instância de banco de dados MySQL usando o console, o comando [create-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html) da CLI ou a operação da API [CreateDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBInstance.html) do RDS. Para obter instruções, consulte [Criar uma instância de banco de dados do Amazon RDS](USER_CreateDBInstance.md). + Modifique uma instância de banco de dados existente do MySQL usando o console, o comando [modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html) da CLI ou a operação da API [ModifyDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html) do RDS. Para obter instruções, consulte [Modificar uma instância de banco de dados do Amazon RDS](Overview.DBInstance.Modifying.md). + Restaure uma instância de banco de dados MySQL de um snapshot de banco de dados usando o console, o comando [ restore-db-instance-from-db-snapshot](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-from-db-snapshot.html) da CLI ou a operação da API [ RestoreDBInstanceFromDBSnapshot](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceFromDBSnapshot.html) do RDS. Para obter instruções, consulte [Restaurar uma instância de banco de dados](USER_RestoreFromSnapshot.md). + Restaure uma instância de banco de dados MySQL em um determinado momento usando o console, o comando [restore-db-instance-to-point-in-time](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-to-point-in-time.html) da CLI ou a operação da API [RestoreDBInstanceToPointInTime](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceToPointInTime.html) do RDS. Para obter instruções, consulte [Restaurar uma instância de banco de dados para um momento especificado no Amazon RDS](USER_PIT.md). A autenticação Kerberos só é compatível com instâncias de banco de dados MySQL em uma VPC. A instância de banco de dados pode estar na mesma VPC do diretório ou em uma VPC diferente. A instância de banco de dados que deve ser usada em um grupo de segurança que permita a saída na VPC do diretório para que a instância de banco de dados possa se comunicar com o diretório. Ao usar o console para criar, modificar ou restaurar uma instância de banco de dados, escolha **Password and Kerberos authentication** (Senha e autenticação Kerberos) na seção **Database authentication** (Autenticação de banco de dados). Escolha **Browse Directory (Procurar diretório)** e selecione o diretório ou escolha **Create a new directory (Criar um diretório)**. ![\[A seção Autenticação do banco de dados com Senha e autenticação Kerberos selecionada no console do Amazon RDS.\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/UserGuide/images/kerberos-authentication.png) Ao utilizar a AWS CLI ou a API do RDS, associe uma instância de banco de dados a um diretório. Os seguintes parâmetros são necessários para que a instância de banco de dados utilize o diretório de domínio que você criou: + Para o parâmetro `--domain`, use o identificador de domínio (identificador "d-\$1") gerado quando o diretório foi criado. + Para o parâmetro `--domain-iam-role-name`, use a função criada que usa a política gerenciada `AmazonRDSDirectoryServiceAccess` do IAM. Por exemplo, o comando da CLI a seguir modifica uma instância de banco de dados para usar um diretório. Para Linux, macOS ou Unix: ``` aws rds modify-db-instance \ --db-instance-identifier mydbinstance \ --domain d-ID \ --domain-iam-role-name role-name ``` Para Windows: ``` aws rds modify-db-instance ^ --db-instance-identifier mydbinstance ^ --domain d-ID ^ --domain-iam-role-name role-name ``` **Importante** Se você modificar uma instância de banco de dados para permitir a autenticação Kerberos, reinicialize a instância de banco de dados após fazer a alteração. ### Etapa 5: Criar logins do MySQL da autenticação Kerberos Use as credenciais de usuário mestre do Amazon RDS para se conectar à instância de banco de dados do MySQL como você faz com qualquer outra instância de banco de dados. A instância de banco de dados é ingressada no domínio AWS Managed Microsoft AD. Assim, é possível provisionar logins e usuários do MySQL de usuários do Active Directory em seu domínio. As permissões de banco de dados são gerenciadas por meio de permissões padrão do MySQL que são concedidas e revogadas desses logins. Você pode permitir que um usuário do Active Directory seja autenticado pelo MySQL. Para fazer isso, primeiro use as credenciais do usuário mestre do Amazon RDS para se conectar à instância de banco de dados MySQL como faz com qualquer outra instância de banco de dados. Depois de fazer login, crie um usuário autenticado externamente com PAM (Pluggable Authentication Modules) no MySQL executando o comando a seguir. Substitua `testuser` pelo nome de usuário. ``` CREATE USER 'testuser'@'%' IDENTIFIED WITH 'auth_pam'; ``` Os usuários (humanos e aplicativos) de seu domínio agora podem se conectar à instância de banco de dados em uma máquina cliente conectada ao domínio usando a autenticação Kerberos. **Importante** Recomendamos vivamente que os clientes usem conexões SSL/TLS ao usar a autenticação PAM. Se eles não usarem conexões SSL/TLS, a senha poderá ser enviada como texto não criptografado em alguns casos. Para exigir uma conexão criptografada SSL/TLS para o usuário do AD, execute o seguinte comando e substitua `testuser` pelo nome do usuário: ``` ALTER USER 'testuser'@'%' REQUIRE SSL; ``` Para obter mais informações, consulte [Suporte do SSL/TLS para instâncias de banco de dados do MySQL no Amazon RDS](MySQL.Concepts.SSLSupport.md). ## Gerenciamento de uma instância de banco de dados em um domínio É possível usar a CLI ou a API do RDS para gerenciar a instância de banco de dados e suas relações com o Active Directory. Por exemplo, você pode associar um Active Directory para autenticação Kerberos e desassociar um Active Directory para desabilitar a autenticação Kerberos. Também é possível mover uma instância de banco de dados para ser autenticada externamente por um Microsoft Active Directory para outro. Por exemplo, usando a API do Amazon RDS, você pode fazer o seguinte: + Para tentar habilitar novamente a autenticação Kerberos para uma associação com falha, use a operação `ModifyDBInstance` da API e especifique o ID do diretório da associação atual. + Para atualizar o nome da função do IAM para a associação, use a operação `ModifyDBInstance` da API e especifique o ID do diretório da associação atual e a nova função do IAM. + Para desabilitar a autenticação Kerberos em uma instância de banco de dados, use a operação `ModifyDBInstance` da API e especifique `none` como o parâmetro de domínio. + Para mover uma instância de banco de dados de um domínio para outro, use a operação `ModifyDBInstance` da API e especifique o identificador do novo domínio como o parâmetro do domínio. + Para listar as associações de cada instância de banco de dados, use a operação `DescribeDBInstances` da API. ### Compreensão da associação de domínio Depois que você cria ou modifica a instância de banco de dados, ela se torna membro do domínio. É possível visualizar o status da associação do domínio da instância de banco de dados executando o comando [describe-db-instances](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-instances.html) da CLI. O status da instância de banco de dados pode ser um dos seguintes: + `kerberos-enabled` – a instância de banco de dados que tem a autenticação Kerberos habilitada. + `enabling-kerberos`: a AWS está no processo de habilitar a autenticação Kerberos nessa instância de bancos de dados. + `pending-enable-kerberos` – a habilitação da autenticação Kerberos está pendente nesta instância de banco de dados. + `pending-maintenance-enable-kerberos`: a AWS tentará habilitar a autenticação Kerberos na instância de bancos de dados durante a próxima janela de manutenção programada. + `pending-disable-kerberos` – a desabilitação da autenticação Kerberos está pendente nesta instância de banco de dados. + `pending-maintenance-disable-kerberos`: a AWS tentará desabilitar a autenticação Kerberos na instância de banco de dados durante a próxima janela de manutenção programada. + `enable-kerberos-failed`: um problema de configuração impediu que a AWS habilitasse a autenticação Kerberos na instância de banco de dados. Verifique e corrija sua configuração antes de emitir novamente o comando de modificação da instância de banco de dados. + `disabling-kerberos`: a AWS está no processo de desabilitar a autenticação Kerberos nessa instância de bancos de dados. Uma solicitação para habilitar a autenticação Kerberos pode falhar por conta de um novo problema de conectividade de rede ou de uma função do IAM incorreta. Por exemplo, suponha que você crie uma instância de banco de dados ou modifique uma instância de banco de dados existente e a tentativa de habilitar a autenticação Kerberos falhe. Se isso acontecer, emita o comando modify novamente ou modifique a instância de banco de dados recém-criada para ingressar no domínio. ## Conectar-se ao MySQL com a autenticação Kerberos Para conectar-se ao MySQL com a autenticação Kerberos, faça login usando o tipo de autenticação Kerberos. Para criar um usuário de banco de dados ao qual você pode se conectar usando a autenticação Kerberos, use uma cláusula `IDENTIFIED WITH` na instrução `CREATE USER`. Para obter instruções, consulte [Etapa 5: Criar logins do MySQL da autenticação Kerberos](#mysql-kerberos-setting-up.create-logins). Para evitar erros, use o cliente `mysql` do MariaDB. É possível baixar o software MariaDB em [https://downloads.mariadb.org/](https://downloads.mariadb.org/). No prompt de comando, conecte-se a um dos endpoints associados à sua instância de banco de dados MySQL. Siga os procedimentos gerais em [Conectar-se à instância de banco de dados do MySQL](USER_ConnectToInstance.md). Quando a senha for solicitada, insira a senha do Kerberos associada a esse nome de usuário. ## Restaurar uma instância de banco de dados MySQL e adicioná-la a um domínio Você pode restaurar um snapshot de banco de dados ou fazer uma restauração point-in-time de uma instância de banco de dados MySQL e adicioná-la a um domínio. Depois que a instância de banco de dados tiver sido restaurada, modifique a instância de banco de dados usando o processo explicado em [Etapa 4: Criar ou modificar uma instância de banco de dados MySQL](#mysql-kerberos-setting-up.create-modify) para adicionar a instância de banco de dados a um domínio. ## Limitações da autenticação Kerberos para MySQL As seguintes limitações se aplicam à autenticação Kerberos para MySQL: + Há suporte somente para AWS Managed Microsoft AD. Contudo, você pode associar as instâncias de banco de dados do RDS para MySQL a domínios gerenciados do Microsoft AD compartilhados de propriedade de contas diferentes na mesma Região da AWS. + Você deve reinicializar a instância de banco de dados depois de habilitar o recurso. + O tamanho do nome do domínio não pode ser maior que 61 caracteres. + Você não pode habilitar a autenticação Kerberos e a autenticação do IAM ao mesmo tempo. Escolha um método de autenticação ou outro para sua instância de banco de dados MySQL. + Não modifique a porta da instância de banco de dados depois de habilitar o recurso. + Não use a autenticação Kerberos com réplicas de leitura. + Se você tiver o upgrade automático de versão secundária ativado para uma instância de banco de dados MySQL que esteja utilizando a autenticação Kerberos, deverá desativar a autenticação Kerberos e depois ativá-la novamente após um upgrade automático. Para ter mais informações sobre upgrades de versões secundárias, consulte [Atualizações automáticas da versão secundária do RDS para MySQL](USER_UpgradeDBInstance.MySQL.Minor.md). + Para excluir uma instância de banco de dados com esse recurso habilitado, primeiro desabilite o recurso. Para isso, execute o comando `modify-db-instance` da CLI para a instância de banco de dados e especifique `none` para o parâmetro `--domain`. Se você usar a CLI ou a API do RDS para excluir uma instância de banco de dados com esse recurso habilitado, espere um atraso. + O RDS para MySQL não comporta a autenticação Kerberos em uma floresta de confiança entre seu AD on-premises ou auto-hospedado e o AWS Managed Microsoft AD. # Melhorar a performance das consultas para o RDS para MySQL com leituras otimizadas do Amazon RDS É possível acelerar o processamento de consultas para o RDS para MySQL com leituras otimizadas do Amazon RDS. Uma instância de banco de dados ou um cluster de banco de dados multi-AZ do RDS para MySQL que utiliza o recurso Leituras otimizadas pelo RDS pode obter um processamento de consultas até duas vezes mais rápido em comparação com uma instância ou um cluster de banco de dados que não utiliza o recurso. **Topics** + [ ## Visão geral das leituras otimizadas do RDS ](#rds-optimized-reads-overview) + [ ## Casos de uso para leituras otimizadas do RDS ](#rds-optimized-reads-use-cases) + [ ## Práticas recomendadas para leituras otimizadas do RDS ](#rds-optimized-reads-best-practices) + [ ## Utilizar leituras otimizadas do RDS ](#rds-optimized-reads-using) + [ ## Monitorar instâncias de banco de dados que utilizam leituras otimizadas do RDS ](#rds-optimized-reads-monitoring) + [ ## Limitações das leituras otimizadas do RDS ](#rds-optimized-reads-limitations) ## Visão geral das leituras otimizadas do RDS Quando você usa uma instância de banco de dados ou um cluster de banco de dados multi-AZ do RDS para MySQL com o recurso Leituras otimizadas pelo RDS ativado, essa instância ou cluster de banco de dados obtém uma performance de consulta mais rápida por meio do uso de um armazenamento de instância. Um *armazenamento de instância* fornece armazenamento temporário em nível de bloco para a instância de banco de dados ou o cluster de banco de dados multi-AZ. O armazenamento está localizado em unidades de estado sólido (SSDs) Non-Volatile Memory Express (NVMe) anexadas fisicamente ao servidor host. Esse armazenamento é otimizado para baixa latência, performance de E/S aleatória muito alta e alto throughput de leitura de sequencial. O recurso Leituras otimizadas pelo RDS é ativado por padrão quando uma instância de banco de dados ou um cluster de banco de dados multi-AZ utiliza uma classe de instância de banco de dados com um armazenamento de instância, como db.m5d ou db.m6gd. Com leituras otimizadas do RDS, alguns objetos temporários são armazenados no armazenamento de instâncias. Esses objetos temporários incluem arquivos temporários internos, tabelas temporárias internas em disco, arquivos de mapa de memória e arquivos de cache de log binário. Para ter mais informações sobre o armazenamento de instância, consulte [Armazenamento de instância do Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/InstanceStorage.html) no *Amazon Elastic Compute Cloud Manual do usuário para instâncias do Linux*. As workloads que geram objetos temporários no MySQL para processamento de consultas podem aproveitar o armazenamento de instâncias para acelerar o processamento das consultas. Esse tipo de workload inclui consultas que envolvem classificações, agregações de hash, uniões de alta carga, expressões de tabela comuns (CTEs) e consultas em colunas não indexadas. Esses volumes de armazenamento de instâncias oferecem um nível superior de IOPS e performance, independentemente das configurações de armazenamento utilizadas para armazenamento persistente do Amazon EBS. Como as leituras otimizadas do RDS transferem operações em objetos temporários para o armazenamento de instâncias, as operações de entrada e saída por segundo (IOPS) ou o throughput do armazenamento persistente (Amazon EBS) agora podem ser utilizadas para operações em objetos persistentes. Essas operações incluem leituras e gravações regulares de arquivos de dados e operações do mecanismo em segundo plano, como limpar e inserir mesclagens de buffer. **nota** Os snapshots manuais e automatizados do RDS contêm apenas arquivos de mecanismo para objetos persistentes. Os objetos temporários criados no armazenamento de instâncias não estão incluídos nos snapshots do RDS. ## Casos de uso para leituras otimizadas do RDS Se você tem workloads que dependem muito de objetos temporários, como tabelas ou arquivos internos, para a execução de consultas, você pode se beneficiar da ativação de leituras otimizadas do RDS. Os seguintes casos de uso são candidatos para leituras otimizadas do RDS: + Aplicações que executam consultas analíticas com expressões de tabela comuns (CTEs) complexas, tabelas derivadas e operações de agrupamento + Réplicas de leitura que oferecem tráfego de leitura intenso com consultas não otimizadas + Aplicações que executam consultas de relatórios dinâmicos ou sob demanda que envolvem operações complexas, como consultas com as cláusulas `GROUP BY` e `ORDER BY` + Workloads que utilizam tabelas temporárias internas para processamento de consultas Você pode monitorar a variável de status do mecanismo `created_tmp_disk_tables` para determinar o número de tabelas temporárias baseadas em disco criadas em sua instância de banco de dados. + Aplicações que criam grandes tabelas temporárias, diretamente ou em procedimentos, para armazenar resultados intermediários + Consultas de banco de dados que realizam agrupamento ou classificação em colunas não indexadas ## Práticas recomendadas para leituras otimizadas do RDS Use as práticas recomendadas a seguir para leituras otimizadas do RDS: + Adicione uma lógica de repetição para consultas somente leitura caso elas falhem devido ao armazenamento de instância estar cheio durante a execução. + Monitore o espaço de armazenamento disponível no armazenamento de instâncias com a métrica do CloudWatch `FreeLocalStorage`. Se o armazenamento de instâncias estiver atingindo seu limite devido à workload na instância de banco de dados, modifique a instância de banco de dados para utilizar uma classe de instância de banco de dados maior. + Quando sua instância de banco de dados ou cluster de banco de dados multi-AZ tiver memória suficiente, mas ainda estiver atingindo o limite de armazenamento no armazenamento de instância, aumente o valor de `binlog_cache_size` para manter as entradas de log binário específicas da sessão na memória. Essa configuração impede a gravação das entradas de log binário em arquivos temporários de cache de log binário no disco. O parâmetro `binlog_cache_size` é específico da sessão. É possível alterar o valor de cada nova sessão. A configuração desse parâmetro pode aumentar a utilização da memória na instância de banco de dados durante a workload de pico. Portanto, considere aumentar o valor do parâmetro com base no padrão de workload de sua aplicação e na memória disponível na instância de banco de dados. + Para o MySQL versão 8.0 e anterior, use o valor padrão de `MIXED` para o parâmetro `binlog_format`. Dependendo do tamanho das transações, definir `binlog_format` como `ROW` pode ocasionar arquivos de cache de log binário grandes no armazenamento de instâncias. Para o MySQL 8.4 e versões posteriores, use o valor padrão de `ROW` para o parâmetro `binlog_format`. + Defina o parâmetro [internal\$1tmp\$1mem\$1storage\$1engine](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_internal_tmp_mem_storage_engine) como `TempTable` e defina o parâmetro [temptable\$1max\$1mmap](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_max_mmap) para corresponder ao tamanho do armazenamento disponível no armazenamento de instâncias. + Evite realizar alterações em massa em uma única transação. Esses tipos de transações podem gerar arquivos de cache de log binário grandes no armazenamento de instâncias e causar problemas quando o armazenamento de instâncias está cheio. Considere dividir as gravações em várias transações pequenas para minimizar o uso de armazenamento para arquivos de cache de log binário. + Utilize o valor padrão de `ABORT_SERVER` para o parâmetro `binlog_error_action`. Isso evita problemas com o registro em log binário em instâncias de banco de dados com backups ativados. ## Utilizar leituras otimizadas do RDS Quando você provisiona uma instância de banco de dados do RDS para MySQL com uma das classes de instância de banco de dados a seguir em uma implantação de instância de banco de dados single-AZ, uma implantação de instância de banco de dados multi-AZ ou uma implantação de cluster de banco de dados multi-AZ, a instância de banco de dados utiliza automaticamente o recurso Leituras otimizadas pelo RDS. Para ativar as leituras otimizadas do RDS, execute um destes procedimentos: + Crie uma instância de banco de dados ou um cluster de banco de dados multi-AZ do RDS para MySQL utilizando uma dessas classes de instância de banco de dados. Para ter mais informações, consulte [Criar uma instância de banco de dados do Amazon RDS](USER_CreateDBInstance.md). + Modifique uma instância de banco de dados ou um cluster de banco de dados multi-AZ existente do RDS para MySQL para utilizar uma dessas classes de instância de banco de dados. Para ter mais informações, consulte [Modificar uma instância de banco de dados do Amazon RDS](Overview.DBInstance.Modifying.md). O recurso Leituras otimizadas pelo RDS está disponível em todas as Regiões da AWS onde há suporte para uma ou mais dessas classes de instância de banco de dados com SSD de NVMe local. Para obter informações sobre classes de instância de banco de dados, consulte [Classes de instâncias de banco de dados do ](Concepts.DBInstanceClass.md). A disponibilidade da classe de instância de banco de dados difere em Regiões da AWS. Para determinar se uma classe de instância de banco de dados é compatível com uma Região da AWS específica, consulte [Determinar o suporte para classes de instância de bancos de dados nas Regiões da AWS](Concepts.DBInstanceClass.RegionSupport.md). Se você não quiser utilizar o recurso Leituras otimizadas pelo RDS, modifique sua instância de banco de dados ou cluster de banco de dados multi-AZ para que não use uma classe de instância de banco de dados compatível com o atributo. ## Monitorar instâncias de banco de dados que utilizam leituras otimizadas do RDS Você pode monitorar instâncias de banco de dados que utilizam leituras otimizadas do RDS com as seguintes métricas do CloudWatch: + `FreeLocalStorage` + `ReadIOPSLocalStorage` + `ReadLatencyLocalStorage` + `ReadThroughputLocalStorage` + `WriteIOPSLocalStorage` + `WriteLatencyLocalStorage` + `WriteThroughputLocalStorage` Essas métricas fornecem dados sobre armazenamento de instâncias, IOPS e throughput. Para ter mais informações sobre essas métricas, consulte [Métricas específicas da instância do Amazon CloudWatch para Amazon RDS](rds-metrics.md#rds-cw-metrics-instance). ## Limitações das leituras otimizadas do RDS As seguintes limitações se aplicam às leituras otimizadas do RDS: + O recurso de leituras otimizadas do RDS é compatível com as seguintes versões: + RDS para MySQL 8.0.28 e versões principais e secundárias posteriores Para obter informações sobre as versões do RDS para MySQL, consulte [MySQL em versões do Amazon RDS](MySQL.Concepts.VersionMgmt.md). + Você não pode alterar a localização de objetos temporários para armazenamento persistente (Amazon EBS) nas classes de instância de banco de dados compatíveis com leituras otimizadas do RDS. + Quando o registro em log binário está ativado em uma instância de banco de dados, o tamanho máximo da transação é limitado pelo tamanho do armazenamento de instância. No MySQL, qualquer sessão que exija mais armazenamento do que o valor de `binlog_cache_size` grava alterações de transações em arquivos temporários de cache de log binário, que são criados no armazenamento de instância. + As transações podem falhar quando o armazenamento de instância está cheio. # Melhorar a performance das gravações com gravações otimizadas pelo RDS para MySQL Você pode melhorar a performance das transações de gravação com as gravações otimizadas pelo Amazon RDS para MySQL. Quando seu banco de dados do RDS para MySQL utiliza gravações otimizadas pelo RDS, ele pode atingir um throughput de transações de gravação até duas vezes maior. **Topics** + [ ## Visão geral das gravações otimizadas do RDS ](#rds-optimized-writes-overview) + [ ## Utilizar gravações otimizadas pelo RDS ](#rds-optimized-writes-using) + [ ## Habilitando gravações otimizadas para RDS em um banco de dados existente ](#rds-optimized-writes-modify-enable) + [ ## Limitações das gravações otimizadas pelo RDS ](#rds-optimized-writes-limitations) ## Visão geral das gravações otimizadas do RDS Quando você ativa as gravações otimizadas pelo Amazon RDS, seus bancos de dados do RDS para MySQL gravam apenas uma vez ao liberar dados em um armazenamento durável sem a necessidade do buffer de gravação dupla. Os bancos de dados continuam fornecendo proteções de propriedade ACID para transações de banco de dados confiáveis, além de desempenho aprimorado. Bancos de dados relacionais, como o MySQL, fornecem as *propriedades ACID* de atomicidade, consistência, isolamento e durabilidade para transações de banco de dados confiáveis. Para ajudar a fornecer essas propriedades, o MySQL utiliza uma área de armazenamento de dados denominada *buffer de gravação dupla* que evita erros parciais de gravação de página. Esses erros ocorrem quando há uma falha de hardware enquanto o banco de dados está atualizando uma página, como no caso de uma queda de energia. Um banco de dados MySQL pode detectar gravações parciais de páginas e recuperá-las com uma cópia da página no buffer de gravação dupla. Embora essa técnica ofereça proteção, ela também ocasiona operações extras de gravação. Para ter mais informações sobre o buffer de gravação dupla do MySQL, consulte [Doublewrite Buffer](https://dev.mysql.com/doc/refman/8.0/en/innodb-doublewrite-buffer.html) (Buffer de gravação dupla) na documentação do MySQL. Com as gravações otimizadas pelo RDS ativadas, os bancos de dados do RDS para MySQL gravam apenas uma vez ao liberar dados em um armazenamento durável sem a necessidade do buffer de gravação dupla. As gravações otimizadas pelo RDS são úteis se você executa workloads de uso intenso de gravação em seus bancos de dados do RDS para MySQL. Exemplos de bancos de dados com workloads de uso intenso de gravação incluem os compatíveis com pagamentos digitais, negociação financeira e aplicações de jogos. Esses bancos de dados são executados em classes de instância de banco de dados que utilizam o AWS Nitro System. Devido à configuração de hardware nesses sistemas, o banco de dados pode gravar páginas de 16 KiB diretamente nos arquivos de dados de forma confiável e durável em uma única etapa. O sistema AWS Nitro possibilita gravações otimizadas pelo RDS. Você pode definir o novo parâmetro de banco de dados `rds.optimized_writes` para controlar o recurso de gravações otimizadas pelo RDS para bancos de dados do RDS para MySQL. Acesse esse parâmetro nos grupos de parâmetros de banco de dados do RDS para MySQL versão 8.0 e RDS para MySQL versão 8.4. Defina o parâmetro com os seguintes valores: + `AUTO`: ative as gravações otimizadas pelo RDS se o banco de dados for compatível com o recurso. Desative as gravações otimizadas pelo RDS se o banco de dados não for compatível com o recurso. Essa é a configuração padrão. + `OFF`: desative as gravações otimizadas pelo RDS mesmo se o banco de dados for compatível com o recurso. Se você tem um banco de dados existente com uma versão de mecanismo, classe de instância de banco de dados e/ou formato de sistema de arquivos que não suporta gravações otimizadas para RDS, você pode ativar o recurso criando uma implantação azul/verde. Para obter mais informações, consulte [Habilitando gravações otimizadas para RDS em um banco de dados existente](#rds-optimized-writes-modify-enable). Se você migrar um banco de dados do RDS para MySQL configurado para usar gravações otimizadas pelo RDS para uma classe de instância de banco de dados que não oferece suporte ao recurso, o RDS desativará automaticamente as gravações otimizadas pelo RDS para o banco de dados. Quando as gravações otimizadas pelo RDS estão desativadas, o banco de dados utiliza o buffer de gravação dupla do MySQL. Para determinar se um banco de dados do RDS para MySQL está usando gravações otimizadas pelo RDS, visualize o valor atual do parâmetro `innodb_doublewrite` para o banco de dados. Se o banco de dados estiver usando gravações otimizadas pelo RDS, esse parâmetro será definido como `FALSE` (`0`). ## Utilizar gravações otimizadas pelo RDS Você pode ativar as gravações otimizadas pelo RDS ao criar um banco de dados do RDS para MySQL com o console do RDS, a AWS CLI o ou a API do RDS. As gravações otimizadas pelo RDS são ativadas automaticamente quando as duas condições a seguir se aplicam durante a criação do banco de dados: + Você especifica uma versão de mecanismo de banco de dados e uma classe de instância de banco de dados compatíveis com as gravações otimizadas pelo RDS. + As gravações otimizadas pelo RDS são compatíveis com a versão 8.0.30 e posteriores do RDS para MySQL. Para obter informações sobre as versões do RDS para MySQL, consulte [MySQL em versões do Amazon RDS](MySQL.Concepts.VersionMgmt.md). + As gravações otimizadas pelo RDS são compatíveis com bancos de dados do RDS para MySQL que usam as seguintes classes de instância de banco de dados: + db.m7i + db.m7g + db.m6g + db.m6gd + db.m6i + db.m5 + db.m5d + db.r7i + db.r7g + db.r6g + db.r6gd + db.r6i + db.r5 + db.r5b + db.r5d + db.x2idn + db.x2iedn Para obter informações sobre classes de instância de banco de dados, consulte [Classes de instâncias de banco de dados do ](Concepts.DBInstanceClass.md). A disponibilidade da classe de instância de banco de dados difere em Regiões da AWS. Para determinar se uma classe de instância de banco de dados é compatível com uma Região da AWS específica, consulte [Determinar o suporte para classes de instância de bancos de dados nas Regiões da AWS](Concepts.DBInstanceClass.RegionSupport.md). Para atualizar seu banco de dados para uma classe de instância de banco de dados compatível com as gravações otimizadas do RDS, você pode criar uma implantação azul/verde. Para obter mais informações, consulte [Habilitando gravações otimizadas para RDS em um banco de dados existente](#rds-optimized-writes-modify-enable). + No grupo de parâmetros associado ao banco de dados, o parâmetro `rds.optimized_writes` é definido como `AUTO`. Nos grupos de parâmetros padrão, esse parâmetro é sempre definido como `AUTO`. Se você quiser usar uma versão do mecanismo de banco de dados e uma classe de instância de banco de dados que sejam compatíveis com gravações otimizadas pelo RDS, mas não quer usar esse recurso, especifique um grupo de parâmetros personalizado ao criar o banco de dados. Nesse grupo de parâmetros, defina o parâmetro `rds.optimized_writes` como `OFF`. Se você quiser que o banco de dados use gravações otimizadas pelo RDS posteriormente, você pode definir o parâmetro `AUTO` para ativá-lo. Para obter informações sobre como criar grupos de parâmetros personalizados e definir parâmetros, consulte [Grupos de parâmetros para Amazon RDS](USER_WorkingWithParamGroups.md). Para obter informações sobre como criar uma instância de banco de dados, consulte [Criar uma instância de banco de dados do Amazon RDS](USER_CreateDBInstance.md). ### Console Ao usar o console do RDS para criar um banco de dados do RDS para MySQL, você pode filtrar as versões do mecanismo de banco de dados e as classes de instância de banco de dados compatíveis com gravações otimizadas pelo RDS. Depois de ativar os filtros, é possível selecionar entre as versões disponíveis do mecanismo de banco de dados e classes de instância de banco de dados. Para selecionar uma versão do mecanismo de banco de dados que seja compatível com gravações otimizadas pelo RDS, filtre as versões do mecanismo de banco de dados do RDS para MySQL compatíveis com o recurso em **Engine version** (Versão do mecanismo) e, depois, selecione uma versão. ![\[A seção Opções do mecanismo com o filtro Gravações otimizadas pelo Amazon RDS ativado para a Versão do mecanismo.\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/UserGuide/images/rds-optimized-writes-version-filter.png) Na seção **Instance configuration** (Configuração da instância), filtre as classes de instância de banco de dados que são compatíveis com gravações otimizadas pelo RDS e selecione uma classe de instância de banco de dados. ![\[A seção Configuração da instância com o filtro Gravações otimizadas pelo Amazon RDS ativado para a Classe de instância de banco de dados.\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/UserGuide/images/rds-optimized-writes-class-filter.png) Depois de fazer essas seleções, você pode selecionar outras configurações que atendam aos seus requisitos e concluir a criação do banco de dados do RDS para MySQL com o console. ### AWS CLI Para criar uma instância de banco de dados utilizando o comando da AWS CLI, execute o comando [create-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html). Os valores `--engine-version` e `--db-instance-class` devem ser compatíveis com gravações otimizadas pelo RDS. Além disso, verifique se o grupo de parâmetros associado a uma instância de banco de dados tem o parâmetro `rds.optimized_writes` definido como `AUTO`. O exemplo associa o grupo de parâmetros padrão à instância de banco de dados. **Example Criar uma instância de banco de dados que utilize gravações otimizadas pelo RDS** Para Linux, macOS ou Unix: ``` 1. aws rds create-db-instance \ 2. --db-instance-identifier mydbinstance \ 3. --engine mysql \ 4. --engine-version 8.0.30 \ 5. --db-instance-class db.r5b.large \ 6. --manage-master-user-password \ 7. --master-username admin \ 8. --allocated-storage 200 ``` Para Windows: ``` 1. aws rds create-db-instance ^ 2. --db-instance-identifier mydbinstance ^ 3. --engine mysql ^ 4. --engine-version 8.0.30 ^ 5. --db-instance-class db.r5b.large ^ 6. --manage-master-user-password ^ 7. --master-username admin ^ 8. --allocated-storage 200 ``` ### API do RDS Você pode criar uma instância de banco de dados utilizando a operação [CreateDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBInstance.html). Ao utilizar essa operação, os valores `EngineVersion` e `DBInstanceClass` devem ser compatíveis com gravações otimizadas pelo RDS. Além disso, verifique se o grupo de parâmetros associado a uma instância de banco de dados tem o parâmetro `rds.optimized_writes` definido como `AUTO`. ## Habilitando gravações otimizadas para RDS em um banco de dados existente Para modificar um banco de dados existente do RDS para MySQL para ativar as gravações otimizadas do RDS, o banco de dados deve ter sido criado com uma versão do mecanismo de banco de dados e uma classe de instância de banco de dados compatíveis. Além disso, o banco de dados deve ter sido criado *após* o lançamento do RDS Optimized Writes em 27 de novembro de 2022, pois a configuração necessária do sistema de arquivos subjacente é incompatível com a dos bancos de dados criados antes do lançamento. Se essas condições forem atendidas, você poderá ativar as gravações otimizadas para RDS definindo o `rds.optimized_writes` parâmetro como. `AUTO` Se seu banco de dados *não* foi criado com uma versão de mecanismo, classe de instância ou configuração de sistema de arquivos compatível, você pode usar o RDS Blue/Green Deployments para migrar para uma configuração compatível. Ao criar a implantação azul/verde, faça o seguinte: + Selecione **Habilitação de gravações otimizadas no banco de dados verde** e, em seguida, especifique uma versão do mecanismo e uma classe de instância de banco de dados compatíveis com as gravações otimizadas do RDS. Para obter uma lista das versões dos mecanismos compatíveis, consulte [Utilizar gravações otimizadas pelo RDS](#rds-optimized-writes-using). + Em **Armazenamento**, escolha **Atualizar a configuração do sistema de arquivos de armazenamento**. Essa opção atualiza o banco de dados para uma configuração de sistema de arquivos subjacente compatível. Ao criar a implantação azul/verde, se o `rds.optimized_writes` parâmetro estiver definido para`AUTO`, as gravações otimizadas do RDS serão ativadas automaticamente no ambiente verde. Você pode então fazer a transição azul/verde, o que promove o ambiente verde para o novo ambiente de produção. Para obter mais informações, consulte [Criar uma implantação azul/verde no Amazon RDS](blue-green-deployments-creating.md). ## Limitações das gravações otimizadas pelo RDS Ao restaurar um banco de dados do RDS para MySQL a partir de um snapshot, você só pode ativar as gravações otimizadas pelo RDS no banco de dados se todas as condições a seguir se aplicarem: + O snapshot foi criado a partir de um banco de dados compatível com gravações otimizadas pelo RDS. + O snapshot foi criado por meio de um banco de dados criado *após* o lançamento de gravações otimizadas pelo RDS. + O snapshot foi restaurado a partir de um banco de dados compatível com gravações otimizadas pelo RDS. + O banco de dados restaurado é associado a um grupo de parâmetros que tenha o parâmetro `rds.optimized_writes` definido como `AUTO`. # Atualizações do mecanismo de banco de dados do RDS para MySQL Quando o Amazon RDS oferece suporte a uma nova versão de um mecanismo de banco de dados, você pode atualizar suas instâncias de banco de dados para essa nova versão. Há dois tipos de atualizações para bancos de dados do MySQL: de versão principal e de versão secundária. **Atualizações de versão principal** As *atualizações da versão principal* podem conter as alterações de banco de dados incompatíveis com os aplicativos existentes. Como resultado, você deve realizar manualmente as atualizações de versões principais das suas instâncias de banco de dados. Você pode iniciar uma atualização de versão principal modificando manualmente sua instância de banco de dados. Antes de realizar uma atualização de versão principal, recomendamos seguir as instruções descritas em [Atualizações da versão principal do RDS para MySQL](USER_UpgradeDBInstance.MySQL.Major.md). Para atualizações de versão principal das implantações de instância de banco de dados multi-AZ, o Amazon RDS faz upgrade simultaneamente das réplicas de espera e primária. A instância de banco de dados não estará disponível até que a atualização seja concluída. Para upgrades de versão principal das implantações de cluster de banco de dados multi-AZ, o Amazon RDS faz upgrade das instâncias membro do cluster uma por vez. É possível minimizar o tempo de inatividade necessário para a atualização da versão principal utilizando uma implantação azul/verde. Para obter mais informações, consulte [Usar implantações azul/verde do Amazon RDS para atualizações de banco de dados](blue-green-deployments.md). **Atualizações de versões secundárias** *Atualizações de versões secundárias* incluem somente alterações compatíveis com versões anteriores das aplicações existentes. Você pode iniciar uma atualização de versão secundária manualmente modificando sua instância de banco de dados. Ou é possível habilitar a opção **Upgrade automático de versões secundárias** ao criar ou modificar uma instância de banco de dados. Isso significa que o Amazon RDS atualiza automaticamente a instância de banco de dados depois de testar e aprovar a nova versão. Para obter informações sobre como realizar uma atualização, consulte [Atualizar a versão de mecanismo de uma instância de banco de dados ](USER_UpgradeDBInstance.Upgrading.md). Quando você realiza uma atualização de versão secundária de um cluster de banco de dados multi-AZ, o Amazon RDS atualiza as instâncias de banco de dados de leitor, uma por vez. Depois, uma das instâncias de banco de dados de leitor passa a ser a nova instância de banco de dados de gravador. Depois, o Amazon RDS atualiza a antiga instância de gravador (que agora é uma instância de leitor). O tempo de inatividade da atualização de uma versão secundária de uma implantação de *instância* de banco de dados multi-AZ pode ser de alguns minutos. Os clusters de banco de dados multi-AZ normalmente reduzem o tempo de inatividade de atualizações de versões secundárias para aproximadamente 35 segundos. Quando usado com o RDS Proxy, é possível reduzir ainda mais o tempo de inatividade para um segundo ou menos. Para obter mais informações, consulte [Amazon RDS Proxy](rds-proxy.md). Como alternativa, é possível usar um proxy de banco de dados de código aberto, como [ProxySQL](https://aws.amazon.com/blogs/database/achieve-one-second-or-less-of-downtime-with-proxysql-when-upgrading-amazon-rds-multi-az-deployments-with-two-readable-standbys/), [PgBouncer](https://aws.amazon.com/blogs/database/fast-switchovers-with-pgbouncer-on-amazon-rds-multi-az-deployments-with-two-readable-standbys-for-postgresql/) ou [driver avançado de encapsulamento JDBC da AWS](https://aws.amazon.com/blogs/database/achieve-one-second-or-less-downtime-with-the-advanced-jdbc-wrapper-driver-when-upgrading-amazon-rds-multi-az-db-clusters/). O Amazon RDS também comporta a política de implementação de atualizações para gerenciar atualizações automáticas de versões secundárias em vários recursos de banco de dados e Contas da AWS. Para obter mais informações, consulte [Usar a política de implementação de atualização do AWS Organizations para atualizações automáticas de versões secundárias](RDS.Maintenance.AMVU.UpgradeRollout.md). Se a instância de banco de dados do MySQL usar réplicas de leitura, atualize todas as réplicas de leitura antes de atualizar a instância de origem. **Topics** + [ ## Considerações sobre as atualizações do MySQL ](#USER_UpgradeDBInstance.MySQL.Considerations) + [ ## Encontrar destinos de atualização válidos ](#USER_UpgradeDBInstance.MySQL.FindingTargets) + [ # Números de versão do MySQL ](USER_UpgradeDBInstance.MySQL.VersionID.md) + [ # Números de versão do RDS no RDS para MySQL ](USER_UpgradeDBInstance.MySQL.rds.version.md) + [ # Atualizações da versão principal do RDS para MySQL ](USER_UpgradeDBInstance.MySQL.Major.md) + [ # Testar uma atualização do RDS para MySQL ](USER_UpgradeDBInstance.MySQL.UpgradeTesting.md) + [ ## Atualizar uma instância de banco de dados MySQL ](#USER_UpgradeDBInstance.MySQL.Upgrading) + [ # Atualizações automáticas da versão secundária do RDS para MySQL ](USER_UpgradeDBInstance.MySQL.Minor.md) + [ # Usar uma réplica de leitura para reduzir o tempo de inatividade ao atualizar um banco de dados do RDS para MySQL ](USER_UpgradeDBInstance.MySQL.ReducedDowntime.md) + [ # Monitorar atualizações do mecanismo do RDS para MySQL com eventos ](USER_UpgradeDBInstance.MySQL.Monitoring.md) ## Considerações sobre as atualizações do MySQL O Amazon RDS usa dois ou mais snapshots de banco de dados durante o processo de upgrade. O Amazon RDS gera até dois snapshots da instância de banco de dados *antes* de fazer qualquer alteração de upgrade. Se o upgrade não funcionar para seus bancos de dados, você poderá restaurar um desses snapshots para criar uma instância de banco de dados executando a versão antiga. O Amazon RDS gera outro snapshot da instância de banco de dados quando o upgrade é concluído. O Amazon RDS obtém esses snapshots independentemente de o AWS Backup gerenciar ou não os backups da instância de banco de dados. **nota** O Amazon RDS só tirará snapshot de banco de dadoss se você tiver definido o período de retenção de backup para sua instância de banco de dados como um número maior que 0. Para alterar o período de retenção de backup, consulte [Modificar uma instância de banco de dados do Amazon RDS](Overview.DBInstance.Modifying.md). Após a conclusão da atualização, você não pode reverter para a versão anterior do mecanismo de banco de dados. Se quiser retornar à versão anterior, restaure o primeiro DB snapshot tirado para criar outra instância de banco de dados. Você controla quando atualizar sua instância do banco de dados para uma nova versão compatível com o Amazon RDS. Esse nível de controle ajuda você a manter a compatibilidade com versões específicas de banco de dados e testar novas versões com seu aplicativo antes de implantá-lo na produção. Quando você estiver pronto, poderá executar as atualizações de versão quando achar melhor. Se a instância de banco de dados usar replicação, atualize todas as réplicas de leitura antes de atualizar a instância de origem. ## Encontrar destinos de atualização válidos Ao usar o Console de gerenciamento da AWS para atualizar uma instância de banco de dados, ele exibe os destinos de atualização válidos para a instância de banco de dados. Também é possível executar o seguinte comando da AWS CLI para identificar os destinos de atualizações válidos para uma instância de banco de dados: Para Linux, macOS ou Unix: ``` aws rds describe-db-engine-versions \ --engine mysql \ --engine-version version_number \ --query "DBEngineVersions[*].ValidUpgradeTarget[*].{EngineVersion:EngineVersion}" --output text ``` Para Windows: ``` aws rds describe-db-engine-versions ^ --engine mysql ^ --engine-version version_number ^ --query "DBEngineVersions[*].ValidUpgradeTarget[*].{EngineVersion:EngineVersion}" --output text ``` Por exemplo, para identificar os destinos de upgrades válidos para uma instância de banco de dados do MySQL versão 8.0.28, execute o seguinte comando da AWS CLI: Para Linux, macOS ou Unix: ``` aws rds describe-db-engine-versions \ --engine mysql \ --engine-version 8.0.28 \ --query "DBEngineVersions[*].ValidUpgradeTarget[*].{EngineVersion:EngineVersion}" --output text ``` Para Windows: ``` aws rds describe-db-engine-versions ^ --engine mysql ^ --engine-version 8.0.28 ^ --query "DBEngineVersions[*].ValidUpgradeTarget[*].{EngineVersion:EngineVersion}" --output text ``` # Números de versão do MySQL A sequência de numeração de versões do mecanismo de banco de dados do RDS para MySQL está no formato *major.minor.patch.YYYYMMDD* ou *major.minor.patch*, por exemplo, 8.0.33.R2.20231201 ou 5.7.44. O formato usado depende da versão do mecanismo do MySQL. Consulte informações sobre a numeração de versão do Suporte estendido do RDS em [Nomenclatura da versão do Suporte estendido do Amazon RDS](extended-support-versions.md#extended-support-naming). **principal** O número da versão principal é o número inteiro e a primeira parte fracionária do número da versão, por exemplo, 8.0. Uma atualização de versão principal aumenta a parte principal do número da versão. Por exemplo, uma atualização de *5.7*.44 para 8.0.33 é uma atualização de versão principal, em que *5.7* e *8.0* são os números da versão principal. **secundária** O número da versão secundária é a terceira parte do número da versão, por exemplo, 33 em 8.0.33. **patch** O patch é a quarta parte do número da versão, por exemplo, o R2 em 8.0.33.R2. Uma versão do patch do RDS inclui correções de bugs importantes adicionadas a uma versão secundária após o lançamento. **YYYYMMDD** O patch é a quinta parte do número da versão, por exemplo, 20231201 em 8.0.33.R2.20231201. Uma versão da data do RDS é um patch de segurança que inclui correções de segurança importantes adicionadas a uma versão secundária após o lançamento. Ela não inclui nenhuma correção que possa mudar o comportamento de um mecanismo. A tabela a seguir explica o esquema de nomenclatura do RDS para MySQL versão 8.4. | Versão secundária 8.4 | Esquema da nomenclatura | | --- | --- | | ≥ 3 | Novas instâncias de banco de dados usam *major.minor.patch.YYMMDD*, por exemplo, 8.4.3.R2.20241201. As instâncias de banco de dados existentes podem usar *major.minor.patch*, por exemplo, 8.4.3.R2, até a próxima atualização de versão principal ou secundária. | A tabela a seguir explica o esquema de nomenclatura do RDS para MySQL versão 8.0. | 8.0 versão secundária | Esquema da nomenclatura | | --- | --- | | ≥ 33 | Novas instâncias de banco de dados usam *major.minor.patch.YYMMDD*, por exemplo, 8.0.33.R2.20231201. As instâncias de banco de dados existentes podem usar *major.minor.patch*, por exemplo, 8.0.33.R2, até a próxima atualização de versão principal ou secundária. | | < 33 | As instâncias de banco de dados existentes usam *major.minor.patch*, por exemplo, 8.0.32.R2. | A tabela a seguir explica o esquema de nomenclatura do RDS para MySQL versão 5.7. | 5.7 versão secundária | Esquema da nomenclatura | | --- | --- | | ≥ 42 | Novas instâncias de banco de dados usam *major.minor.patch.YYMMDD*, por exemplo, 5.7.42.R2.20231201. As instâncias de banco de dados existentes podem usar *major.minor.patch*, por exemplo, 5.7.42.R2, até a próxima atualização de versão principal ou secundária. | # Números de versão do RDS no RDS para MySQL Os números de versão do RDS usam o esquema de nomenclatura `major.minor.patch` ou `major.minor.patch.YYYYMMDD`. As versões do Suporte estendido do Amazon RDS usam o esquema de nomenclatura de versões secundárias *minor-RDS.AAAAMMDD*. Uma versão do patch do RDS inclui correções de bugs importantes adicionadas a uma versão secundária após o lançamento. Uma versão de data do RDS (*AAAAMMDD*) é um patch de segurança. Um patch de segurança não inclui nenhuma correção que possa mudar o comportamento do mecanismo. Consulte informações sobre a numeração de versão do Suporte estendido do RDS em [Nomenclatura da versão do Suporte estendido do Amazon RDS](extended-support-versions.md#extended-support-naming). É possível descobrir o número da versão do RDS do banco de dados do RDS para MySQL com a seguinte consulta SQL: ``` mysql> select mysql.rds_version(); ``` Por exemplo, consultar um banco de dados do RDS para MySQL 8.0.34 exibe a seguinte saída: ``` +---------------------+ | mysql.rds_version() | +---------------------+ | 8.0.34.R2.20231201 | +---------------------+ 1 row in set (0.01 sec) ``` # Atualizações da versão principal do RDS para MySQL O Amazon RDS oferece suporte para as seguintes atualizações in-loco para versões principais do mecanismo de banco de dados MySQL: + MySQL 5.7 a MySQL 8.0 + MySQL 8.0 a MySQL 8.4 **nota** Você só pode criar instâncias de banco de dados MySQL versões 5.7, 8.0 e 8.4 com classes de instância de banco de dados de última geração e da geração atual. Em alguns casos, você deseja atualizar uma instância de banco de dados em execução em uma classe de instância de banco de dados de geração anterior com uma versão do mecanismo MySQL posterior. Nesses casos, primeiro modifique a instância de banco de dados para usar uma classe de instância de última geração ou de geração atual. Depois de fazer isso, você poderá modificar a instância de banco de dados para usar a versão de mecanismo de banco de dados MySQL posterior. Para obter informações sobre classes de instâncias de banco de dados do Amazon RDS, consulte [Classes de instâncias de banco de dados do ](Concepts.DBInstanceClass.md). **Topics** + [ ## Visão geral de atualizações de versões principais do MySQL ](#USER_UpgradeDBInstance.MySQL.Major.Overview) + [ ## Pré-verificações de atualizações ](#USER_UpgradeDBInstance.MySQL.Prechecks) + [ ## Reversão após falha na atualização ](#USER_UpgradeDBInstance.MySQL.Major.RollbackAfterFailure) ## Visão geral de atualizações de versões principais do MySQL As atualizações da versão principal podem conter as alterações de banco de dados incompatíveis com os aplicativos existentes. Como resultado, o Amazon RDS não aplica atualizações da versão principal automaticamente. Você deve modificar manualmente sua instância de banco de dados. Convém testar completamente qualquer atualização antes de aplicá-la às suas instâncias de produção. Para realizar uma atualização de versão principal, primeiro execute todas as atualizações de sistema operacional disponíveis. Após a conclusão das atualizações do sistema operacional, atualize para as versões principais, por exemplo, de 5.7 para 8.0 e, depois, para 8.4. Para obter informações sobre a atualização de um cluster de banco de dados multi-AZ do RDS para MySQL, consulte [Atualização da versão de mecanismo de um cluster de banco de dados multi-AZ para o Amazon RDS](multi-az-db-clusters-upgrading.md). As instâncias de banco de dados MySQL criadas antes de 24 de abril de 2014 mostrarão uma atualização do sistema operacional disponível enquanto a atualização não for aplicada. Para obter mais informações sobre atualizações do sistema operacional, consulte [Aplicar atualizações para uma instânciade banco de dados](USER_UpgradeDBInstance.Maintenance.md#USER_UpgradeDBInstance.OSUpgrades). Durante uma atualização de versão principal do MySQL, o Amazon RDS executa o binário do MySQL `mysql_upgrade` para atualizar tabelas, se necessário. Além disso, o Amazon RDS esvazia as tabelas `slow_log` e `general_log` durante uma atualização de versão principal. Para preservar as informações do log, salve o conteúdo do log antes da atualização da versão principal. Em geral, as atualizações da versão principal do MySQL são concluídas em cerca de 10 minutos. Algumas atualizações podem demorar mais por causa do tamanho da classe da instância de banco de dados ou porque a instância não segue certas diretrizes operacionais em [Práticas recomendadas do Amazon RDS](CHAP_BestPractices.md). Se você atualizar uma instância de banco de dados do console do Amazon RDS, o status dessa instância indicará quando a atualização estiver concluída. Se você atualizar usando a AWS Command Line Interface (AWS CLI), use o comando [describe-db-instances](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-instances.html) e verifique o valor de `Status`. ## Pré-verificações de atualizações O Amazon RDS executa verificações prévias antes da atualização para verificar se há incompatibilidades. Essas incompatibilidades variam de acordo com a versão do MySQL para a qual está sendo feita a atualização. As pré-verificações incluem algumas que estão incluídas com o MySQL e outras que foram criadas especificamente pela equipe do Amazon RDS. Para obter informações sobre as pré-verificações fornecidas pelo MySQL, consulte [Utilitário verificador de atualização](https://dev.mysql.com/doc/mysql-shell/8.4/en/mysql-shell-utilities-upgrade.html). As pré-verificações são executadas antes que a instância de banco de dados seja interrompida para a atualização, o que significa que elas não causam nenhum tempo de inatividade quando são executadas. Se as pré-verificações encontrarem uma incompatibilidade, o Amazon RDS cancelará automaticamente a atualização antes que a instância de banco de dados seja interrompida. O Amazon RDS também gera um evento para a incompatibilidade. Para obter mais informações sobre eventos do Amazon RDS, consulte [Trabalhar com a notificação de eventos do Amazon RDS](USER_Events.md). O Amazon RDS registra informações detalhadas sobre cada incompatibilidade no arquivo de log `PrePatchCompatibility.log`. Na maioria dos casos, a entrada de log inclui um link para a documentação do MySQL para corrigir a incompatibilidade. Para obter mais informações sobre como exibir arquivos de log, consulte [Como visualizar e listar arquivos de log do banco de dados](USER_LogAccess.Procedural.Viewing.md). Devido à natureza das pré-verificações, eles analisam os objetos do seu banco de dados. Essa análise resulta no consumo do recurso e aumenta o tempo para que a atualização seja concluída. **Topics** + [ ### Pré-verificações de atualizações do MySQL 8.0 para 8.4 ](#USER_UpgradeDBInstance.MySQL.80to84Prechecks) + [ ### Pré-verificações de upgrades do MySQL 5.7 a 8.0 ](#USER_UpgradeDBInstance.MySQL.57to80Prechecks) ### Pré-verificações de atualizações do MySQL 8.0 para 8.4 O MySQL 8.4 inclui várias incompatibilidades com o MySQL 8.0. Essas incompatibilidades podem causar problemas durante uma atualização do MySQL 8.0 para o MySQL 8.4. Portanto, pode ser necessária uma certa preparação no seu banco de dados para que a atualização seja bem-sucedida. Veja a seguir uma lista geral dessas incompatibilidades: + Não deve haver tabelas que usam funções ou tipos de dados obsoletos. + Os gatilhos não devem ter um definidor vazio ou ausente ou um contexto de criação inválido. + Não deve haver violações de palavra-chave ou palavra reservada. Algumas palavras-chave podem ser reservadas no MySQL 8.4 que não eram reservadas anteriormente. Para obter mais informações, consulte [Palavras-chave e palavras reservadas](https://dev.mysql.com/doc/refman/8.4/en/keywords.html) na documentação do MySQL. + Não deve haver tabelas no banco de dados do sistema `mysql` do MySQL 8.0 com o mesmo nome de uma tabela usada pelo dicionário de dados do MySQL 8.4. + Não deve haver modos obsoletos do SQL definidos na configuração de variável do sistema `sql_mode`. + Não deve haver tabelas ou procedimentos armazenados com elementos de coluna `ENUM` ou `SET` individuais que excedam 255 caracteres ou 1020 bytes. + A instalação do MySQL 8.0 não deve usar recursos incompatíveis com o MySQL 8.4. Para obter mais informações, consulte [Recursos removidos no MySQL 8.4](https://dev.mysql.com/doc/refman/8.4/en/mysql-nutshell.html#mysql-nutshell-removals) na documentação do MySQL. + Não deve haver nomes de restrição de chave externa maiores que 64 caracteres. + Para obter suporte aprimorado ao Unicode, revise as seguintes informações: + Considere a conversão de objetos que usam o conjunto de caracteres `utf8mb3` para que usem o conjunto de caracteres `utf8mb4`. O conjunto de caracteres `utf8mb3` está obsoleto. + Considere o uso de `utf8mb4` para referências de conjuntos de caracteres em vez de `utf8`, pois, no momento, `utf8` é um alias para o conjunto de caracteres `utf8mb3`. Se possível, mude `utf8` para `utf8mb4` primeiro e, depois, faça upgrade do banco de dados. + Como clientes mais antigos podem receber um erro de conjunto de caracteres desconhecido para `utf8mb3`, faça upgrade dos clientes de banco de dados antes de fazer upgrade do banco de dados. Para obter mais informações, consulte [ The utf8mb3 character set (3-byte UTF-8 unicode encoding)](https://dev.mysql.com/doc/refman/8.4/en/charset-unicode-utf8mb3.html) na documentação do MySQL. Para alterar os conjuntos de caracteres, é possível executar manualmente o processo de backup, restauração e replicação do banco de dados. Ou você pode usar implantações azul/verde do Amazon RDS. Para obter mais informações, consulte [Usar implantações azul/verde do Amazon RDS para atualizações de banco de dados](blue-green-deployments.md). Quando você inicia uma atualização do MySQL 8.0 para 8.4, o Amazon RDS executa pré-verificações automaticamente para detectar essas incompatibilidades. Para obter informações sobre como atualizar para o MySQL 8.4, consulte [Atualização do MySQL](https://dev.mysql.com/doc/refman/8.4/en/upgrading.html) na documentação do MySQL. Essas pré-verificações são obrigatórias. Você não pode optar por ignorá-las. As pré-verificações fornecem os seguintes benefícios: + Elas permitem evitar o tempo de inatividade não planejado durante a atualização. + Se houver incompatibilidades, o Amazon RDS impedirá a atualização e fornecerá um log para que você saiba sobre elas. Dessa forma, você poderá usar o log para preparar seu banco de dados para a atualização para o MySQL 8.4 ao reduzir essas incompatibilidades. Consulte informações detalhadas sobre como remover incompatibilidades em [Preparação da instalação para atualização](https://dev.mysql.com/doc/refman/8.4/en/upgrade-prerequisites.html) na documentação do MySQL. ### Pré-verificações de upgrades do MySQL 5.7 a 8.0 O MySQL 8.0 inclui várias incompatibilidades com o MySQL 5.7. Essas incompatibilidades podem causar problemas durante uma atualização do MySQL 5.7 para o MySQL 8.0. Portanto, pode ser necessária uma certa preparação no seu banco de dados para que a atualização seja bem-sucedida. Veja a seguir uma lista geral dessas incompatibilidades: + Não deve haver tabelas que usam funções ou tipos de dados obsoletos. + Não deve haver arquivos \$1.frm órfãos. + Os gatilhos não devem ter um definidor vazio ou ausente ou um contexto de criação inválido. + Não deve haver tabela particionada que usa um mecanismo de armazenamento que não tem suporte para particionamento nativo, + Não deve haver violações de palavra-chave ou palavra reservada. Algumas palavras-chave podem ser reservadas no MySQL 8.0 que não eram reservadas anteriormente. Para obter mais informações, consulte [Palavras-chave e palavras reservadas](https://dev.mysql.com/doc/refman/8.0/en/keywords.html) na documentação do MySQL. + Não deve haver tabelas no banco de dados do sistema `mysql` do MySQL 5.7 com o mesmo nome de uma tabela usada pelo dicionário de dados do MySQL 8.0. + Não deve haver modos obsoletos do SQL definidos na configuração de variável do sistema `sql_mode`. + Não deve haver tabelas ou procedimentos armazenados com elementos de coluna `ENUM` ou `SET` individuais que excedam 255 caracteres ou 1020 bytes. + Antes de atualizar para o MySQ 8.0.13 ou posterior, não deve haver partições de tabela que residam em espaços de tabela compartilhados do InnoDB. + Não deve haver consultas e definições de programa armazenadas do MySQL 8.0.12 ou anterior que usem qualificadores `ASC` ou `DESC` para causas `GROUP BY`. + A instalação do MySQL 5.7 não deve usar recursos incompatíveis com o MySQL 8.0. Para obter mais informações, consulte [ Recursos removidos no MySQL 8.0](https://dev.mysql.com/doc/refman/8.0/en/mysql-nutshell.html#mysql-nutshell-removals) na documentação do MySQL. + Não deve haver nomes de restrição de chave externa maiores que 64 caracteres. + Para obter suporte aprimorado ao Unicode, revise as seguintes informações: + Considere a conversão de objetos que usam o conjunto de caracteres `utf8mb3` para que usem o conjunto de caracteres `utf8mb4`. O conjunto de caracteres `utf8mb3` está obsoleto. + Considere o uso de `utf8mb4` para referências de conjuntos de caracteres em vez de `utf8`, pois, no momento, `utf8` é um alias para o conjunto de caracteres `utf8mb3`. Se possível, mude `utf8` para `utf8mb4` primeiro e, depois, faça upgrade do banco de dados. + Como clientes mais antigos podem receber um erro de conjunto de caracteres desconhecido para `utf8mb3`, faça upgrade dos clientes de banco de dados antes de fazer upgrade do banco de dados. Para obter mais informações, consulte [ The utf8mb3 character set (3-byte UTF-8 unicode encoding)](https://dev.mysql.com/doc/refman/8.4/en/charset-unicode-utf8mb3.html) na documentação do MySQL. Para alterar os conjuntos de caracteres, é possível executar manualmente o processo de backup, restauração e replicação do banco de dados. Ou você pode usar implantações azul/verde do Amazon RDS. Para obter mais informações, consulte [Usar implantações azul/verde do Amazon RDS para atualizações de banco de dados](blue-green-deployments.md). Quando você inicia uma atualização do MySQL 5,7 para 8,0, o Amazon RDS executa pré-verificações automaticamente para detectar essas incompatibilidades. Para obter informações sobre como atualizar para o MySQL 8.0, consulte [Upgrading MySQL (em inglês)](https://dev.mysql.com/doc/refman/8.0/en/upgrading.html) na documentação do MySQL. Essas pré-verificações são obrigatórias. Você não pode optar por ignorá-las. As pré-verificações fornecem os seguintes benefícios: + Elas permitem evitar o tempo de inatividade não planejado durante a atualização. + Se houver incompatibilidades, o Amazon RDS impedirá a atualização e fornecerá um log para que você saiba sobre elas. Dessa forma, você poderá usar o log para preparar seu banco de dados para a atualização para o MySQL 8.0 ao reduzir essas incompatibilidades. Para obter informações detalhadas sobre como remover incompatibilidades, consulte [Preparing your installation for upgrade](https://dev.mysql.com/doc/refman/8.0/en/upgrade-prerequisites.html) na documentação do MySQL e [Upgrading to MySQL 8.0? Here is what you need to know...](https://dev.mysql.com/blog-archive/upgrading-to-mysql-8-0-here-is-what-you-need-to-know/) no blog do MySQL Server. ## Reversão após falha na atualização Quando você atualiza uma instância de banco de dados do MySQL versão 5.7 para o MySQL versão 8.0 ou do MySQL versão 8.0 para 8.4, a atualização pode falhar. Em particular, ela pode falhar se o dicionário de dados contiver incompatibilidades que não foram capturadas pelas pré-verificações. Nesse caso, não é possível iniciar o banco de dados com sucesso na nova versão do MySQL, a 8.0 ou 8.4. Nesse ponto, o Amazon RDS reverte as alterações realizadas para a atualização. Após a reversão, a instância de banco de dados MySQL executa a versão original: + MySQL versão 8.0 (para uma reversão do MySQL 8.4) + MySQL versão 5.7 (para uma reversão do MySQL 8.0) Quando uma atualização falha e é revertida, o Amazon RDS gera um evento com o ID de evento RDS-EVENT-0188. Normalmente, uma atualização falha porque há incompatibilidades nos metadados entre os bancos de dados em sua instância de banco de dados e a versão de destino do MySQL. Quando uma atualização falha, você pode visualizar os detalhes sobre essas incompatibilidades no arquivo `upgradeFailure.log`. Resolva as incompatibilidades antes de tentar atualizar novamente. Durante uma tentativa de atualização e reversão malsucedidas, sua instância de banco de dados é reiniciada. Quaisquer alterações de parâmetro pendentes são aplicadas durante a reinicialização e persistem após a reversão. Para obter mais informações sobre como atualizar para o MySQL 8.0, consulte os seguintes tópicos na documentação do MySQL: + [ Preparing Your Installation for Upgrade](https://dev.mysql.com/doc/refman/8.0/en/upgrade-prerequisites.html) + [ Upgrading to MySQL 8.0? Here is what you need to know…](https://dev.mysql.com/blog-archive/upgrading-to-mysql-8-0-here-is-what-you-need-to-know/) Para obter mais informações sobre como atualizar para o MySQL 8.4, consulte [Preparação da instalação para atualização](https://dev.mysql.com/doc/refman/8.4/en/upgrade-prerequisites.html) na documentação do MySQL. # Testar uma atualização do RDS para MySQL Antes de executar uma atualização de versão principal na sua instância de banco de dados, você deve testar completamente seu banco de dados para verificar a compatibilidade com a nova versão. Além disso, teste exaustivamente todos os aplicativos que acessam o banco de dados para compatibilidade com a nova versão. Recomendamos que você use o procedimento a seguir. **Para testar um upgrade de versão principal** 1. Reveja a documentação de upgrade para a nova versão do mecanismo de banco de dados para ver se existem problemas de compatibilidade que podem afetar seu banco de dados ou seus aplicativos: + [Alterações feitas no MySQL 5.7](http://dev.mysql.com/doc/refman/5.7/en/upgrading-from-previous-series.html) + [Alterações feitas no MySQL 8.0](http://dev.mysql.com/doc/refman/8.0/en/upgrading-from-previous-series.html) + [Alterações feitas no MySQL 8.4](http://dev.mysql.com/doc/refman/8.4/en/upgrading-from-previous-series.html) 1. Se a sua instância de banco de dados for um membro de um grupo de parâmetros de banco de dados personalizado, crie um novo grupo de parâmetros de banco de dados com as configurações existentes que seja compatível com a nova versão principal. Especifique o novo grupo de parâmetros de banco de dados quando você atualizar sua instância de teste, de modo que seu teste de atualização garanta que ela funcione corretamente. Para obter mais informações sobre como criar um parameter group de banco de dados, consulte [Grupos de parâmetros para Amazon RDS](USER_WorkingWithParamGroups.md). 1. Crie um snapshot de banco de dados da instância de banco de dados a ser atualizada. Para ter mais informações, consulte [Criar um snapshot de banco de dados para uma instância de banco de dados single-AZ para o Amazon RDS](USER_CreateSnapshot.md). 1. Restaure o snapshot de banco de dados para criar uma nova instância de banco de dados de teste. Para obter mais informações, consulte [Restaurar uma instância de banco de dados](USER_RestoreFromSnapshot.md). 1. Modifique essa nova instância de banco de dados de teste para atualizá-la para a nova versão, usando um dos métodos detalhados a seguir. Se você criou um novo parameter group na etapa 2, especifique-o. 1. Avalie o armazenamento usado pela instância atualizada para determinar se o upgrade requer armazenamento adicional. 1. Execute quantos testes de garantia de qualidade na instância de banco de dados atualizada forem necessários para garantir que o seu banco de dados e o seu aplicativo funcionem corretamente com a nova versão. Implemente os novos testes necessários para avaliar o impacto de problemas de compatibilidade que você identificou na etapa 1. Teste todos os procedimentos armazenados e funções. Direcione versões de teste dos seus aplicativos à instância de banco de dados atualizada. 1. Se todos os testes forem aprovados, realize o upgrade na sua instância de banco de dados de produção. Recomendamos que você não permita operações de gravação na instância de banco de dados até confirmar que tudo está funcionando corretamente. ## Atualizar uma instância de banco de dados MySQL Para obter informações sobre como atualizar manual ou automaticamente uma instância de banco de dados MySQL, consulte [Atualizar a versão de mecanismo de uma instância de banco de dados ](USER_UpgradeDBInstance.Upgrading.md). # Atualizações automáticas da versão secundária do RDS para MySQL Se você especificar as seguintes configurações ao criar ou modificar uma instância de banco de dados, poderá fazer com que sua instância de banco de dados seja atualizada automaticamente. + A configuração **Auto minor version upgrade (Atualização automática de versão secundária)** está habilitada. + A configuração **Backup retention period (Período de retenção de backup)** é maior que 0. No Console de gerenciamento da AWS, essas configurações estão em **Additional configuration** (Configuração adicional). A imagem a seguir mostra a configuração **Auto minor version upgrade** (Atualização automática para versão secundária). ![\[A seção Manutenção com Habilitar atualização automática de versão secundária selecionada no console do Amazon RDS.\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/UserGuide/images/amvu.png) Para ter mais informações sobre essas configurações, consulte [Configurações para instâncias de banco de dados](USER_ModifyInstance.Settings.md). Para algumas versões principais do RDS para MySQL em algumas Regiões da AWS, uma versão secundária é designada pelo RDS como a versão de atualização automática. Depois que uma versão secundária foi testada e aprovada pelo Amazon RDS, a atualização de versão secundária ocorre automaticamente durante a janela de manutenção. O RDS não define automaticamente versões secundárias lançadas mais recentemente como a versão de atualização automática. Antes de o RDS designar uma versão de atualização automática, diversos critérios são considerados, como estes: + Problemas de segurança conhecidos + Bugs na versão da comunidade do MySQL + Estabilidade geral de frota desde que a versão secundária foi lançada. É possível executar o comando da AWS CLI a seguir para determinar a versão atual secundária de destino de atualização automática para uma versão secundária do MySQL especificada em uma Região da AWS específica. Para Linux, macOS ou Unix: ``` aws rds describe-db-engine-versions \ --engine mysql \ --engine-version minor_version \ --region region \ --query "DBEngineVersions[*].ValidUpgradeTarget[*].{AutoUpgrade:AutoUpgrade,EngineVersion:EngineVersion}" \ --output text ``` Para Windows: ``` aws rds describe-db-engine-versions ^ --engine mysql ^ --engine-version minor_version ^ --region region ^ --query "DBEngineVersions[*].ValidUpgradeTarget[*].{AutoUpgrade:AutoUpgrade,EngineVersion:EngineVersion}" ^ --output text ``` Por exemplo, o comando da AWS CLI a seguir determina o destino de atualização secundária automática para a versão 8.0.11 secundária do MySQL na Região da AWS Leste dos EUA (Ohio) (us-east-2). Para Linux, macOS ou Unix: ``` aws rds describe-db-engine-versions \ --engine mysql \ --engine-version 8.0.11 \ --region us-east-2 \ --query "DBEngineVersions[*].ValidUpgradeTarget[*].{AutoUpgrade:AutoUpgrade,EngineVersion:EngineVersion}" \ --output table ``` Para Windows: ``` aws rds describe-db-engine-versions ^ --engine mysql ^ --engine-version 8.0.11 ^ --region us-east-2 ^ --query "DBEngineVersions[*].ValidUpgradeTarget[*].{AutoUpgrade:AutoUpgrade,EngineVersion:EngineVersion}" ^ --output table ``` A saída é semelhante à seguinte. ``` ---------------------------------- | DescribeDBEngineVersions | +--------------+-----------------+ | AutoUpgrade | EngineVersion | +--------------+-----------------+ | False | 8.0.15 | | False | 8.0.16 | | False | 8.0.17 | | False | 8.0.19 | | False | 8.0.20 | | False | 8.0.21 | | True | 8.0.23 | | False | 8.0.25 | +--------------+-----------------+ ``` Neste exemplo, o valor de `AutoUpgrade` é `True` para o MySQL versão 8.0.23. Portanto, o destino de upgrade secundário automático é o MySQL versão 8.0.23, que está realçado na saída. Uma instância de banco de dados MySQL é atualizada automaticamente durante a janela de manutenção, caso os seguintes critérios sejam atendidos: + A configuração **Auto minor version upgrade (Atualização automática de versão secundária)** está habilitada. + A configuração **Backup retention period (Período de retenção de backup)** é maior que 0. + A instância de banco de dados está executando uma versão de mecanismo de banco de dados secundária que é menor que a versão secundária de atualização automática. Para obter mais informações, consulte [Atualizar automaticamente a versão do mecanismo espelho](USER_UpgradeDBInstance.Upgrading.md#USER_UpgradeDBInstance.Upgrading.AutoMinorVersionUpgrades). # Usar uma réplica de leitura para reduzir o tempo de inatividade ao atualizar um banco de dados do RDS para MySQL Na maioria dos casos, uma implantação azul/verde é a melhor opção para reduzir o tempo de inatividade ao atualizar uma instância de banco de dados MySQL. Para ter mais informações, consulte [Usar implantações azul/verde do Amazon RDS para atualizações de banco de dados](blue-green-deployments.md). Se não for possível usar uma implantação azul/verde e se sua instância de banco de dados MySQL estiver em uso com uma aplicação de produção, você poderá usar o procedimento a seguir para atualizar a versão de banco de dados da sua instância de banco de dados. Esse procedimento pode reduzir o tempo de inatividade do seu aplicativo. Usando uma réplica de leitura, você pode executar a maioria das etapas de manutenção antes do tempo e minimizar as alterações necessárias durante a interrupção real. Com essa técnica, você pode testar e preparar a nova instância de banco de dados sem fazer alterações em sua instância de banco de dados existente. O procedimento a seguir mostra um exemplo de atualização do MySQL versão 5.7 para o MySQL versão 8.0. Você pode usar as mesmas etapas gerais nas atualizações para outras versões principais. Você pode usar as mesmas etapas gerais nas atualizações para outras versões principais. **nota** Quando você estiver atualizando do MySQL versão 5.7 para o MySQL versão 8.0 ou do MySQL versão 8.0 para o MySQL versão 8.4, conclua as pré-verificações antes de executar a atualização. Para ter mais informações, consulte [Pré-verificações de upgrades do MySQL 5.7 a 8.0](USER_UpgradeDBInstance.MySQL.Major.md#USER_UpgradeDBInstance.MySQL.57to80Prechecks) e [Pré-verificações de atualizações do MySQL 8.0 para 8.4](USER_UpgradeDBInstance.MySQL.Major.md#USER_UpgradeDBInstance.MySQL.80to84Prechecks). **Como atualizar um banco de dados MySQL enquanto uma instância de banco de dados está em uso** 1. Faça login no Console de gerenciamento da AWS e abra o console do Amazon RDS em [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/). 1. Crie uma réplica de leitura da instância de banco de dados MySQL 5.7. Esse processo cria uma cópia atualizável do seu banco de dados. Outras réplicas de leitura da instância de banco de dados também podem existir. 1. No console, escolha **Databases (Bancos de dados)** e depois escolha a instância de banco de dados que você deseja atualizar. 1. Em **Actions (Ações)**, escolha **Create read replica (Criar réplica de leitura)**. 1. Forneça o valor do **DB instance identifier (Identificador de instância de banco de dados)** para a réplica de leitura e verifique se a **DB instance class (Classe da instância de banco de dados)** e as outras configurações correspondem à instância de banco de dados MySQL 5.7. 1. Escolha **Create read replica (Criar réplica de leitura)**. 1. (Opcional) Quando a réplica de leitura for criada e **Status** for exibida **Available (Disponível)**, converta a réplica de leitura em uma implantação multi-AZ e ative backups. Por padrão, uma réplica de leitura é criada com backups desabilitados. Como a réplica de leitura se torna a instância de banco de dados de produção, uma prática recomendada é configurar uma implantação multi-AZ e habilitar backups. 1. No console, selecione **Databases (Bancos de dados)** e a réplica de leitura que você acabou de criar. 1. Selecione **Modify**. 1. Para **Multi-AZ deployment (Implantação multi-AZ)**, escolha **Create a standby instance (Criar uma instância em espera)**. 1. Em **Backup Retention Period** (Período de retenção de backup), escolha um valor positivo diferente de zero, como 3 dias, depois selecione **Continue** (Continuar). 1. Em **Scheduling of modifications (Programação de modificações)**, selecione **Apply immediately (Aplicar imediatamente)**. 1. Selecione **Modify DB instance (Modificar instância de banco de dados)**. 1. Quando o **Status** da réplica de leitura mostrar **Available (Disponível)**, atualize a réplica de leitura para o MySQL 8.0: 1. No console, selecione **Databases (Bancos de dados)** e a réplica de leitura que você acabou de criar. 1. Selecione **Modify**. 1. Em **DB engine version (Versão do mecanismo de banco de dados)**, selecione a versão do MySQL 8.0 para a qual atualizar e, em seguida, selecione **Continue (Continuar)**. 1. Em **Scheduling of modifications (Programação de modificações)**, selecione **Apply immediately (Aplicar imediatamente)**. 1. Selecione **Modify DB instance (Modificar instância de banco de dados)** para iniciar a atualização. 1. Quando a atualização for concluída e o **Status** mostrar **Disponível**, verifique se a réplica de leitura foi atualizada com a instância de banco de dados MySQL 5.7 de origem. Para verificar, conecte-se à réplica de leitura e execute o comando `SHOW REPLICA STATUS`. Se o campo `Seconds_Behind_Master` for `0`, a replicação está atualizada. **nota** As versões anteriores do MySQL usavam `SHOW SLAVE STATUS` em vez de `SHOW REPLICA STATUS`. Se você estiver usando uma versão do MySQL anterior à 8.0.23, use `SHOW SLAVE STATUS`. 1. (Opcional) Crie uma réplica de leitura da réplica de leitura. Se você quiser que a instância de banco de dados tenha uma réplica de leitura depois que ela for promovida para uma instância de banco de dados autônoma, você pode criar a réplica de leitura agora. 1. No console, selecione **Databases (Bancos de dados)** e selecione a réplica de leitura que você acabou de atualizar. 1. Em **Actions (Ações)**, escolha **Create read replica (Criar réplica de leitura)**. 1. Forneça o valor do **DB instance identifier (Identificador de instância de banco de dados)** para a réplica de leitura e verifique se a **DB instance class (Classe da instância de banco de dados)** e as outras configurações correspondem à instância de banco de dados MySQL 5.7. 1. Escolha **Create read replica (Criar réplica de leitura)**. 1. (Opcional) Configure um grupo de parâmetros de banco de dados personalizado para a réplica de leitura. Se você quiser que a instância de banco de dados use um grupo de parâmetros personalizado depois de ser promovida para uma instância de banco de dados autônoma, poderá criar o grupo de parâmetros de banco de dados agora pode associá-lo à réplica de leitura. 1. Crie um grupo de parâmetros de banco de dados personalizado para o MySQL 8.0. Para obter instruções, consulte [Criar um grupo de parâmetros de banco de dados no Amazon RDS](USER_WorkingWithParamGroups.Creating.md). 1. Modifique os parâmetros que você deseja alterar no grupo de parâmetros de banco de dados que você acabou de criar. Para obter instruções, consulte [Modificar parâmetros em um grupo de parâmetros de banco de dados no Amazon RDS](USER_WorkingWithParamGroups.Modifying.md). 1. No console, selecione **Databases (Bancos de dados)** e a réplica de leitura. 1. Selecione **Modify**. 1. Para o **DB parameter group (Grupo de parâmetros do banco de dados)**, escolha o grupo de parâmetros do banco de dados MySQL 8.0 que você acabou de criar e, em seguida, escolha **Continue (Continuar)**. 1. Em **Scheduling of modifications (Programação de modificações)**, selecione **Apply immediately (Aplicar imediatamente)**. 1. Selecione **Modify DB instance (Modificar instância de banco de dados)** para iniciar a atualização. 1. Torne sua réplica de leitura MySQL 8.0 uma instância de banco de dados autônoma. **Importante** Quando você promove a réplica de leitura do MySQL 8.0 para uma instância de banco de dados autônoma, ela deixa de ser uma réplica da instância de banco de dados MySQL 5.7. Recomendamos que você promova a replica de leitura do MySQL 8.0 durante uma janela de manutenção, quando a instância de banco de dados MySQL 5.7 estiver no modo somente leitura e todas as operações de gravação estiverem suspensas. Quando a promoção terminar, você poderá direcionar suas operações de gravação para a instância de banco de dados MySQL 8.0 atualizada, para garantir que nenhuma operação de gravação seja perdida. Além disso, recomendamos que, antes de promover a réplica de leitura do MySQL 8.0, você realize todas as operações de DDL (linguagem de definição de dados) necessárias na réplica de leitura do MySQL 8.0. Um exemplo é a criação de índices. Essa abordagem evita efeitos negativos sobre a performance da réplica de leitura do MySQL 8.0 após a sua promoção. Para promover uma réplica de leitura, use o procedimento a seguir. 1. No console, selecione **Databases (Bancos de dados)** e selecione a réplica de leitura que você acabou de atualizar. 1. Em **Actions (Ações)**, selecione **Promote (Promover)**. 1. Selecione **Yes (Sim)** para habilitar backups automatizados da instância da réplica de leitura. Para obter mais informações, consulte [Introdução aos backups](USER_WorkingWithAutomatedBackups.md). 1. Escolha **Continue**. 1. Escolha **Promote Read Replica (Promover réplica de leitura)**. 1. Agora, você possui uma versão atualizada do seu banco de dados MySQL. Neste ponto, você pode direcionar as aplicações para a nova instância de banco de dados MySQL 8.0. # Monitorar atualizações do mecanismo do RDS para MySQL com eventos Quando você atualiza a versão do mecanismo de um banco de dados do RDS para MySQL, o Amazon RDS emite um evento específico durante cada fase do processo. Para acompanhar o progresso de uma atualização, você pode visualizar ou assinar esses eventos. Para acessar mais informações sobre eventos do RDS, consulte [Monitorar eventos do Amazon RDS](working-with-events.md). Para acessar informações detalhadas sobre um evento específico do Amazon RDS ocorrido durante a atualização do seu mecanismo, consulte [Categorias de eventos e mensagens de eventos ](USER_Events.Messages.md). # Atualizar uma versão do mecanismo de snapshot de banco de dados do MySQL Com o Amazon RDS, você pode criar um snapshot de banco de dados do volume de armazenamento de sua instância de banco de dados MySQL. Ao criar um snapshot de banco de dados, ele é baseado na versão do mecanismo usada pela instância de banco de dados. É possível fazer a atualização da versão do mecanismo para os snapshots de banco de dados. Para o RDS para MySQL, é possível atualizar um snapshot versão 5.7 para a versão 8.0 ou um snapshot versão 8.0 para a versão 8.4. É possível atualizar snapshots de banco de dados criptografados ou não criptografados. Para visualizar as versões de mecanismo disponíveis para o snapshot de banco de dados do RDS para MySQL, use o exemplo da AWS CLI a seguir. ``` aws rds describe-db-engine-versions --engine mysql --include-all --engine-version example-engine-version --query "DBEngineVersions[*].ValidUpgradeTarget[*].{EngineVersion:EngineVersion}" --output text ``` Se você não vir resultados para o snapshot, a versão do seu mecanismo pode estar obsoleta. Se a versão do mecanismo tiver sido descontinuada, recomendamos que você atualize para o destino de atualização da versão principal mais recente ou para um dos outros destinos de atualização disponíveis para essa versão. Para obter mais informações, consulte [Opções de atualização para snapshots de banco de dados com versões de mecanismo incompatíveis para o RDS para MySQL](mysql-upgrade-snapshot.upgrade-options.md). Após restaurar um snapshot de banco de dados atualizado para uma nova versão do mecanismo, certifique-se de testar se a atualização foi bem-sucedida. Para obter mais informações sobre uma atualização de versão principal, consulte [Atualizações do mecanismo de banco de dados do RDS para MySQL](USER_UpgradeDBInstance.MySQL.md). Para saber como restaurar um snapshot de banco de dados, consulte [Restaurar uma instância de banco de dados](USER_RestoreFromSnapshot.md). **nota** Não é possível atualizar snapshots de banco de dados automatizados criados durante o processo de backup automatizado. É possível atualizar um snapshot de banco de dados usando o Console de gerenciamento da AWS, a AWS CLI ou a API do RDS. ------ #### [ Console ] Para atualizar uma versão do mecanismo de snapshot de banco de dados usando o Console de gerenciamento da AWS, use o procedimento a seguir. **Para atualizar um snapshot de banco de dados** 1. Faça login no Console de gerenciamento da AWS e abra o console do Amazon RDS em [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/). 1. No painel de navegação, selecione **Snapshots**. 1. Escolha o snapshot que você deseja atualizar. 1. Em **Actions (Ações)**, selecione **Upgrade snapshot (Atualizar snapshot)**. A página **Upgrade snapshot (Atualizar snapshot)** é exibida. 1. Escolha a opção **New engine version (Nova versão de mecanismo)** para a qual atualizar. 1. Escolha **Save changes (Salvar alterações)** para atualizar o snapshot. Durante o processo de atualização, todas as ações do snapshot serão desabilitadas para esse snapshot de banco de dados. Além disso, o status do snapshot de banco de dados muda de **Disponível** para **Fazendo upgrade** e, depois, muda para **Ativo** após a conclusão. Se não for possível atualizar o snapshot de banco de dados devido a problemas de corrupção do snapshot, o status mudará para **Indisponível**. Não é possível recuperar o snapshot desse estado. **nota** Se a atualização do snapshot de banco de dados falhar, o snapshot será revertido para o estado original com a versão original. ------ #### [ AWS CLI ] Para atualizar um snapshot de banco de dados para uma nova versão do mecanismo de banco de dados, execute o comando [modify-db-snapshot](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-snapshot.html) da AWS CLI. **Opções** + `--db-snapshot-identifier` – o identificador do snapshot de banco de dados a ser atualizado. O identificador deve ser um nome de recurso da Amazon (ARN) exclusivo. Para obter mais informações, consulte [Nomes de recurso da Amazon (ARNs) no Amazon RDS](USER_Tagging.ARN.md). + `--engine-version` – a versão do mecanismo para a qual será feita a atualização do snapshot de banco de dados. **Example** Para Linux, macOS ou Unix: ``` 1. aws rds modify-db-snapshot \ 2. 3. --db-snapshot-identifier my_db_snapshot \ 4. --engine-version new_version ``` Para Windows: ``` 1. aws rds modify-db-snapshot ^ 2. --db-snapshot-identifier my_db_snapshot ^ 3. --engine-version new_version ``` ------ #### [ Amazon RDS API ] Para atualizar um snapshot de banco de dados para uma nova versão do mecanismo de banco de dados, chame a operação [ModifyDBSnapshot](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBSnapshot.html) da API do RDS. **Parâmetros** + `DBSnapshotIdentifier` – o identificador do snapshot de banco de dados a ser atualizado. O identificador deve ser um nome de recurso da Amazon (ARN) exclusivo. Para obter mais informações, consulte [Nomes de recurso da Amazon (ARNs) no Amazon RDS](USER_Tagging.ARN.md). + `EngineVersion` – a versão do mecanismo para a qual será feita a atualização do snapshot de banco de dados. ------ # Opções de atualização para snapshots de banco de dados com versões de mecanismo incompatíveis para o RDS para MySQL A tabela a seguir mostra para quais versões do mecanismo é possível fazer a atualização de uma versão de mecanismo incompatível com snapshots de banco de dados do RDS para MySQL. **nota** Talvez você precise atualizar o snapshot de banco de dados mais de uma vez para fazer a atualização para a versão do mecanismo escolhida. | Versão do mecanismo do snapshot de banco de dados | Versões do mecanismo disponíveis para atualização | | --- | --- | | 5.5.8 | 5.5.62, 5.6.51 | | 5.5.12 | 5.5.62, 5.6.51 | | 5.5.20 | 5.5.62, 5.6.51 | | 5.5.23 | 5.5.62, 5.6.51 | | 5.5.25a | 5.5.62, 5.6.51 | | 5.5.27 | 5.5.62, 5.6.51 | | 5.5.31 | 5.5.62, 5.6.51 | | 5.5.33 | 5.5.62, 5.6.51 | | 5.5.37 | 5.5.62, 5.6.51 | | 5.5.38 | 5.5.62, 5.6.51 | | 5.5.40 | 5.5.62, 5.6.51 | | 5.5.40a | 5.5.62, 5.6.51 | | 5.5.40b | 5.5.62, 5.6.51 | | 5.5.41 | 5.5.62, 5.6.51 | | 5.5.42 | 5.5.62, 5.6.51 | | 5.5.59 | 5.5.62, 5.6.51 | | 5.6.12 | 5.6.51, 5.7.44 | | 5.6.13 | 5.6.51, 5.7.44 | | 5.6.17 | 5.6.51, 5.7.44 | | 5.6.19 | 5.6.51, 5.7.44 | | 5.6.19a | 5.6.51, 5.7.44 | | 5.6.19b | 5.6.51, 5.7.44 | | 5.6.21 | 5.6.51, 5.7.44 | | 5.6.21b | 5.6.51, 5.7.44 | | 5.6.22 | 5.6.51, 5.7.44 | | 5.6.23 | 5.6.51, 5.7.44 | | 5.6.27 | 5.6.51, 5.7.44 | | 5.6.27a | 5.6.51, 5.7.44 | | 5.7.10 | 5.7.44, 5.7.44-rds.20240408, 5.7.44-rds.20240529, 5.7.44-rds.20250103, 5.7.44-rds.20250213, 8.0.32, 8.0.33, 8.0.34, 8.0.35, 8.0.36, 8.0.37, 8.0.39, 8.0.40, 8.0.41 | | 5.7.11 | 5.7.44, 5.7.44-rds.20240408, 5.7.44-rds.20240529, 5.7.44-rds.20250103, 5.7.44-rds.20250213, 8.0.32, 8.0.33, 8.0.34, 8.0.35, 8.0.36, 8.0.37, 8.0.39, 8.0.40, 8.0.41 | | 5.7.12 | 5.7.44, 5.7.44-rds.20240408, 5.7.44-rds.20240529, 5.7.44-rds.20250103, 5.7.44-rds.20250213, 8.0.32, 8.0.33, 8.0.34, 8.0.35, 8.0.36, 8.0.37, 8.0.39, 8.0.40, 8.0.41 | # Importar dados para uma instância de banco de dados do Amazon RDS para MySQL. Você pode usar várias técnicas diferentes para importar os dados para uma instância de banco de dados do RDS para MySQL. A melhor abordagem depende de inúmeros fatores: + origem dos dados; + Quantidade de dados + importação única ou contínua; + quantidade de tempo de inatividade. Se você também estiver migrando uma aplicação com os dados, é importante considerar a quantidade de tempo de inatividade. A seguinte tabela lista técnicas para importar dados em uma instância de banco de dados do RDS para MySQL: | Origem | Quantidade de dados | Uma vez ou contínuo | Tempo de inatividade da aplicação | Técnica | Mais informações | | --- | --- | --- | --- | --- | --- | | Banco de dados MySQL existente no local ou no Amazon EC2 | Quaisquer | Uma vez | Alguns | Crie um backup de seu banco de dados no local, armazene-o no Amazon S3 e, em seguida, restaure o arquivo de backup para uma nova instância de banco de dados do Amazon RDS executando MySQL. | [Restaurar um backup em uma instância de banco de dados do Amazon RDS para MySQL](MySQL.Procedural.Importing.md) | | Banco de dados MySQL existente no local ou no Amazon EC2 | Quaisquer | Contínuo | Mínimo | Configure a replicação com um banco de dados MySQL existente como origem de replicação. | [Configurar a replicação da posição do arquivo de log binário com uma instância de origem externa](MySQL.Procedural.Importing.External.Repl.md) [Importar dados para um banco de dados do Amazon RDS para MySQL com tempo de inatividade reduzido](mysql-importing-data-reduced-downtime.md) | | Qualquer banco de dados existente | Quaisquer | Uma vez ou contínuo | Mínimo | Use o AWS Database Migration Service para migrar o banco de dados com o mínimo de tempo de inatividade e, para diversos mecanismos de banco de dados (DB), continuar a replicação contínua. | [What is AWS Database Migration Service](https://docs.aws.amazon.com/dms/latest/userguide/Welcome.html) (O que é o ) e [Using a MySQL-compatible database as a target for AWS DMS](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Target.MySQL.html) (Usar um banco de dados compatível com MySQL como destino para o ) no *Guia do usuário do AWS Database Migration Service* | | Instância de banco de dados MySQL existente | Quaisquer | Uma vez ou contínuo | Mínimo | Crie uma réplica de leitura para a replicação contínua. Promova a réplica de leitura para a criação única de uma instância de banco de dados. | [Trabalhar com réplicas de leitura de instância de banco de dados](USER_ReadRepl.md) | | Banco de dados existente do MySQL | Pequeno | Uma vez | Alguns | Copie os dados diretamente para sua instância de banco de dados MySQL usando um utilitário de linha de comando. | [Importar dados de um banco de dados externo do MySQL para uma instância de banco de dados do Amazon RDS para MySQL.](mysql-importing-data-external-database.md) | | Dados não armazenados em um banco de dados existente | Médio | Uma vez | Alguns | Crie arquivos simples e importe-os usando instruções MySQL LOAD DATA LOCAL INFILE. | [Importar dados de qualquer fonte para uma instância de banco de dados do Amazon RDS para MySQL](mysql-importing-data-any-source.md) | **nota** O banco de dados do sistema `mysql` contém informações de autenticação e autorização necessárias para fazer login na instância de banco de dados e acessar os dados. Soltar, alterar, renomear ou truncar tabelas, dados ou outros conteúdos do banco de dados `mysql` em sua instância de banco de dados pode resultar em erros e pode tornar a instância de banco de dados e seus dados inacessíveis. Se isso ocorrer, você poderá restaurar a instância de banco de dados por meio de um snapshot usando o comando [https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-from-db-snapshot.html](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-from-db-snapshot.html) da AWS CLI. Você pode recuperar a instância de banco de dados usando o comando [https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-to-point-in-time.html](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-to-point-in-time.html) da AWS CLI. # Considerações sobre importação de dados para o MySQL O conteúdo a seguir apresenta informações técnicas relacionadas ao carregamento de dados no MySQL. Este conteúdo é destinado a usuários que estão familiarizados com a arquitetura do servidor MySQL. ## registro em log binário A habilitação do registro em log binário reduz a performance do carregamento de dados e requer até quatro vezes mais espaço em disco em comparação com o registro em log desabilitado. O tamanho da transação usada para carregar os dados afeta diretamente a performance do sistema e as necessidades de espaço em disco. As transações maiores exigem mais recursos. ## Tamanho da transação O tamanho da transação influencia os seguintes aspectos dos carregamentos de dados do MySQL: + Consumo de recursos + Utilização de espaço em disco + Processo de retomada + Tempo de recuperação + Formato de entrada (arquivos simples ou SQL) Esta seção descreve como o tamanho da transação afeta o registro em log binário e justifica a desabilitação do registro em log binário durante grandes cargas de dados. Você pode habilitar e desabilitar o registro em log binário configurando o período de retenção de backup automatizado do Amazon RDS. Valores diferentes de zero habilitam o registro em log binário, enquanto um valor de zero o desabilita. Para obter mais informações, consulte [Período de retenção de backup](USER_WorkingWithAutomatedBackups.BackupRetention.md). Esta seção descreve também o impacto de grandes transações sobre o InnoDB e por que é importante que o tamanho das transações seja pequeno. ### Transações pequenas Para pequenas transações, o registro em log binário duplica o número de gravações em disco necessárias para carregar os dados. Esse efeito pode degradar severamente a performance de outras sessões de banco de dados e aumentar o tempo necessário para carregar os dados. A degradação experimentada depende em parte dos seguintes fatores: + Taxa de upload + Outra atividade do banco de dados que ocorre durante o carregamento + Capacidade da instância de banco de dados do Amazon RDS Os logs binários também consomem um espaço em disco aproximadamente igual à quantidade de dados carregados enquanto os logs são copiados e removidos. O Amazon RDS minimiza isso fazendo backup e removendo os logs binários com frequência. ### Transações grandes Quanto a transações grandes, o registro em log binário triplica as IOPS e o uso do disco pelos seguintes motivos: + O cache de log binário armazena os dados da transação temporariamente no disco. + Esse cache se amplia de acordo com o tamanho da transação, o que consome espaço em disco. + Quando a transação (de confirmação ou reversão) é concluída, o sistema copia o cache para o log binário. Esse processo cria três cópias dos dados: + os dados originais; + o cache no disco; + a entrada final do log binário. Cada operação de gravação incorre em E/S adicional, afetando ainda mais a performance. Por isso, o registro em log binário requer o triplo de espaço em disco em comparação com o registro desabilitado. Por exemplo, carregar 10 GiB de dados como uma única transação cria três cópias: + 10 GiB para os dados da tabela; + 10 GiB para o cache de log binário; + 10 GiB para o arquivo de log binário. O total de espaço em disco temporário necessário é 30 GiB. Considerações importantes sobre o espaço em disco: + O arquivo de cache persiste até que a sessão termine ou uma nova transação crie outro cache. + O log binário permanece até o momento em que ele é copiado, possivelmente mantendo 20 GiB (cache e log) por um período prolongado. Se você usar `LOAD DATA LOCAL INFILE` para carregar os dados, a recuperação de dados criará uma quarta cópia caso o banco de dados tenha que ser recuperado de um backup feito antes do carregamento. Durante a recuperação, o MySQL extrai dados de log binário em um arquivo simples. Em seguida, o MySQL executa `LOAD DATA LOCAL INFILE`. Com base no exemplo anterior, essa recuperação requer um total de espaço em disco temporário de 40 GiB ou 10 GiB cada para tabela, cache, log e arquivo local. Sem pelo menos 40 GiB de espaço livre em disco, a recuperação falhará. ### Otimizar grandes carregamentos de dados No caso de grandes carregamentos de dados, desabilite o registro em log binário para reduzir os custos indiretos e os requisitos de espaço em disco. Você pode desabilitar o registro em log binário definindo o período de retenção de backup como 0. Após o término do carregamento, substitua o período de retenção de backup por um valor apropriado diferente de zero. Para ter mais informações, consulte [Modificar uma instância de banco de dados do Amazon RDS](Overview.DBInstance.Modifying.md) e [Período de retenção de backup](USER_ModifyInstance.Settings.md) na tabela de configurações. **nota** Se a instância de banco de dados for uma instância de banco de dados de origem para réplicas de leitura, não será possível definir o período de retenção de backup como 0. Antes de carregar os dados, recomendamos criar um snapshot do banco de dados. Para obter mais informações, consulte [Gerenciar backups manuais](USER_ManagingManualBackups.md). ## InnoDB As informações a seguir sobre o registro em log de desfazer e as opções de recuperação ajudam a manter as transações do InnoDB pequenas para otimizar a performance do banco de dados. ### Conceitos básicos sobre o registro em log de desfazer no InnoDB Desfazer é um mecanismo de registro em log que permite a reversão de transações e comporta o controle de simultaneidade de várias versões (MVCC). No caso do MySQL 5.7 e versões anteriores, os logs de desfazer são armazenados no espaço de tabela do sistema InnoDB (geralmente ibdata1) e são retidos até que o thread de limpeza os remova. Por esse motivo, grandes transações de carregamento de dados podem fazer com que o espaço de tabela do sistema se torne muito grande e consuma espaço em disco que não pode ser recuperado sem recriar o banco de dados. Para todas as versões do MySQL, o thread de limpeza só deve remover quaisquer logs de desfazer depois que a transação ativa mais antiga for confirmada ou revertida. Se o banco de dados estiver processando outras transações durante o carregamento, os logs de desfazer também se acumularão e não poderão ser removidos, mesmo que as transações sejam confirmadas e nenhuma outra precise dos logs de desfazer para o MVCC. Nessa situação, todas as transações, incluindo as transações somente leitura, ficam mais lentas. Essa desaceleração ocorre porque todas as transações acessam todas as linhas que qualquer transação, não apenas a transação de carregamento, altera. Na prática, as transações devem examinar os logs de desfazer cuja eliminação foi impedida pelas transações de carregamento de longa duração durante uma limpeza de logs de desfazer. Isso afeta a performance de qualquer operação que acesse linhas modificadas. ### Opções de recuperação de transações do InnoDB Embora o InnoDB otimize as operações de confirmação, a reversão de grandes transações é lenta. Para uma recuperação mais rápida, execute uma recuperação para um ponto no tempo ou restaure um snapshot do banco de dados. Para obter mais informações, consulte [Recuperação para um ponto no tempo](USER_PIT.md) e [Restaurar uma instância de banco de dados](USER_RestoreFromSnapshot.md). ## Formatos de importação de dados O MySQL aceita dois formatos de importação de dados: arquivos simples e SQL. Analise as informações sobre cada formato para determinar a melhor opção para suas necessidades. ### Arquivos simples Para transações pequenas, carregue arquivos simples com `LOAD DATA LOCAL INFILE`. Esse formato de importação de dados pode oferecer os seguintes benefícios em relação ao uso do SQL: + regras de tráfego de rede; + custos de transmissão de dados mais baixos; + redução dos custos indireto de processamento do banco de dados; + processamento de fluxos. `LOAD DATA LOCAL INFILE` carrega todo o arquivo simples como uma única transação. Mantenha os arquivos individuais com um tamanho pequeno para obter as seguintes vantagens: + **Capacidade de retomar**: é fácil manter o controle de quais arquivos foram carregados. Se surgir um problema durante o carregamento, você poderá continuar de onde parou. Você pode precisar retransmitir alguns dados ao Amazon RDS, mas, com arquivos pequenos, a quantidade retransmitida é mínima. + **Carregamento de dados em paralelo**: se você tiver IOPS e largura de banda da rede suficientes para carregamento de um único arquivo, o carregamento em paralelo pode economizar tempo. + **Controle da taxa de carregamento**: se o carregamento de dados tiver um impacto negativo em outros processos, você poderá controlar a taxa de carregamento aumentando o intervalo entre os arquivos. Grandes transações reduzem os benefícios de usar `LOAD DATA LOCAL INFILE` para importar dados. Quando você não conseguir dividir uma grande quantidade de dados em arquivos menores, considere a possibilidade de usar o SQL. ### SQL O SQL tem uma vantagem fundamental em relação aos arquivos simples: é fácil manter as transações com um tamanho pequeno. Contudo, o tempo de carregamento do SQL pode ser significativamente mais longo do que o dos arquivos simples. Além disso, após uma falha, pode ser difícil determinar onde retomar. Não é possível reiniciar os arquivos mysqldump. Se ocorrer uma falha ao carregar um arquivo mysqldump, você deve modificá-lo ou substituí-lo para que o carregamento possa continuar. Ou, alternativamente, depois de corrigir a causa da falha, você pode restaurar para o ponto no tempo anterior ao carregamento e reenviar o arquivo. Para obter mais informações, consulte [Recuperação para um ponto no tempo](USER_PIT.md). ## Usar snapshots de banco de dados do Amazon RDS para pontos de verificação de banco de dados Se você carrega dados por longos períodos, como horas ou dias, sem registro em log binário, use snapshots de banco de dados para oferecer pontos de verificação periódicos em prol da segurança dos dados. Cada snapshot de banco de dados cria uma cópia consistente da instância de banco de dados, que serve como ponto de recuperação durante falhas do sistema ou eventos de corrupção de dados. Como os snapshots de banco de dados são rápidos, os pontos de verificação frequentes têm um impacto mínimo na performance do carregamento. Você pode excluir snapshots de banco de dados anteriores sem afetar a durabilidade ou os recursos de recuperação do banco de dados. Para ter mais informações sobre snapshots de banco de dados, consulte [Gerenciar backups manuais](USER_ManagingManualBackups.md). ## Reduzir os tempos de carregamento do banco de dados Os seguintes itens são dicas adicionais para reduzir os tempos de carregamento: + Crie todos os índices secundários antes de carregar dados nos bancos de dados MySQL. Ao contrário de outros sistemas de banco de dados, o MySQL reconstrói a tabela inteira ao adicionar ou modificar índices secundários. Esse processo cria outra tabela com alterações no índice, copia todos os dados e descarta a tabela original. + Carregue os dados na ordem da chave primária. Quanto a tabelas do InnoDB, isso pode reduzir os tempos de carregamento em 75% a 80% e diminuir o tamanho do arquivo de dados em 50%. + Desabilite as restrições de chave estrangeira definindo `foreign_key_checks` como `0`. Isso com frequência é necessário para arquivos simples carregados com `LOAD DATA LOCAL INFILE`. Com relação a qualquer carregamento, desabilitar as verificações de chave estrangeira acelera o carregamento de dados. Após a conclusão do carregamento, habilite novamente as restrições configurando `foreign_key_checks` como `1` e verifique os dados. + Carregue os dados em paralelo, a menos que esteja se aproximando de um limite de recursos. Para habilitar o carregamento simultâneo em vários segmentos da tabela, use tabelas particionadas quando apropriado. + Para reduzir os custos indiretos de execução do SQL, combine várias instruções `INSERT` em operações `INSERT` únicas de vários valores. `mysqldump` implementa essa otimização automaticamente. + Reduza as operações de E/S de log do InnoDB configurando `innodb_flush_log_at_trx_commit` como `0`. Após a conclusão do carregamento, restaure `innodb_flush_log_at_trx_commit` para `1`. **Atenção** Ao definir `innodb_flush_log_at_trx_commit` como `0`, o InnoDB descarrega os respectivos logs a cada segundo em vez de a cada confirmação. Essa configuração aumenta a performance, mas pode gerar risco de perda de transações durante falhas no sistema. + Se você estiver carregando dados em uma instância de banco de dados que não tem réplicas de leitura, defina `sync_binlog` como `0`. Após a conclusão do carregamento, restaure `sync_binlog parameter` para `1`. + Carregue os dados antes de converter a instância de banco de dados em uma implantação multi-AZ. Se a instância de banco de dados já utiliza uma implantação multi-AZ, não recomendamos mudar para uma implantação single-AZ para carregamento de dados. Se fizer isso, obterá apenas pequenas melhorias. # Restaurar um backup em uma instância de banco de dados do Amazon RDS para MySQL O Amazon RDS permite a importação de bancos de dados MySQL com arquivos de backup. Você pode criar um backup do banco de dados, armazenar o arquivo de backup no Amazon S3 e, depois, restaurar o arquivo de backup em uma nova instância de banco de dados do Amazon RDS que executa o MySQL. O Amazon RDS permite a importação de arquivos de backup do Amazon S3 em todas as Regiões da AWS. O cenário descrito nesta seção restaura um backup de um banco de dados on-premises. Desde que o banco de dados esteja acessível, você pode usar essa técnica para bancos de dados em outros locais, como o Amazon EC2 ou outros serviços de nuvem. O diagrama a seguir mostra o cenário com suporte. ![\[MySQL importando arquivos de backup do S3.\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/UserGuide/images/MySQL-bak-file.png) Se seu banco de dados on-premises puder ficar off-line enquanto você cria, copia e restaura os arquivos de backup, recomendamos usar os arquivos de backup para importar o banco de dados para o Amazon RDS. Se o banco de dados não puder ficar off-line, use um dos seguintes métodos: + **Logs binários**: primeiro, importe arquivos de backup do Amazon S3 para o Amazon RDS, conforme explicado neste tópico. Em seguida, use a replicação de log binário (binlog) para atualizar o banco de dados. Para obter mais informações, consulte [Configurar a replicação da posição do arquivo de log binário com uma instância de origem externa](MySQL.Procedural.Importing.External.Repl.md). + **AWS Database Migration Service**: use o AWS Database Migration Service para migrar o banco de dados para o Amazon RDS. Para ter mais informações, consulte [O que é o AWS Database Migration Service?](https://docs.aws.amazon.com/dms/latest/userguide/Welcome.html) ## Visão geral da configuração para importar arquivos de backup do Amazon S3 para o Amazon RDS Para configurar importar arquivos de backup do Amazon S3 para o Amazon RDS, você precisa dos seguintes componentes: + Um bucket do Amazon S3 para armazenar seus arquivos de backup. Se você já tiver um bucket do Amazon S3, poderá usá-lo. Se você não tiver um bucket do Amazon S3, crie um. Para mais informações, consulte [ Criar um bucket](https://docs.aws.amazon.com/AmazonS3/latest/userguide/CreatingaBucket.html). + Um backup de seu banco de dados no local criado pelo Percona XtraBackup. Para obter mais informações, consulte [Criar o backup de banco de dados](#MySQL.Procedural.Importing.Backup). + Um perfil do AWS Identity and Access Management (IAM) para permitir que o Amazon RDS acesse o bucket do S3. Se você já tiver um perfil do IAM, poderá usá-lo e anexar políticas de confiança e permissões a ele. Para obter mais informações, consulte [Criação manual de uma função do IAM](#MySQL.Procedural.Importing.Enabling.IAM). Se você não tiver um perfil do IAM, há duas opções: + É possível criar um perfil do IAM manualmente. Para obter mais informações, consulte [Criação manual de uma função do IAM](#MySQL.Procedural.Importing.Enabling.IAM). + Você pode optar por deixar o Amazon RDS criar um perfil do IAM para você. Se quiser que o Amazon RDS crie um perfil do IAM para você, siga o procedimento que usa o Console de gerenciamento da AWS na seção [Importar dados do Amazon S3 para uma nova instância de banco de dados MySQL](#MySQL.Procedural.Importing.PerformingImport). ## Criar o backup de banco de dados Use o software Percona XtraBackup para criar seu backup. É recomendável utilizar a versão mais recente do Percona XtraBackup. Você pode instalar o Percona XtraBackup em [Software Downloads](https://www.percona.com/downloads/) no site da Percona. **Atenção** Ao criar um backup de banco de dados, o XtraBackup pode salvar credenciais no arquivo xtrabackup\$1info. Confirme se a configuração `tool_command` no arquivo xtrabackup\$1info não contém informações confidenciais. A versão do Percona XtraBackup a ser usada depende da versão do MySQL da qual você está fazendo backup. + **MySQL 8.4**: use o Percona XtraBackup versão 8.4. + **MySQL 8.0**: use o Percona XtraBackup versão 8.0. **nota** O Percona XtraBackup 8.0.12 e versões posteriores oferecem suporte à migração de todas as versões do MySQL 8.0. Se você estiver migrando para o RDS para MySQL 8.0.32 ou posterior, use o Percona XtraBackup 8.0.12 ou posterior. + **MySQL 5.7**: use o Percona XtraBackup versão 2.4. Você pode usar o Percona XtraBackup para criar um backup completo de seus arquivos de banco de dados MySQL. Ou, se você já usa o Percona XtraBackup para fazer o backup dos arquivos do banco de dados MySQL, pode fazer upload dos arquivos e diretórios de backup completos e incrementais. Para ter mais informações sobre como fazer backup do banco de dados com o Percona XtraBackup, consulte [Percona XtraBackup - Documentation](https://www.percona.com/doc/percona-xtrabackup/LATEST/index.html) no site da Percona. ### Criar um backup completo com o Percona XtraBackup Para criar um backup completo dos arquivos do banco de dados MySQL que o Amazon RDS pode restaurar do Amazon S3, use o utilitário Percona XtraBackup (`xtrabackup`). Por exemplo, o seguinte comando cria um backup de um banco de dados MySQL e armazena os arquivos na pasta `/on-premises/s3-restore/backup`. ``` xtrabackup --backup --user=myuser --password=password --target-dir=/on-premises/s3-restore/backup ``` Se você deseja compactar o backup em um único arquivo, que pode ser dividido posteriormente, se necessário, salve o backup em um dos seguintes formatos com base em sua versão do MySQL: + **Gzip (.gz)**: para MySQL 5.7 e versões anteriores. + **tar (.tar)**: para MySQL 5.7 e versões anteriores. + **Percona xbstream (.xbstream)**: para todas as versões do MySQL. **nota** O Percona XtraBackup 8.0 e posterior permite que apenas o Percona xbstream seja usado para compactação. **MySQL 5.7 e versões anteriores** O comando a seguir cria um backup do seu banco de dados MySQL dividido em vários arquivos Gzip. Substitua os valores por suas próprias informações. ``` xtrabackup --backup --user=my_user --password=password --stream=tar \ --target-dir=/on-premises/s3-restore/backup | gzip - | split -d --bytes=500MB \ - /on-premises/s3-restore/backup/backup.tar.gz ``` **MySQL 5.7 e versões anteriores** O comando a seguir cria um backup do seu banco de dados MySQL dividido em vários arquivos tar. Substitua os valores por suas próprias informações. ``` xtrabackup --backup --user=my_user --password=password --stream=tar \ --target-dir=/on-premises/s3-restore/backup | split -d --bytes=500MB \ - /on-premises/s3-restore/backup/backup.tar ``` **Todas as versões do MySQL** O comando a seguir cria um backup do seu banco de dados MySQL dividido em vários arquivos xbstream. Substitua os valores por suas próprias informações. ``` xtrabackup --backup --user=myuser --password=password --stream=xbstream \ --target-dir=/on-premises/s3-restore/backup | split -d --bytes=500MB \ - /on-premises/s3-restore/backup/backup.xbstream ``` **nota** Se você vir o erro a seguir, é provável que você tenha misturado os formatos de arquivo em seu comando: ``` ERROR:/bin/tar: This does not look like a tar archive ``` ### Usar backups incrementais com o Percona XtraBackup Se você já usa o Percona XtraBackup para fazer backups completos e incrementais de seus arquivos de banco de dados MySQL, não precisa criar um backup completo e fazer upload dos arquivos de backup no Amazon S3. Em vez disso, para economizar tempo, copie os diretórios e arquivos de backup existentes no bucket do Amazon S3. Para ter mais informações sobre como criar backups incrementais usando o Percona XtraBackup, consulte [Create an incremental backup](https://docs.percona.com/percona-xtrabackup/LATEST/create-incremental-backup.html) no site da Percona. Quando copiar os arquivos existentes de backup completo e incremental para um bucket do Amazon S3, copie recursivamente o conteúdo do diretório de base. Esse conteúdo inclui o backup completo e todos os diretórios e arquivos de backup incremental. Essa cópia deve preservar a estrutura de diretórios no bucket do Amazon S3. O Amazon RDS percorre todos os arquivos e diretórios. O Amazon RDS usa o arquivo `xtrabackup-checkpoints` incluído em cada backup incremental para identificar o diretório de base e ordenar os backups incrementais por intervalo de número de sequência de log (LSN). ### Considerações sobre backup para o Percona XtraBackup O Amazon RDS consome seus arquivos de backup com base no nome do arquivo. Nomeie os arquivos de backup com a extensão de arquivo apropriada com base no formato do arquivo. Por exemplo, use `.xbstream` para arquivos armazenados que usam o formato Percona xbstream. O Amazon RDS consome os arquivos de backup em ordem alfabética assim como na ordem numérica natural. Para garantir que os arquivos de backup sejam gravados e nomeados na ordem apropriada, use a opção `split` ao emitir o comando `xtrabackup`. O Amazon RDS não oferece suporte a backups parciais criados com o Percona XtraBackup. Não é possível usar as seguintes opções para criar um backup parcial ao fazer backup dos arquivos de origem de seu banco de dados: + `--tables` + `--tables-exclude` + `--tables-file` + `--databases` + `--databases-exclude` + `--databases-file` ## Criação manual de uma função do IAM Se você não tiver um perfil do IAM, crie um novo manualmente. No entanto, se você restaurar o banco de dados usando o Console de gerenciamento da AWS, recomendamos que deixe que Amazon o RDS crie esse perfil do IAM para você. Para que o Amazon RDS crie esse perfil para você, siga o procedimento na seção [Importar dados do Amazon S3 para uma nova instância de banco de dados MySQL](#MySQL.Procedural.Importing.PerformingImport). Para criar manualmente um perfil do IAM para importar seu banco de dados do Amazon S3, crie um perfil para delegar permissões do Amazon RDS ao bucket do Amazon S3. Quando você cria um perfil do IAM, você anexa as políticas de confiança e permissões. Para importar os arquivos de backup do Amazon S3, use políticas de confiança e de permissões semelhantes aos exemplos a seguir. Para ter mais informações sobre como criar a função, consulte [Criar uma função para delegar permissões a um AWSserviço da ](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html). As políticas de confiança e permissões exigem que você forneça um Nome do recurso da Amazon (ARN). Para ter mais informações sobre como formatar o ARN, consulte [Nomes de recurso da Amazon (ARNs) e AWS namespaces de serviço da ](https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html). **Example política de confiança para importar do Amazon S3** **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "AssumeRoleForBackup", "Effect": "Allow", "Principal": { "Service": "rds.amazonaws.com" }, "Action": "sts:AssumeRole" } ] } ``` **Example política de permissões para importar do Amazon S3: permissões de usuário do IAM** No exemplo a seguir, substitua *iam\$1user\$1id* por seu próprio valor. **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "AllowS3AccessRole", "Effect": "Allow", "Action": "iam:PassRole", "Resource": "arn:aws:iam::111122223333:role/S3Access" } ] } ``` **Example Política de permissões para importar do Amazon S3: permissões de perfil** No exemplo a seguir, substitua *amzn-s3-demo-bucket* e *prefix* por seus próprios valores. **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:ListBucket", "s3:GetBucketLocation" ], "Resource": "arn:aws:s3:::amzn-s3-demo-bucket" }, { "Effect": "Allow", "Action": [ "s3:GetObject" ], "Resource": "arn:aws:s3:::amzn-s3-demo-bucket/prefix*" }, { "Effect": "Allow", "Action": [ "kms:Decrypt" ], "Resource": [ "arn:aws:kms:us-east-1:111122223333:key/key_id*" ] } ] } ``` Se você incluir um prefixo de nome de arquivo, inclua o asterisco (\$1) após o prefixo. Se não quiser especificar um prefixo, especifique apenas um asterisco. ## Importar dados do Amazon S3 para uma nova instância de banco de dados MySQL Você pode importar dados do Amazon S3 para uma nova instância de banco de dados do MySQL usando o Console de gerenciamento da AWS, a AWS CLI ou a API do RDS. ### Console **Para importar dados do Amazon S3 para uma nova instância de banco de dados MySQL** 1. Faça login no Console de gerenciamento da AWS e abra o console do Amazon RDS em [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/). 1. No canto superior direito do console do Amazon RDS, escolha a Região da AWS na qual você quer criar a instância de banco de dados. Escolha a mesma Região da AWS do bucket do Amazon S3 que contém o backup do banco de dados. 1. No painel de navegação, escolha **Databases (Bancos de dados)**. 1. Escolha **Restore from S3 (Restaurar do S3)**. A página **Create database by restoring from S3 (Criar banco de dados restaurando a partir do S3)** é exibida. ![\[A página Criar banco de dados restaurando pelo S3 em que você especifica os detalhes para restaurar uma instância de banco de dados pelo S3.\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/UserGuide/images/mys-s3-ingestion.png) 1. Em **Origem do S3**: 1. Selecione o **S3 bucket** (bucket do S3) que contém o backup. 1. (Opcional) Em **Prefixo do S3**, insira o prefixo do caminho dos arquivos armazenados no bucket do Amazon S3. Se você não especificar um prefixo, o Amazon RDS criará a instância de banco de dados usando todos os arquivos e pastas na pasta raiz do bucket do S3. Se você especificar um prefixo, o Amazon RDS criará a instância de banco de dados usando os arquivos e as pastas no bucket do S3 no qual o caminho para o arquivo começa com o prefixo especificado. Por exemplo, você armazena seus arquivos de backup no S3 em uma subpasta denominada backups e tem vários conjuntos de arquivos de backup, cada um em seu próprio diretório (gzip\$1backup1, gzip\$1backup2 e assim por diante). Nesse caso, para restaurar dos arquivos na pasta gzip\$1backup1 para especifique o prefixo backups/gzip\$1backup1. 1. Em **Engine options (Opções de mecanismo)**: 1. Em **Engine type (Tipo de mecanismo)**, escolha **MySQL**. 1. Para **Source engine version (Versão do mecanismo de origem)**, escolha a versão principal do MySQL de seu banco de dados de origem. 1. Em **Versão do mecanismo**, escolha a versão secundária padrão da versão principal do MySQL na Região da AWS. No Console de gerenciamento da AWS, apenas a versão secundária padrão está disponível. Depois de concluir a importação, você pode atualizar a instância de banco de dados. 1. Em **Perfil do IAM**, crie ou escolha o perfil do IAM com a política de confiança e a política de permissões necessárias para que o Amazon RDS acesse o bucket do Amazon S3. Execute uma das seguintes ações: + (Recomendado) Escolha **Criar um perfil** e insira o **Nome do perfil do IAM**. Com essa opção, o Amazon RDS cria automaticamente o perfil com a política de confiança e a política de permissões para você. + Escolha um perfil do IAM existente. Verifique se esse perfil atende a todos os critérios em [Criação manual de uma função do IAM](#MySQL.Procedural.Importing.Enabling.IAM). 1. Especifique as informações da instância de banco de dados. Para obter informações sobre cada configuração, consulte [Configurações para instâncias de banco de dados](USER_CreateDBInstance.Settings.md). **nota** Aloque armazenamento suficiente para sua nova instância de banco de dados para que a operação de restauração possa continuar. Para permitir o crescimento futuro automaticamente, em **Configuração adicional de armazenamento**, escolha **Habilitar escalabilidade automática do armazenamento**. 1. Escolha configurações adicionais conforme necessário. 1. Escolha **Criar banco de dados**. ### AWS CLI Para importar dados do Amazon S3 para uma nova instância de banco de dados MySQL usando a AWS CLI, execute o comando [restore-db-instance-from-s3](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-from-s3.html) com as opções a seguir. Para obter informações sobre cada configuração, consulte [Configurações para instâncias de banco de dados](USER_CreateDBInstance.Settings.md). **nota** Aloque armazenamento suficiente para sua nova instância de banco de dados para que a operação de restauração possa continuar. Para habilitar o ajuste de escala automático do armazenamento e permitir o crescimento futuro automaticamente, use a opção `--max-allocated-storage`. + `--allocated-storage` + `--db-instance-identifier` + `--db-instance-class` + `--engine` + `--master-username` + `--manage-master-user-password` + `--s3-bucket-name` + `--s3-ingestion-role-arn` + `--s3-prefix` + `--source-engine` + `--source-engine-version` **Example** Para Linux, macOS ou Unix: ``` 1. aws rds restore-db-instance-from-s3 \ 2. --allocated-storage 250 \ 3. --db-instance-identifier my_identifier \ 4. --db-instance-class db.m5.large \ 5. --engine mysql \ 6. --master-username admin \ 7. --manage-master-user-password \ 8. --s3-bucket-name amzn-s3-demo-bucket \ 9. --s3-ingestion-role-arn arn:aws:iam::account-number:role/rolename \ 10. --s3-prefix bucket_prefix \ 11. --source-engine my_sql \ 12. --source-engine-version 8.0.32 \ 13. --max-allocated-storage 1000 ``` Para Windows: ``` 1. aws rds restore-db-instance-from-s3 ^ 2. --allocated-storage 250 ^ 3. --db-instance-identifier my_identifier ^ 4. --db-instance-class db.m5.large ^ 5. --engine mysql ^ 6. --master-username admin ^ 7. --manage-master-user-password ^ 8. --s3-bucket-name amzn-s3-demo-bucket ^ 9. --s3-ingestion-role-arn arn:aws:iam::account-number:role/rolename ^ 10. --s3-prefix bucket_prefix ^ 11. --source-engine mysql ^ 12. --source-engine-version 8.0.32 ^ 13. --max-allocated-storage 1000 ``` ### API do RDS Para importar dados do Amazon S3 para uma nova instância de banco de dados MySQL usando a API do Amazon RDS, chame a operação [RestoreDBInstanceFromS3](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceFromS3.html). ## Limitações e considerações para importar arquivos de backup do Amazon S3 para o Amazon RDS As seguintes limitações e considerações se aplicam à importação de arquivos de backup do Amazon S3 para uma instância de banco de dados do RDS para MySQL: + Só é possível migrar os dados para uma nova instância de banco de dados, não para uma instância existente. + Você deve usar o Percona XtraBackup para fazer backup dos dados no Amazon S3. Para obter mais informações, consulte [Criar o backup de banco de dados](#MySQL.Procedural.Importing.Backup). + O bucket do Amazon S3 e a instância de banco de dados do RDS para MySQL devem estar na mesma Região da AWS. + Não é possível restaurar nas seguintes origens: + Uma exportação de um snapshot de instância de banco de dados para o Amazon S3. Também não é possível migrar dados de uma exportação de snapshot de instância de banco de dados para o bucket do Amazon S3. + Um banco de dados de origem criptografado. Entretanto, você pode criptografar os dados que estão sendo migrados. Também é possível deixar os dados não criptografados durante o processo de migração. + Um banco de dados MySQL 5.5 ou 5.6. + O RDS para MySQL não aceita o Percona Server para MySQL como banco de dados de origem porque ele pode conter tabelas `compression_dictionary*` no esquema `mysql schema`. + O RDS para MySQL não permite a reversão de migrações para versões principais ou secundárias. Por exemplo, não é possível migrar do MySQL versão 8.0 para o RDS para MySQL 5.7 nem do MySQL versão 8.0.32 para o RDS para MySQL versão 8.0.26. + O Amazon RDS não permite fazer importações na classe de instância de banco de dados db.t2.micro por meio do Amazon S3. Contudo, você poderá restaurar para outra classe de instância de banco de dados e, posteriormente, alterar a instância de banco de dados. Para mais informações sobre as classes da instância, consulte [Especificações de hardware para classes de instância de banco de dados](Concepts.DBInstanceClass.Summary.md). + O Amazon S3 limita o tamanho de um arquivo carregado para um bucket do Amazon S3 a 5 TB. Se um arquivo de backup exceder 5 TB, você deverá dividi o arquivo de backup em arquivos menores. + O Amazon RDS limita a 1 milhão o número de arquivos carregados para um bucket do Amazon S3. Se os dados de backup do banco de dados, incluindo todos os backups completos e incrementais, exceder 1 milhão de arquivos, use um arquivo Gzip (.gz), tar (.tar.gz) ou Percona xbstream (.xbstream) para armazenar arquivos de backup completos e incrementais no bucket do Amazon S3. O Percona XtraBackup 8.0 oferece suporte apenas ao Percona xbstream para compactação. + Para fornecer serviços de gerenciamento para cada instância de banco de dados, o Amazon RDS cria o usuário `rdsadmin` ao criar a instância de banco de dados. Como `rdsamin` é um usuário reservado no Amazon RDS, as seguintes limitações se aplicam: + O Amazon RDS não importa funções, procedimentos, visualizações, eventos e acionadores com o definidor `'rdsadmin'@'localhost'`. Para obter mais informações, consulte [Objetos armazenados com “rdsadmin'@'localhost” como definidor](#MySQL.Procedural.Importing.StoredObjects) e [Privilégios da conta de usuário mestre](UsingWithRDS.MasterAccounts.md). + Ao criar a instância de banco de dados, o Amazon RDS cria um usuário principal com os privilégios máximos permitidos. Na restauração por meio de backup, o Amazon RDS remove automaticamente qualquer privilégio não permitido atribuído aos usuários que estão sendo importados. Para identificar usuários que possam ser afetados por isso, consulte [Contas de usuário com privilégios não compatíveis](#MySQL.Migrating.ExtMySQL.Prechecks.Users). Para ter mais informações sobre privilégios permitidos no RDS para MySQL, consulte [Modelo de privilégios baseados em perfis para o RDS para MySQL](Appendix.MySQL.CommonDBATasks.privilege-model.md). + O Amazon RDS não migra tabelas criadas pelo usuário no esquema `mysql`. + Você deve configurar o parâmetro `innodb_data_file_path` com apenas um arquivo de dados que usa o nome de arquivo de dados padrão `ibdata1:12M:autoextend`. Você pode migrar bancos de dados com dois arquivos de dados ou com um arquivo de dados com um nome diferente usando esse método. Os seguintes exemplos são nomes de arquivo que o Amazon RDS não permite: + `innodb_data_file_path=ibdata1:50M` + `ibdata2:50M:autoextend` + `innodb_data_file_path=ibdata01:50M:autoextend` + Não é possível migrar de um banco de dados de origem que tenha tabelas definidas fora do diretório de dados MySQL padrão. + O tamanho máximo aceito para backups não compactados usando esse método é 64 TiB. Para backups compactados, esse limite é menor para levar em conta os requisitos de espaço sem compactação. Nesses casos, o tamanho máximo de backup aceito é `64 TiB - compressed backup size`. Para ter informações sobre o tamanho máximo do banco de dados que o Amazon RDS para MySQL permite, consulte [Armazenamento SSD de uso geral](CHAP_Storage.md#Concepts.Storage.GeneralSSD) e [Armazenamento SSD de IOPS provisionadas](CHAP_Storage.md#USER_PIOPS). + O Amazon RDS não permite importações do MySQL e de outros componentes e plug-ins externos. + Ele não restaura tudo do seu banco de dados. Recomendamos salvar o esquema do banco de dados e os valores dos itens do banco de dados MySQL de origem relacionados abaixo e adicioná-los à instância de banco de dados restaurada do RDS para MySQL depois que ela for criada: + Contas de usuário + Funções + Procedimentos armazenados + Informações de fuso horário. As informações de fuso horário são carregadas do sistema operacional local da instância de banco de dados do RDS para MySQL. Para obter mais informações, consulte [Fuso horário local para instâncias de banco de dados MySQL](MySQL.Concepts.LocalTimeZone.md). ### Objetos armazenados com “rdsadmin'@'localhost” como definidor O Amazon RDS não importa funções, procedimentos, visualizações, eventos e acionadores com o `'rdsadmin'@'localhost'` como definidor. Você pode usar o script SQL a seguir, no banco de dados MySQL de origem, a fim de listar os objetos armazenados que têm o definidor incompatível. ``` -- This SQL query lists routines with `rdsadmin`@`localhost` as the definer. SELECT ROUTINE_SCHEMA, ROUTINE_NAME FROM information_schema.routines WHERE definer = 'rdsadmin@localhost'; -- This SQL query lists triggers with `rdsadmin`@`localhost` as the definer. SELECT TRIGGER_SCHEMA, TRIGGER_NAME, DEFINER FROM information_schema.triggers WHERE DEFINER = 'rdsadmin@localhost'; -- This SQL query lists events with `rdsadmin`@`localhost` as the definer. SELECT EVENT_SCHEMA, EVENT_NAME FROM information_schema.events WHERE DEFINER = 'rdsadmin@localhost'; -- This SQL query lists views with `rdsadmin`@`localhost` as the definer. SELECT TABLE_SCHEMA, TABLE_NAME FROM information_schema.views WHERE DEFINER = 'rdsadmin@localhost'; ``` ### Contas de usuário com privilégios não compatíveis As contas de usuário com privilégios que o RDS para MySQL não permite são importadas sem os privilégios não permitidos. Para ver a lista de privilégios compatíveis, consulte [Modelo de privilégios baseados em perfis para o RDS para MySQL](Appendix.MySQL.CommonDBATasks.privilege-model.md). É possível executar a consulta SQL a seguir em seu banco de dados de origem para listar as contas de usuário com privilégios incompatíveis. ``` SELECT user, host FROM mysql.user WHERE Shutdown_priv = 'y' OR File_priv = 'y' OR Super_priv = 'y' OR Create_tablespace_priv = 'y'; ``` # Importar dados de um banco de dados externo do MySQL para uma instância de banco de dados do Amazon RDS para MySQL. É possível importar dados de um banco de dados MySQL existente para uma instância de banco de dados do RDS para MySQL. Para isso, copie o banco de dados com [mysqldump](https://dev.mysql.com/doc/refman/8.0/en/mysqldump.html) e conecte-o diretamente à instância de banco de dados do RDS para MySQL. O utilitário de linha de comandos `mysqldump` é comumente usado para fazer backups e transferir dados de um servidor MySQL para outro. Ele está incluído no software-cliente do MySQL. **nota** Se você estiver importando ou exportando grandes volumes de dados com uma instância de banco de dados do MySQL, será mais confiável e mais rápido mover dados para dentro e para fora do Amazon RDS usando arquivos de backup `xtrabackup` e o Amazon S3. Para obter mais informações, consulte [Restaurar um backup em uma instância de banco de dados do Amazon RDS para MySQL](MySQL.Procedural.Importing.md). Um comando `mysqldump` típico para mover dados de um banco de dados externo para uma instância de banco de dados do Amazon RDS é semelhante ao exemplo a seguir. Substitua os valores por suas próprias informações. ``` mysqldump -u local_user \ --databases database_name \ --single-transaction \ --compress \ --order-by-primary \ --routines=0 \ --triggers=0 \ --events=0 \ -plocal_password | mysql -u RDS_user \ --port=port_number \ --host=host_name \ -pRDS_password ``` **Importante** Não deixe um espaço entre a opção `-p` e a senha inserida. Faz parte das práticas recomendadas de segurança especificar credenciais diferentes dos prompts mostrados neste exemplo. Analise as seguintes recomendações e considerações: + Exclua os seguintes esquemas do arquivo de despejo: + `sys` + `performance_schema` + `information_schema` O utilitário `mysqldump` exclui esses esquemas por padrão. + Para migrar usuários e privilégios, considere o uso de uma ferramenta que gera a linguagem de controle de dados (DCL) para recriá-los, como o utilitário [pt-show-grants](https://www.percona.com/doc/percona-toolkit/LATEST/pt-show-grants.html). + Para realizar a importação, verifique se o usuário que está fazendo isso tem acesso à instância de banco de dados. Para obter mais informações, consulte [Controlar acesso com grupos de segurança](Overview.RDSSecurityGroups.md). Os parâmetros utilizados são os seguintes: + `-u local_user` – use para especificar um nome do usuário. Ao usar esse parâmetro pela primeira vez, especifique o nome de uma conta de usuário no banco de dados local MySQL que você identifica com o parâmetro `--databases`. + `--databases database_name`: use para especificar o nome do banco de dados na instância do MySQL local que você deseja importar para o Amazon RDS. + `--single-transaction` – use para garantir que todos os dados carregados do banco de dados local sejam consistentes com um único ponto no tempo. Se houver outros processos alterando os dados enquanto eles são lidos por `mysqldump`, usar esse parâmetro ajudará a manter a integridade dos dados. + `--compress` – use para reduzir o consumo de largura de banda da rede, compactando os dados do banco de dados local antes de os enviar para o Amazon RDS. + `--order-by-primary` – use para reduzir o tempo de carregamento, ordenando os dados de cada tabela de acordo com a chave primária. + `--routines`: use se houver determinadas rotinas, como funções ou procedimentos armazenados, no banco de dados que você está copiando. Defina o parâmetro como `0`, o que exclui as rotinas durante o processo de importação. Depois, recrie manualmente as rotinas no banco de dados do Amazon RDS. + `--triggers`: use se houver gatilhos no banco de dados que você está copiando. Defina o parâmetro como `0`, o que exclui os gatilhos durante o processo de importação. Depois, recrie manualmente os gatilhos no banco de dados do Amazon RDS. + `--events`: use se houver eventos no banco de dados que você está copiando. Defina o parâmetro como `0`, o que exclui os eventos durante o processo de importação. Em seguida, recrie manualmente os eventos no banco de dados do Amazon RDS. + `-plocal_password`: use para especificar uma senha. Ao usar esse parâmetro pela primeira vez, especifique a senha da conta de usuário que você identifica com o primeiro parâmetro `-u`. + `-u RDS_user` – use para especificar um nome do usuário. Ao usar esse parâmetro pela segunda vez, especifique o nome de uma conta de usuário no banco de dados padrão para a instância de banco de dados do MySQL que você identifica com o parâmetro `--host`. + `--port port_number`: use para especificar a porta da sua instância de banco de dados MySQL. Por padrão, essa porta é 3306, a menos que você tenha alterado o valor ao criar a instância de banco de dados. + `--host host_name` – use para especificar o nome do Sistema de Nome de Domínio (DNS) do endpoint da instância de banco de dados Amazon RDS, por exemplo, `myinstance.123456789012.us-east-1.rds.amazonaws.com`. Você pode encontrar o valor do endpoint nos detalhes da instância do banco de dados no console do Amazon RDS. + `-pRDS_password` – use para especificar uma senha. Na segunda utilização desse parâmetro, você especifica a senha da conta de usuário identificada pelo segundo parâmetro `-u`. Certifique-se de criar procedimentos armazenados, acionadores, funções ou eventos manualmente no seu banco de dados Amazon RDS. Se algum desses objetos estiver no banco de dados que você está copiando, exclua-os quando executar `mysqldump`. Para fazer isso, inclua estes parâmetros em seu comando `mysqldump`: + `--routines=0` + `--triggers=0` + `--events=0` **Exemplo** O exemplo a seguir copia o banco de dados de exemplo `world` no host local para uma instância de banco de dados do RDS para MySQL. Substitua os valores por suas próprias informações. Para Linux, macOS ou Unix: ``` sudo mysqldump -u local_user \ --databases world \ --single-transaction \ --compress \ --order-by-primary \ --routines=0 \ --triggers=0 \ --events=0 \ -plocal_password | mysql -u rds_user \ --port=3306 \ --host=my_instance.123456789012.us-east-1.rds.amazonaws.com \ -pRDS_password ``` Para Windows: Execute o comando a seguir em um prompt de comando que foi aberto clicando com o botão direito do mouse em **Prompt de comando** no menu de programas do Windows e escolhendo **Executar como administrador**. Substitua os valores por suas próprias informações. ``` mysqldump -u local_user ^ --databases world ^ --single-transaction ^ --compress ^ --order-by-primary ^ --routines=0 ^ --triggers=0 ^ --events=0 ^ -plocal_password | mysql -u RDS_user ^ --port=3306 ^ --host=my_instance.123456789012.us-east-1.rds.amazonaws.com ^ -pRDS_password ``` **nota** Faz parte das práticas recomendadas de segurança especificar credenciais diferentes dos prompts mostrados no exemplo. # Importar dados para um banco de dados do Amazon RDS para MySQL com tempo de inatividade reduzido Em alguns casos, pode ser preciso importar dados de um banco de dados MySQL externo compatível com uma aplicação dinâmica para uma instância de banco de dados do RDS para MySQL ou um cluster de banco de dados multi-AZ do RDS para MySQL. Use o procedimento a seguir para minimizar o impacto sobre a disponibilidade das aplicações. Este procedimento também pode ser útil se você está trabalhando com um banco de dados muito grande. Usando esse procedimento, você pode reduzir o custo da importação ao diminuir a quantidade de dados transmitidos pela rede para a AWS. Neste procedimento, você transfere uma cópia dos dados do banco de dados para uma instância do Amazon EC2 e importa os dados em um novo banco de dados do Amazon RDS. Depois, use a replicação para atualizar o banco de dados do Amazon RDS em relação à instância externa dinâmica, antes de redirecionar sua aplicação ao banco de dados do Amazon RDS. Configure a replicação com base nas coordenadas do log binário. **nota** Se você quiser importar dados para uma instância de banco de dados RDS para MySQL e o seu ambiente for compatível, recomendamos mover dados para dentro e para fora do Amazon RDS usando arquivos de backup e o Amazon S3. Para obter mais informações, consulte [Restaurar um backup em uma instância de banco de dados do Amazon RDS para MySQL](MySQL.Procedural.Importing.md). O diagrama a seguir mostra como importar um banco de dados MySQL externo para um banco de dados MySQL no Amazon RDS. ![\[Fluxo de trabalho que mostra como importar um banco de dados MySQL externo para um banco de dados MySQL no Amazon RDS.\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/UserGuide/images/MigrateMySQLToRDS_1.png) ## Tarefa 1: criar uma cópia do banco de dados existente A primeira etapa no processo de migração de um grande volume de dados para um banco de dados do RDS para MySQL com o mínimo de tempo de inatividade é criar uma cópia dos dados de origem. O diagrama a seguir mostra como criar um backup do banco de dados MySQL. ![\[Fluxo de trabalho que mostra como criar um backup do banco de dados MySQL.\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/UserGuide/images/MigrateMySQLToRDS_2.png) Você pode usar o utilitário `mysqldump` para criar um backup de banco de dados no formato SQL ou de texto delimitado. Recomendamos que você faça uma execução de teste com cada formato em um ambiente que não seja de produção para ver qual método minimiza o tempo de execução de `mysqldump`. Recomendamos também que você pondere a performance de `mysqldump` em relação ao benefício oferecido usando o formato de texto delimitado para o carregamento. Um backup usando o formato de texto delimitado cria um arquivo de texto separado por tabulação para cada tabela que está sendo despejada. Você pode carregar esses arquivos em paralelo usando o comando `LOAD DATA LOCAL INFILE` para reduzir a quantidade de tempo necessária para importar seu banco de dados. Para acessar mais informações, consulte [Etapa 5: Carregar os dados](mysql-importing-data-any-source.md#mysql-importing-data-any-source-load-data) no procedimento Importar dados de qualquer origem. Antes de iniciar a operação de backup, defina as opções de replicação no banco de dados MySQL que você está copiando para o Amazon RDS. As opções de replicação incluem ativar o registro em log binário e definir um ID de servidor exclusivo. Configurar essas opções faz com que seu servidor comece a registrar em log transações de banco de dados e o prepara para ser um uma instância de replicação de origem mais adiante nesse processo. Analise as seguintes recomendações e considerações: + Use a opção `--single-transaction` com `mysqldump` porque ela despeja um estado consistente do banco de dados. Para garantir um arquivo de despejo válido, não execute instruções de linguagem de definição de dados (DDL) enquanto `mysqldump` estiver em execução. É possível programar uma janela de manutenção para essas operações. + Exclua os seguintes esquemas do arquivo de despejo: + `sys` + `performance_schema` + `information_schema` O utilitário `mysqldump` exclui esses esquemas por padrão. + Para migrar usuários e privilégios, considere o uso de uma ferramenta que gera a linguagem de controle de dados (DCL) para recriá-los, como o utilitário [pt-show-grants](https://www.percona.com/doc/percona-toolkit/LATEST/pt-show-grants.html). ### Como definir opções de replicação 1. Edite o arquivo `my.cnf`. Esse arquivo geralmente está localizado em `/etc`. ``` sudo vi /etc/my.cnf ``` Adicione as opções `log_bin` e `server_id` à seção `[mysqld]`. A opção `log_bin` fornece um identificador de nome de arquivo para arquivos de log binário. A opção `server_id` fornece um identificador exclusivo para o servidor em relações entre origem e réplica. O seguinte exemplo mostra a seção `[mysqld]` atualizada de um arquivo `my.cnf`: ``` [mysqld] log-bin=mysql-bin server-id=1 ``` Para ter mais informações, consulte [Setting the Replication Source Configuration](https://dev.mysql.com/doc/refman/8.4/en/replication-howto-masterbaseconfig.html) na documentação do MySQL. 1. Para replicação com um cluster de banco de dados multi-AZ, defina os parâmetros `ENFORCE_GTID_CONSISTENCY` e `GTID_MODE` como `ON`. ``` mysql> SET @@GLOBAL.ENFORCE_GTID_CONSISTENCY = ON; ``` ``` mysql> SET @@GLOBAL.GTID_MODE = ON; ``` Essas configurações não são necessárias para a replicação com uma instância de banco de dados. 1. Reinicie o serviço `mysql`. ``` sudo service mysqld restart ``` ### Como criar uma cópia de backup do banco de dados existente 1. Crie um backup dos seus dados usando o utilitário `mysqldump`, especificando o formato SQL ou texto delimitado. Para o MySQL 8.0.25 e versões anteriores, especifique `--master-data=2` para criar um arquivo de backup que possa ser usado para iniciar a replicação entre servidores. Para o MySQL 8.0.26 e versões posteriores, especifique `--source-data=2` para criar um arquivo de backup que possa ser usado para iniciar a replicação entre servidores. Para ter mais informações, consulte [mysqldump — A Database Backup Program](https://dev.mysql.com/doc/refman/8.4/en/mysqldump.html) na documentação do MySQL. Para melhorar a performance e garantir a integridade dos dados, use as opções `--order-by-primary` e `--single-transaction` para `mysqldump`. Para evitar a inclusão do banco de dados do sistema MySQL no backup, não use a opção `--all-databases` com `mysqldump`. Para ter mais informações, consulte [Creating a Data Snapshot Using mysqldump](https://dev.mysql.com/doc/mysql-replication-excerpt/8.0/en/replication-howto-mysqldump.html) na documentação do MySQL. Use `chmod`, se necessário, para garantir que o diretório no qual o arquivo de backup está sendo criado seja gravável. **Importante** No Windows, execute a janela de comando como um administrador. + Para produzir a saída SQL, use o seguinte comando: Para Linux, macOS ou Unix: ``` sudo mysqldump \ --databases database_name \ --master-data=2 \ --single-transaction \ --order-by-primary \ -r backup.sql \ -u local_user \ -ppassword ``` **nota** Faz parte das práticas recomendadas de segurança especificar credenciais diferentes dos prompts mostrados no exemplo. Para Windows: ``` mysqldump ^ --databases database_name ^ --master-data=2 ^ --single-transaction ^ --order-by-primary ^ -r backup.sql ^ -u local_user ^ -ppassword ``` **nota** Faz parte das práticas recomendadas de segurança especificar credenciais diferentes dos prompts mostrados no exemplo. + Para produzir uma saída de texto delimitado, use o seguinte comando: Para Linux, macOS ou Unix: ``` sudo mysqldump \ --tab=target_directory \ --fields-terminated-by ',' \ --fields-enclosed-by '"' \ --lines-terminated-by 0x0d0a \ database_name \ --master-data=2 \ --single-transaction \ --order-by-primary \ -ppassword ``` Para Windows: ``` mysqldump ^ --tab=target_directory ^ --fields-terminated-by "," ^ --fields-enclosed-by """ ^ --lines-terminated-by 0x0d0a ^ database_name ^ --master-data=2 ^ --single-transaction ^ --order-by-primary ^ -ppassword ``` **nota** Faz parte das práticas recomendadas de segurança especificar credenciais diferentes dos prompts mostrados no exemplo. Certifique-se de criar procedimentos armazenados, acionadores, funções ou eventos manualmente no seu banco de dados Amazon RDS. Se algum desses objetos estiver no banco de dados que você está copiando, exclua-os quando executar `mysqldump`. Para fazer isso, inclua estes argumentos com o comando`mysqldump`: `--routines=0` `--triggers=0` `--events=0` Para o MySQL 8.0.22 e versões anteriores, quando você executa `mysqldump` e especifica o formato de texto delimitado, um comentário `CHANGE MASTER TO` é exibido. Esse comentário contém o nome e a posição do arquivo de log mestre. Para o MySQL 8.0.23 e versões posteriores, quando você executa `mysqldump` usando o formato de texto delimitado, um comentário `CHANGE REPLICATION SOURCE TO` é exibido. Esse comentário contém o nome e a posição do arquivo de log de origem. Se a instância externa for o MySQL 8.0.23 e versões posteriores, observe os valores para `MASTER_LOG_FILE` e `MASTER_LOG_POS`. Esses valores são necessários ao configurar a replicação. A seguinte saída é exibida para o MySQL 8.0.22 e versões anteriores: ``` -- Position to start replication or point-in-time recovery from -- -- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin-changelog.000031', MASTER_LOG_POS=107; ``` A seguinte saída é retornada para o MySQL 8.0.23 e versões posteriores: ``` -- Position to start replication or point-in-time recovery from -- -- CHANGE SOURCE TO SOURCE_LOG_FILE='mysql-bin-changelog.000031', SOURCE_LOG_POS=107; ``` Para o MySQL 8.0.22 e versões anteriores, se você estiver usando o formato SQL, poderá obter o nome e a posição do arquivo de log mestre no comentário `CHANGE MASTER TO` no arquivo de backup. Para o MySQL 8.0.23 e versões posteriores, se você estiver usando o formato SQL, poderá obter o nome e a posição do arquivo de log de origem no comentário `CHANGE REPLICATION SOURCE TO` no arquivo de backup. 1. Compacte os dados copiados para reduzir a quantidade de recursos de rede necessários para copiar seus dados para o banco de dados do Amazon RDS. Anote o tamanho do arquivo de backup. Você precisará dessas informações ao determinar o tamanho de uma instância do Amazon EC2 a ser criada. Quando terminar, compacte o arquivo de backup usando o GZIP ou seu utilitário de compactação preferido. + Para compactar a saída SQL, use o seguinte comando: ``` gzip backup.sql ``` + Para compactar a saída de texto delimitado, use o seguinte comando: ``` tar -zcvf backup.tar.gz target_directory ``` ## Tarefa 2: criar uma instância do Amazon EC2 e copiar o banco de dados compactado Copiar seu arquivo de backup de banco de dados compactado para uma instância do Amazon EC2 requer menos recursos de rede do que fazer uma cópia direta de dados não compactados entre instâncias de bancos de dados. Depois que seus dados estiverem no Amazon EC2, você poderá copiá-los de lá diretamente para o banco de dados MySQL. Para reduzir o custo dos recursos de rede, a instância do Amazon EC2 deve estar na mesma Região da AWS que a instância de banco de dados do Amazon RDS. Ter a instância do Amazon EC2 na mesma Região da AWS que o banco de dados do Amazon RDS também reduz a latência da rede durante a importação. O diagrama a seguir mostra como copiar o backup do banco de dados para uma instância do Amazon EC2. ![\[Fluxo de trabalho que mostra como copiar o backup do banco de dados para uma instância do EC2.\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/UserGuide/images/MigrateMySQLToRDS_3.png) ### Como criar uma instância do Amazon EC2 e copiar seus dados 1. Na Região da AWS em que você planeja criar o banco de dados do Amazon RDS, crie uma nuvem privada virtual (VPC), um grupo de segurança de VPC e uma sub-rede de VPC. Certifique-se de que as regras de entrada para o grupo de segurança da VPC permitam os endereços IP necessários para a aplicação se conectar ao AWS. Você pode especificar uma variedade de endereços IP (por exemplo, `203.0.113.0/24`) ou outro grupo de segurança de VPC. É possível usar o [console da Amazon VPC](https://console.aws.amazon.com/vpc) para criar e gerenciar VPCs, sub-redes e grupos de segurança. Para ter mais informações, consulte [Conceitos básicos da Amazon VPC](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html#getting-started) no *Manual do usuário da Amazon Virtual Private Cloud*. 1. Abra o [console do Amazon EC2](https://console.aws.amazon.com/ec2) e escolha a Região da AWS para conter tanto a instância do Amazon EC2 como o banco de dados do Amazon RDS. Inicie uma instância do Amazon EC2 usando a VPC, a sub-rede e o grupo de segurança que você criou na Etapa 1. Certifique-se de selecionar um tipo de instância com armazenamento suficiente para o arquivo de backup de banco de dados quando ele não estiver compactado. Para ter detalhes sobre instâncias do Amazon EC2, consulte [Comece a usar o Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EC2_GetStarted.html) no *Guia do usuário do Amazon Elastic Compute Cloud*. 1. Para se conectar ao banco de dados do Amazon RDS pela sua instância do Amazon EC2, edite seu grupo de segurança da VPC. Adicione uma regra de entrada especificando o endereço IP privado da sua instância do EC2. Você pode encontrar o endereço IP privado na guia **Details (Detalhes)** do painel **Instance (Instância)** na janela do console do EC2. Para editar o grupo de segurança de VPC e adicionar uma regra de entrada, escolha **Security Groups (Grupos de segurança)** no painel de navegação do console do EC2, escolha o grupo de segurança e, em seguida, adicione uma regra de entrada para MySQL ouAurora especificando o endereço IP privado da sua instância do EC2. Para saber como adicionar uma regra de entrada a um grupo de segurança de VPC, consulte [Regras de grupos de segurança](https://docs.aws.amazon.com/vpc/latest/userguide/security-group-rules.html) no *Manual do usuário da Amazon Virtual Private Cloud*. 1. Copie o arquivo de backup de banco de dados compactado do seu sistema local para a sua instância do Amazon EC2. Use `chmod`, se necessário, para garantir que você tenha permissão de gravação para o diretório de destino da instância do Amazon EC2. Você pode usar `scp` ou um cliente Secure Shell (SSH) para copiar o arquivo. O seguinte comando é um exemplo de comando `scp`: ``` scp -r -i key pair.pem backup.sql.gz ec2-user@EC2 DNS:/target_directory/backup.sql.gz ``` **Importante** Ao copiar dados sensíveis, use um protocolo de transferência de rede segura. 1. Conecte-se à sua instância do Amazon EC2 e instale as atualizações e as ferramentas do cliente MySQL mais recentes usando os seguintes comandos: ``` sudo yum update -y sudo yum install mysql -y ``` Para ter mais informações, consulte [Conectar-se à instância](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EC2_GetStarted.html#ec2-connect-to-instance-linux) no *Guia do usuário do Amazon Elastic Compute Cloud para Linux*. **Importante** Este exemplo instala o cliente MySQL em uma distribuição de imagem de máquina da Amazon (AMI) do Amazon Linux. Este exemplo não instala o cliente MySQL em uma distribuição diferente, como Ubuntu ou Red Hat Enterprise Linux. Para ter informações sobre como instalar o MySQL, consulte [Installing MySQL](https://dev.mysql.com/doc/refman/8.4/en/installing.html) na documentação do MySQL. 1. Enquanto estiver conectado à sua instância do Amazon EC2, descompacte o arquivo de backup do banco de dados. Os comandos a seguir são exemplos. + Para descompactar a saída SQL, use o seguinte comando: ``` gzip backup.sql.gz -d ``` + Para descomprimir a saída de texto delimitada, use o seguinte comando: ``` tar xzvf backup.tar.gz ``` ## Tarefa 3: criar um banco de dados MySQL e importar os dados da instância do Amazon EC2 Ao criar uma instância de banco de dados ou um cluster de banco de dados multi-AZ do RDS para MySQL na mesma Região da AWS que a instância do Amazon EC2, você pode importar o arquivo de backup do banco de dados do Amazon EC2 mais rapidamente do que pela internet. O diagrama a seguir mostra como importar o backup de uma instância do Amazon EC2 para um banco de dados MySQL. ![\[Fluxo de trabalho que mostra como importar o backup da instância do EC2 para o banco de dados MySQL.\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/UserGuide/images/MigrateMySQLToRDS_4.png) ### Como criar um banco de dados MySQL e importar seus dados 1. Determine qual classe de instância de banco de dados e que quantidade de espaço de armazenamento são necessários para atender à workload esperada para esse banco de dados do Amazon RDS. Como parte desse processo, decida sobre o espaço suficiente e a capacidade de processamento para os seus procedimentos de carregamento de dados. Além disso, decida o que é necessário para lidar com a workload de produção. Você pode estimar isso com base no tamanho e nos recursos do banco de dados MySQL de origem. Para obter mais informações, consulte [Classes de instâncias de banco de dados do ](Concepts.DBInstanceClass.md). 1. Crie uma instância de banco de dados ou um cluster de banco de dados multi-AZ na Região da AWS que contém a instância do Amazon EC2. Para criar um cluster de banco de dados multi-AZ do RDS para MySQL, siga as instruções em [Criar um cluster de banco de dados multi-AZ para o Amazon RDS](create-multi-az-db-cluster.md). Para criar uma instância de banco de dados do RDS para MySQL, siga as instruções em [Criar uma instância de banco de dados do Amazon RDS](USER_CreateDBInstance.md) e use as seguintes diretrizes: + Especifique uma versão do mecanismo de banco de dados que seja compatível com a sua instância de banco de dados de origem. + Especifique a mesma nuvem privada virtual (VPC) e o grupo de segurança da VPC para sua instância do Amazon EC2. Essa abordagem garante que sua instância do Amazon EC2 e sua instância do Amazon RDS sejam visíveis uma para a outra na rede. Verifique se sua instância de banco de dados pode ser acessada publicamente. Para configurar a replicação com o banco de dados de origem, conforme descrito em uma seção mais adiante, a instância de banco de dados deve ser acessível ao público. + Não configure várias zonas de disponibilidade, retenção de backup nem réplicas de leitura até depois de ter importado o backup do banco de dados. Quando a importação estiver concluída, você poderá configurar o recurso multi-AZ e a retenção de backup para a instância de produção. 1. Reveja as opções de configuração padrão para o banco de dados do Amazon RDS. Se o grupo de parâmetros padrão para o banco de dados não tiver as opções de configuração desejadas, encontre outro que as inclua ou crie um grupo de parâmetros. Para ter mais informações sobre como criar um grupo de parâmetros, consulte [Grupos de parâmetros para Amazon RDS](USER_WorkingWithParamGroups.md). 1. Conecte-se ao novo banco de dados do Amazon RDS como usuário principal. Crie os usuários necessários para dar suporte aos administradores, aplicações e serviços que precisam acessar a instância de banco de dados. O nome do host para o banco de dados do Amazon RDS é o valor do **endpoint** dessa instância, de banco de dados sem o número da porta; por exemplo, `mysampledb.123456789012.us-west-2.rds.amazonaws.com`. Você pode encontrar o valor do endpoint nos detalhes do banco de dados no console do Amazon RDS. 1. Conecte-se à sua instância Amazon EC2. Para ter mais informações, consulte [Conectar-se à instância](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EC2_GetStarted.html#ec2-connect-to-instance-linux) no *Guia do usuário do Amazon Elastic Compute Cloud para Linux*. 1. Conecte-se ao seu banco de dados do Amazon RDS como um host remoto pela sua instância do Amazon EC2 usando o comando `mysql`. O seguinte comando é um exemplo: ``` mysql -h host_name -P 3306 -u db_master_user -p ``` O *host\$1name* é o endpoint do banco de dados do Amazon RDS. 1. No prompt `mysql`, execute o comando `source` e passe a ele o nome do arquivo de despejo do banco de dados. Esse comando carrega os dados na instância de banco de dados do Amazon RDS. + Para o formato SQL, use o seguinte comando: ``` mysql> source backup.sql; ``` + Para o formato de texto delimitado, primeiro crie o banco de dados, se ele não for o banco de dados padrão que você criou ao configurar o banco de dados do Amazon RDS. ``` mysql> create database database_name; mysql> use database_name; ``` Em seguida, crie as tabelas. ``` mysql> source table1.sql mysql> source table2.sql etc... ``` Em seguida, importe os dados. ``` mysql> LOAD DATA LOCAL INFILE 'table1.txt' INTO TABLE table1 FIELDS TERMINATED BY ',' ENCLOSED BY '"' LINES TERMINATED BY '0x0d0a'; mysql> LOAD DATA LOCAL INFILE 'table2.txt' INTO TABLE table2 FIELDS TERMINATED BY ',' ENCLOSED BY '"' LINES TERMINATED BY '0x0d0a'; etc... ``` Para melhorar a performance, você pode realizar essas operações em paralelo de várias conexões, para que todas as tabelas sejam criadas e carregadas ao mesmo tempo. **nota** Se você usou qualquer opção de formatação de dados com `mysqldump` quando despejou inicialmente a tabela, use as mesmas opções com `LOAD DATA LOCAL INFILE` para assegurar uma interpretação adequada do conteúdo do arquivo de dados. 1. Execute uma consulta `SELECT` simples em uma ou duas das tabelas no banco de dados importado para verificar se a importação foi bem-sucedida. Se você não precisa mais da instância do Amazon EC2 usada neste procedimento, encerre-a para reduzir o uso de recursos de uso da AWS. Para encerrar uma instância do EC2, consulte [Como encerrar uma instância](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/terminating-instances.html#terminating-instances-console) no *Guia do usuário do Amazon Elastic Compute Cloud*. ## Tarefa 4: replicar dados do banco de dados externo para o novo banco de dados do Amazon RDS Seu banco de dados de origem provavelmente foi atualizado durante o tempo decorrido entre a cópia e a transferência dos dados para o banco de dados MySQL. Assim, você pode usar a replicação para atualizar o banco de dados copiado com o banco de dados de origem. ![\[Fluxo de trabalho que mostra como replicar dados do banco de dados MySQL externo para o banco de dados no Amazon RDS.\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/UserGuide/images/MigrateMySQLToRDS_5.png) As permissões necessárias para iniciar a replicação em um banco de dados do Amazon RDS são restritas e não estão disponíveis ao seu usuário principal do Amazon RDS. Por esse motivo, use o procedimento armazenado apropriado do Amazon RDS para a versão principal do mecanismo: + [mysql\$1rds\$1set\$1external\$1master (versões principais do RDS para MySQL 8.0 ou anterior)](mysql-stored-proc-replicating.md#mysql_rds_set_external_master) + [mysql.rds\$1set\$1external\$1source (RDS para MySQL versões principais 8.4 e posteriores)](mysql-stored-proc-replicating.md#mysql_rds_set_external_source) + [mysql.rds\$1set\$1external\$1master\$1gtid](mysql_rds_set_external_master_gtid.md) para configurar a replicação e [mysql.rds\$1start\$1replication](mysql-stored-proc-replicating.md#mysql_rds_start_replication) para iniciar a replicação ### Como iniciar a replicação Na Tarefa 1, [ao definir as opções de replicação](#mysql-importing-data-reduced-downtime-set-replication-options), você ativou o registro em log binário e definiu um ID de servidor exclusivo para o banco de dados de origem. Agora, é possível configurar seu banco de dados Amazon RDS como uma réplica com seu banco de dados dinâmico como a instância de replicação de origem. 1. No console do Amazon RDS, adicione o endereço IP do servidor que hospeda o banco de dados de origem ao grupo de segurança da VPC para o banco de dados do Amazon RDS. Para ter mais informações sobre grupos de segurança da VPC, consulte [Configurar regras de grupo de segurança](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-security-group-rules.html) no *Manual do usuário da Amazon Virtual Private Cloud*. Você também pode precisar configurar a rede local para permitir conexões com o endereço IP do banco de dados do Amazon RDS, para que ele possa se comunicar com a instância de origem. Para localizar o endereço IP do banco de dados do Amazon RDS, use o comando `host`: ``` host host_name ``` O *host\$1name* é o nome DNS do endpoint do banco de dados do Amazon RDS; por exemplo, `myinstance.123456789012.us-east-1.rds.amazonaws.com`. Você pode encontrar o valor do endpoint nos detalhes da instância do banco de dados no console do Amazon RDS. 1. Usando o cliente de sua preferência, conecte-se à instância de origem e crie um usuário a ser usado para a replicação. Esta conta é usada unicamente para replicação e deve estar restrita ao seu domínio para melhorar a segurança. O seguinte comando é um exemplo: ``` CREATE USER 'repl_user'@'mydomain.com' IDENTIFIED BY 'password'; ``` **nota** Especifique credenciais diferentes dos prompts mostrados aqui como prática recomendada de segurança. 1. Para a instância de origem, conceda os privilégios `REPLICATION CLIENT` e `REPLICATION SLAVE` para seu usuário de replicação. Por exemplo, para conceder os privilégios de `REPLICATION CLIENT` e `REPLICATION SLAVE` em todos os bancos de dados para o usuário '`repl_user`' de seu domínio, emita o seguinte comando: ``` GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'mydomain.com'; ``` 1. Torne o banco de dados do Amazon RDS a réplica. Conecte-se ao banco de dados Amazon RDS como usuário principal e identifique o banco de dados de origem como a instância de replicação de origem usando o comando o procedimento armazenado apropriado do Amazon RDS. + [mysql\$1rds\$1set\$1external\$1master (versões principais do RDS para MySQL 8.0 ou anterior)](mysql-stored-proc-replicating.md#mysql_rds_set_external_master) + [mysql.rds\$1set\$1external\$1source (RDS para MySQL versões principais 8.4 e posteriores)](mysql-stored-proc-replicating.md#mysql_rds_set_external_source) Se você tiver um arquivo de backup no formato SQL, use o nome do arquivo de log mestre e a posição do log mestre que você determinou na Etapa 4. Se você usou o formato de texto delimitado, use o nome e a posição que você determinou ao criar os arquivos de backup. Os seguintes comandos são exemplos: **MySQL 8.4 e versões posteriores** ``` CALL mysql.rds_set_external_source ('myserver.mydomain.com', 3306, 'repl_user', 'password', 'mysql-bin-changelog.000031', 107, 1); ``` **MySQL 8.0 e versões anteriores** ``` CALL mysql.rds_set_external_master ('myserver.mydomain.com', 3306, 'repl_user', 'password', 'mysql-bin-changelog.000031', 107, 1); ``` **nota** Especifique credenciais diferentes dos prompts mostrados aqui como prática recomendada de segurança. 1. No banco de dados Amazon RDS, para iniciar a replicação, execute o seguinte comando que usa o procedimento armazenado [mysql.rds\$1start\$1replication](mysql-stored-proc-replicating.md#mysql_rds_start_replication): ``` CALL mysql.rds_start_replication; ``` 1. No banco de dados do Amazon RDS, para determinar quando a réplica está atualizada com a instância de replicação de origem, execute o comando [SHOW REPLICA STATUS](https://dev.mysql.com/doc/refman/8.0/en/show-replica-status.html). Os resultados do comando `SHOW REPLICA STATUS` incluem o campo `Seconds_Behind_Master`. Quando o campo `Seconds_Behind_Master` retorna 0, a réplica é atualizada com a instância de replicação de origem. **nota** As versões anteriores do MySQL usavam `SHOW SLAVE STATUS` em vez de `SHOW REPLICA STATUS`. Se você estiver usando uma versão do MySQL anterior à 8.0.23, use `SHOW SLAVE STATUS`. 1. Depois que o banco de dados do Amazon RDS estiver atualizado, ative backups automatizados para poder restaurar esse banco de dados, se necessário. Você pode ativar ou modificar backups automatizados para um banco de dados do Amazon RDS usando o [console do Amazon RDS](https://console.aws.amazon.com/rds/). Para obter mais informações, consulte [Introdução aos backups](USER_WorkingWithAutomatedBackups.md). ## Tarefa 5: redirecionar a aplicação ativa para a instância do Amazon RDS Depois que o banco de dados MySQL estiver atualizado com a instância de replicação de origem, será possível atualizar a aplicação dinâmica para usar a instância do Amazon RDS. ![\[Fluxo de trabalho que mostra como interromper a replicação e direcionar a aplicação ativa para o banco de dados no Amazon RDS.\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/UserGuide/images/MigrateMySQLToRDS_6.png) ### Como redirecionar a aplicação dinâmica para o banco de dados MySQL e interromper a replicação 1. Para adicionar o grupo de segurança de VPC para o banco de dados do Amazon RDS, adicione o endereço IP do servidor que hospeda a aplicação. Para ter mais informações sobre como modificar um grupo de segurança de VPC, consulte [Configurar regras de grupo de segurança](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-security-group-rules.html) no *Manual do usuário da Amazon Virtual Private Cloud*. 1. Verifique se o campo `Seconds_Behind_Master` nos resultados do comando [SHOW REPLICA STATUS](https://dev.mysql.com/doc/refman/8.0/en/show-replica-status.html) é 0, o que indica que a réplica está atualizada com a instância de replicação de origem. ``` SHOW REPLICA STATUS; ``` **nota** As versões anteriores do MySQL usavam `SHOW SLAVE STATUS` em vez de `SHOW REPLICA STATUS`. Se você estiver usando uma versão do MySQL anterior à 8.0.23, use `SHOW SLAVE STATUS`. 1. Feche todas as conexões com a origem quando suas transações terminarem. 1. Atualize sua aplicação para usar o banco de dados do Amazon RDS. Normalmente, essa atualização envolve a alteração das configurações de conexão para identificar o nome do host e a porta do banco de dados do Amazon RDS, a conta de usuário e a senha para conexão e o banco de dados para uso. 1. Conecte-se à instância de banco de dados. No caso de um cluster de banco de dados multi-AZ, conecte-se a uma instância de banco de dados gravadora. 1. Interrompa a replicação da instância do Amazon RDS usando o seguinte comando que usa o procedimento armazenado [mysql.rds\$1stop\$1replication](mysql-stored-proc-replicating.md#mysql_rds_stop_replication): ``` CALL mysql.rds_stop_replication; ``` 1. Redefina a configuração de replicação de maneira que essa instância não seja mais identificada como uma réplica, usando o procedimento armazenado apropriado do Amazon RDS no banco de dados do Amazon RDS. + [mysql\$1rds\$1reset\$1external\$1master (versões principais do RDS para MySQL 8.0 e anteriores)](mysql-stored-proc-replicating.md#mysql_rds_reset_external_master) + [mysql.rds\$1reset\$1external\$1source (RDS para MySQL versões principais 8.4 e posteriores)](mysql-stored-proc-replicating.md#mysql_rds_reset_external_source) **MySQL 8.4 e versões posteriores** ``` CALL mysql.rds_reset_external_source; ``` **MySQL 8.0 e versões anteriores** ``` CALL mysql.rds_reset_external_master; ``` 1. Ative recursos adicionais do Amazon RDS, como o suporte a multi-AZ e réplicas de leitura. Para obter mais informações, consulte [Configurar e gerenciar uma implantação multi-AZ para o Amazon RDS](Concepts.MultiAZ.md) e [Trabalhar com réplicas de leitura de instância de banco de dados](USER_ReadRepl.md). # Importar dados de qualquer fonte para uma instância de banco de dados do Amazon RDS para MySQL Com o Amazon RDS, você pode migrar dados existentes do MySQL de qualquer origem para uma instância de banco de dados do RDS para MySQL. Você pode transferir dados de bancos de dados on-premises, outros provedores de nuvem ou instâncias de banco de dados do RDS para MySQL DB existentes para sua instância de banco de dados do RDS para MySQL de destino. Com essa funcionalidade, você pode consolidar bancos de dados, implementar soluções de recuperação de desastres ou fazer a transição de bancos de dados autogerenciados. São cenários comuns migrar de servidores do MySQL auto-hospedados para instâncias de banco de dados do Amazon RDS totalmente gerenciadas, consolidar vários bancos de dados MySQL em uma única instância de banco de dados ou criar ambientes de teste com dados de produção. As seções a seguir apresentam instruções detalhadas sobre como importar dados do MySQL usando métodos, como `mysqldump`, arquivos de backup ou replicação. ## Etapa 1: Criar arquivos simples contendo os dados a serem carregados Use um formato comum, como valores separados por vírgula (CSV), para armazenar os dados a serem carregados. Cada tabela deve ter um arquivo próprio. Não é possível combinar os dados de várias tabelas no mesmo arquivo. Dê a cada arquivo o mesmo nome que a tabela correspondente. A extensão do arquivo pode ser qualquer opção desejada. Por exemplo, se o nome da tabela for `sales`, o nome do arquivo poderá ser `sales.csv` ou `sales.txt`. Se possível, ordene os dados pela chave primária da tabela que está sendo carregada. Fazer isso melhora drasticamente os tempos de carregamento e minimiza os requisitos de armazenamento em disco. A velocidade e a eficiência desse procedimento dependem de manter o tamanho dos arquivos pequenos. Se o tamanho descompactado de qualquer arquivo individual for maior que 1 GiB, divida-o em vários arquivos e carregue cada um separadamente. Em sistemas semelhantes ao Unix (incluindo o Linux), use o comando `split`. Por exemplo, o seguinte comando divide o arquivo `sales.csv` em vários arquivos com menos de 1 GiB, dividindo apenas em intervalos de linha (-C 1024m). Os nomes dos novos arquivos incluem sufixos numéricos ascendentes. O comando a seguir produz arquivos com nomes, como `sales.part_00` e `sales.part_01`. ``` split -C 1024m -d sales.csv sales.part_ ``` Utilitários semelhantes estão disponíveis para outros sistemas operacionais. Você pode armazenar os arquivos simples em qualquer lugar. No entanto, ao carregar os dados na [Etapa 5](#mysql-importing-data-any-source-load-data), você deve invocar o shell `mysql` do mesmo local em que os arquivos estão ou usar o caminho absoluto para os arquivos ao executar `LOAD DATA LOCAL INFILE`. ## Etapa 2: impedir que quaisquer aplicações acessem a instância de banco de dados de destino Antes de iniciar um grande carregamento, impeça que qualquer atividade da aplicação acesse a instância de banco de dados de destino para a qual planeja fazer o carregamento. Recomendamos isso especialmente se outras sessões modificarem as tabelas que estão sendo carregadas ou as tabelas às quais elas fazem referência. Isso reduz o risco de violações de restrição durante o carregamento e melhora a performance do carregamento. Também possibilita restaurar a instância de banco de dados até o ponto antes do carregamento, sem perder as alterações feitas pelos processos não envolvidos no carregamento. É que isso pode não ser possível ou prático. Se você não conseguir impedir que as aplicações acessem a instância de banco de dados antes do carregamento, tome medidas para garantir a disponibilidade e a integridade dos seus dados. As etapas específicas necessárias variam muito dependendo dos casos específicos de uso e dos requisitos do site. ## Etapa 3: Criar um snapshot de banco de dados Se você planeja carregar dados em uma nova instância de banco de dados que não contém dados, pode ignorar essa etapa. Do contrário, recomendamos criar snapshots de banco de dados da instância de banco de dados de destino do Amazon RDS antes e depois do carregamento dos dados. Os snapshots de banco de dados do Amazon RDS são backups completos da instância de banco de dados que podem ser usados para restaurá-la em um estado conhecido. Quando você inicia um snapshot de banco de dados, as operações de E/S na sua instância de banco de dados são momentaneamente suspensas enquanto é feito o backup do banco de dados. Criar um snapshot de banco de dados imediatamente antes do carregamento possibilita a restauração do banco de dados para o estado anterior ao carregamento, se necessário. Um snapshot de banco de dados feito imediatamente após a carga evita que você tenha que carregar os dados novamente caso ocorra um problema. Você também pode usar snapshots de banco de dados após o carregamento para importar dados para novas instâncias de banco de dados. O exemplo a seguir executa o comando [create-db-snapshot](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-snapshot.html) da AWS CLI para criar um snapshot de banco de dados da instância `AcmeRDS` e fornece ao snapshot do banco de dados o identificador `"preload"`. Para Linux, macOS ou Unix: ``` aws rds create-db-snapshot \ --db-instance-identifier AcmeRDS \ --db-snapshot-identifier preload ``` Para Windows: ``` aws rds create-db-snapshot ^ --db-instance-identifier AcmeRDS ^ --db-snapshot-identifier preload ``` Você também pode usar a restauração da funcionalidade de snapshot do banco de dados para criar instâncias de banco de dados de teste para execuções simuladas ou para desfazer alterações feitas durante o carregamento. Tenha em mente que restaurar um banco de dados de um snapshot de banco de dados cria uma nova instância de banco de dados que, como todas as instâncias de banco de dados, possui um identificador exclusivo e um endpoint. Para restaurar a instância de banco de dados sem alterar o endpoint, primeiro exclua a instância de banco de dados para poder reutilizar o endpoint. Por exemplo, para criar uma instância de banco de dados para execuções simuladas ou outros testes, forneça à instância de banco de dados um identificador próprio. Na exemplo, o identificador é `AcmeRDS-2`. O exemplo se conecta à instância de banco de dados usando o endpoint associado ao `AcmeRDS-2`. Para ter mais informações, consulte [restore-db-instance-from-db-snapshot](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-from-db-snapshot.html). Para Linux, macOS ou Unix: ``` aws rds restore-db-instance-from-db-snapshot \ --db-instance-identifier AcmeRDS-2 \ --db-snapshot-identifier preload ``` Para Windows: ``` aws rds restore-db-instance-from-db-snapshot ^ --db-instance-identifier AcmeRDS-2 ^ --db-snapshot-identifier preload ``` Para reutilizar o endpoint existente, primeiro exclua a instância de banco de dados e forneça ao banco de dados restaurado o mesmo identificador. Para ter mais informações, consulte [delete-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/delete-db-instance.html). O exemplo a seguir também cria um snapshot de banco de dados final da instância de banco de dados antes de excluí-la. Isso é opcional, porém é recomendado. Para Linux, macOS ou Unix: ``` aws rds delete-db-instance \ --db-instance-identifier AcmeRDS \ --final-db-snapshot-identifier AcmeRDS-Final aws rds restore-db-instance-from-db-snapshot \ --db-instance-identifier AcmeRDS \ --db-snapshot-identifier preload ``` Para Windows: ``` aws rds delete-db-instance ^ --db-instance-identifier AcmeRDS ^ --final-db-snapshot-identifier AcmeRDS-Final aws rds restore-db-instance-from-db-snapshot ^ --db-instance-identifier AcmeRDS ^ --db-snapshot-identifier preload ``` ## Etapa 4 (opcional): desativar os backups automatizados do Amazon RDS **Atenção** Não desative os backups automatizados se você precisa realizar uma recuperação para um ponto no tempo. A desativação de backups automatizados ajuda a otimizar a performance e não é necessária para carregamentos de dados. Ao desativar os backups automatizados, todos os backups existentes são apagados. Consequentemente, após a desativação dos backups automatizados, não é possível realizar uma recuperação para um ponto no tempo. Os snapshots do banco de dados manuais não são afetados com a desativação dos backups automatizados. Todos os snapshots de banco de dados manuais existentes ainda estão disponíveis para restauração. Desativar os backups automatizados reduz o tempo de carregamento em cerca de 25% e reduz a quantidade de espaço de armazenamento necessária durante o carregamento. Se você planeja carregar dados em uma nova instância de banco de dados que não contém dados, desativar os backups é uma maneira fácil de acelerar o carregamento e evitar o uso do armazenamento adicional necessário para backups. No entanto, em alguns casos, você pode planejar fazer o carregamento em uma instância de banco de dados que já contenha dados. Se for o caso, avalie os benefícios da desativação de backups em relação ao impacto da perda da capacidade de realizar a recuperação em um ponto anterior no tempo. As instâncias de bancos de dados têm backups automatizados desativados por padrão (com um período de retenção de um dia). Para desatiar os backups automáticos, defina o período de retenção de backup para zero. Após o carregamento, você pode reativar os backups definindo o período de retenção de backup como um valor diferente de zero. Para ativar ou desativar os backups, o Amazon RDS desliga a instância de banco de dados e a reinicia para ativar ou desativar o registro em log do MySQL. Execute o comando AWS CLI da `modify-db-instance` para definir a retenção do backup como zero e aplicar a alteração imediatamente. Definir o período de retenção como zero exige uma reinicialização da instância de banco de dados. Por isso, aguarde até que a reinicialização tenha sido concluída antes de prosseguir. Para obter mais informações, consulte [modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html). Para Linux, macOS ou Unix: ``` aws rds modify-db-instance \ --db-instance-identifier AcmeRDS \ --apply-immediately \ --backup-retention-period 0 ``` Para Windows: ``` aws rds modify-db-instance ^ --db-instance-identifier AcmeRDS ^ --apply-immediately ^ --backup-retention-period 0 ``` Você pode conferir o status sua instância de banco de dados com o comando [describe-db-instances](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-instances.html). O seguinte exemplo mostra o status da instância de banco de dados `AcmeRDS`: ``` aws rds describe-db-instances --db-instance-identifier AcmeRDS --query "*[].{DBInstanceStatus:DBInstanceStatus}" ``` Quando o status da instância de banco de dados for `available`, você poderá prosseguir para a próxima etapa. ## Etapa 5: Carregar os dados Para ler as linhas dos arquivos simples nas tabelas do banco de dados, use a instrução MySQL `LOAD DATA LOCAL INFILE`. **nota** Você deve invocar o shell `mysql` do mesmo local em que seus arquivos simples estão ou usar o caminho absoluto para os arquivos ao executar `LOAD DATA LOCAL INFILE`. O seguinte exemplo mostra como carregar dados de um arquivo chamado `sales.txt` em uma tabela denominada `Sales` no banco de dados: ``` mysql> LOAD DATA LOCAL INFILE 'sales.txt' INTO TABLE Sales FIELDS TERMINATED BY ' ' ENCLOSED BY '' ESCAPED BY '\\'; Query OK, 1 row affected (0.01 sec) Records: 1 Deleted: 0 Skipped: 0 Warnings: 0 ``` Para ter mais informações sobre a instrução `LOAD DATA`, consulte [LOAD DATA Statement](https://dev.mysql.com/doc/refman/8.4/en/load-data.html) na documentação do MySQL. ## Etapa 6: reativar os backups automatizados do Amazon RDS Se você desativou os backups automatizados do Amazon RDS na [Etapa 4](#mysql-importing-data-any-source-turn-off-automated-backups), depois que o carregamento for concluído, ative os backups automatizados definindo o período de retenção de backup de volta como o valor anterior ao carregamento. Conforme mencionado na Etapa 4, como o Amazon RDS reinicia a instância de banco de dados, prepare-se para uma breve interrupção. O seguinte exemplo executa o comando [modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html) da AWS CLI para ativar os backups automatizados da instância de banco de dados `AcmeRDS` e define o período de retenção para um dia: Para Linux, macOS ou Unix: ``` aws rds modify-db-instance \ --db-instance-identifier AcmeRDS \ --backup-retention-period 1 \ --apply-immediately ``` Para Windows: ``` aws rds modify-db-instance ^ --db-instance-identifier AcmeRDS ^ --backup-retention-period 1 ^ --apply-immediately ``` # Trabalhar com a replicação do MySQL no Amazon RDS Normalmente, você usa réplicas de leitura para configurar a replicação entre as instâncias de banco de dados do Amazon RDS. Para obter informações gerais sobre réplicas de leitura, consulte [Trabalhar com réplicas de leitura de instância de banco de dados](USER_ReadRepl.md). Para obter informações específicas sobre como trabalhar com réplicas de leitura no Amazon RDS para MySQL, consulte [Trabalhar com réplicas de leitura do MySQL](USER_MySQL.Replication.ReadReplicas.md). Você pode utilizar Global Transaction Identifiers (GTIDs – Identificadores de transação global) para replicação com o RDS para MySQL. Para obter mais informações, consulte [Usar a replicação baseada em GTID](mysql-replication-gtid.md). A replicação também pode ser configurada entre uma instância de banco de dados do RDS para MySQL e uma instância MySQL ou MariaDB externa ao Amazon RDS. Para obter informações sobre como configurar a replicação com uma origem externa, consulte [Configurar a replicação da posição do arquivo de log binário com uma instância de origem externa](MySQL.Procedural.Importing.External.Repl.md). Para todas essas opções de replicação, use replicação baseada em linha, em instrução ou mista. A replicação baseada em linha só replica as linhas alteradas resultantes de uma instrução SQL. A replicação baseada em instrução copia toda a instrução SQL. A replicação mista usa uma replicação baseada em instrução quando possível, mas alterna para replicação baseada em linha quando as instruções SQL não seguras para replicação baseada em instrução são executadas. Na maioria dos casos, a replicação mista é recomendada. O formato de log binário da instância de banco de dados determina se a replicação se baseia na linha, na instrução ou mista. Para obter informações sobre como definir o formato de log binário, consulte [Configurar o registro em log binário do RDS para MySQL para bancos de dados single-AZ](USER_LogAccess.MySQL.BinaryFormat.md). **nota** Você pode configurar a replicação para importar bancos de dados de uma instância MySQL ou MariaDB externa ao Amazon RDS, ou exportar bancos de dados para essas instâncias. Para obter mais informações, consulte [Importar dados para um banco de dados do Amazon RDS para MySQL com tempo de inatividade reduzido](mysql-importing-data-reduced-downtime.md) e [Exportar dados de uma instância de banco de dados MySQL usando replicação](MySQL.Procedural.Exporting.NonRDSRepl.md). Depois de restaurar a instância de banco de dados com base em um snapshot ou realizar uma recuperação para um ponto no tempo, é possível visualizar a última posição do log binário recuperada do banco de dados de origem no console do RDS. Em **Logs e eventos**, insira **log binário**. A posição do log binário aparece em **Notas do sistema**. **Topics** + [ # Trabalhar com réplicas de leitura do MySQL ](USER_MySQL.Replication.ReadReplicas.md) + [ # Usar a replicação baseada em GTID ](mysql-replication-gtid.md) + [ # Configurar a replicação da posição do arquivo de log binário com uma instância de origem externa ](MySQL.Procedural.Importing.External.Repl.md) + [ # Configurar a replicação de várias fontes do Amazon RDS para MySQL ](mysql-multi-source-replication.md) # Trabalhar com réplicas de leitura do MySQL A seguir, você pode encontrar informações específicas sobre como trabalhar com réplicas de leitura no RDS para MySQL. Para obter informações gerais sobre as réplicas de leitura e as instruções de como usá-las, consulte [Trabalhar com réplicas de leitura de instância de banco de dados](USER_ReadRepl.md). Para ter mais informações sobre réplicas de leitura do MySQL, consulte os tópicos a seguir. + [Configurar filtros de replicação com MySQL](USER_MySQL.Replication.ReadReplicas.ReplicationFilters.md) + [Configurar replicação atrasada com o MySQL](USER_MySQL.Replication.ReadReplicas.DelayReplication.md) + [Atualizar réplicas de leitura com o MySQL](USER_MySQL.Replication.ReadReplicas.Updates.md) + [Trabalhar com implantações de réplicas de leitura multi-AZ com o MySQL](USER_MySQL.Replication.ReadReplicas.MultiAZ.md) + [Usar réplicas de leitura em cascata com o RDS para MySQL](USER_MySQL.Replication.ReadReplicas.Cascading.md) + [Monitorar o atraso de replicação para réplicas de leitura do MySQL](USER_MySQL.Replication.ReadReplicas.Monitor.md) + [Início e interrupção de replicação com réplicas de leitura do MySQL](USER_MySQL.Replication.ReadReplicas.StartStop.md) + [Solucionar problemas de uma réplica de leitura do MySQL](USER_ReadRepl.Troubleshooting.md) ## Configurar réplicas de leitura com o MySQL Antes que uma instância de banco de dados do MySQL possa servir como uma fonte de replicação, certifique-se de habilitar os backups automáticos na instância de banco de dados de origem. Para fazer isso, defina o período de retenção de backup como um valor diferente de 0. Esse requisito também se aplica a uma réplica de leitura que seja a instância de banco de dados de origem de outra réplica de leitura. Os backups automáticos são compatíveis somente com réplicas de leitura que executam qualquer versão do MySQL. Você pode configurar a replicação com base nas coordenadas do log binário para uma instância de banco de dados MySQL. Você pode configurar a replicação usando identificadores de transação global (GTIDs) nas seguintes versões: + RDS para MySQL versão 5.7.44 e versões 5.7 posteriores + RDS para MySQL versão 8.0.28 e versões 8.0 posteriores + RDS para MySQL versão 8.4.3 e versões 8.4 posteriores Para obter mais informações, consulte [Usar a replicação baseada em GTID](mysql-replication-gtid.md). Você pode criar até quinze réplicas de leitura de uma instância de banco de dados na mesma região. Para que a replicação funcione efetivamente, cada réplica de leitura deve ter a mesma quantidade de recursos de computação e de armazenamento que a instância de banco de dados de origem. Se você dimensionar a instância de banco de dados de origem, dimensione as réplicas de leitura também. O RDS para MySQL é compatível com réplicas de leitura em cascata. Para saber mais sobre como configurar réplicas de leitura em cascata, consulte [Usar réplicas de leitura em cascata com o RDS para MySQL](USER_MySQL.Replication.ReadReplicas.Cascading.md). É possível executar várias ações simultâneas de criação ou exclusão de réplicas de leitura que fazem referência à mesma instância de banco de dados de origem. Ao realizar essas ações, permaneça dentro do limite de quinze réplicas de leitura para cada instância de origem. Uma réplica de leitura de uma instância de banco de dados MySQL não pode usar uma versão de mecanismo de banco de dados inferior à sua instância de banco de dados de origem. ### Preparar instâncias de banco de dados MySQL que usam MyISAM Se sua instância de banco de dados MySQL usar um mecanismo não transacional, como o MyISAM, será necessário realizar as etapas a seguir para configurar sua réplica de leitura com sucesso. Essas etapas são necessárias para garantir que a réplica de leitura tenha uma cópia consistente de seus dados. Essas etapas não são necessárias caso todas as suas tabelas utilizem um mecanismo transacional como InnoDB. 1. Interrompa todas as operações de linguagem de manipulação de dados (DML) e de linguagem de definição de dados (DDL) em tabelas não transacionais na instância de banco de dados de origem e aguarde pela conclusão delas. Comandos SELECIONAR podem continuar sendo executados. 1. Descarregue e bloqueie as tabelas na instância do banco de dados de origem. 1. Crie a réplica de leitura usando um dos métodos nas seções a seguir. 1. Verifique o andamento da criação da réplica de leitura usando, por exemplo, a operação da API `DescribeDBInstances`. Após a réplica de leitura estar disponível, desbloqueie as tabelas da instância de banco de dados de origem e retome as operações de banco de dados normais. # Configurar filtros de replicação com MySQL Você pode usar filtros de replicação para especificar quais bancos de dados e tabelas são replicados com uma réplica de leitura. Os filtros de replicação podem incluir bancos de dados e tabelas na replicação ou excluí-los da replicação. Veja a seguir alguns casos de uso para filtros de replicação: + Para reduzir o tamanho de uma réplica de leitura. Com a filtragem de replicação, você pode excluir os bancos de dados e tabelas que não são necessários na réplica de leitura. + Para excluir bancos de dados e tabelas de réplicas de leitura por motivos de segurança. + Para replicar diferentes bancos de dados e tabelas para casos de uso específicos em diferentes réplicas de leitura. Por exemplo, você pode usar réplicas de leitura específicas para análise ou fragmentação. + Para uma instância de banco de dados que tenha réplicas de leitura em diferentes Regiões da AWS, para replicar diferentes bancos de dados ou tabelas em diferentes Regiões da AWS. **nota** É possível usar filtros de replicação para especificar quais bancos de dados e tabelas serão replicados com uma instância de banco de dados primária do MySQL configurada como uma réplica em uma topologia de replicação de entrada. Para obter mais informações sobre essa configuração, consulte [Configurar a replicação da posição do arquivo de log binário com uma instância de origem externa](MySQL.Procedural.Importing.External.Repl.md). **Topics** + [ ## Configurar parâmetros de filtragem de replicação para o RDS para MySQL ](#USER_MySQL.Replication.ReadReplicas.ReplicationFilters.Configuring) + [ ## Limitações de filtragem de replicação do RDS para MySQL ](#USER_MySQL.Replication.ReadReplicas.ReplicationFilters.Limitations) + [ ## Exemplos de filtragem de replicação do RDS para MySQL ](#USER_MySQL.Replication.ReadReplicas.ReplicationFilters.Examples) + [ ## Visualizar os filtros de replicação para uma réplica de leitura ](#USER_MySQL.Replication.ReadReplicas.ReplicationFilters.Viewing) ## Configurar parâmetros de filtragem de replicação para o RDS para MySQL Para configurar filtros de replicação, defina os seguintes parâmetros de filtragem de replicação na réplica de leitura: + `replicate-do-db` – Replicar alterações nos bancos de dados especificados. Quando você define esse parâmetro para uma réplica de leitura, somente os bancos de dados especificados no parâmetro são replicados. + `replicate-ignore-db` – Não replique as alterações nos bancos de dados especificados. Quando o parâmetro `replicate-do-db` é definido para uma réplica de leitura, esse parâmetro não é avaliado. + `replicate-do-table` – Replicar alterações nas tabelas especificadas. Quando você define esse parâmetro para uma réplica de leitura, somente as tabelas especificadas no parâmetro são replicadas. Além disso, quando o parâmetro `replicate-do-db` ou `replicate-ignore-db` estiver definido, certifique-se de incluir o banco de dados que inclui as tabelas especificadas na replicação com a réplica de leitura. + `replicate-ignore-table` – Não replique as alterações nas tabelas especificadas. Quando o parâmetro `replicate-do-table` é definido para uma réplica de leitura, esse parâmetro não é avaliado. + `replicate-wild-do-table` – Replicar tabelas com base nos padrões de nome de banco de dados e tabela especificados. Os caracteres curinga `%` e `_` são compatíveis. Quando o parâmetro `replicate-do-db` ou `replicate-ignore-db` estiver definido, certifique-se de incluir o banco de dados que inclui as tabelas especificadas na replicação com a réplica de leitura. + `replicate-wild-ignore-table` – Não replique tabelas com base nos padrões de nome de banco de dados e tabela especificados. Os caracteres curinga `%` e `_` são compatíveis. Quando o parâmetro `replicate-do-table` ou `replicate-wild-do-table` é definido para uma réplica de leitura, esse parâmetro não é avaliado. Os parâmetros são avaliados na ordem em que estão listados. Para obter mais informações sobre como esses parâmetros funcionam, consulte a documentação do MySQL: + Para obter informações gerais, consulte [ Opções e variáveis do servidor de réplica](https://dev.mysql.com/doc/refman/8.0/en/replication-options-replica.html). + Para obter informações sobre como os parâmetros de filtragem de replicação de banco de dados são avaliados, consulte [ Avaliação de opções de replicação em nível de banco de dados e log binário](https://dev.mysql.com/doc/refman/8.0/en/replication-rules-db-options.html). + Para obter informações sobre como os parâmetros de filtragem de replicação de tabela são avaliados, consulte [ Avaliação de opções de replicação em nível de tabela](https://dev.mysql.com/doc/refman/8.0/en/replication-rules-table-options.html). Por padrão, cada um desses parâmetros tem um valor vazio. Em cada réplica de leitura, você pode usar esses parâmetros para definir, alterar e excluir filtros de replicação. Quando você define um desses parâmetros, separe cada filtro dos outros com uma vírgula. Você pode usar `%` os caracteres curinga `_` e nos parâmetros `replicate-wild-do-table` e `replicate-wild-ignore-table`. O curinga `%` corresponde a qualquer número de caracteres e o caractere curinga `_` corresponde apenas a um caractere. O formato de log binário da instância de banco de dados de origem é importante para replicação porque determina o registro de alterações de dados. A configuração do parâmetro `binlog_format` determina se a replicação é baseada em linha ou baseada em declaração. Para obter mais informações, consulte [Configurar o registro em log binário do RDS para MySQL para bancos de dados single-AZ](USER_LogAccess.MySQL.BinaryFormat.md). **nota** Todas as instruções DDL (Data Definition Language, linguagem de definição de dados) são replicadas como instruções, independentemente da `binlog_format` configuração na instância de banco de dados de origem. ## Limitações de filtragem de replicação do RDS para MySQL As seguintes limitações aplicam-se à filtragem de replicação para o RDS para MySQL: + Cada parâmetro de filtragem de replicação tem um limite de 2.000 caracteres. + As vírgulas não são aceitas em filtros de replicação para valores de parâmetros. Em uma lista de parâmetros, as vírgulas só podem ser usadas como separadores de valores. Por exemplo, `ParameterValue='`a,b`'` não é aceito, mas `ParameterValue='a,b'` é. + O MySQL `--binlog-do-db` e `--binlog-ignore-db` as opções para filtragem de log binário não são compatíveis. + A filtragem de replicação não suporta transações XA. Para obter mais informações, consulte [Restrictions on XA Transactions](https://dev.mysql.com/doc/refman/8.0/en/xa-restrictions.html) na documentação do MySQL. ## Exemplos de filtragem de replicação do RDS para MySQL Para configurar a filtragem de replicação para uma réplica de leitura, modifique os parâmetros de filtragem de replicação no grupo de parâmetros associado à réplica de leitura. **nota** Não é possível modificar um grupo de parâmetros padrão. Se a réplica de leitura estiver usando um grupo de parâmetros padrão, crie um novo grupo de parâmetros e o associe à instância de banco de dados. Para obter mais informações sobre grupos de parâmetros de banco de dados, consulte [Grupos de parâmetros para Amazon RDS](USER_WorkingWithParamGroups.md). Você pode definir parâmetros em um grupo de parâmetros usando a Console de gerenciamento da AWS, a AWS CLI ou a API do RDS. Para obter informações sobre como configurar parâmetros, consulte [Modificar parâmetros em um grupo de parâmetros de banco de dados no Amazon RDS](USER_WorkingWithParamGroups.Modifying.md). Quando você define parâmetros em um grupo de parâmetros, todas as instâncias de banco de dados associadas ao grupo de parâmetros usam as configurações de parâmetro. Se você definir os parâmetros de filtragem de replicação em um grupo de parâmetros, verifique se o grupo de parâmetros está associado apenas a réplicas de leitura. Deixe os parâmetros de filtragem de replicação vazios para instâncias de banco de dados de origem. Os exemplos a seguir definem os parâmetros usando o AWS CLI. Estes exemplos definem `ApplyMethod` para `immediate` de modo que as mudanças do parâmetro ocorram imediatamente depois que o comando CLI termina. Se você quiser que uma alteração pendente seja aplicada depois que a réplica de leitura for reinicializada, defina como `ApplyMethod` `pending-reboot`. Os exemplos a seguir definem filtros de replicação: + [Including databases in replication](#rep-filter-in-dbs-mysql) + [Including tables in replication](#rep-filter-in-tables-mysql) + [Including tables in replication with wildcard characters](#rep-filter-in-tables-wildcards-mysql) + [Excluding databases from replication](#rep-filter-ex-dbs-mysql) + [Excluding tables from replication](#rep-filter-ex-tables-mysql) + [Excluding tables from replication using wildcard characters](#rep-filter-ex-tables-wildcards-mysql) **Example Incluir bancos de dados em replicação** O exemplo a seguir inclui os bancos de dados `mydb1` e `mydb2` na replicação. Para Linux, macOS ou Unix: ``` aws rds modify-db-parameter-group \ --db-parameter-group-name myparametergroup \ --parameters "ParameterName=replicate-do-db,ParameterValue='mydb1,mydb2',ApplyMethod=immediate" ``` Para Windows: ``` aws rds modify-db-parameter-group ^ --db-parameter-group-name myparametergroup ^ --parameters "ParameterName=replicate-do-db,ParameterValue='mydb1,mydb2',ApplyMethod=immediate" ``` **Example Incluir tabelas na replicação** O exemplo a seguir inclui as tabelas `table1` e `table2` no banco de dados `mydb1` na replicação. Para Linux, macOS ou Unix: ``` aws rds modify-db-parameter-group \ --db-parameter-group-name myparametergroup \ --parameters "ParameterName=replicate-do-table,ParameterValue='mydb1.table1,mydb1.table2',ApplyMethod=immediate" ``` Para Windows: ``` aws rds modify-db-parameter-group ^ --db-parameter-group-name myparametergroup ^ --parameters "ParameterName=replicate-do-table,ParameterValue='mydb1.table1,mydb1.table2',ApplyMethod=immediate" ``` **Example Incluir tabelas na replicação usando caracteres curinga** O exemplo a seguir inclui tabelas com nomes que começam com `order` e `return` no banco de dados `mydb` na replicação. Para Linux, macOS ou Unix: ``` aws rds modify-db-parameter-group \ --db-parameter-group-name myparametergroup \ --parameters "ParameterName=replicate-wild-do-table,ParameterValue='mydb.order%,mydb.return%',ApplyMethod=immediate" ``` Para Windows: ``` aws rds modify-db-parameter-group ^ --db-parameter-group-name myparametergroup ^ --parameters "ParameterName=replicate-wild-do-table,ParameterValue='mydb.order%,mydb.return%',ApplyMethod=immediate" ``` **Example Excluir bancos de dados da replicação** O exemplo a seguir exclui os bancos de dados `mydb5` e `mydb6` da replicação. Para Linux, macOS ou Unix: ``` aws rds modify-db-parameter-group \ --db-parameter-group-name myparametergroup \ --parameters "ParameterName=replicate-ignore-db,ParameterValue='mydb5,mydb6',ApplyMethod=immediate" ``` Para Windows: ``` aws rds modify-db-parameter-group ^ --db-parameter-group-name myparametergroup ^ --parameters "ParameterName=replicate-ignore-db,ParameterValue='mydb5,mydb6',ApplyMethod=immediate" ``` **Example Excluir tabelas da replicação** O exemplo a seguir exclui a tabela `table1` no banco de dados `mydb5` e a tabela `table2` no banco de dados `mydb6` da replicação. Para Linux, macOS ou Unix: ``` aws rds modify-db-parameter-group \ --db-parameter-group-name myparametergroup \ --parameters "ParameterName=replicate-ignore-table,ParameterValue='mydb5.table1,mydb6.table2',ApplyMethod=immediate" ``` Para Windows: ``` aws rds modify-db-parameter-group ^ --db-parameter-group-name myparametergroup ^ --parameters "ParameterName=replicate-ignore-table,ParameterValue='mydb5.table1,mydb6.table2',ApplyMethod=immediate" ``` **Example Excluir tabelas da replicação usando caracteres curinga** O exemplo a seguir exclui tabelas com nomes que começam com `order` e `return` no banco de dados `mydb7` da replicação. Para Linux, macOS ou Unix: ``` aws rds modify-db-parameter-group \ --db-parameter-group-name myparametergroup \ --parameters "ParameterName=replicate-wild-ignore-table,ParameterValue='mydb7.order%,mydb7.return%',ApplyMethod=immediate" ``` Para Windows: ``` aws rds modify-db-parameter-group ^ --db-parameter-group-name myparametergroup ^ --parameters "ParameterName=replicate-wild-ignore-table,ParameterValue='mydb7.order%,mydb7.return%',ApplyMethod=immediate" ``` ## Visualizar os filtros de replicação para uma réplica de leitura Você pode visualizar os filtros de replicação de uma réplica de leitura das seguintes maneiras: + Verifique as configurações dos parâmetros de filtragem de replicação no grupo de parâmetros associado à réplica de leitura. Para obter instruções, consulte [Visualizar valores de parâmetros para um grupo de parâmetros de banco de dados no Amazon RDS](USER_WorkingWithParamGroups.Viewing.md). + Em um cliente MySQL, conecte-se à réplica de leitura e execute a instrução `SHOW REPLICA STATUS`. Na saída, os campos a seguir mostram os filtros de replicação para a réplica de leitura: + `Replicate_Do_DB` + `Replicate_Ignore_DB` + `Replicate_Do_Table` + `Replicate_Ignore_Table` + `Replicate_Wild_Do_Table` + `Replicate_Wild_Ignore_Table` Para obter mais informações sobre esses campos, consulte [Verificar o status da replicação](https://dev.mysql.com/doc/refman/8.0/en/replication-administration-status.html) na documentação do MySQL. # Configurar replicação atrasada com o MySQL Você pode usar a replicação atrasada como uma estratégia para a recuperação de desastres. Com a replicação atrasada, você especifica o tempo mínimo, em segundos, para atrasar a replicação da origem para a réplica de leitura. Em caso de um desastre, como uma tabela excluída acidentalmente, você executa as seguintes etapas para recuperar-se rapidamente do desastre: + Interrompa a replicação da réplica de leitura antes que a alteração que causou o desastre seja enviada para ela. Use o procedimento armazenado [mysql.rds\$1stop\$1replication](mysql-stored-proc-replicating.md#mysql_rds_stop_replication) para interromper a replicação. + Inicie a replicação e especifique que a replicação deve ser interrompida automaticamente em um local do arquivo de log. Especifique um local imediatamente antes do desastre usando o procedimento armazenado [mysql.rds\$1start\$1replication\$1until](mysql-stored-proc-replicating.md#mysql_rds_start_replication_until). + Promova a réplica de leitura para ser a nova instância de banco de dados de origem usando as instruções em [Promoção de uma réplica de leitura a uma instância de banco de dados autônoma](USER_ReadRepl.Promote.md). **nota** No RDS para MySQL 8.4, a replicação atrasada tem suporte para o MySQL 8.4.3 e versões posteriores. No RDS para MySQL 8.0, a replicação atrasada tem suporte para o MySQL 8.0.28 e versões posteriores. No RDS para MySQL 5.7, a replicação atrasada é compatível com o MySQL 5.7.44 e posterior. Use procedimentos armazenados para configurar a replicação atrasada. Você não pode configurar a replicação atrasada com o Console de gerenciamento da AWS, a AWS CLI ou a API do Amazon RDS. Você pode usar a replicação com base em identificadores de transação global (GTIDs) em uma configuração de replicação atrasada para as seguintes versões: RDS para MySQL versão 5.7.44 e versões 5.7 posteriores RDS para MySQL versão 8.0.28 e versões 8.0 posteriores RDS para MySQL versão 8.4.3 e versões 8.4 posteriores Caso você use a replicação baseada em GTID, use o procedimento armazenado [mysql.rds\$1start\$1replication\$1until\$1gtid](mysql-stored-proc-gtid.md#mysql_rds_start_replication_until_gtid) em vez do procedimento armazenado [mysql.rds\$1start\$1replication\$1until](mysql-stored-proc-replicating.md#mysql_rds_start_replication_until). Para obter mais informações sobre a replicação baseada em GTID, consulte [Usar a replicação baseada em GTID](mysql-replication-gtid.md). **Topics** + [ ## Configurar replicação atrasada durante a criação da réplica de leitura ](#USER_MySQL.Replication.ReadReplicas.DelayReplication.ReplicaCreation) + [ ## Modificar replicação atrasada de uma réplica de leitura existente ](#USER_MySQL.Replication.ReadReplicas.DelayReplication.ExistingReplica) + [ ## Configurar um local para interromper a replicação para uma réplica de leitura ](#USER_MySQL.Replication.ReadReplicas.DelayReplication.StartUntil) + [ ## Promover uma réplica de leitura ](#USER_MySQL.Replication.ReadReplicas.DelayReplication.Promote) ## Configurar replicação atrasada durante a criação da réplica de leitura Para configurar a replicação atrasada para qualquer réplica de leitura futura criada a partir de uma instância de banco de dados, execute o procedimento armazenado [mysql.rds\$1set\$1configuration](mysql-stored-proc-configuring.md#mysql_rds_set_configuration) com o parâmetro `target delay`. **Para configurar a replicação atrasada durante a criação da réplica de leitura** 1. Usando um cliente MySQL, conecte-se à instância de banco de dados MySQL que será a origem para réplicas de leitura como o usuário mestre. 1. Execute o procedimento armazenado [mysql.rds\$1set\$1configuration](mysql-stored-proc-configuring.md#mysql_rds_set_configuration) com o parâmetro `target delay`. Por exemplo, execute o procedimento armazenado a seguir para especificar que a replicação é atrasada em pelo menos uma hora (3,600 segundos) para qualquer réplica de leitura criada a partir da instância de banco de dados atual. ``` call mysql.rds_set_configuration('target delay', 3600); ``` **nota** Após executar esse procedimento armazenado, qualquer réplica de leitura que você criar usando a AWS CLI ou a API do Amazon RDS será configurada com a replicação atrasada pelo número de segundos especificado. ## Modificar replicação atrasada de uma réplica de leitura existente Para modificar a replicação atrasada para uma réplica de leitura existente, execute o procedimento armazenado [mysql.rds\$1set\$1source\$1delay](mysql-stored-proc-replicating.md#mysql_rds_set_source_delay). **Para modificar a replicação atrasada para uma réplica de leitura existente** 1. Usando um cliente do MySQL, conecte-se à réplica de leitura como o usuário mestre. 1. Use o procedimento armazenado [mysql.rds\$1stop\$1replication](mysql-stored-proc-replicating.md#mysql_rds_stop_replication) para interromper a replicação. 1. Execute o procedimento armazenado [mysql.rds\$1set\$1source\$1delay](mysql-stored-proc-replicating.md#mysql_rds_set_source_delay). Por exemplo, execute o procedimento armazenado a seguir para especificar que a replicação para a réplica de leitura é atrasada em pelo menos uma hora (3.600 segundos) para qualquer réplica de leitura criada a partir da instância de banco de dados atual. ``` call mysql.rds_set_source_delay(3600); ``` 1. Use o procedimento armazenado [mysql.rds\$1start\$1replication](mysql-stored-proc-replicating.md#mysql_rds_start_replication) para iniciar a replicação. ## Configurar um local para interromper a replicação para uma réplica de leitura Após interromper a replicação para a réplica de leitura, você pode começar a replicação e interrompê-la em um local especificado do arquivo de log binário usando o procedimento armazenado [mysql.rds\$1start\$1replication\$1until](mysql-stored-proc-replicating.md#mysql_rds_start_replication_until). **Para iniciar a replicação para uma Réplica de leitura e interrompê-la em um local específico** 1. Usando um cliente do MySQL, conecte-se à instância de banco de dados MySQL de origem como o usuário mestre. 1. Execute o procedimento armazenado [mysql.rds\$1start\$1replication\$1until](mysql-stored-proc-replicating.md#mysql_rds_start_replication_until). O exemplo a seguir inicia a replicação e replica as alterações até que ela atinja o local `120` no arquivo de log binário `mysql-bin-changelog.000777`. Em um cenário de recuperação de desastres, suponha que o local `120` é imediatamente antes do desastre. ``` call mysql.rds_start_replication_until( 'mysql-bin-changelog.000777', 120); ``` A replicação é interrompida automaticamente quando o ponto de interrupção é atingido. O seguinte evento do RDS é gerado: `Replication has been stopped since the replica reached the stop point specified by the rds_start_replication_until stored procedure`. ## Promover uma réplica de leitura Após a replicação ser interrompida, em um cenário de recuperação de desastres, você pode promover uma réplica de leitura para ser a nova instância de banco de dados de origem. Para obter informações sobre como promover uma réplica de leitura, consulte [Promoção de uma réplica de leitura a uma instância de banco de dados autônoma](USER_ReadRepl.Promote.md). # Atualizar réplicas de leitura com o MySQL As réplicas de leitura foram projetadas para oferecer suporte a consultas de leitura, mas você pode precisar fazer atualizações ocasionais. Por exemplo, talvez seja necessário adicionar um índice para otimizar tipos específicos de consultas que acessam a réplica. Embora você possa habilitar as atualizações definindo o parâmetro `read_only` como `0` no grupo de parâmetros de banco de dados para a réplica de leitura, é recomendável não fazer isso, pois essa ação pode causar problemas se a réplica de leitura tornar-se incompatível com a instância de banco de dados de origem. Para operações de manutenção, recomendamos que você use implantações azul/verde. Para obter mais informações, consulte [Usar implantações azul/verde para atualizações de banco de dados](blue-green-deployments.md). Se você desabilitar a opção somente leitura em uma réplica de leitura, altere o valor do parâmetro `read_only` de volta para `1` o mais rápido possível. # Trabalhar com implantações de réplicas de leitura multi-AZ com o MySQL É possível criar uma réplica de leitura a partir de implantações de instâncias de banco de dados single-AZ ou multi-AZ. Você pode usar implantações multi-AZ para melhorar a durabilidade e a disponibilidade de dados essenciais. No entanto, não é possível usar o multi-AZ secundário para atender a consultas somente leitura. Em vez disso, crie réplicas de leitura de instâncias de banco de dados multi-AZ de alto tráfego para descarregar consultas somente leitura. Se a instância de origem de uma implantação multi-AZ falhar na secundária, todas as réplicas de leitura associadas serão automaticamente alteradas para usar a secundária (não a primária) como a origem de replicação. Para obter mais informações, consulte [Configurar e gerenciar uma implantação multi-AZ para o Amazon RDS](Concepts.MultiAZ.md). É possível criar uma réplica de leitura como uma instância de banco de dados multi-AZ. O Amazon RDS cria um em modo de espera de sua réplica em outra zona de disponibilidade para suporte a failover da réplica. Você pode criar a réplica de leitura como uma instância de banco de dados multi-AZ independentemente de o banco de dados de origem ser ou não uma instância de banco de dados multi-AZ. # Usar réplicas de leitura em cascata com o RDS para MySQL O RDS para MySQL é compatível com réplicas de leitura em cascata. Com *réplicas de leitura em cascata*, é possível escalar leituras sem adicionar sobrecarga à instância de banco de dados do RDS para MySQL de origem. Com réplicas de leitura em cascata, sua instância de banco de dados do RDS para MySQL envia dados para a primeira réplica de leitura da cadeia. Essa réplica de leitura envia dados para a segunda réplica na cadeia e assim por diante. O resultado final é que todas as réplicas de leitura na cadeia têm as alterações da instância de banco de dados do RDS para MySQL DB, mas sem a sobrecarga apenas na instância de banco de dados de origem. É possível criar uma série de até três réplicas de leitura em uma cadeia de uma instância de banco de dados de origem do RDS para MySQL. Por exemplo, suponha que você tenha uma instância de banco de dados do RDS para MySQL, `mysql-main`. Você pode fazer o seguinte: + Começando com `mysql-main`, crie a primeira réplica de leitura na cadeia, `read-replica-1`. + Na `read-replica-1`, crie a próxima réplica de leitura na cadeia, `read-replica-2`. + Finalmente, na `read-replica-2`, crie a terceira réplica de leitura na cadeia, `read-replica-3`. Não é possível criar outra réplica de leitura além dessa terceira réplica de leitura em cascata na série de `mysql-main`. Uma série completa de instâncias de uma instância de banco de dados de origem do RDS para MySQL até o final de uma série de réplicas de leitura em cascata pode consistir em, no máximo, quatro instâncias de banco de dados. Para que as réplicas de leitura em cascata funcionem, cada instância de banco de dados do RDS para MySQL de origem deve ter os backups automatizados ativados. Para ativar backups automáticos em uma réplica de leitura, primeiro crie a réplica de leitura e a modifique para ativar backups automáticos. Para ter mais informações, consulte [Como criar uma réplica de leitura](USER_ReadRepl.Create.md). Como em qualquer réplica de leitura, é possível promover uma réplica de leitura que faz parte de uma cascata. A promoção de uma réplica de leitura de uma cadeia de réplicas de leitura remove essa réplica da cadeia. Por exemplo, suponha que você queira mover parte da workload da instância de banco de dados `mysql-main` para uma nova instância para uso somente pelo departamento de contabilidade. Pressupondo a cadeia com três réplicas de leitura do exemplo, você decide promover `read-replica-2`. A cadeia é afetada da seguinte forma: + A promoção de `read-replica-2` a remove da cadeia de replicação. + Ela agora é uma instância de banco de dados de leitura/gravação completa. + Ela continua replicando para `read-replica-3`, da mesma forma como estava fazendo antes da promoção. + A `mysql-main` continua a replicar para a `read-replica-1`. Para obter mais informações sobre como promover réplicas de leitura, consulte [Promoção de uma réplica de leitura a uma instância de banco de dados autônoma](USER_ReadRepl.Promote.md). # Monitorar o atraso de replicação para réplicas de leitura do MySQL Para as réplicas de leitura do MySQL, você pode monitorar o atraso da replicação no Amazon CloudWatch visualizando a métrica `ReplicaLag` do Amazon RDS. A métrica `ReplicaLag` relata o valor do campo `Seconds_Behind_Master` do comando `SHOW REPLICA STATUS`. As causas comuns para o atraso da replicação do MySQL são as seguintes: + Uma queda de rede. + Gravação em tabelas com índices diferentes em uma réplica de leitura. Se o parâmetro `read_only` estiver definido como `0` na réplica de leitura, a replicação poderá ser interrompida se a réplica de leitura torna-se incompatível com a instância de banco de dados de origem. Depois de realizar tarefas de manutenção na réplica de leitura, recomendamos que você defina o parâmetro `read_only` de volta para `1`. + Uso de um mecanismo de armazenamento não transacional, como o MyISAM. A replicação só é compatível com o mecanismo de armazenamento InnoDB no MySQL. Quando a métrica `ReplicaLag` chega a 0, isso mostra que a réplica alcançou a instância do banco de dados de origem. Se a métrica `ReplicaLag` retornar -1, então a replicação não está ativa no momento. `ReplicaLag` = -1 é equivalente a `Seconds_Behind_Master` = `NULL`. # Início e interrupção de replicação com réplicas de leitura do MySQL Você pode interromper e reiniciar o processo de replicação em uma instância de banco de dados do Amazon RDS ao chamar os procedimentos armazenados do sistema [mysql.rds\$1stop\$1replication](mysql-stored-proc-replicating.md#mysql_rds_stop_replication) e [mysql.rds\$1start\$1replication](mysql-stored-proc-replicating.md#mysql_rds_start_replication). Você pode fazer isso ao replicar entre duas instâncias do Amazon RDS para operações de longa duração, como a criação de índices grandes. Você também precisa interromper e iniciar a replicação ao importar ou exportar bancos de dados. Para obter mais informações, consulte [Importar dados para um banco de dados do Amazon RDS para MySQL com tempo de inatividade reduzido](mysql-importing-data-reduced-downtime.md) e [Exportar dados de uma instância de banco de dados MySQL usando replicação](MySQL.Procedural.Exporting.NonRDSRepl.md). Se a replicação for interrompida por mais de 30 dias consecutivos, seja manualmente ou devido a um erro de replicação, o Amazon RDS a encerrará entre a instância de banco de dados de origem e todas as réplicas de leitura. Isso acontece para evitar um aumento nos requisitos de armazenamento da instância de banco de dados de origem e nos tempos de failover prolongado. A instância de banco de dados da réplica de leitura ainda está disponível. No entanto, a replicação não pode ser retomada porque os logs binários exigidos pela réplica de leitura são excluídos da instância de banco de dados de origem após a conclusão da replicação. Você pode criar uma nova réplica de leitura para a instância de banco de dados de origem a fim de restabelecer a replicação. # Solucionar problemas de uma réplica de leitura do MySQL Para instâncias de bancos de dados MySQL, em alguns casos as réplicas de leitura apresentam erros de replicação ou inconsistências de dados entre a réplica de leitura e sua fonte da instância de banco de dados. Esse problema ocorre quando alguns eventos de log binário (binlog) ou logs redo do InnoDB não são liberados durante uma falha da réplica de leitura ou da instância de banco de dados de origem. Nesses casos, exclua e recrie manualmente as réplicas de leitura. Você pode reduzir a chance disso acontecer definindo os seguintes valores de parâmetro: `sync_binlog=1` e `innodb_flush_log_at_trx_commit=1`. Essas configurações podem reduzir a performance, portanto, teste o impacto delas antes de implantar as alterações em um ambiente de produção. **Atenção** No grupo de parâmetros associado à fonte da instância de banco de dados, recomendamos manter esses valores de parâmetros: `sync_binlog=1` e `innodb_flush_log_at_trx_commit=1`. Esses parâmetros são dinâmicos. Se você não quiser usar essas configurações, recomendamos definir temporariamente esses valores antes de executar qualquer operação na fonte da instância de banco de dados que possa fazer com que ela seja reiniciada. Essas operações incluem, entre outras, a reinicialização, a reinicialização com failover, a atualização da versão do banco de dados e a alteração da classe de instância de banco de dados ou seu armazenamento. A mesma recomendação se aplica à criação de novas réplicas de leitura para a fonte da instância de banco de dados. Não seguir essa orientação aumenta o risco de réplicas de leitura apresentarem erros de replicação ou inconsistências de dados (ou ambas) entre a réplica de leitura e sua fonte da instância de banco de dados. As tecnologias de replicação do MySQL são assíncronas. Como são assíncronas, são esperados ocasionais aumentos de `BinLogDiskUsage` na instância de banco de dados de origem e `ReplicaLag` na réplica de leitura. Por exemplo, um volume elevado de operações de gravação para a instância de banco de dados de origem pode ocorrer em paralelo. Por outro lado, as operações de gravação na réplica de leitura são serializadas usando um único thread de E/S, o que pode ocasionar um atraso entre a instância de origem e a réplica de leitura. Para obter mais informações sobre réplicas somente leitura na documentação do MySQL, consulte [Detalhes de implantação da replicação](https://dev.mysql.com/doc/refman/8.0/en/replication-implementation-details.html). Você pode fazer várias coisas para reduzir o atraso entre as atualizações de uma instância de banco de dados de origem e as atualizações subsequentes da réplica de leitura, como o seguinte: + Dimensionar uma réplica de leitura para ter um tamanho de armazenamento e uma categoria de instância de banco de dados comparáveis à da instância de banco de dados de origem. + Assegurar-se de que as configurações de parâmetros nos grupos de parâmetros de banco de dados utilizados pela instância de banco de dados de origem e pela réplica de leitura são compatíveis. Para mais informações e um exemplo, consulte a discussão sobre o parâmetro `max_allowed_packet` posteriormente nesta seção. O Amazon RDS monitora o status de replicação de suas réplicas de leitura e atualiza o campo `Replication State` da instância da réplica de leitura para `Error` caso a replicação seja interrompida por qualquer motivo. Um exemplo pode ser se as consultas DML forem executadas no seu conflito de réplica de leitura com as atualizações feitas na instância de banco de dados de origem. Você pode analisar os detalhes do erro associado gerado pelo mecanismo do MySQL visualizando o campo `Replication Error`. Os eventos que indicam o status da réplica de leitura também são gerados, incluindo [RDS-EVENT-0045](USER_Events.Messages.md#RDS-EVENT-0045), [RDS-EVENT-0046](USER_Events.Messages.md#RDS-EVENT-0046) e [RDS-EVENT-0047](USER_Events.Messages.md#RDS-EVENT-0047). Para mais informações sobre eventos e como se inscrever neles, consulte [Trabalhar com a notificação de eventos do Amazon RDS](USER_Events.md). Se for retornada uma mensagem de erro do MySQL, analise o número de erro na [ documentação de mensagens de erro do MySQL](https://dev.mysql.com/doc/mysql-errors/8.0/en/server-error-reference.html). Um problema comum que pode causar erros de replicação é quando o valor do parâmetro `max_allowed_packet` para uma réplica de leitura é menor que o do parâmetro `max_allowed_packet` para a instância de banco de dados de origem. O parâmetro `max_allowed_packet` é um parâmetro personalizado que você pode definir em um grupo de parâmetros de banco de dados. Use o `max_allowed_packet` para especificar o tamanho máximo do código DML que pode ser executado no banco de dados. Em alguns casos, o valor do `max_allowed_packet` no grupo de parâmetros de banco de dados associado a uma réplica de leitura é menor do que o valor de `max_allowed_packet` no grupo de parâmetros de banco de dados associado à instância de banco de dados de origem. Nesses casos, o processo de replicação pode lançar o erro `Packet bigger than 'max_allowed_packet' bytes` e interromper a replicação. Para corrigir o erro, faça com que a instância de banco de dados de origem e a réplica de leitura usem grupos de parâmetros de banco de dados com os mesmos valores de parâmetro `max_allowed_packet` Outras situações comuns que podem causar erros de replicação incluem o seguinte: + A gravação em tabelas em uma réplica de leitura. Em alguns casos, é possível criar índices em uma réplica de leitura diferentes dos índices na instância de banco de dados da origem. Se você fizer isso, defina o parâmetro `read_only` como `0` para criar índices. Se você gravar em tabelas na réplica de leitura, isso poderá interromper a replicação se a réplica de leitura tornar-se incompatível com a instância de banco de dados de origem. Depois de realizar tarefas de manutenção na réplica de leitura, recomendamos que você defina o parâmetro `read_only` de volta para `1`. + Uso de um mecanismo de armazenamento não transacional, como o MyISAM. As réplicas de leitura exigem um mecanismo de armazenamento transacional. A replicação só é compatível com o mecanismo de armazenamento InnoDB no MySQL. + Usando consultas não deterministas inseguras, como `SYSDATE()`. Para obter mais informações, consulte [Determinação de instruções seguras e inseguras no registro de logs binários](https://dev.mysql.com/doc/refman/8.0/en/replication-rbr-safe-unsafe.html). Se você acreditar que pode ignorar um erro com segurança, siga as etapas descritas na seção [Ignorar o erro de replicação atual para o RDS para MySQL](Appendix.MySQL.CommonDBATasks.SkipError.md). Caso contrário, você pode excluir a réplica de leitura primeiro. Crie uma instância usando o mesmo identificador de instância de banco de dados para que o endpoint permaneça o mesmo que o da sua antiga réplica de leitura. Se um erro de replicação for corrigido, o `Replication State` mudará para *replicating*. # Usar a replicação baseada em GTID O conteúdo a seguir explica como usar identificadores de transações globais (GTIDs) com a replicação de logs binários (binlog) entre instâncias de banco de dados do Amazon RDS para MySQL. Se você usa a replicação de logs binários e não conhece a replicação baseada em GTID com o MySQL, consulte [Replication with global transaction identifiers](https://dev.mysql.com/doc/refman/5.7/en/replication-gtids.html) na documentação do MySQL. A replicação baseada em GTID é compatível com as seguintes versões: + Todas as versões do RDS para MySQL 8.4 + Todas as versões do RDS para MySQL 8.0 + Todas as versões do RDS para MySQL 5.7 Todas as instâncias de banco de dados do MySQL em uma configuração de replicação devem atender a esse requisito de versão. **Topics** + [ ## Visão geral dos identificadores de transações globais (GTIDs) ](#mysql-replication-gtid.overview) + [ ## Parâmetros para replicação baseada em GTID ](#mysql-replication-gtid.parameters) + [ # Ativar a replicação baseada em GTID para novas réplicas de leitura para RDS para MySQL ](mysql-replication-gtid.configuring-new-read-replicas.md) + [ # Ativar a replicação baseada em GTID para réplicas de leitura existentes para RDS para MySQL ](mysql-replication-gtid.configuring-existing-read-replicas.md) + [ # Desabilitação da replicação baseada em GTID para uma instância de banco de dados do RDS for MySQL com réplicas de leitura ](mysql-replication-gtid.disabling.md) ## Visão geral dos identificadores de transações globais (GTIDs) *GTIDs* são identificadores exclusivos gerados para transações MySQL confirmadas. Você pode usar GTIDs para tornar a replicação de log binário mais simples e fácil de solucionar. O MySQL usa dois tipos diferentes de transações para a replicação de log binário: + *Transações GTID* – Transações identificadas por um GTID. + *Transações anônimas* – transações que não têm um GTID atribuído. Em uma configuração de replicação, GTIDs são exclusivos entre todas as instâncias de banco de dados. Os GTIDs simplificam a configuração da replicação porque ao usá-los você não precisa consultar posições de arquivo de log. Os GTIDs também facilitam o rastreamento de transações replicadas e a determinação da consistência da instância de origem e de réplicas. É possível usar replicação baseada em GTID para replicar dados com réplicas de leitura do RDS for MySQL. É possível configurar a replicação baseada em GTID ao criar réplicas de leitura ou você pode converter réplicas de leitura existentes para usar a replicação baseada em GTID. Você também pode utilizar a replicação baseada em GTID em uma configuração de replicação atrasada com o RDS for MySQL. Para ter mais informações, consulte [Configurar replicação atrasada com o MySQL](USER_MySQL.Replication.ReadReplicas.DelayReplication.md). ## Parâmetros para replicação baseada em GTID Use os parâmetros a seguir para configurar a replicação baseada em GTID. | Parâmetro | Valores válidos | Descrição | | --- | --- | --- | | `gtid_mode` | `OFF`, `OFF_PERMISSIVE`, `ON_PERMISSIVE`, `ON` | `OFF` especifica que novas transações são anônimas (ou seja, não têm GTIDs) e que uma transação deve ser anônima para ser replicada. `OFF_PERMISSIVE` especifica que novas transações são anônimas, mas todas podem ser replicadas. `ON_PERMISSIVE` especifica que novas transações são GTID, mas todas podem ser replicadas. `ON` especifica que novas transações são GTID e que uma transação deve ser GTID para ser replicada. | | `enforce_gtid_consistency` | `OFF`, `ON`, `WARN` | `OFF` permite que as transações violem a consistência GTID. `ON` evita que as transações violem a consistência GTID. `WARN` permite que as transações violem a consistência GTID, mas gera um aviso quando ocorre uma violação. | **nota** No Console de gerenciamento da AWS, o parâmetro `gtid_mode` aparece como `gtid-mode`. Para a replicação baseada em GTID, use estas configurações para o grupo de parâmetros da instância de banco de dados ou réplica de leitura: + `ON` e `ON_PERMISSIVE` somente são aplicáveis à replicação de saída de uma instância de banco de dados do RDS. Esses dois valores fazem com que a sua instância de banco de dados do RDS usem GTIDs para transações que são replicadas. O `ON` requer que o banco de dados de destino também use a replicação baseada em GTID. O `ON_PERMISSIVE` torna a replicação baseada em GTID opcional no banco de dados de destino. + `OFF_PERMISSIVE`, se definido, significa que as instâncias de banco de dados do RDS podem aceitar a replicação de entrada de um banco de dados de origem. Eles podem fazer isso independentemente de o banco de dados de origem usar a replicação baseada em GTID. + `OFF`, se definido, significa que sua instância de banco de dados do RDS apenas aceita a replicação de entrada de bancos de dados de origem que não usam a replicação baseada em GTID. Para obter mais informações sobre parameter groups, consulte [Grupos de parâmetros para Amazon RDS](USER_WorkingWithParamGroups.md). # Ativar a replicação baseada em GTID para novas réplicas de leitura para RDS para MySQL Quando a replicação baseada em GTID é habilitada para uma instância de banco de dados do RDS for MySQL, a replicação é configurada automaticamente para réplicas de leitura da instância de banco de dados. **Como habilitar a replicação baseada em GTID para novas réplicas de leitura** 1. Verifique se o grupo de parâmetros associado a uma instância de banco de dados tem as seguintes configurações de parâmetro: + `gtid_mode` – `ON` ou `ON_PERMISSIVE` + `enforce_gtid_consistency` – `ON` Para obter mais informações sobre a definição de parâmetros de configuração usando grupos de parâmetros, consulte [Grupos de parâmetros para Amazon RDS](USER_WorkingWithParamGroups.md). 1. Se você tiver alterado o grupo de parâmetros da instância de banco de dados, reinicie a instância de banco de dados. Para obter mais informações sobre como fazer isso, consulte [Reinicializar uma instância de banco de dados](USER_RebootInstance.md). 1. Crie uma ou mais réplicas de leitura da instância de banco de dados. Para obter mais informações sobre como fazer isso, consulte [Como criar uma réplica de leitura](USER_ReadRepl.Create.md). O Amazon RDS tenta estabelecer a replicação baseada em GTID entre a instância de banco de dados do MySQL e as réplicas de leitura usando o `MASTER_AUTO_POSITION`. Caso a tentativa falhe, o Amazon RDS usa posições de arquivo de log na replicação com as réplicas de leitura. Para obter mais informações sobre o `MASTER_AUTO_POSITION`, consulte [ GTID Auto-Positioning](https://dev.mysql.com/doc/refman/5.7/en/replication-gtids-auto-positioning.html) na documentação do MySQL. # Ativar a replicação baseada em GTID para réplicas de leitura existentes para RDS para MySQL Para uma instância de banco de dados do RDS for MySQL existente com réplicas de leitura que não usam a replicação baseada em GTID, é possível configurar a replicação baseada em GTID entre a instância de banco de dados e as réplicas de leitura. **Como habilitar a replicação baseada em GTID para réplicas de leitura existentes** 1. Se a instância de banco de dados ou qualquer réplica de leitura estiver utilizando uma versão 8.0 do RDS for MySQL inferior a 8.0.26, faça upgrade da instância de banco de dados ou da réplica de leitura para 8.0.26 ou uma versão posterior do MySQL 8.0. Todas as versões do RDS para MySQL versões 8.4 e 5.7 são compatíveis com replicação baseada em GTID. Para obter mais informações, consulte [Atualizações do mecanismo de banco de dados do RDS para MySQL](USER_UpgradeDBInstance.MySQL.md). 1. (Opcional) Redefina os parâmetros GTID e teste o comportamento da instância de banco de dados e as réplicas de leitura: 1. Verifique se o grupo de parâmetros associado a uma instância de banco de dados e cada réplica de leitura tem o parâmetro `enforce_gtid_consistency` definido como `WARN`. Para obter mais informações sobre a definição de parâmetros de configuração usando grupos de parâmetros, consulte [Grupos de parâmetros para Amazon RDS](USER_WorkingWithParamGroups.md). 1. Se você tiver alterado o grupo de parâmetros da instância de banco de dados, reinicie a instância de banco de dados. Se você tiver alterado o grupo de parâmetros para uma réplica de leitura, reinicie a réplica de leitura. Para obter mais informações, consulte [Reinicializar uma instância de banco de dados](USER_RebootInstance.md). 1. Execute a instância de banco de dados e as réplicas de leitura com a workload normal e monitore os arquivos de log. Caso você veja avisos sobre transações incompatíveis com GTID, ajuste o aplicativo de maneira que ele só use recursos compatíveis com GTID. Verifique se a instância de banco de dados não estiver gerando avisos sobre transações incompatíveis com GTID antes de avançar à próxima etapa. 1. Redefina os parâmetros GTID para replicação baseada em GTID que permite transações anônimas até que as réplicas de leitura tenham processado todas elas. 1. Verifique se o grupo de parâmetros associado a uma instância de banco de dados e cada réplica de leitura tem as seguintes configurações de parâmetro: + `gtid_mode` – `ON_PERMISSIVE` + `enforce_gtid_consistency` – `ON` 1. Se você tiver alterado o grupo de parâmetros da instância de banco de dados, reinicie a instância de banco de dados. Se você tiver alterado o grupo de parâmetros para uma réplica de leitura, reinicie a réplica de leitura. 1. Aguarde a replicação de todas as transações anônimas. Para verificar se elas estão replicadas, faça o seguinte: 1. Execute a instrução a seguir na instância de banco de dados de origem. **MySQL 8.4** ``` SHOW BINARY LOG STATUS; ``` **MySQL 5.7 e 8.0** ``` SHOW MASTER STATUS; ``` Observe os valores nas colunas `File` e `Position`. 1. Em cada réplica de leitura, use as informações de arquivo e posição de sua instância de origem na etapa anterior para executar a consulta a seguir. ``` SELECT MASTER_POS_WAIT('file', position); ``` Por exemplo, caso o nome do arquivo seja `mysql-bin-changelog.000031` e a posição seja `107`, execute a declaração a seguir. ``` SELECT MASTER_POS_WAIT('mysql-bin-changelog.000031', 107); ``` Se a réplica de leitura ultrapassar a posição especificada, a consulta retornará imediatamente. Do contrário, a função aguarda. Prossiga para a próxima etapa quando a consulta retornar para todas as réplicas de leitura. 1. Redefina os parâmetros GTID apenas para replicação baseada em GTID. 1. Verifique se o grupo de parâmetros associado a uma instância de banco de dados e cada réplica de leitura tem as seguintes configurações de parâmetro: + `gtid_mode` – `ON` + `enforce_gtid_consistency` – `ON` 1. Reinicialize a instância de banco de dados e cada réplica de leitura. 1. Em cada réplica de leitura, execute o procedimento a seguir. **MySQL 8.4 e versões principais posteriores** ``` CALL mysql.rds_set_source_auto_position(1); ``` **MySQL 8.0 e versões principais anteriores** ``` CALL mysql.rds_set_master_auto_position(1); ``` # Desabilitação da replicação baseada em GTID para uma instância de banco de dados do RDS for MySQL com réplicas de leitura Você pode desabilitar a replicação baseada em GTID para uma instância de banco de dados MySQL com réplicas de leitura. **Para desabilitar a replicação baseada em GTID para uma instância de banco de dados do RDS for MySQL com réplicas de leitura** 1. Em cada réplica de leitura, execute o seguinte procedimento: **MySQL 8.4 e versões principais posteriores** ``` CALL mysql.rds_set_source_auto_position(0); ``` **MySQL 8.0 e versões principais anteriores** ``` CALL mysql.rds_set_master_auto_position(0); ``` 1. Redefina o `gtid_mode` como `ON_PERMISSIVE`. 1. Verifique se o grupo de parâmetros associado a uma instância de banco de dados do MySQL e cada réplica de leitura tem possuem `gtid_mode` definido como `ON_PERMISSIVE`. Para obter mais informações sobre a definição de parâmetros de configuração usando grupos de parâmetros, consulte [Grupos de parâmetros para Amazon RDS](USER_WorkingWithParamGroups.md). 1. Reinicialize a instância de banco de dados do MySQL e cada réplica de leitura. Para obter mais informações sobre como reiniciar, consulte [Reinicializar uma instância de banco de dados](USER_RebootInstance.md). 1. Redefina o `gtid_mode` como `OFF_PERMISSIVE`. 1. Verifique se o grupo de parâmetros associado a uma instância de banco de dados do MySQL e cada réplica de leitura tem possuem `gtid_mode` definido como `OFF_PERMISSIVE`. 1. Reinicialize a instância de banco de dados do MySQL e cada réplica de leitura. 1. Aguarde todas as transações GTID serem aplicadas a todas as réplicas de leitura. Para conferir se elas foram aplicadas, siga estas etapas: 1. Na instância de banco de dados do MySQL, execute o comando a seguir: **MySQL 8.4** ``` SHOW BINARY LOG STATUS ``` **MySQL 5.7 e 8.0** ``` SHOW MASTER STATUS ``` Sua saída deve ser semelhante ao resultado a seguir. ``` File Position ------------------------------------ mysql-bin-changelog.000031 107 ------------------------------------ ``` Observe o arquivo e posicione na saída. 1. Em cada réplica de leitura, use as informações de arquivo e posição de sua instância de origem na etapa anterior para executar a seguinte consulta: **MySQL 8.4 e MySQL 8.0.26 e versões posteriores do MySQL** ``` SELECT SOURCE_POS_WAIT('file', position); ``` **MySQL 5.7** ``` SELECT MASTER_POS_WAIT('file', position); ``` Por exemplo, caso o nome do arquivo seja `mysql-bin-changelog.000031` e a posição seja `107`, execute a seguinte declaração: **MySQL 8.4 e MySQL 8.0.26 e versões posteriores do MySQL 8.0** ``` SELECT SOURCE_POS_WAIT('mysql-bin-changelog.000031', 107); ``` **MySQL 5.7** ``` SELECT MASTER_POS_WAIT('mysql-bin-changelog.000031', 107); ``` 1. Redefina os parâmetros de GTID para desabilitar a replicação baseada em GTID. 1. Verifique se o grupo de parâmetros associado à instância de banco de dados MySQL e cada réplica de leitura possuem as seguintes configurações de parâmetro: + `gtid_mode` – `OFF` + `enforce_gtid_consistency` – `OFF` 1. Reinicialize a instância de banco de dados do MySQL e cada réplica de leitura. # Configurar a replicação da posição do arquivo de log binário com uma instância de origem externa É possível configurar a replicação entre uma instância de banco de dados do RDS para MySQL ou do MariaDB e uma instância do MySQL ou do MariaDB externa ao Amazon RDS usando a replicação de arquivos de log binários. **Topics** + [ ## Antes de começar ](#MySQL.Procedural.Importing.External.Repl.BeforeYouBegin) + [ ## Configurar a replicação da posição do arquivo de log binário com uma instância de origem externa ](#MySQL.Procedural.Importing.External.Repl.Procedure) ## Antes de começar Você pode configurar a replicação usando a posição do arquivo de log binário de transações replicadas. As permissões necessárias para iniciar a replicação em uma instância de banco de dados do Amazon RDS são restritas e não estão disponíveis ao seu usuário mestre do Amazon RDS. Por isso, use os comandos [mysql.rds\$1set\$1external\$1master (RDS para MariaDB e RDS para MySQL versões principais 8.0 e anteriores)](mysql-stored-proc-replicating.md#mysql_rds_set_external_master) ou [mysql.rds\$1set\$1external\$1source (RDS para MySQL versões principais 8.4 e posteriores)](mysql-stored-proc-replicating.md#mysql_rds_set_external_source) e [mysql.rds\$1start\$1replication](mysql-stored-proc-replicating.md#mysql_rds_start_replication) do Amazon RDS para configurar a replicação entre seu banco de dados on-line e seu banco de dados do Amazon RDS. Para definir o formato de registro em log binário para um banco de dados MySQL e MariaDB, atualize o parâmetro `binlog_format`. Se a instância de banco de dados usar o grupo de parâmetros da instância de banco de dados padrão, crie um novo grupo de parâmetros de banco de dados para modificar o parâmetro `binlog_format`. No MariaDB e no MySQL 8.0 e versões anteriores, `binlog_format` tem como padrão `MIXED`. No entanto, você também pode definir o `binlog_format` como `ROW` ou `STATEMENT` se precisar de um formato específico de log binário (binlog). Reinicie a instância de banco de dados para que a alteração entre em vigor. No MySQL 8.4 e versões superiores, `binlog_format` tem como padrão `ROW`. Para obter informações sobre como definir o parâmetro `binlog_format`, consulte [Configurar o registro em log binário do RDS para MySQL para bancos de dados single-AZ](USER_LogAccess.MySQL.BinaryFormat.md). Para obter informações sobre as implicações de tipos de replicação do MySQL diferentes, consulte [Vantagens e desvantagens da replicação baseada em instrução e baseada em linha](https://dev.mysql.com/doc/refman/8.0/en/replication-sbr-rbr.html) na documentação do MySQL. ## Configurar a replicação da posição do arquivo de log binário com uma instância de origem externa Siga estas diretrizes ao configurar uma instância de origem externa e uma réplica no Amazon RDS: + Monitore eventos de failover para a instância do banco de dados do Amazon RDS, que é sua réplica. Se ocorrer um failover, a instância de banco de dados que for a sua réplica poderá ser recriada em um novo host com um endereço de rede diferente. Para obter informações sobre como monitorar eventos de failover, consulte [Trabalhar com a notificação de eventos do Amazon RDS](USER_Events.md). + Retenha os logs binários na instância de origem até confirmar que eles foram aplicados à réplica. Esta manutenção garante que seja possível restaurar sua instância de origem em caso de falha. + Ative backups automatizados na sua instância de banco de dados do Amazon RDS. Ativar backups automáticos garante que seja possível restaurar sua réplica para um determinado ponto no tempo, caso seja necessário ressincronizar sua instância de origem e sua réplica. Para obter informações sobre backups e restauração Point-In-Time, consulte [Backup, restauração e exportação de dados](CHAP_CommonTasks.BackupRestore.md). **Como configurar a replicação do arquivo de log binário com uma instância de origem externa** 1. Torne a instância de origem MySQL ou MariaDB somente leitura. ``` mysql> FLUSH TABLES WITH READ LOCK; mysql> SET GLOBAL read_only = ON; ``` 1. Execute o comando `SHOW MASTER STATUS` na instância do MySQL ou MariaDB de origem para determinar a localização do log binário. Você recebe um resultado semelhante ao seguinte exemplo. ``` File Position ------------------------------------ mysql-bin-changelog.000031 107 ------------------------------------ ``` 1. Copie o banco de dados da instância externa para a instância de banco de dados do Amazon RDS usando `mysqldump`. Para bancos de dados muito grandes, convém usar o procedimento em [Importar dados para um banco de dados do Amazon RDS para MySQL com tempo de inatividade reduzido](mysql-importing-data-reduced-downtime.md). Para Linux, macOS ou Unix: ``` mysqldump --databases database_name \ --single-transaction \ --compress \ --order-by-primary \ -u local_user \ -plocal_password | mysql \ --host=hostname \ --port=3306 \ -u RDS_user_name \ -pRDS_password ``` Para Windows: ``` mysqldump --databases database_name ^ --single-transaction ^ --compress ^ --order-by-primary ^ -u local_user ^ -plocal_password | mysql ^ --host=hostname ^ --port=3306 ^ -u RDS_user_name ^ -pRDS_password ``` **nota** Confirme que não há um espaço entre a opção `-p` e a senha inserida. Para especificar o nome do host, o nome do usuário, a porta e a senha para se conectar à instância de banco de dados Amazon RDS, use as opções `--host`, `--user (-u)`, `--port` e `-p` no comando `mysql`. O nome do host é o nome do Serviço de Nome de Domínio (DNS) do endpoint da instância de banco de dados do Amazon RDS, por exemplo, `myinstance.123456789012.us-east-1.rds.amazonaws.com`. Você pode encontrar o valor do endpoint nos detalhes da instância no Console de gerenciamento da AWS. 1. Torne a instância MySQL ou MariaDB de origem novamente gravável. ``` mysql> SET GLOBAL read_only = OFF; mysql> UNLOCK TABLES; ``` Para obter mais informações sobre como fazer backups para usar com a replicação, consulte a [documentação do MySQL](https://dev.mysql.com/doc/refman/8.0/en/replication-solutions-backups-read-only.html). 1. No Console de gerenciamento da AWS, adicione o endereço IP do servidor que hospeda o banco de dados externo ao grupo de segurança da nuvem privada virtual (VPC) para a instância de banco de dados Amazon RDS. Para obter mais informações sobre como modificar um grupo de segurança da VPC, consulte [Grupos de segurança para a VPC](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html) no *Guia do usuário da Amazon Virtual Private Cloud*. O endereço IP poderá ser alterado se as seguintes condições forem atendidas: + Se você estiver usando um endereço IP público para a comunicação entre a instância de origem externa e a instância de banco de dados. + A instância de origem externa foi interrompida e reiniciada. Se essas condições forem atendidas, verifique o endereço IP antes de adicioná-lo. Você também pode precisar configurar a rede local para permitir conexões com o endereço IP da instância de banco de dados do Amazon RDS. Isso é realizado para que a rede local consiga se comunicar com a instância do MySQL ou do MariaDB externa. Para localizar o endereço IP da instância de banco de dados do Amazon RDS, use o comando `host`. ``` host db_instance_endpoint ``` O nome do host é o nome de DNS do endpoint da instância de banco de dados do Amazon RDS. 1. Usando o cliente de sua preferência, conecte-se à instância externa e crie um usuário a ser usado para a replicação. Use essa conta unicamente para replicação e restrinja-a ao seu domínio para melhorar a segurança. Veja um exemplo a seguir. ``` CREATE USER 'repl_user'@'mydomain.com' IDENTIFIED BY 'password'; ``` **nota** Especifique uma senha diferente do prompt mostrado aqui como prática recomendada de segurança. 1. Para a instância externa, conceda os privilégios `REPLICATION CLIENT` e `REPLICATION SLAVE` para seu usuário de replicação. Por exemplo, para conceder os privilégios de `REPLICATION CLIENT` e `REPLICATION SLAVE` em todos os bancos de dados para o usuário '`repl_user`' de seu domínio, emita o seguinte comando. ``` GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'mydomain.com'; ``` 1. Transforma a instância de banco de dados do Amazon RDS na réplica. Para fazer isso, primeiro se conecte à instância de banco de dados do Amazon RDS como usuário mestre. Depois disso, identifique o banco de dados MySQL ou MariaDB externo como a instância de origem usando o comando [mysql.rds\$1set\$1external\$1source (RDS para MySQL versões principais 8.4 e posteriores)](mysql-stored-proc-replicating.md#mysql_rds_set_external_source) ou [mysql.rds\$1set\$1external\$1master (RDS para MariaDB e RDS para MySQL versões principais 8.0 e anteriores)](mysql-stored-proc-replicating.md#mysql_rds_set_external_master). Use o nome do arquivo de log mestre e a posição do log mestre que você determinou na etapa 2. Os comandos a seguir são exemplos. **MySQL 8.4** ``` CALL mysql.rds_set_external_source ('mysourceserver.mydomain.com', 3306, 'repl_user', 'password', 'mysql-bin-changelog.000031', 107, 1); ``` **MariaDB e MySQL 8.0 e 5.7** ``` CALL mysql.rds_set_external_master ('mymasterserver.mydomain.com', 3306, 'repl_user', 'password', 'mysql-bin-changelog.000031', 107, 1); ``` **nota** No RDS para MySQL, é possível optar por usar a replicação atrasada executando o procedimento armazenado [mysql.rds\$1set\$1external\$1source\$1with\$1delay (RDS para MySQL versões principais 8.4 e superiores)](mysql-stored-proc-replicating.md#mysql_rds_set_external_source_with_delay) ou [mysql.rds\$1set\$1external\$1master\$1with\$1delay (RDS para MariaDB e RDS para MySQL versões principais 8.0 e anteriores)](mysql-stored-proc-replicating.md#mysql_rds_set_external_master_with_delay). No RDS para MySQL, um motivo para usar a replicação atrasada é ativar a recuperação de desastres com o procedimento armazenado [mysql.rds\$1start\$1replication\$1until](mysql-stored-proc-replicating.md#mysql_rds_start_replication_until). Atualmente, o RDS para MariaDB é compatível com a replicação atrasada, mas não com o procedimento `mysql.rds_start_replication_until`. 1. Na instância de banco de dados do Amazon RDS, emita o comando [mysql.rds\$1start\$1replication](mysql-stored-proc-replicating.md#mysql_rds_start_replication) para iniciar a replicação. ``` CALL mysql.rds_start_replication; ``` # Configurar a replicação de várias fontes do Amazon RDS para MySQL Com a replicação de várias fontes, é possível configurar uma instância de banco de dados do Amazon RDS para MySQL como uma réplica que recebe eventos de logs binários de mais de uma instância de banco de dados de origem do RDS para MySQL. A replicação de várias fontes é compatível com instâncias de banco de dados do RDS para MySQL que executam as seguintes versões de mecanismo: + Todas as versões do MySQL 8.4 + 8.0.35 e versões secundárias posteriores + 5.7.44 e versões secundárias posteriores Para ter informações sobre a replicação de várias fontes do MySQL, consulte [MySQL Multi-Source Replication](https://dev.mysql.com/doc/refman/8.0/en/replication-multi-source.html) na documentação do MySQL. A documentação do MySQL contém informações detalhadas sobre esse recurso, enquanto este tópico descreve como configurar e gerenciar canais de replicação de várias fontes nas instâncias de banco de dados do RDS para MySQL. ## Casos de uso da replicação de várias fontes Os casos a seguir são bons candidatos para usar a replicação de várias fontes no RDS para MySQL: + Aplicações que precisam mesclar ou combinar vários fragmentos em instâncias de banco de dados separadas em um único fragmento. + Aplicações que precisam gerar relatórios a partir de dados consolidados de várias fontes. + Requisitos para criar backups consolidados de longo prazo de dados distribuídos entre várias instâncias de banco de dados do RDS para MySQL. ## Pré-requisitos para replicação de várias fontes Antes de configurar a replicação de várias fontes, cumpra os pré-requisitos a seguir. + Garanta que cada instância de banco de dados do RDS para MySQL de origem tenha backups automáticos habilitados. A ativação de backups automáticos habilita o registro em log binário. Para saber como habilitar os backups automáticos, consulte [Ativar backups automáticos](USER_WorkingWithAutomatedBackups.Enabling.md). + Para evitar erros de replicação, recomendamos bloquear as operações de gravação nas instâncias de banco de dados de origem. É possível fazer isso definindo o parâmetro `read-only` como `ON` em um grupo de parâmetros personalizado associado à instância de banco de dados de origem do RDS para MySQL. É possível usar o Console de gerenciamento da AWS ou a AWS CLI para criar um grupo de parâmetros personalizado ou modificar um existente. Para obter mais informações, consulte [Criar um grupo de parâmetros de banco de dados no Amazon RDS](USER_WorkingWithParamGroups.Creating.md) e [Modificar parâmetros em um grupo de parâmetros de banco de dados no Amazon RDS](USER_WorkingWithParamGroups.Modifying.md). + Para cada instância de banco de dados de origem, adicione o endereço IP da instância ao grupo de segurança da Amazon Virtual Private Cloud (VPC) para a instância de banco de dados de várias fontes de dados. Para identificar o endereço IP de uma instância de banco de dados de origem, é possível executar o comando `dig RDS Endpoint`. Execute o comando a partir de uma instância do Amazon EC2 na mesma VPC da instância de banco de dados de várias fontes de destino. + Para cada instância de banco de dados de origem, use um cliente para se conectar à instância de banco de dados e criar um usuário de banco de dados com os privilégios necessários para replicação, como no exemplo a seguir. ``` CREATE USER 'repl_user' IDENTIFIED BY 'password'; GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'; ``` **nota** A partir do MySQL 8.4, o privilégio `REPLICATION SLAVE` foi descontinuado e substituído por `REPLICATION REPLICA`. Para MySQL 8.4 e versões posteriores, use a seguinte sintaxe: ``` CREATE USER 'repl_user' IDENTIFIED BY 'password'; GRANT REPLICATION CLIENT, REPLICATION REPLICA ON *.* TO 'repl_user'; ``` ## Configurar canais de replicação de várias fontes nas instâncias de banco de dados do RDS para MySQL A configuração de canais de replicação de várias fontes é semelhante à configuração da replicação de uma única fonte. Para replicação de várias fontes, primeiro habilite o registro em log binário na instância de origem. Depois, importe os dados das fontes para a réplica de várias fontes. Então, inicie a replicação de cada fonte usando as coordenadas binárias do log binário ou usando o posicionamento automático do GTID. Para configurar uma instância de banco de dados do RDS para MySQL como uma réplica de várias fontes de duas ou mais instâncias de banco de dados do RDS para MySQL, execute as etapas a seguir. **Topics** + [ ### Etapa 1: Importar dados das instâncias de banco de dados de origem para a réplica de várias fontes ](#mysql-multi-source-replication-import) + [ ### Etapa 2: Iniciar a replicação das instâncias de banco de dados de origem para a réplica de várias fontes ](#mysql-multi-source-replication-setting-up-start-replication-other) ### Etapa 1: Importar dados das instâncias de banco de dados de origem para a réplica de várias fontes Execute as etapas a seguir em cada instância de banco de dados de origem. Antes de importar os dados de uma fonte para a réplica de várias fontes, determine o arquivo de log binário atual e a posição executando o comando `SHOW MASTER STATUS`. Anote esses detalhes para uso na próxima etapa. Neste exemplo de saída, o arquivo é `mysql-bin-changelog.000031` e a posição é `107`. **nota** A partir do MySQL 8.4, o comando `SHOW MASTER STATUS` foi descontinuado e substituído por `SHOW BINARY LOG STATUS`. Para MySQL 8.4 e versões posteriores, use `SHOW BINARY LOG STATUS`. ``` File Position ----------------------------------- mysql-bin-changelog.000031 107 ----------------------------------- ``` Agora, copie o banco de dados da instância de banco de dados de origem para a réplica de várias fontes usando `mysqldump`, como no exemplo a seguir. ``` mysqldump --databases database_name \ --single-transaction \ --compress \ --order-by-primary \ -u RDS_user_name \ -p RDS_password \ --host=RDS Endpoint | mysql \ --host=RDS Endpoint \ --port=3306 \ -u RDS_user_name \ -p RDS_password ``` Depois de copiar o banco de dados, é possível definir o parâmetro somente leitura como `OFF` na instância de banco de dados de origem. ### Etapa 2: Iniciar a replicação das instâncias de banco de dados de origem para a réplica de várias fontes Para cada instância de banco de dados de origem, use as credenciais de usuário administrativas para se conectar à instância e executar os dois procedimentos armazenados a seguir. Esses procedimentos armazenados configuram a replicação em um canal e iniciam a replicação. Este exemplo usa o nome do arquivo de log binário e a posição da saída do exemplo na etapa anterior. ``` CALL mysql.rds_set_external_source_for_channel('mysourcehost.example.com', 3306, 'repl_user', 'password', 'mysql-bin-changelog.000031', 107, 1, 'channel_1'); CALL mysql.rds_start_replication_for_channel('channel_1'); ``` Para ter mais informações sobre como usar esses procedimentos armazenados e outros para configurar e gerenciar os canais de replicação, consulte [Gerenciar a replicação de várias fontes](mysql-stored-proc-multi-source-replication.md). ## Usar filtros com replicação de várias fontes É possível usar filtros de replicação para especificar quais bancos de dados e tabelas são replicados em uma réplica de várias fontes. Os filtros de replicação podem incluir bancos de dados e tabelas na replicação ou excluí-los da replicação. Para ter mais informações sobre filtros de replicação , consulte [Configurar filtros de replicação com MySQL](USER_MySQL.Replication.ReadReplicas.ReplicationFilters.md). Com a replicação de várias fontes, é possível configurar filtros de replicação globalmente ou em nível de canal. A filtragem em nível de canal está disponível somente com instâncias de banco de dados compatíveis que executam a versão 8.0 ou 8.4. Os exemplos a seguir mostram como gerenciar filtros globalmente ou em nível de canal. Observe os seguintes requisitos e comportamento com a filtragem na replicação de várias fontes: + Aspas invertidas (``) ao redor dos nomes dos canais são obrigatórias. + Se você alterar os filtros de replicação no grupo de parâmetros, `sql_thread` das réplicas de várias fontes de todos os canais com atualizações será reiniciado para aplicar as alterações dinamicamente. Se uma atualização envolver um filtro global, todos os canais de replicação no estado de execução serão reiniciados. + Todos os filtros globais são aplicados antes de qualquer filtro específico do canal. + Se um filtro for aplicado globalmente e em nível de canal, somente o filtro em nível de canal será aplicado. Por exemplo, se os filtros forem `replicate_ignore_db="db1,`channel_22`:db2"`, `replicate_ignore_db` definido como `db1` será aplicado a todos os canais, exceto a `channel_22` e somente `channel_22` ignorará as alterações de `db2`. Exemplo 1: Definir um filtro global No exemplo a seguir, o banco de dados `temp_data` é excluído da replicação em todos os canais. Para Linux, macOS ou Unix: ``` aws rds modify-db-parameter-group \ --db-parameter-group-name myparametergroup \ --parameters "ParameterName=replicate-ignore-db,ParameterValue='temp_data',ApplyMethod=immediate" ``` Exemplo 2: Definir um filtro em nível de canal No exemplo a seguir, as alterações do banco de dados `sample22` são incluídas somente no canal `channel_22`. Da mesma forma, as alterações do banco de dados `sample99` são incluídas apenas no canal `channel_99`. Para Linux, macOS ou Unix: ``` aws rds modify-db-parameter-group \ --db-parameter-group-name myparametergroup \ --parameters "ParameterName=replicate-do-db,ParameterValue='\`channel_22\`:sample22,\`channel_99\`:sample99',ApplyMethod=immediate" ``` ## Monitorar canais de replicação de várias fontes É possível monitorar canais individuais em uma réplica de várias fontes usando os seguintes métodos: + Para monitorar o status de todos os canais ou de um canal específico, conecte-se à réplica de várias fontes e execute o comando `SHOW REPLICA STATUS` ou `SHOW REPLICA STATUS FOR CHANNEL 'channel_name'`. Para ter mais informações, consulte [Checking Replication Status](https://dev.mysql.com/doc/refman/8.0/en/replication-administration-status.html) na documentação do MySQL. + Para receber uma notificação quando um canal de replicação for iniciado, interrompido ou removido, use a notificação de eventos do RDS. Para obter mais informações, consulte [Trabalhar com a notificação de eventos do Amazon RDS](USER_Events.md). + Para monitorar o atraso de um canal específico, confira a métrica `ReplicationChannelLag`. Os pontos de dados dessa métrica têm um período de 60 segundos (1 minuto) e ficam disponíveis por 15 dias. Para localizar o atraso de replicação de um canal, use o identificador da instância e o nome do canal de replicação. Para receber uma notificação quando esse atraso exceder um determinado limite, configure um alarme do CloudWatch. Para obter mais informações, consulte [Monitorar métricas do Amazon RDS com o Amazon CloudWatch](monitoring-cloudwatch.md). ## Considerações e práticas recomendadas para replicação de várias fontes Antes de usar a replicação de várias fontes no RDS para MySQL, analise as seguintes considerações e práticas recomendadas: + Garanta que uma instância de banco de dados configurada como uma réplica de várias fontes tenha recursos suficientes, como throughput, memória, CPU e IOPS, para lidar com a workload de instâncias de várias fontes. + Monitore regularmente a utilização de recursos na réplica de várias fontes e ajuste a configuração do armazenamento ou da instância para lidar com a workload sem sobrecarregar os recursos. + É possível configurar a replicação multithread em uma réplica de várias fontes definindo a variável do sistema `replica_parallel_workers` com um valor maior que `0`. Nesse caso, o número de threads alocados para cada canal é o valor dessa variável, mais um thread coordenador para gerenciar os threads aplicadores. + Configure os filtros de replicação corretamente para evitar conflitos. Para replicar um banco de dados inteiro em outro banco de dados em uma réplica, é possível usar a opção `--replicate-rewrite-db`. Por exemplo, é possível replicar todas as tabelas no banco de dados A no banco de dados B em uma instância de réplica. Essa abordagem pode ser útil quando todas as instâncias de origem estão usando a mesma convenção de nomenclatura de esquema. Para ter informações sobre a opção `--replicate-rewrite-db`, consulte [Replica Server Options and Variables](https://dev.mysql.com/doc/refman/8.0/en/replication-options-replica.html) na documentação do MySQL. + Para evitar erros de replicação, evite gravar na réplica. Recomendamos habilitar o parâmetro `read_only` em réplicas de várias fontes para bloquear as operações de gravação. Isso ajuda a eliminar problemas de replicação causados por operações de gravação conflitantes. + Para melhor a performance das operações de leitura, como classificações e junções de alta carga que são executadas na réplica de várias fontes, pense em usar leituras otimizadas pelo RDS. Esse recurso pode ajudar com consultas que dependem de grandes tabelas temporárias ou arquivos de classificação. Para obter mais informações, consulte [Melhorar a performance das consultas para o RDS para MySQL com leituras otimizadas do Amazon RDS](rds-optimized-reads.md). + Para minimizar o atraso na replicação e melhorar a performance de uma réplica de várias fontes, pense em habilitar gravações otimizadas. Para obter mais informações, consulte [Melhorar a performance das gravações com gravações otimizadas pelo RDS para MySQL](rds-optimized-writes.md). + Execute operações de gerenciamento (como alterar a configuração) em um canal por vez e evite realizar alterações em vários canais a partir de várias conexões. Essas práticas podem causar conflitos nas operações de replicação. Por exemplo, a execução simultânea de procedimentos `rds_skip_repl_error_for_channel` e `rds_start_replication_for_channel` de várias conexões pode causar a omissão de eventos em um canal diferente do pretendido. + É possível habilitar backups em uma instância de replicação de várias fontes e exportar dados dessa instância para um bucket do Amazon S3 para armazená-los para fins de longo prazo. No entanto, é importante também configurar backups com retenção adequada nas instâncias de origem individuais. Para ter informações sobre como exportar dados de snapshot para o Amazon S3, consulte [Exportação de dados de snapshot de banco de dados para o Amazon S3 para Amazon RDS](USER_ExportSnapshot.md). + Para distribuir a workload de leitura em uma réplica de várias fontes, é possível criar réplicas de leitura de uma réplica de várias fontes. É possível localizar essas réplicas de leitura em Regiões da AWS diferentes com base nos requisitos da aplicação. Para ter mais informações sobre réplicas de leitura, consulte [Trabalhar com réplicas de leitura do MySQL](USER_MySQL.Replication.ReadReplicas.md). ## Limitações da replicação de várias fontes do RDS para MySQL As seguintes limitações se aplicam à replicação de várias fontes no RDS para MySQL: + No momento, o RDS para MySQL comporta a configuração de no máximo 15 canais para uma réplica de várias fontes. + Uma instância de réplica de leitura não pode ser configurada como uma réplica de várias fontes. + Para configurar a replicação de várias fontes no RDS para MySQL executando a versão 5.7 do mecanismo, o Performance Schema deve estar habilitado na instância de réplica. A ativação do Performance Schema é opcional no RDS para MySQL executando a versão 8.0 ou 8.4 do mecanismo. + Para o RDS para MySQL que executa a versão 5.7 do mecanismo, os filtros de replicação se aplicam a todos os canais de replicação. Para o RDS para MySQL que executa a versão 8.0 ou 8.4 do mecanismo, é possível configurar filtros que se aplicam a todos os canais de replicação ou a canais individuais. + Restaurar um snapshot do RDS ou realizar uma recuperação para um ponto no tempo (PITR) não restaura configurações de canais de réplica de várias fontes. + Ao criar uma réplica de leitura por meio de uma réplica de várias fontes, ela replica apenas os dados da instância de várias fontes. Ela não restaura a configuração de nenhum canal. + O MySQL não comporta a configuração de um número diferente de operadores paralelos para cada canal. Cada canal recebe o mesmo número de operadores paralelos com base no valor `replica_parallel_workers`. As seguintes limitações adicionais se aplicarão se o destino de replicação de várias fontes for um cluster de banco de dados multi-AZ: + É necessário configurar um canal para uma instância de origem do RDS para MySQL antes de qualquer gravação nessa instância. + Cada instância do RDS para MySQL de origem deve ter a replicação baseada em GTID habilitada. + Um evento de failover no cluster de banco de dados remove a configuração de replicação de várias fontes. A restauração dessa configuração requer a repetição das etapas de configuração. # Configurar clusters ativos-ativos para RDS para MySQL Um cluster ativo-ativo no Amazon RDS é uma configuração de banco de dados em que vários nós lidam ativamente com operações de leitura e gravação, distribuindo a workload entre instâncias para melhorar a disponibilidade e a escalabilidade. Cada nó no cluster é sincronizado para manter a consistência de dados, permitindo alta disponibilidade e um failover mais rápido em caso de falha do nó. É possível configurar um cluster ativo-ativo para o RDS para MySQL usando o plug-in MySQL Group Replication. O plug-in de replicação de grupo é compatível com instâncias de banco de dados do RDS para MySQL que executam as seguintes versões: + Todas as versões do MySQL 8.4 + MySQL 8.0.35 e versões secundárias posteriores Para ter informações sobre a MySQL Group Replication, consulte [ Group Replication](https://dev.mysql.com/doc/refman/8.0/en/group-replication.html) na documentação do MySQL. A documentação do MySQL contém informações detalhadas sobre esse recurso, enquanto este tópico descreve como configurar e gerenciar o plug-in nas instâncias de banco de dados do RDS para MySQL. **nota** Para resumir, todas as menções de cluster “ativo-ativo” neste tópico se referem a clusters ativos-ativos usando o plug-in MySQL Group Replication. ## Casos de uso de clusters ativos-ativos Os casos a seguir são bons candidatos ao uso de clusters ativos-ativos: + Aplicações que precisam de todas as instâncias de banco de dados do cluster para comportar operações de gravação. O plug-in Group Replication mantém os dados consistentes em cada instância de banco de dados no cluster ativo-ativo. Para ter informações sobre como isso funciona, consulte [ Group Replication](https://dev.mysql.com/doc/refman/8.0/en/group-replication-summary.html) na documentação do MySQL. + Aplicações que exigem disponibilidade contínua do banco de dados. Com um cluster ativo-ativo, os dados são retidos em todas as instâncias de banco de dados contidas no cluster. Se uma instância de banco de dados falhar, a aplicação poderá redirecionar o tráfego para outra instância de banco de dados no cluster. + Aplicações que talvez precisem dividir as operações de leitura e gravação entre diferentes instâncias de banco de dados no cluster para fins de balanceamento de carga. Com um cluster ativo-ativo, as aplicações podem enviar tráfego de leitura a instâncias de banco de dados específicas e tráfego de gravação a outras. Também é possível alternar para quais instâncias de banco de dados enviar leituras ou gravações a qualquer momento. **Topics** + [ ## Casos de uso de clusters ativos-ativos ](#mysql-active-active-clusters-benefits) + [ # Limitações e considerações sobre cluster ativo-ativo ](mysql-active-active-clusters-considerations-limitations.md) + [ # Preparar um cluster ativo-ativo entre VPCs ](mysql-active-active-clusters-cross-vpc-prerequisites.md) + [ # Configurações de parâmetros obrigatórias para clusters ativos-ativos ](mysql-active-active-clusters-parameters.md) + [ # Converter uma instância de banco de dados existente em um cluster ativo-ativo ](mysql-active-active-clusters-converting.md) + [ # Configurar um cluster ativo-ativo com novas instâncias de banco de dados ](mysql-active-active-clusters-setting-up.md) + [ # Adicionar uma instância de banco de dados em um cluster ativo-ativo ](mysql-active-active-clusters-adding.md) + [ # Monitorar clusters ativos-ativos ](mysql-active-active-clusters-monitoring.md) + [ # Interromper a Group Replication em uma instância de banco de dados em um cluster ativo-ativo ](mysql-active-active-clusters-stopping.md) + [ # Renomear uma instância de banco de dados em um cluster ativo-ativo ](mysql-active-active-clusters-renaming.md) + [ # Remover uma instância de banco de dados de um cluster ativo-ativo ](mysql-active-active-clusters-remove.md) # Limitações e considerações sobre cluster ativo-ativo O clusters ativo-ativo no Amazon RDS oferece maior disponibilidade e escalabilidade ao distribuir workloads em várias instâncias. No entanto, há limitações e considerações importantes a saber ao usar essa arquitetura. As seções a seguir descrevem os principais fatores, como atrasos na replicação, resolução de conflitos, alocação de recursos e comportamento de failover. Compreender essas considerações pode ajudar a garantir o desempenho e a confiabilidade ideais em implantações de cluster ativo-ativo. **Topics** + [ ## Limitações dos clusters ativos-ativos do RDS para MySQL ](#mysql-active-active-clusters-limitations) + [ ## Considerações e práticas recomendadas para cluster ativo-ativo do RDS para MySQL ](#mysql-active-active-clusters-considerations) ## Limitações dos clusters ativos-ativos do RDS para MySQL As seguintes limitações se aplicam a clusters ativos-ativos do RDS para MySQL: + O nome de usuário principal não pode ser `rdsgrprepladmin` para instâncias de banco de dados em um cluster ativo-ativo. Esse nome de usuário é reservado para conexões da Group Replication. + Para instâncias de banco de dados com réplicas de leitura em clusters ativos-ativos, um status de replicação prolongado diferente de `Replicating` pode fazer com que os arquivos de log excedam os limites de armazenamento. Para ter informações sobre o status de réplicas de leitura, consulte [Monitoramento da replicação de leitura](USER_ReadRepl.Monitoring.md). + As implantações azul/verde não são compatíveis com instâncias de banco de dados em um cluster ativo-ativo. Para obter mais informações, consulte [Usar implantações azul/verde do Amazon RDS para atualizações de banco de dados](blue-green-deployments.md). + A autenticação Kerberos não é compatível com instâncias de banco de dados em um cluster ativo-ativo. Para obter mais informações, consulte [Uso da autenticação do Kerberos para o Amazon RDS para MySQL](mysql-kerberos.md). + As instâncias de banco de dados em um cluster de banco de dados multi-AZ não podem ser adicionadas a um cluster ativo-ativo. No entanto, as instâncias de banco de dados em uma implantação de instância de banco de dados multi-AZ podem ser adicionadas a um cluster ativo-ativo. Para obter mais informações, consulte [Configurar e gerenciar uma implantação multi-AZ para o Amazon RDS](Concepts.MultiAZ.md). + As tabelas que não têm uma chave primária não são replicadas em um cluster ativo-ativo porque as gravações são rejeitadas pelo plug-in Group Replication. + As tabelas que não são do InnoDB não são replicadas em um cluster ativo-ativo. + Clusters ativos-ativos não comportam declarações DML e DDL simultâneas em diferentes instâncias de banco de dados no cluster. + Não é possível configurar um cluster ativo-ativo para usar o modo primário único para o modo de replicação do grupo. Para essa configuração, recomendamos usar um cluster de banco de dados multi-AZ. Para obter mais informações, consulte [Implantações de cluster de banco de dados multi-AZ para o Amazon RDS](multi-az-db-clusters-concepts.md). + A replicação de várias fontes não é compatível com instâncias de banco de dados em um cluster ativo-ativo. + Um cluster ativo-ativo entre regiões não pode impor a verificação da autoridade de certificação (CA) para conexões da Group Replication. ## Considerações e práticas recomendadas para cluster ativo-ativo do RDS para MySQL Antes de usar clusters ativos-ativos do RDS para MySQL, analise as seguintes considerações e práticas recomendadas: + Os clusters ativos-ativos não podem ter mais de nove instâncias de banco de dados. + Com o plug-in Group Replication, é possível controlar as garantias de consistência da transação do cluster ativo-ativo. Para ter mais informações, consulte [ Transaction Consistency Guarantees](https://dev.mysql.com/doc/refman/8.0/en/group-replication-consistency-guarantees.html) na documentação do MySQL. + Conflitos são possíveis quando diferentes instâncias de banco de dados atualizam a mesma linha em um cluster ativo-ativo. Para ter informações sobre conflitos e sua resolução, consulte [ Group Replication](https://dev.mysql.com/doc/refman/8.0/en/group-replication-summary.html) na documentação do MySQL. + Para tolerância a falhas, inclua pelo menos três instâncias de banco de dados no cluster ativo-ativo. É possível configurar um cluster ativo-ativo com apenas uma ou duas instâncias de banco de dados, mas o cluster não tolerará falhas. Para ter informações sobre tolerância a falhas, consulte [ Fault -tolerance](https://dev.mysql.com/doc/refman/8.0/en/group-replication-fault-tolerance.html) na documentação do MySQL. + Quando uma instância de banco de dados ingressa em um cluster ativo-ativo existente e está executando a mesma versão que a mais baixa do mecanismo no cluster, a instância de banco de dados ingressa no modo de leitura-gravação. + Quando uma instância de banco de dados ingressa em um cluster ativo-ativo existente e está executando uma versão mais alta do que a mais do mecanismo no cluster, a instância de banco de dados deve permanecer no modo de leitura-gravação. + Se você habilitar a Group Replication para uma instância de banco de dados definindo o parâmetro `rds.group_replication_enabled` como `1` no grupo de parâmetros do banco de dados, mas a replicação não foi iniciada ou falhou ao iniciar, a instância de banco de dados será colocada no modo de superleitura para evitar inconsistências de dados. Para ter informações sobre o modo superleitura, consulte a [documentação do MySQL](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_super_read_only). + É possível atualizar uma instância de banco de dados em um cluster ativo-ativo, mas a instância de banco de dados é somente leitura até que todas as outras instâncias de banco de dados no cluster ativo-ativo sejam atualizadas para a mesma versão do mecanismo ou uma versão superior. Quando você atualiza uma instância de banco de dados, a instância de banco de dados ingressa automaticamente no mesmo cluster ativo-ativo quando a atualização é concluída. Para evitar uma mudança não intencional para o modo somente leitura de uma instância de banco de dados, desabilite as atualizações automáticas de versões secundárias para ela. Para ter mais informações sobre como atualizar uma instância de banco de dados MySQL, consulte [Atualizações do mecanismo de banco de dados do RDS para MySQL](USER_UpgradeDBInstance.MySQL.md). + É possível adicionar uma instância de banco de dados em uma implantação de instância de banco de dados multi-AZ para um cluster ativo-ativo existente. Também é possível converter uma instância de banco de dados single-AZ em um cluster ativo-ativo em uma implantação de instância de banco de dados multi-AZ. Se uma instância de banco de dados primária em uma implantação multi-AZ falhar, essa instância primária fará o failover para a instância em espera. A nova instância de banco de dados primária ingressa automaticamente no mesmo cluster após a conclusão do failover. Para ter mais informações sobre implantações de instâncias de banco de dados multi-AZ, consulte [Implantações de instâncias de banco de dados multi-AZ para o Amazon RDS](Concepts.MultiAZSingleStandby.md). + Recomendamos que as instâncias de banco de dados em um cluster ativo-ativo tenham intervalos de tempo diferentes para as janelas de manutenção. Essa prática evita que várias instâncias de banco de dados no cluster fiquem off-line para manutenção ao mesmo tempo. Para obter mais informações, consulte [Janela de manutenção do Amazon RDS](USER_UpgradeDBInstance.Maintenance.md#Concepts.DBMaintenance). + Clusters ativos-ativos podem usar SSL para conexões entre instâncias de banco de dados. Para configurar conexões SSL, defina os parâmetros [ group\$1replication\$1recovery\$1use\$1ssl](https://dev.mysql.com/doc/refman/8.0/en/group-replication-system-variables.html#sysvar_group_replication_recovery_use_ssl) e [ group\$1replication\$1ssl\$1mode](https://dev.mysql.com/doc/refman/8.0/en/group-replication-system-variables.html#sysvar_group_replication_ssl_mode). Os valores desses parâmetros devem coincidir em todas as instâncias de banco de dados no cluster ativo-ativo. Atualmente, os clusters ativos-ativos não comportam a verificação de autoridade de certificação (CA) para conexões entre Regiões da AWS. Portanto, o parâmetro [group\$1replication\$1ssl\$1mode](https://dev.mysql.com/doc/refman/8.0/en/group-replication-system-variables.html#sysvar_group_replication_ssl_mode) deve ser definido como `DISABLED` (o padrão) ou como `REQUIRED` para clusters entre regiões. + Um cluster ativo-ativo do RDS para MySQL é executado no modo multiprimário. O valor padrão de [group\$1replication\$1enforce\$1update\$1everywhere\$1checks é e o parâmetro](https://dev.mysql.com/doc/refman/8.0/en/group-replication-system-variables.html#sysvar_group_replication_enforce_update_everywhere_checks) é `ON` e o parâmetro é estático. Quando esse parâmetro é definido como `ON`, as aplicações não podem ser inseridas em uma tabela que tenha restrições de chave externa em cascata. + Um cluster ativo do RDS para MySQL usa a pilha de comunicação MySQL para segurança de conexão em vez de XCOM. Para ter mais informações, consulte [ Communication Stack for Connection Security Management](https://dev.mysql.com/doc/refman/8.0/en/group-replication-connection-security.html) na documentação do MySQL. + Quando um grupo de parâmetros de banco de dados está associado a uma instância de banco de dados em um cluster ativo-ativo, recomendamos associar esse grupo de parâmetros de banco de dados somente a outras instâncias de banco de dados que estejam no cluster. + Os clusters ativos-ativos são compatíveis somente com instâncias de banco de dados do RDS para MySQL. Essas instâncias de banco de dados devem estar executando versões compatíveis do mecanismo de banco de dados. + Quando uma instância de banco de dados em um cluster ativo-ativo sofre uma falha inesperada, o RDS inicia a recuperação dela automaticamente. Se a instância de banco de dados não se recuperar, recomendamos substituí-la por uma nova instância de banco de dados executando uma recuperação pontual com uma instância de banco de dados íntegra no cluster. Para instruções, consulte [Adicionar uma instância de banco de dados a um cluster ativo-ativo usando a recuperação para um ponto no tempo](mysql-active-active-clusters-adding.md#mysql-active-active-clusters-adding-pitr). + É possível excluir uma instância de banco de dados em um cluster ativo-ativo sem afetar as outras instâncias de banco de dados no cluster. Para obter informações sobre como excluir uma instância de banco de dados, consulte [Excluir uma instância de banco de dados](USER_DeleteInstance.md). + Quando uma instância de banco de dados deixa acidentalmente um cluster ativo-ativo, por padrão, o parâmetro `group_replication_exit_state_action` é alterado para `OFFLINE_MODE`. Nesse estado, a instância de banco de dados fica inacessível e você deve reinicializá-la para colocá-la novamente online e para que ela volte a fazer parte do cluster. Você pode alterar esse comportamento modificando o parâmetro `group_replication_exit_state_action` em um grupo de parâmetros personalizado. Ao definir o parâmetro como `READ_ONLY`, quando a instância de banco de dados sai acidentalmente de um cluster, ela entra em um super estado de somente leitura em vez de ficar offline. # Preparar um cluster ativo-ativo entre VPCs É possível configurar um cluster ativo-ativo com instâncias de banco de dados do Amazon RDS para MySQL em mais de uma VPC. As VPCs podem se encontrar na mesma Região da AWS ou em diferentes Regiões da AWS. **nota** O envio de tráfego entre várias Regiões da AWS pode gerar custos adicionais. Para ter mais informações, consulte [Overview of Data Transfer Costs for Common Architectures](https://aws.amazon.com/blogs/architecture/overview-of-data-transfer-costs-for-common-architectures/). Se você estiver configurando um cluster ativo-ativo em uma única VPC, poderá ignorar essas etapas e ir para [Configurar um cluster ativo-ativo com novas instâncias de banco de dados](mysql-active-active-clusters-setting-up.md). **Como se preparar para um cluster ativo-ativo com instâncias de banco de dados em mais de uma VPC** 1. Garanta que os intervalos de endereços IPv4 nos blocos CIDR atendam aos seguintes requisitos: + Os intervalos de endereços IPv4 nos blocos CIDR das VPCs não podem se sobrepor. + Todos os intervalos de endereços IPv4 nos blocos CIDR devem ser menores que `128.0.0.0/subnet_mask` ou maiores que 128.0.0.0/*subnet\$1mask*. Os seguintes intervalos ilustram estes requisitos: + `10.1.0.0/16` em uma VPC e `10.2.0.0/16` na outra VPC são aceitos. + `172.1.0.0/16` em uma VPC e `172.2.0.0/16` na outra VPC são aceitos. + `10.1.0.0/16` em uma VPC e `10.1.0.0/16` na outra VPC *não são* aceitos porque os intervalos se sobrepõem. + `10.1.0.0/16` em uma VPC e `172.1.0.0/16` na outra VPC *não são aceitos* porque um está abaixo de `128.0.0.0/subnet_mask` e o outro está acima de `128.0.0.0/subnet_mask`. Para ter informações sobre os blocos CIDR, consulte [VPC CIDR blocks](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-cidr-blocks.html) no *Manual do usuário da Amazon VPC*. 1. Em cada VPC, garanta que os nomes de host e a resolução do DNS estejam habilitados. Para ter instruções, consulte [ Exibir e atualizar atributos DNS para sua VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html#vpc-dns-updating) no *Manual do usuário da Amazon VPC*. 1. Configure as VPCs para que você possa rotear o tráfego entre elas de uma das seguintes maneiras: + Crie uma conexão de emparelhamento da VPC entre as VPCs. Para ter instruções, consulte [ Create a VPC peering connection](https://docs.aws.amazon.com/vpc/latest/peering/create-vpc-peering-connection.html) no *Guia de emparelhamento da Amazon VPC*. Em cada VPC, verifique se há regras de entrada para os grupos de segurança que façam referência a grupos de segurança na VPC emparelhada. Fazendo isso, você permite que o tráfego flua entre as instâncias associadas com o grupo de segurança referenciado na VPC emparelhada. Para ter instruções, consulte [ Update your security groups to reference peer security groups](https://docs.aws.amazon.com/vpc/latest/peering/vpc-peering-security-groups.html) no *Guia de emparelhamento da Amazon VPC*. + Crie um gateway de trânsito entre as VPCs. Para ter instruções, consulte [ Getting started with transit gateways](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-getting-started.html) em *Amazon VPC Transit Gateways*. Em cada VPC, verifique se há regras de entrada para os grupos de segurança que permitam o tráfego da outra VPC, como regras de entrada que especifiquem o CIDR da outra VPC. Ao fazer isso, você permite que o tráfego flua entre as instâncias associadas ao grupo de segurança referenciado no cluster ativo-ativo. Para ter mais informações, consulte [ Control traffic to your AWS resources using security groups](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-security-groups.html#working-with-security-groups) no *Manual do usuário da Amazon VPC*. # Configurações de parâmetros obrigatórias para clusters ativos-ativos Configurar parâmetros para clusters ativos-ativos no Amazon RDS para MySQL é essencial para manter o desempenho consistente e a estabilidade operacional. Esta tabela detalha os principais parâmetros que controlam a replicação, a resolução de conflitos e a distribuição da workload. A configuração correta garante uma sincronização eficiente entre os nós, minimiza o atraso na replicação e otimiza a utilização de recursos em ambientes distribuídos ou de alto tráfego. | Parameter | Descrição | Configuração necessária | | --- | --- | --- | | `binlog_format` | Define o formato de registro em log binário. O valor padrão para o RDS para MySQL versão 8.0 e anterior é `MIXED`. O valor padrão para o RDS para MySQL versão 8.4 é `ROW`. Para ter mais informações, consulte [ a documentação do MySQL](https://dev.mysql.com/doc/refman/8.0/en/replication-options-binary-log.html#sysvar_binlog_format). | `ROW` | | `enforce_gtid_consistency` | Reforça a consistência do GTID para execução de declarações. O valor padrão do RDS para MySQL é `OFF`. Para ter mais informações, consulte [ a documentação do MySQL](https://dev.mysql.com/doc/refman/8.0/en/replication-options-gtids.html#sysvar_enforce_gtid_consistency). | `ON` | | `group_replication_group_name` | Define o nome da Group Replication como um UUID. O formato do UUID é `11111111-2222-3333-4444-555555555555`. É possível gerar um UUID do MySQL conectando-se a uma instância de banco de dados MySQL e executando `SELECT UUID()`. O valor deve ser o mesmo para todas as instâncias de banco de dados no cluster ativo-ativo. Para ter mais informações, consulte [ a documentação do MySQL](https://dev.mysql.com/doc/refman/8.0/en/miscellaneous-functions.html#function_uuid). | Um UUID do MySQL | | `gtid-mode` | Controla o registro em log baseado em GTID. O valor padrão do RDS para MySQL é `OFF_PERMISSIVE`. Para ter mais informações, consulte [ a documentação do MySQL](https://dev.mysql.com/doc/refman/8.0/en/replication-options-gtids.html#sysvar_gtid_mode). | `ON` | | `rds.custom_dns_resolution` | Especifica se você deve permitir a resolução de DNS do servidor Amazon DNS na VPC. A resolução de DNS deve ser habilitada quando a Group Replication é habilitada com o parâmetro `rds.group_replication_enabled`. A resolução de DNS não deve ser habilitada quando a Group Replication é desabilitada com o parâmetro `rds.group_replication_enabled`. Para ter mais informações, consulte [ Amazon DNS server](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html#AmazonDNS) no *Manual do usuário da Amazon VPC*. | `1` | | `rds.group_replication_enabled` | Especifica se a Group Replication está habilitada para uma instância de banco de dados. A Group Replication deve estar habilitada em uma instância de banco de dados em um cluster ativo-ativo. | `1` | | `replica_preserve_commit_order` (RDS para MySQL 8.4 e versões posteriores) ou `slave_preserve_commit_order` (RDS para versões 8.0 do MySQL) | Controla a ordem em que as transações são confirmadas em uma réplica. O valor padrão do RDS para MySQL é `ON`. Para ter mais informações, consulte [ a documentação do MySQL](https://dev.mysql.com/doc/refman/8.0/en/replication-options-replica.html#sysvar_slave_preserve_commit_order). | `ON` | # Converter uma instância de banco de dados existente em um cluster ativo-ativo A versão do mecanismo de banco de dados da instância de banco de dados que você deseja migrar para um cluster ativo-ativo deve ser uma destas: + Todas as versões do MySQL 8.4 + MySQL 8.0.35 e versões secundárias posteriores Se você precisar atualizar a versão do mecanismo, consulte [Atualizações do mecanismo de banco de dados do RDS para MySQL](USER_UpgradeDBInstance.MySQL.md). Se estiver configurando um cluster ativo-ativo com instâncias de banco de dados em mais de uma VPC, cumpra os pré-requisitos em [Preparar um cluster ativo-ativo entre VPCs](mysql-active-active-clusters-cross-vpc-prerequisites.md). Conclua as etapas a seguir para migrar uma instância de banco de dados existente para um cluster ativo-ativo do RDS para MySQL. **Topics** + [ ## Etapa 1: Definir os parâmetros de cluster ativo-ativo em um ou mais grupos de parâmetros personalizados ](#mysql-active-active-clusters-converting-parameter-group) + [ ## Etapa 2: Associar a instância de banco de dados a um grupo de parâmetros de banco de dados que tenha os parâmetros obrigatórios da Group Replication definidos ](#mysql-active-active-clusters-converting-associate-parameter-group) + [ ## Etapa 3: Criar o cluster ativo-ativo ](#mysql-active-active-clusters-converting-associate-parameter-groups) + [ ## Etapa 4: Criar instâncias de banco de dados do RDS para MySQL adicionais para o cluster ativo-ativo ](#mysql-active-active-clusters-converting-add-db-instances) + [ ## Etapa 5: Inicializar o grupo na instância de banco de dados que você está convertendo ](#mysql-active-active-clusters-converting-start-replication-first) + [ ## Etapa 6: Iniciar a replicação nas outras instâncias de banco de dados no cluster ativo-ativo ](#mysql-active-active-clusters-converting-start-replication-other) + [ ## Etapa 7: (Recomendado) Conferir o status do cluster ativo-ativo ](#mysql-active-active-clusters-converting-view) ## Etapa 1: Definir os parâmetros de cluster ativo-ativo em um ou mais grupos de parâmetros personalizados As instâncias de banco de dados do RDS para MySQL em um cluster ativo-ativo devem estar associadas a um grupo de parâmetros personalizado que tenha a configuração correta para os parâmetros obrigatórios. Para ter informações sobre os parâmetros e a configuração necessária para cada um, consulte [Configurações de parâmetros obrigatórias para clusters ativos-ativos](mysql-active-active-clusters-parameters.md). É possível definir esses parâmetros em novos grupos de parâmetros ou em grupos de parâmetros existentes. No entanto, para não afetar acidentalmente as instâncias de banco de dados que não fazem parte do cluster ativo-ativo, é altamente recomendável criar um grupo de parâmetros personalizado. As instâncias de banco de dados em um cluster ativo-ativo podem ser associadas ao mesmo grupo de parâmetros de banco de dados ou a grupos de parâmetros de banco de dados diferentes. É possível usar o Console de gerenciamento da AWS ou a AWS CLI para criar um grupo de parâmetros personalizado. Para obter mais informações, consulte [Criar um grupo de parâmetros de banco de dados no Amazon RDS](USER_WorkingWithParamGroups.Creating.md). O seguinte exemplo executa o comando [create-db-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-parameter-group.html) da AWS CLI para criar um grupo de parâmetros de banco de dados personalizado chamado `myactivepg` para o RDS para MySQL 8.0: Para Linux, macOS ou Unix: ``` aws rds create-db-parameter-group \ --db-parameter-group-name myactivepg \ --db-parameter-group-family mysql8.0 \ --description "Parameter group for active-active clusters" ``` Para Windows: ``` aws rds create-db-parameter-group ^ --db-parameter-group-name myactivepg ^ --db-parameter-group-family mysql8.0 ^ --description "Parameter group for active-active clusters" ``` Também é possível usar o Console de gerenciamento da AWS ou a AWS CLI para definir os parâmetros no grupo de parâmetros personalizado. Para obter mais informações, consulte [Modificar parâmetros em um grupo de parâmetros de banco de dados no Amazon RDS](USER_WorkingWithParamGroups.Modifying.md). O seguinte exemplo executa o comando [modify-db-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-parameter-group.html) da AWS CLI para definir os parâmetros para o RDS para MySQL 8.0. Para usar esse exemplo com o RDS para MySQL 8.4, altere `slave_preserve_commit_order` para `replica_preserve_commit_order`. Para Linux, macOS ou Unix: ``` aws rds modify-db-parameter-group \ --db-parameter-group-name myactivepg \ --parameters "ParameterName='rds.group_replication_enabled',ParameterValue='1',ApplyMethod=pending-reboot" \ "ParameterName='rds.custom_dns_resolution',ParameterValue='1',ApplyMethod=pending-reboot" \ "ParameterName='enforce_gtid_consistency',ParameterValue='ON',ApplyMethod=pending-reboot" \ "ParameterName='gtid-mode',ParameterValue='ON',ApplyMethod=pending-reboot" \ "ParameterName='binlog_format',ParameterValue='ROW',ApplyMethod=immediate" \ "ParameterName='slave_preserve_commit_order',ParameterValue='ON',ApplyMethod=immediate" \ "ParameterName='group_replication_group_name',ParameterValue='11111111-2222-3333-4444-555555555555',ApplyMethod=pending-reboot" ``` Para Windows: ``` aws rds modify-db-parameter-group ^ --db-parameter-group-name myactivepg ^ --parameters "ParameterName='rds.group_replication_enabled',ParameterValue='1',ApplyMethod=pending-reboot" ^ "ParameterName='rds.custom_dns_resolution',ParameterValue='1',ApplyMethod=pending-reboot" ^ "ParameterName='enforce_gtid_consistency',ParameterValue='ON',ApplyMethod=pending-reboot" ^ "ParameterName='gtid-mode',ParameterValue='ON',ApplyMethod=pending-reboot" ^ "ParameterName='binlog_format',ParameterValue='ROW',ApplyMethod=immediate" ^ "ParameterName='slave_preserve_commit_order',ParameterValue='ON',ApplyMethod=immediate" ^ "ParameterName='group_replication_group_name',ParameterValue='11111111-2222-3333-4444-555555555555',ApplyMethod=pending-reboot" ``` ## Etapa 2: Associar a instância de banco de dados a um grupo de parâmetros de banco de dados que tenha os parâmetros obrigatórios da Group Replication definidos Associe a instância de banco de dados a um grupo de parâmetros que você criou ou modificou na etapa anterior. Para instruções, consulte [Associar um grupo de parâmetros de banco de dados a uma instância de banco de dados no Amazon RDS](USER_WorkingWithParamGroups.Associating.md). Reinicialize a instância de banco de dados para que as novas configurações dos parâmetros tenham efeito. Para instruções, consulte [Reinicializar uma instância de banco de dados](USER_RebootInstance.md). ## Etapa 3: Criar o cluster ativo-ativo No grupo de parâmetros de banco de dados associado à instância de banco de dados, defina o parâmetro `group_replication_group_seeds` como o endpoint da instância de banco de dados que você está convertendo. É possível usar o Console de gerenciamento da AWS ou a AWS CLI para definir o parâmetro. Não é necessário reinicializar a instância de banco de dados depois de definir esse parâmetro. Para obter mais informações sobre como configurar parâmetros, consulte [Modificar parâmetros em um grupo de parâmetros de banco de dados no Amazon RDS](USER_WorkingWithParamGroups.Modifying.md). O seguinte exemplo executa o comando [modify-db-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-parameter-group.html) da AWS CLI para definir os parâmetros: Para Linux, macOS ou Unix: ``` aws rds modify-db-parameter-group \ --db-parameter-group-name myactivepg \ --parameters "ParameterName='group_replication_group_seeds',ParameterValue='myactivedb1.123456789012.us-east-1.rds.amazonaws.com:3306',ApplyMethod=immediate" ``` Para Windows: ``` aws rds modify-db-parameter-group ^ --db-parameter-group-name myactivepg ^ --parameters "ParameterName='group_replication_group_seeds',ParameterValue='myactivedb1.123456789012.us-east-1.rds.amazonaws.com:3306',ApplyMethod=immediate" ``` ## Etapa 4: Criar instâncias de banco de dados do RDS para MySQL adicionais para o cluster ativo-ativo Para criar instâncias de banco de dados adicionais para o cluster ativo-ativo, execute a recuperação pontual na instância de banco de dados que você está convertendo. Para instruções, consulte [Adicionar uma instância de banco de dados a um cluster ativo-ativo usando a recuperação para um ponto no tempo](mysql-active-active-clusters-adding.md#mysql-active-active-clusters-adding-pitr). Um cluster ativo-ativo pode ter até nove instâncias de banco de dados. Execute a recuperação pontual na instância de banco de dados até ter o número de instâncias de banco de dados que você deseja para o cluster. Ao realizar a recuperação pontual, não se esqueça de associar a instância de banco de dados que você está adicionando a um grupo de parâmetros de banco de dados que tenha `rds.group_replication_enabled` definida como `1`. Caso contrário, a Group Replication não será iniciada na instância de banco de dados recém-adicionada. ## Etapa 5: Inicializar o grupo na instância de banco de dados que você está convertendo Inicialize o grupo e inicie a replicação: 1. Conecte-se à instância de banco de dados que você está convertendo em um cliente SQL. Para ter mais informações sobre como se conectar a uma instância de banco de dados do RDS para MySQL, consulte [Conectar-se à instância de banco de dados do MySQL](USER_ConnectToInstance.md). 1. No cliente SQL, execute os procedimentos armazenados a seguir e substitua *group\$1replication\$1user\$1password* pela senha do usuário `rdsgrprepladmin`. O usuário `rdsgrprepladmin` está reservado para conexões da Group Replication em um cluster ativo-ativo. A senha desse usuário deve ser a mesma em todas as instâncias de banco de dados em um cluster ativo-ativo. ``` call mysql.rds_set_configuration('binlog retention hours', 168); -- 7 days binlog call mysql.rds_group_replication_create_user('group_replication_user_password'); call mysql.rds_group_replication_set_recovery_channel('group_replication_user_password'); call mysql.rds_group_replication_start(1); ``` Este exemplo define o valor `binlog retention hours` como `168`, o que significa que os arquivos de log binários são retidos por sete dias na instância de banco de dados. É possível ajustar esse valor para atender aos requisitos. Este exemplo especifica `1` no procedimento armazenado `mysql.rds_group_replication_start` para inicializar um novo grupo com a instância de banco de dados atual. Para ter mais informações sobre os procedimentos armazenados chamados no exemplo, consulte [Gerenciar clusters ativos-ativos](mysql-stored-proc-active-active-clusters.md). ## Etapa 6: Iniciar a replicação nas outras instâncias de banco de dados no cluster ativo-ativo Para cada uma das instâncias de banco de dados no cluster ativo-ativo, use um cliente SQL para se conectar à instância e execute os procedimentos armazenados a seguir. Substitua *group\$1replication\$1user\$1password* pela senha do usuário `rdsgrprepladmin`. ``` call mysql.rds_set_configuration('binlog retention hours', 168); -- 7 days binlog call mysql.rds_group_replication_create_user('group_replication_user_password'); call mysql.rds_group_replication_set_recovery_channel('group_replication_user_password'); call mysql.rds_group_replication_start(0); ``` Este exemplo define o valor `binlog retention hours` como `168`, o que significa que os arquivos de log binários são retidos por sete dias em cada instância de banco de dados. É possível ajustar esse valor para atender aos requisitos. Este exemplo especifica `0` no procedimento armazenado `mysql.rds_group_replication_start` para inserir a instância de banco de dados atual em um grupo existente. **dica** Execute esses procedimentos armazenados em todas as outras instâncias de banco de dados no cluster ativo-ativo. ## Etapa 7: (Recomendado) Conferir o status do cluster ativo-ativo Para garantir que cada membro do cluster esteja configurado corretamente, confira o status do cluster conectando-se a uma instância de banco de dados no cluster ativo-ativo e executando o seguinte comando SQL: ``` SELECT * FROM performance_schema.replication_group_members; ``` A saída deve exibir `ONLINE` para `MEMBER_STATE` de cada instância de banco de dados, como neste exemplo de saída: ``` +---------------------------+--------------------------------------+----------------+-------------+--------------+-------------+----------------+----------------------------+ | CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION | MEMBER_COMMUNICATION_STACK | +---------------------------+--------------------------------------+----------------+-------------+--------------+-------------+----------------+----------------------------+ | group_replication_applier | 9854d4a2-5d7f-11ee-b8ec-0ec88c43c251 | ip-10-15-3-137 | 3306 | ONLINE | PRIMARY | 8.0.35 | MySQL | | group_replication_applier | 9e2e9c28-5d7f-11ee-8039-0e5d58f05fef | ip-10-15-3-225 | 3306 | ONLINE | PRIMARY | 8.0.35 | MySQL | | group_replication_applier | a6ba332d-5d7f-11ee-a025-0a5c6971197d | ip-10-15-1-83 | 3306 | ONLINE | PRIMARY | 8.0.35 | MySQL | +---------------------------+--------------------------------------+----------------+-------------+--------------+-------------+----------------+----------------------------+ 3 rows in set (0.00 sec) ``` Para ter informações sobre os valores `MEMBER_STATE` possíveis, consulte [ Group Replication Server States](https://dev.mysql.com/doc/refman/8.0/en/group-replication-server-states.html) na documentação do MySQL. # Configurar um cluster ativo-ativo com novas instâncias de banco de dados Conclua as etapas a seguir para configurar um cluster ativo-ativo usando novas instâncias de banco de dados do Amazon RDS para MySQL. Se estiver configurando um cluster ativo-ativo com instâncias de banco de dados em mais de uma VPC, cumpra os pré-requisitos em [Preparar um cluster ativo-ativo entre VPCs](mysql-active-active-clusters-cross-vpc-prerequisites.md). **Topics** + [ ## Etapa 1: Definir os parâmetros de cluster ativo-ativo em um ou mais grupos de parâmetros personalizados ](#mysql-active-active-clusters-setting-up-parameter-group) + [ ## Etapa 2: Criar instâncias de banco de dados do RDS para MySQL para o cluster ativo-ativo ](#mysql-active-active-clusters-setting-up-db-instances) + [ ## Etapa 3: especificar as instâncias de banco de dados no cluster ativo-ativo ](#mysql-active-active-clusters-setting-up-associate-parameter-groups) + [ ## Etapa 4: inicializar o grupo em uma instância de banco de dados e iniciar a replicação ](#mysql-active-active-clusters-setting-up-start-replication-first) + [ ## Etapa 5: iniciar a replicação nas outras instâncias de banco de dados no cluster ativo-ativo ](#mysql-active-active-clusters-setting-up-start-replication-other) + [ ## Etapa 6: (recomendado) conferir o status do cluster ativo-ativo ](#mysql-active-active-clusters-setting-up-view) + [ ## Etapa 7: (opcional) importar dados para uma instância de banco de dados no cluster ativo-ativo ](#mysql-active-active-clusters-import) ## Etapa 1: Definir os parâmetros de cluster ativo-ativo em um ou mais grupos de parâmetros personalizados As instâncias de banco de dados do RDS para MySQL em um cluster ativo-ativo devem estar associadas a um grupo de parâmetros personalizado que tenha a configuração correta para os parâmetros obrigatórios. Para ter informações sobre os parâmetros e a configuração necessária para cada um, consulte [Configurações de parâmetros obrigatórias para clusters ativos-ativos](mysql-active-active-clusters-parameters.md). É possível definir esses parâmetros em novos grupos de parâmetros ou em grupos de parâmetros existentes. No entanto, para não afetar acidentalmente as instâncias de banco de dados que não fazem parte do cluster ativo-ativo, é altamente recomendável criar um grupo de parâmetros personalizado. As instâncias de banco de dados em um cluster ativo-ativo podem ser associadas ao mesmo grupo de parâmetros de banco de dados ou a grupos de parâmetros de banco de dados diferentes. É possível usar o Console de gerenciamento da AWS ou a AWS CLI para criar um grupo de parâmetros personalizado. Para obter mais informações, consulte [Criar um grupo de parâmetros de banco de dados no Amazon RDS](USER_WorkingWithParamGroups.Creating.md). O seguinte exemplo executa o comando [create-db-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-parameter-group.html) da AWS CLI para criar um grupo de parâmetros de banco de dados personalizado chamado `myactivepg` para o RDS para MySQL 8.0: Para Linux, macOS ou Unix: ``` aws rds create-db-parameter-group \ --db-parameter-group-name myactivepg \ --db-parameter-group-family mysql8.0 \ --description "Parameter group for active-active clusters" ``` Para Windows: ``` aws rds create-db-parameter-group ^ --db-parameter-group-name myactivepg ^ --db-parameter-group-family mysql8.0 ^ --description "Parameter group for active-active clusters" ``` Também é possível usar o Console de gerenciamento da AWS ou a AWS CLI para definir os parâmetros no grupo de parâmetros personalizado. Para obter mais informações, consulte [Modificar parâmetros em um grupo de parâmetros de banco de dados no Amazon RDS](USER_WorkingWithParamGroups.Modifying.md). O seguinte exemplo executa o comando [modify-db-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-parameter-group.html) da AWS CLI para definir os parâmetros para o RDS para MySQL 8.0. Para usar esse exemplo com o RDS para MySQL 8.4, altere `slave_preserve_commit_order` para `replica_preserve_commit_order`. Para Linux, macOS ou Unix: ``` aws rds modify-db-parameter-group \ --db-parameter-group-name myactivepg \ --parameters "ParameterName='rds.group_replication_enabled',ParameterValue='1',ApplyMethod=pending-reboot" \ "ParameterName='rds.custom_dns_resolution',ParameterValue='1',ApplyMethod=pending-reboot" \ "ParameterName='enforce_gtid_consistency',ParameterValue='ON',ApplyMethod=pending-reboot" \ "ParameterName='gtid-mode',ParameterValue='ON',ApplyMethod=pending-reboot" \ "ParameterName='binlog_format',ParameterValue='ROW',ApplyMethod=immediate" \ "ParameterName='slave_preserve_commit_order',ParameterValue='ON',ApplyMethod=immediate" \ "ParameterName='group_replication_group_name',ParameterValue='11111111-2222-3333-4444-555555555555',ApplyMethod=pending-reboot" ``` Para Windows: ``` aws rds modify-db-parameter-group ^ --db-parameter-group-name myactivepg ^ --parameters "ParameterName='rds.group_replication_enabled',ParameterValue='1',ApplyMethod=pending-reboot" ^ "ParameterName='rds.custom_dns_resolution',ParameterValue='1',ApplyMethod=pending-reboot" ^ "ParameterName='enforce_gtid_consistency',ParameterValue='ON',ApplyMethod=pending-reboot" ^ "ParameterName='gtid-mode',ParameterValue='ON',ApplyMethod=pending-reboot" ^ "ParameterName='binlog_format',ParameterValue='ROW',ApplyMethod=immediate" ^ "ParameterName='slave_preserve_commit_order',ParameterValue='ON',ApplyMethod=immediate" ^ "ParameterName='group_replication_group_name',ParameterValue='11111111-2222-3333-4444-555555555555',ApplyMethod=pending-reboot" ``` ## Etapa 2: Criar instâncias de banco de dados do RDS para MySQL para o cluster ativo-ativo Clusters ativos-ativos são compatíveis com as seguintes versões de instâncias de banco de dados do RDS para MySQL: + Todas as versões do MySQL 8.4 + MySQL versão 8.0.35 e versões secundárias posteriores É possível criar até nove novas instâncias de banco de dados para o cluster. É possível usar o Console de gerenciamento da AWS ou a AWS CLI para criar instâncias de banco de dados. Para ter mais informações sobre como criar uma instância de banco de dados, consulte [Criar uma instância de banco de dados do Amazon RDS](USER_CreateDBInstance.md). Ao criar a instância de banco de dados, associe-a a um grupo de parâmetros de banco de dados que você criou ou modificou na etapa anterior. ## Etapa 3: especificar as instâncias de banco de dados no cluster ativo-ativo No grupo de parâmetros de banco de dados associado a cada instância de banco de dados, defina o parâmetro `group_replication_group_seeds` como os endpoints das instâncias de banco de dados que você deseja incluir no cluster. É possível usar o Console de gerenciamento da AWS ou a AWS CLI para definir o parâmetro. Não é necessário reinicializar a instância de banco de dados depois de definir esse parâmetro. Para obter mais informações sobre como configurar parâmetros, consulte [Modificar parâmetros em um grupo de parâmetros de banco de dados no Amazon RDS](USER_WorkingWithParamGroups.Modifying.md). O seguinte exemplo executa o comando [modify-db-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-parameter-group.html) da AWS CLI para definir os parâmetros: Para Linux, macOS ou Unix: ``` aws rds modify-db-parameter-group \ --db-parameter-group-name myactivepg \ --parameters "ParameterName='group_replication_group_seeds',ParameterValue='myactivedb1.123456789012.us-east-1.rds.amazonaws.com:3306,myactivedb2.123456789012.us-east-1.rds.amazonaws.com:3306,myactivedb3.123456789012.us-east-1.rds.amazonaws.com:3306',ApplyMethod=immediate" ``` Para Windows: ``` aws rds modify-db-parameter-group ^ --db-parameter-group-name myactivepg ^ --parameters "ParameterName='group_replication_group_seeds',ParameterValue='myactivedb1.123456789012.us-east-1.rds.amazonaws.com:3306,myactivedb2.123456789012.us-east-1.rds.amazonaws.com:3306,myactivedb3.123456789012.us-east-1.rds.amazonaws.com:3306',ApplyMethod=immediate" ``` **dica** Defina o parâmetro `group_replication_group_seeds` em cada grupo de parâmetros de banco de dados associado a uma instância de banco de dados no cluster ativo-ativo. ## Etapa 4: inicializar o grupo em uma instância de banco de dados e iniciar a replicação É possível selecionar qualquer novo banco de dados para inicializar o grupo e iniciar a replicação. Para fazer isso, realize as etapas a seguir: 1. Selecione uma instância de banco de dados no cluster ativo-ativo e conecte-se a essa instância de banco de dados em um cliente SQL. Para ter mais informações sobre como se conectar a uma instância de banco de dados do RDS para MySQL, consulte [Conectar-se à instância de banco de dados do MySQL](USER_ConnectToInstance.md). 1. No cliente SQL, execute os procedimentos armazenados a seguir e substitua *group\$1replication\$1user\$1password* pela senha do usuário `rdsgrprepladmin`. O usuário `rdsgrprepladmin` está reservado para conexões da Group Replication em um cluster ativo-ativo. A senha desse usuário deve ser a mesma em todas as instâncias de banco de dados em um cluster ativo-ativo. ``` call mysql.rds_set_configuration('binlog retention hours', 168); -- 7 days binlog call mysql.rds_group_replication_create_user('group_replication_user_password'); call mysql.rds_group_replication_set_recovery_channel('group_replication_user_password'); call mysql.rds_group_replication_start(1); ``` Este exemplo define o valor `binlog retention hours` como `168`, o que significa que os arquivos de log binários são retidos por sete dias na instância de banco de dados. É possível ajustar esse valor para atender aos requisitos. Este exemplo especifica `1` no procedimento armazenado `mysql.rds_group_replication_start` para inicializar um novo grupo com a instância de banco de dados atual. Para ter mais informações sobre os procedimentos armazenados chamados no exemplo, consulte [Gerenciar clusters ativos-ativos](mysql-stored-proc-active-active-clusters.md). ## Etapa 5: iniciar a replicação nas outras instâncias de banco de dados no cluster ativo-ativo Para cada uma das instâncias de banco de dados no cluster ativo-ativo, use um cliente SQL para se conectar à instância e execute os procedimentos armazenados a seguir. Substitua *group\$1replication\$1user\$1password* pela senha do usuário `rdsgrprepladmin`. ``` call mysql.rds_set_configuration('binlog retention hours', 168); -- 7 days binlog call mysql.rds_group_replication_create_user('group_replication_user_password'); call mysql.rds_group_replication_set_recovery_channel('group_replication_user_password'); call mysql.rds_group_replication_start(0); ``` Este exemplo define o valor `binlog retention hours` como `168`, o que significa que os arquivos de log binários são retidos por sete dias em cada instância de banco de dados. É possível ajustar esse valor para atender aos requisitos. Este exemplo especifica `0` no procedimento armazenado `mysql.rds_group_replication_start` para inserir a instância de banco de dados atual em um grupo existente. **dica** Execute esses procedimentos armazenados em todas as outras instâncias de banco de dados no cluster ativo-ativo. ## Etapa 6: (recomendado) conferir o status do cluster ativo-ativo Para garantir que cada membro do cluster esteja configurado corretamente, confira o status do cluster conectando-se a uma instância de banco de dados no cluster ativo-ativo e executando o seguinte comando SQL: ``` SELECT * FROM performance_schema.replication_group_members; ``` A saída deve exibir `ONLINE` para `MEMBER_STATE` de cada instância de banco de dados, como neste exemplo de saída: ``` +---------------------------+--------------------------------------+----------------+-------------+--------------+-------------+----------------+----------------------------+ | CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION | MEMBER_COMMUNICATION_STACK | +---------------------------+--------------------------------------+----------------+-------------+--------------+-------------+----------------+----------------------------+ | group_replication_applier | 9854d4a2-5d7f-11ee-b8ec-0ec88c43c251 | ip-10-15-3-137 | 3306 | ONLINE | PRIMARY | 8.0.35 | MySQL | | group_replication_applier | 9e2e9c28-5d7f-11ee-8039-0e5d58f05fef | ip-10-15-3-225 | 3306 | ONLINE | PRIMARY | 8.0.35 | MySQL | | group_replication_applier | a6ba332d-5d7f-11ee-a025-0a5c6971197d | ip-10-15-1-83 | 3306 | ONLINE | PRIMARY | 8.0.35 | MySQL | +---------------------------+--------------------------------------+----------------+-------------+--------------+-------------+----------------+----------------------------+ 3 rows in set (0.00 sec) ``` Para ter informações sobre os valores `MEMBER_STATE` possíveis, consulte [ Group Replication Server States](https://dev.mysql.com/doc/refman/8.0/en/group-replication-server-states.html) na documentação do MySQL. ## Etapa 7: (opcional) importar dados para uma instância de banco de dados no cluster ativo-ativo É possível importar dados de um banco de dados MySQL para uma instância de banco de dados no cluster ativo-ativo. Depois que os dados são importados, a Group Replication os replica para as outras instâncias de banco de dados no cluster. Para ter informações sobre como importar dados, consulte [Importar dados para um banco de dados do Amazon RDS para MySQL com tempo de inatividade reduzido](mysql-importing-data-reduced-downtime.md). # Adicionar uma instância de banco de dados em um cluster ativo-ativo É possível adicionar uma instância de banco de dados a um cluster ativo-ativo do Amazon RDS para MySQL restaurando um snapshot de banco de dados ou restaurando uma instância de banco de dados para um ponto no tempo. Um cluster ativo-ativo pode incluir até nove instâncias de banco de dados. Ao recuperar uma instância de banco de dados em um ponto no tempo, geralmente ela inclui transações mais recentes do que uma instância de banco de dados que foi restaurada por meio de um snapshot de banco de dados. Quando a instância de banco de dados tem transações mais recentes, menos transações precisam ser aplicadas ao iniciar a replicação. Portanto, usar a recuperação para um ponto no tempo para adicionar uma instância de banco de dados a um cluster geralmente é mais rápido do que restaurar por meio de um snapshot de banco de dados. **Topics** + [ ## Adicionar uma instância de banco de dados a um cluster ativo-ativo usando a recuperação para um ponto no tempo ](#mysql-active-active-clusters-adding-pitr) + [ ## Adicionar uma instância de banco de dados em um cluster ativo-ativo usando um snapshot de banco de dados ](#mysql-active-active-clusters-adding-snapshot) ## Adicionar uma instância de banco de dados a um cluster ativo-ativo usando a recuperação para um ponto no tempo É possível adicionar uma instância de banco de dados a um cluster ativo-ativo realizando a recuperação para um ponto no tempo em uma instância de banco de dados no cluster. Para ter informações sobre como recuperar uma instância de banco de dados para um ponto no tempo em uma Região da AWS diferente, consulte [Replicar backups automatizados para outra Região da AWS](USER_ReplicateBackups.md). **Como adicionar uma instância de banco de dados a um cluster ativo-ativo usando a recuperação para um ponto no tempo** 1. Crie uma instância de banco de dados realizando a recuperação para um ponto no tempo em uma instância de banco de dados no cluster ativo-ativo. É possível realizar a recuperação para um ponto no tempo em qualquer instância de banco de dados no cluster para criar a instância de banco de dados. Para obter instruções, consulte [Restaurar uma instância de banco de dados para um momento especificado no Amazon RDS](USER_PIT.md). **Importante** Durante a recuperação para um ponto no tempo, associe a nova instância de banco de dados a um grupo de parâmetros de banco de dados que tenha os parâmetros de cluster ativo-ativo definidos. Caso contrário, a Group Replication não será iniciada na nova instância de banco de dados. Para ter informações sobre os parâmetros e a configuração necessária para cada um, consulte [Configurações de parâmetros obrigatórias para clusters ativos-ativos](mysql-active-active-clusters-parameters.md). **dica** Se você criar um snapshot da instância de banco de dados antes de iniciar a recuperação para um ponto no tempo, poderá reduzir o tempo necessário para aplicar transações na nova instância de banco de dados. 1. Adicione a instância de banco de dados ao parâmetro `group_replication_group_seeds` em cada grupo de parâmetros de banco de dados associado a uma instância de banco de dados no cluster ativo-ativo, incluindo o grupo de parâmetros de banco de dados que você associou à nova instância de banco de dados. Para obter mais informações sobre como configurar parâmetros, consulte [Modificar parâmetros em um grupo de parâmetros de banco de dados no Amazon RDS](USER_WorkingWithParamGroups.Modifying.md). 1. Em um cliente SQL, conecte-se à nova instância de banco de dados e chame o procedimento armazenado [mysql.rds\$1group\$1replication\$1set\$1recovery\$1channel](mysql-stored-proc-active-active-clusters.md#mysql_rds_group_replication_set_recovery_channel). Substitua *group\$1replication\$1user\$1password* pela senha do usuário `rdsgrprepladmin`. ``` call mysql.rds_group_replication_set_recovery_channel('group_replication_user_password'); ``` 1. Usando o cliente SQL, chame o procedimento armazenado [mysql.rds\$1group\$1replication\$1start](mysql-stored-proc-active-active-clusters.md#mysql_rds_group_replication_start) para iniciar a replicação: ``` call mysql.rds_group_replication_start(0); ``` ## Adicionar uma instância de banco de dados em um cluster ativo-ativo usando um snapshot de banco de dados É possível adicionar uma instância de banco de dados a um cluster ativo-ativo criando um snapshot de banco de dados de uma instância de banco de dados no cluster e, depois, restaurando o snapshot de banco de dados. Para ter mais informações como copiar um snapshot em uma Região da AWS diferente, consulte [Considerações sobre a cópia de snapshots entre regiões](USER_CopySnapshot.md#USER_CopySnapshot.AcrossRegions). **Como adicionar uma instância de banco de dados em um cluster ativo-ativo usando um snapshot de banco de dados** 1. Crie um snapshot de banco de dados de uma instância de banco de dados no cluster ativo-ativo. É possível criar um snapshot de banco de dados de qualquer instância de banco de dados no cluster. Para obter instruções, consulte [Criar um snapshot de banco de dados para uma instância de banco de dados single-AZ para o Amazon RDS](USER_CreateSnapshot.md). 1. Restaure uma instância de banco de dados por meio do snapshot de banco de dados. Durante a operação de recuperação de snapshot, associe a nova instância de banco de dados a um grupo de parâmetros de banco de dados que tenha os parâmetros de cluster ativo-ativo definidos. Para ter informações sobre os parâmetros e a configuração necessária para cada um, consulte [Configurações de parâmetros obrigatórias para clusters ativos-ativos](mysql-active-active-clusters-parameters.md). Para ter mais informações sobre como restaurar uma instância de banco de dados por meio de um snapshot de banco de dados, consulte [Restaurar uma instância de banco de dados](USER_RestoreFromSnapshot.md). 1. Adicione a instância de banco de dados ao parâmetro `group_replication_group_seeds` em cada grupo de parâmetros de banco de dados associado a uma instância de banco de dados no cluster ativo-ativo, incluindo o grupo de parâmetros de banco de dados que você associou à nova instância de banco de dados. Para obter mais informações sobre como configurar parâmetros, consulte [Modificar parâmetros em um grupo de parâmetros de banco de dados no Amazon RDS](USER_WorkingWithParamGroups.Modifying.md). 1. Em um cliente SQL, conecte-se à nova instância de banco de dados e chame o procedimento armazenado [mysql.rds\$1group\$1replication\$1set\$1recovery\$1channel](mysql-stored-proc-active-active-clusters.md#mysql_rds_group_replication_set_recovery_channel). Substitua *group\$1replication\$1user\$1password* pela senha do usuário `rdsgrprepladmin`. ``` call mysql.rds_group_replication_set_recovery_channel('group_replication_user_password'); ``` 1. Usando o cliente SQL, chame o procedimento armazenado [mysql.rds\$1group\$1replication\$1start](mysql-stored-proc-active-active-clusters.md#mysql_rds_group_replication_start) para iniciar a replicação: ``` call mysql.rds_group_replication_start(0); ``` # Monitorar clusters ativos-ativos O monitoramento de clusters ativos-ativos no Amazon RDS para MySQL é crucial para monitorar o desempenho, a integridade da replicação e a sincronização de nós. É possível monitorar o cluster ativo-ativo conectando-se a uma instância de banco de dados no cluster e executando o seguinte comando SQL: ``` SELECT * FROM performance_schema.replication_group_members; ``` A saída deve exibir `ONLINE` para `MEMBER_STATE` de cada instância de banco de dados, como neste exemplo de saída: ``` +---------------------------+--------------------------------------+----------------+-------------+--------------+-------------+----------------+----------------------------+ | CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION | MEMBER_COMMUNICATION_STACK | +---------------------------+--------------------------------------+----------------+-------------+--------------+-------------+----------------+----------------------------+ | group_replication_applier | 9854d4a2-5d7f-11ee-b8ec-0ec88c43c251 | ip-10-15-3-137 | 3306 | ONLINE | PRIMARY | 8.0.35 | MySQL | | group_replication_applier | 9e2e9c28-5d7f-11ee-8039-0e5d58f05fef | ip-10-15-3-225 | 3306 | ONLINE | PRIMARY | 8.0.35 | MySQL | | group_replication_applier | a6ba332d-5d7f-11ee-a025-0a5c6971197d | ip-10-15-1-83 | 3306 | ONLINE | PRIMARY | 8.0.35 | MySQL | +---------------------------+--------------------------------------+----------------+-------------+--------------+-------------+----------------+----------------------------+ 3 rows in set (0.00 sec) ``` Para ter informações sobre os valores `MEMBER_STATE` possíveis, consulte [ Group Replication Server States](https://dev.mysql.com/doc/refman/8.0/en/group-replication-server-states.html) na documentação do MySQL. # Interromper a Group Replication em uma instância de banco de dados em um cluster ativo-ativo É possível interromper a Group Replication em uma instância de banco de dados em um cluster ativo-ativo. Ao interromper a Group Replication, a instância de banco de dados é colocada no modo somente superleitura até que a replicação seja reiniciada ou essa instância de banco de dados seja removida do cluster ativo-ativo. Para ter informações sobre o modo superleitura, consulte a [documentação do MySQL](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_super_read_only). **Como interromper temporariamente a Group Replication para um cluster ativo-ativo** 1. Conecte-se a uma instância de banco de dados no cluster ativo-ativo usando um cliente SQL. Para ter mais informações sobre como se conectar a uma instância de banco de dados do RDS para MySQL, consulte [Conectar-se à instância de banco de dados do MySQL](USER_ConnectToInstance.md). 1. No cliente SQL, chame o procedimento armazenado [mysql.rds\$1group\$1replication\$1stop](mysql-stored-proc-active-active-clusters.md#mysql_rds_group_replication_stop): ``` call mysql.rds_group_replication_stop(); ``` # Renomear uma instância de banco de dados em um cluster ativo-ativo É possível alterar o nome de uma instância de banco de dados em um cluster ativo-ativo. Para renomear mais de uma instância de banco de dados em um cluster ativo-ativo, faça isso em uma instância de banco de dados por vez. Então, renomeie uma instância de banco de dados e insira-a novamente no cluster antes de renomear a próxima instância de banco de dados. **Como renomear uma instância de banco de dados em um cluster ativo-ativo** 1. Conecte-se à instância de banco de dados em um cliente SQL e chame o procedimento armazenado [mysql.rds\$1group\$1replication\$1stop](mysql-stored-proc-active-active-clusters.md#mysql_rds_group_replication_stop): ``` call mysql.rds_group_replication_stop(); ``` 1. Renomeie a instância de banco de dados seguindo as instruções em [Renomear uma instância de banco de dados](USER_RenameInstance.md). 1. Modifique o parâmetro `group_replication_group_seeds` em cada grupo de parâmetros de banco de dados associado a uma instância de banco de dados no cluster ativo-ativo. Na configuração de parâmetros, substitua o endpoint antigo da instância de banco de dados pelo novo endpoint da instância de banco de dados. Para obter mais informações sobre como configurar parâmetros, consulte [Modificar parâmetros em um grupo de parâmetros de banco de dados no Amazon RDS](USER_WorkingWithParamGroups.Modifying.md). 1. Conecte-se à instância de banco de dados em um cliente SQL e chame o procedimento armazenado [mysql.rds\$1group\$1replication\$1start](mysql-stored-proc-active-active-clusters.md#mysql_rds_group_replication_start): ``` call mysql.rds_group_replication_start(0); ``` # Remover uma instância de banco de dados de um cluster ativo-ativo Ao remover uma instância de banco de dados de um cluster ativo-ativo, ela é revertida para uma instância de banco de dados autônoma. **Como remover uma instância de banco de dados de um cluster ativo-ativo** 1. Conecte-se à instância de banco de dados em um cliente SQL e chame o procedimento armazenado [mysql.rds\$1group\$1replication\$1stop](mysql-stored-proc-active-active-clusters.md#mysql_rds_group_replication_stop): ``` call mysql.rds_group_replication_stop(); ``` 1. Modifique o parâmetro `group_replication_group_seeds` para as instâncias de banco de dados que permanecerão no cluster ativo-ativo. No parâmetro `group_replication_group_seeds`, exclua a instância de banco de dados que você está removendo do cluster ativo-ativo. Para obter mais informações sobre como configurar parâmetros, consulte [Modificar parâmetros em um grupo de parâmetros de banco de dados no Amazon RDS](USER_WorkingWithParamGroups.Modifying.md). 1. Modifique os parâmetros da instância de banco de dados que você está removendo do cluster ativo-ativo para que ela não faça mais parte do cluster. É possível associar a instância de banco de dados a um grupo de parâmetros diferente ou modificar os parâmetros no grupo de parâmetros de banco de dados associado à instância. Os parâmetros a serem modificados incluem `group_replication_group_name`, `rds.group_replication_enabled` e `group_replication_group_seeds`. Para ter mais informações sobre parâmetros de cluster ativo-ativo, consulte [Configurações de parâmetros obrigatórias para clusters ativos-ativos](mysql-active-active-clusters-parameters.md). Se você modificar os parâmetros em um grupo de parâmetros de banco de dados, garanta que o grupo de parâmetros de banco de dados não esteja associado a outras instâncias de banco de dados no cluster ativo-ativo. 1. Reinicialize a instância de banco de dados que você removeu do cluster ativo-ativo para que as novas configurações de parâmetros tenham efeito. Para instruções, consulte [Reinicializar uma instância de banco de dados](USER_RebootInstance.md). # Exportar dados de uma instância de banco de dados MySQL usando replicação Para exportar dados de uma instância de banco de dados do RDS para MySQL para uma instância do MySQL executada externamente ao Amazon RDS, é possível usar a replicação. Nesse cenário, a instância de banco de dados MySQL é a *instância de banco de dados MySQL de origem* e a instância MySQL executada externamente em relação ao Amazon RDS é o *banco de dados MySQL externo*. O banco de dados MySQL externo pode ser executado localmente em seu datacenter ou em uma instância do Amazon EC2. O banco de dados MySQL externo deve executar a mesma versão da instância de banco de dados MySQL de origem ou uma versão posterior. A replicação para um banco de dados MySQL externo só é compatível durante o tempo necessário para exportar um banco de dados da instância de banco de dados MySQL de origem. A replicação deve ser encerrada quando os dados tiverem sido exportados e os aplicativos puderem começar a acessar a instância MySQL externa. A lista a seguir mostra as etapas a serem realizadas. Cada etapa é discutida em maiores detalhes nas seções mais adiante. 1. Prepare uma instância de banco de dados MySQL externa. 1. Prepare a instância de banco de dados MySQL de origem para replicação. 1. Use o utilitário mysqldump para transferir o banco de dados da instância de banco de dados MySQL de origem para o banco de dados MySQL externo. 1. Inicie a replicação para o banco de dados MySQL externo. 1. Após a conclusão da exportação, pare a replicação. ## Preparar um banco de dados MySQL externo Execute as etapas a seguir para preparar o banco de dados MySQL externo. **Como preparar o banco de dados MySQL externo** 1. Instale o banco de dados MySQL externo. 1. Conecte-se ao banco de dados MySQL externo como o usuário mestre. Depois, crie os usuários necessários para dar suporte aos administradores, aplicativos e serviços que acessam o banco de dados. 1. Siga as instruções na documentação do MySQL para preparar o banco de dados MySQL externo como uma réplica. Para ter mais informações, consulte [Setting the Replica Configuration](https://dev.mysql.com/doc/refman/8.0/en/replication-howto-slavebaseconfig.html), na documentação do MySQL. 1. Configure uma regra de saída para o banco de dados MySQL externo operar como uma réplica de leitura durante a exportação. A regra de saída permite que o banco de dados MySQL externo se conecte à instância de banco de dados MySQL de origem durante a replicação. Especifique uma regra de saída que permita conexões Transmission Control Protocol (TCP) com a porta e o endereço IP da instância de banco de dados MySQL de origem. Especifique as regras de saída apropriadas para o ambiente: + Se o banco de dados MySQL externo estiver sendo executado em uma instância do Amazon EC2 em uma nuvem privada virtual (VPC) com base no serviço da Amazon VPC, especifique as regras de saída em um grupo de segurança da VPC. Para obter mais informações, consulte [Controlar acesso com grupos de segurança](Overview.RDSSecurityGroups.md). + Se o banco de dados MySQL externo estiver instalado localmente, especifique as regras de saída em um firewall. 1. Se o banco de dados MySQL externo estiver sendo executado em uma VPC, configure regras para a lista de controle de acesso (ACL) da VPC, além da regra de saída do grupo de segurança: + Configure uma regra de entrada da ACL que permita o tráfego TCP para as portas 1024–65535 a partir do endereço IP da instância de banco de dados MySQL de origem. + Configure uma regra de saída da ACL que permita o tráfego TCP de saída para a porta e o endereço IP da instância de banco de dados MySQL de origem. Para obter mais informações sobre network ACLs da Amazon VPC, consulte [Network ACLs​](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html) no *Guia do usuário da Amazon VPC*. 1. (Opcional) Defina o parâmetro `max_allowed_packet` como o tamanho máximo para evitar erros de replicação. Recomendamos essa configuração. ## Preparar a instância de banco de dados MySQL Execute as etapas a seguir para preparar a instância de banco de dados MySQL de origem como a origem de replicação. **Como preparar a instância de banco de dados MySQL de origem** 1. Ao configurar a replicação, verifique se o computador cliente tem espaço suficiente em disco disponível para salvar os logs binários. 1. Conecte-se à instância de banco de dados do MySQL de origem e crie uma conta de replicação seguindo as instruções em [Creating a User for Replication](http://dev.mysql.com/doc/refman/8.0/en/replication-howto-repuser.html) na documentação do MySQL. 1. Configure regras de entrada no sistema que executa a instância de banco de dados MySQL de origem para permitir que o banco de dados MySQL externo se conecte durante a replicação. Especifique uma regra de entrada que permita conexões TCP com a porta usada pela instância de banco de dados MySQL de origem do endereço IP do banco de dados MySQL externo. 1. Especifique as regras de saída: + Se a instância de banco de dados MySQL de origem estiver em execução em uma VPC, especifique as regras de entrada em um grupo de segurança da VPC. Para obter mais informações, consulte [Controlar acesso com grupos de segurança](Overview.RDSSecurityGroups.md). 1. Se a instância de banco de dados MySQL de origem estiver sendo executada em uma VPC, configure regras de ACL da VPC, além da regra de entrada do grupo de segurança: + Configure uma regra de entrada de ACL para permitir conexões TCP com a porta usada pela instância do Amazon RDS do endereço IP do banco de dados MySQL externo. + Configure uma regra de saída de ACL para permitir conexões TCP das portas 1024–65535 com o endereço IP do banco de dados MySQL externo. Para obter mais informações sobre network ACLs da Amazon VPC, consulte [Network ACLs​](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html) no *Guia do usuário da Amazon VPC*. 1. Certifique-se de que o período de retenção de backup seja definido o tempo suficiente para que nenhum log binário seja removido durante a exportação. Se algum dos logs for limpo antes da conclusão da exportação, será necessário reiniciar a replicação desde o início. Para obter mais informações sobre como configurar o período de retenção de backup, consulte [Introdução aos backups](USER_WorkingWithAutomatedBackups.md). 1. Use o procedimento armazenado `mysql.rds_set_configuration` para definir o período de retenção de logs binários pelo tempo suficiente para que os logs binários não sejam limpos durante a exportação. Para obter mais informações, consulte [Acessar logs binários do MySQL](USER_LogAccess.MySQL.Binarylog.md). 1. Crie uma réplica de leitura do Amazon RDS na instância de banco de dados MySQL de origem como uma garantia adicional de que os logs binários da instância de banco de dados MySQL de origem não sejam limpos. Para obter mais informações, consulte [Como criar uma réplica de leitura](USER_ReadRepl.Create.md). 1. Depois que a réplica de leitura do Amazon RDS tiver sido criada, chame o procedimento armazenado `mysql.rds_stop_replication` para interromper o processo de replicação. A instância de banco de dados MySQL de origem não limpa mais seus arquivos de log binários, portanto, eles estão disponíveis para o processo de replicação. 1. (Opcional) Configure os parâmetros `max_allowed_packet` e `slave_max_allowed_packet` com o tamanho máximo, para evitar erros de replicação. O tamanho máximo de ambos os parâmetros é de 1 GB. Recomendamos essa configuração para ambos os parâmetros. Para obter informações sobre como configurar parâmetros, consulte [Modificar parâmetros em um grupo de parâmetros de banco de dados no Amazon RDS](USER_WorkingWithParamGroups.Modifying.md). ## Copiar o banco de dados Execute as etapas a seguir para copiar o banco de dados. **Como copiar o banco de dados** 1. Conecte-se à réplica de leitura do RDS da instância de banco de dados MySQL de origem e execute a instrução `SHOW REPLICA STATUS\G` do MySQL. Anote os seguintes valores: + `Master_Host` + `Master_Port` + `Master_Log_File` + `Exec_Master_Log_Pos` **nota** As versões anteriores do MySQL usavam `SHOW SLAVE STATUS` em vez de `SHOW REPLICA STATUS`. Se você estiver usando uma versão do MySQL anterior à 8.0.23, use `SHOW SLAVE STATUS`. 1. Use o utilitário mysqldump para criar um snapshot, que copia os dados do Amazon RDS para seu computador cliente local. Verifique se o computador cliente tem espaço suficiente para armazenar os arquivos `mysqldump` dos bancos de dados a serem replicados. Esse processo pode levar várias horas para bancos de dados muito grandes. Siga as instruções em [Creating a Data Snapshot Using mysqldump](https://dev.mysql.com/doc/mysql-replication-excerpt/8.0/en/replication-howto-mysqldump.html) na documentação do MySQL. O exemplo a seguir executa `mysqldump` em um cliente e grava o despejo em um arquivo. Para Linux, macOS ou Unix: ``` mysqldump -h source_MySQL_DB_instance_endpoint \ -u user \ -ppassword \ --port=3306 \ --single-transaction \ --routines \ --triggers \ --databases database database2 > path/rds-dump.sql ``` Para Windows: ``` mysqldump -h source_MySQL_DB_instance_endpoint ^ -u user ^ -ppassword ^ --port=3306 ^ --single-transaction ^ --routines ^ --triggers ^ --databases database database2 > path\rds-dump.sql ``` Você pode carregar o arquivo de backup no banco de dados MySQL externo. Para obter mais informações, consulte [ Reloading SQL-Format Backups](https://dev.mysql.com/doc/refman/8.0/en/reloading-sql-format-dumps.html) (Recarregar backups do formato SQL) na documentação do MySQL. É possível executar outro utilitário para carregar os dados no banco de dados MySQL externo. ## Concluir a exportação Execute as etapas a seguir para concluir a exportação. **Como concluir a exportação** 1. Use a instrução `CHANGE MASTER` do MySQL para configurar o banco de dados MySQL externo. Especifique o ID e a senha das permissões `REPLICATION SLAVE` concedidas pelo usuário. Especifique os valores `Master_Host`, `Master_Port`, `Relay_Master_Log_File` e `Exec_Master_Log_Pos` obtidos da instrução `SHOW REPLICA STATUS\G` do MySQL executada na réplica de leitura do RDS. Consulte mais informações em [CHANGE MASTER TO Statement](https://dev.mysql.com/doc/refman/8.0/en/change-master-to.html) na documentação do MySQL. **nota** As versões anteriores do MySQL usavam `SHOW SLAVE STATUS` em vez de `SHOW REPLICA STATUS`. Se você estiver usando uma versão do MySQL anterior à 8.0.23, use `SHOW SLAVE STATUS`. 1. Use o comando `START REPLICA` do MySQL para iniciar a replicação da instância de banco de dados MySQL de origem para o banco de dados MySQL externo. Isso inicia a replicação da instância de banco de dados MySQL de origem e exporta todas as alterações de origem que ocorreram após a interrupção da replicação da réplica de leitura do Amazon RDS. **nota** As versões anteriores do MySQL usavam `START SLAVE` em vez de `START REPLICA`. Se você estiver usando uma versão do MySQL anterior à 8.0.23, use `START SLAVE`. 1. Execute o comando `SHOW REPLICA STATUS\G` do MySQL no banco de dados MySQL externo para verificar se ele está operando como uma réplica de leitura. Para ter mais informações sobre como interpretar os resultados, consulte [SHOW SLAVE \$1 REPLICA STATUS Statement](https://dev.mysql.com/doc/refman/8.0/en/show-slave-status.html) na documentação do MySQL. 1. Após a replicação no banco de dados MySQL externo estar sincronizada com a instância de banco de dados MySQL de origem, use o comando `STOP REPLICA` do MySQL para interromper a replicação da instância de banco de dados MySQL de origem. **nota** As versões anteriores do MySQL usavam `STOP SLAVE` em vez de `STOP REPLICA`. Se você estiver usando uma versão do MySQL anterior à 8.0.23, use `STOP SLAVE`. 1. Na réplica de leitura do Amazon RDS, chame o procedimento armazenado `mysql.rds_start_replication`. Isso permite que o Amazon RDS comece a limpar os arquivos de log binários da instância de banco de dados MySQL de origem. # Opções para instâncias de bancos de dados MySQL A seguir, você encontrará uma descrição das opções, ou recursos adicionais, que estão disponíveis para instâncias do Amazon RDS que executam o mecanismo de banco de dados do MySQL. Para habilitar essas opções, você pode adicioná-las a um grupo de opções personalizado e, em seguida, associe o grupo de opções à sua instância de banco de dados. Para mais informações sobre como trabalhar com grupos de opções, consulte [Trabalhar com grupos de opções](USER_WorkingWithOptionGroups.md). O Amazon RDS oferece suporte às seguintes opções do MySQL: **** | Opção | ID da opção | Versões do mecanismo | | --- | --- | --- | | [Suporte ao plug-in de auditoria do MariaDB para MySQL](Appendix.MySQL.Options.AuditPlugin.md) | `MARIADB_AUDIT_PLUGIN` | Todas as versões do MySQL 8.4MySQL 8.0.28 e versões 8.0 posterioresTodas as versões do MySQL 5.7 | | [Suporte a memcached MySQL](Appendix.MySQL.Options.memcached.md) | `MEMCACHED` | Todas as versões do MySQL 5.7 e 8.0 | # Suporte ao plug-in de auditoria do MariaDB para MySQL O Amazon RDS oferece um plug-in de auditoria para instâncias de banco de dados MySQL que se baseia no plug-in de auditoria de código aberto do MariaDB. Para obter mais informações, consulte o [ Plugin de auditoria para o repositório do GitHub do MySQL Server](https://github.com/aws/audit-plugin-for-mysql). **nota** O plug-in de auditoria para MySQL é baseado no plug-in de auditoria do MariaDB. Ao longo deste artigo, nos referimos a ele como plug-in de auditoria do MariaDB. O plug-in de auditoria do MariaDB registra a atividade do banco de dados, incluindo usuários que fazem login no banco de dados e as consultas ao banco de dados que são executadas. O registro da atividade do banco de dados é armazenado em um arquivo de log. ## Definições de opções do plugin de auditoria O Amazon RDS oferece suporte para as seguintes configurações para a opção MariaDB Audit Plugin. | Configuração da opção | Valores válidos | Valor padrão | Descrição | | --- | --- | --- | --- | | `SERVER_AUDIT_FILE_PATH` | `/rdsdbdata/log/audit/` | `/rdsdbdata/log/audit/` | A localização dos arquivos de log. O arquivo de log contém o registro de atividades especificadas em `SERVER_AUDIT_EVENTS`. Para obter mais informações, consulte [Como visualizar e listar arquivos de log do banco de dados](USER_LogAccess.Procedural.Viewing.md) e [Arquivos de log do banco de dados MySQL](USER_LogAccess.Concepts.MySQL.md). | | `SERVER_AUDIT_FILE_ROTATE_SIZE` | 1–1000000000 | 1000000 | O tamanho em bytes que, quando alcançado, faz com que o arquivo rotacione. Para obter mais informações, consulte [Visão geral dos logs de banco de dados do RDS para MySQL](USER_LogAccess.MySQL.LogFileSize.md). | | `SERVER_AUDIT_FILE_ROTATIONS` | 0–100 | 9 | O número de rotações de log para salvar quando `server_audit_output_type=file`. Se definido como 0, o arquivo de log nunca é alternado. Para obter mais informações, consulte [Visão geral dos logs de banco de dados do RDS para MySQL](USER_LogAccess.MySQL.LogFileSize.md) e [Como baixar um arquivo de log de banco de dados](USER_LogAccess.Procedural.Downloading.md). | | `SERVER_AUDIT_EVENTS` | `CONNECT`, `QUERY`, `QUERY_DDL`, `QUERY_DML`, `QUERY_DML_NO_SELECT`, `QUERY_DCL` | `CONNECT`, `QUERY` | Os tipos de atividades a serem gravados no log. A instalação do MariaDB Audit Plugin é registrada em log. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/UserGuide/Appendix.MySQL.Options.AuditPlugin.html) Para MySQL, `TABLE` não é compatível. | | `SERVER_AUDIT_INCL_USERS` | Vários valores separados por vírgulas | Nenhum | Inclua apenas atividades dos usuários especificados. Por padrão, a atividade é registrada para todos os usuários. `SERVER_AUDIT_INCL_USERS` e `SERVER_AUDIT_EXCL_USERS` são mutuamente exclusivos. Se você adicionar valores ao `SERVER_AUDIT_INCL_USERS`, certifique-se de que nenhum valor seja adicionado ao `SERVER_AUDIT_EXCL_USERS`. | | `SERVER_AUDIT_EXCL_USERS` | Vários valores separados por vírgulas | Nenhum | Exclua a atividade dos usuários especificados. Por padrão, a atividade é registrada para todos os usuários. `SERVER_AUDIT_INCL_USERS` e `SERVER_AUDIT_EXCL_USERS` são mutuamente exclusivos. Se você adicionar valores ao `SERVER_AUDIT_EXCL_USERS`, certifique-se de que nenhum valor seja adicionado ao `SERVER_AUDIT_INCL_USERS`. O usuário `rdsadmin` consulta o banco de dados a cada segundo para verificar a integridade do banco de dados. Dependendo das suas outras configurações, essa atividade pode fazer com que o tamanho do seu arquivo de log cresça muito rapidamente. Se você não precisa registrar essa atividade, adicione o usuário `rdsadmin` à lista `SERVER_AUDIT_EXCL_USERS`. `CONNECT`A atividade é sempre registrada para todos os usuários, mesmo se o usuário é especificado para essa configuração de opção. | | `SERVER_AUDIT_LOGGING` | `ON` | `ON` | O registro em log está ativo. O único valor válido é `ON`. O Amazon RDS não oferece suporte à desativação do registro em log. Se quiser desativar o registro log, remova o MariaDB Audit Plugin. Para obter mais informações, consulte [Remover o MariaDB Audit Plugin](#Appendix.MySQL.Options.AuditPlugin.Remove). | | `SERVER_AUDIT_QUERY_LOG_LIMIT` | 0–2147483647 | 1024 | O limite do tamanho da string de consulta em um registro. | ## Adicionar o MariaDB Audit Plugin O processo geral para adicionar o MariaDB Audit Plugin a uma instância de banco de dados é o seguinte: + Crie um novo grupo de opções, ou copie ou modifique um existente + Adicione opções ao grupo de opções + Associe o grupo de opções à instância de banco de dados Depois de adicionar o MariaDB Audit Plugin, você não precisará reiniciar sua instância de banco de dados. Assim que o grupo de opções estiver ativo, a auditoria começará imediatamente. **Importante** Adicionar o plugin de auditoria do MariaDB a uma instância de banco de dados ode causar uma interrupção. Recomendamos adicionar o plugin de auditoria do MariaDB durante uma janela de manutenção ou durante um horário de baixa workload de banco de dados. **Para adicionar o MariaDB Audit Plugin** 1. Determine o grupo de opções que você deseja usar. Você pode criar um novo grupo de opções ou usar um existente. Se você quiser usar um grupo de opções existente, vá para a próxima etapa. Caso contrário, crie um grupo de opções de banco de dados personalizado. Selecione **mysql** em **Mecanismo** e escolha **5.7**, **8.0** ou **8.4** em **Versão principal do mecanismo**. Para obter mais informações, consulte [Criar um grupo de opções](USER_WorkingWithOptionGroups.md#USER_WorkingWithOptionGroups.Create). 1. Adicione a opção **MARIADB\$1AUDIT\$1PLUGIN** ao grupo de opções e defina as configurações da opção. Para ter mais informações sobre a adição de opções, consulte [Adicionar uma opção a um grupo de opções](USER_WorkingWithOptionGroups.md#USER_WorkingWithOptionGroups.AddOption). Para ter mais informações sobre cada configuração, consulte [Definições de opções do plugin de auditoria](#Appendix.MySQL.Options.AuditPlugin.Options). 1. Aplique o grupo de opções a uma instância de banco de dados nova ou existente. + Para uma nova instância de banco de dados, você aplica o grupo de opções ao executar a instância. Para ter mais informações, consulte [Criar uma instância de banco de dados do Amazon RDS](USER_CreateDBInstance.md). + Para uma instância de banco de dados existente, você aplica o grupo de opções modificando a instância e anexando o novo grupo de opções. Para obter mais informações, consulte [Modificar uma instância de banco de dados do Amazon RDS](Overview.DBInstance.Modifying.md). ## Formato do log de auditoria Os arquivos de log são representados como arquivos de variáveis separadas por vírgula (CSV) no formato UTF-8. **dica** As entradas do log não estão em ordem sequencial. Para ordenar as entradas, use o valor do carimbo de data/hora. Para ver os eventos mais recentes, talvez seja preciso analisar todos os arquivos de log. Para obter mais flexibilidade na classificação e pesquisa dos dados de log, ative a configuração para carregar os logs de auditoria no CloudWatch e visualizá-los usando a interface do CloudWatch. Para visualizar dados de auditoria com mais tipos de campos e com saída no formato JSON, você também pode usar o recurso Database Activity Streams. Para obter mais informações, consulte [Monitorar o Amazon RDS com o recurso Database Activity Streams](DBActivityStreams.md). Os arquivos de log de auditoria incluem as seguintes informações delimitadas por vírgulas nas linhas, na ordem especificada: | Campo | Descrição | | --- | --- | | timestamp | O `YYYYMMDD` seguido pelo `HH:MI:SS` (24 horas) para o evento registrado em log. | | serverhost | O nome da instância em que o evento foi registrado. | | username | O nome de usuário conectado. | | host | O host no qual o usuário está conectado. | | connectionid | O número de ID da conexão para a operação registrada. | | queryid | O número do ID de consulta, que pode ser usado para encontrar os eventos relacionais da tabela e consultas relacionadas. Para eventos `TABLE`, são adicionadas várias linhas. | | operação | O tipo de ação gravado. Os valores possíveis são: `CONNECT`, `QUERY`, `READ`, `WRITE`, `CREATE`, `ALTER`, `RENAME` e `DROP`. | | banco de dados | O banco de dados ativo, conforme definido pelo comando `USE`. | | objeto | Para eventos de `QUERY`, esse valor indica a consulta executada pelo banco de dados. Para eventos de `TABLE`, indica o nome da tabela. | | retcode | O código de retorno da operação registrada. | | connection\$1type | O estado de segurança da conexão com o servidor. Os valores possíveis são: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/UserGuide/Appendix.MySQL.Options.AuditPlugin.html) | ## Visualizar e baixar o log do plugin de auditoria do MariaDB Depois de habilitar o MariaDB Audit Plugin, você acessará os resultados nos arquivos de log da mesma forma que você acessa outros arquivos de log baseados em texto. Os arquivos de log de auditoria estão localizados em `/rdsdbdata/log/audit/`. Para obter informações sobre como visualizar o arquivo de log no console, consulte [Como visualizar e listar arquivos de log do banco de dados](USER_LogAccess.Procedural.Viewing.md). Para obter informações sobre como baixar o arquivo de log, consulte [Como baixar um arquivo de log de banco de dados](USER_LogAccess.Procedural.Downloading.md). ## Modificar as configurações do plugin de auditoria do MariaDB Depois de habilitar o MariaDB Audit Plugin, você pode modificar as configurações. Para mais informações sobre como modificar as configurações da opção, consulte [Modificar uma configuração de opção](USER_WorkingWithOptionGroups.md#USER_WorkingWithOptionGroups.ModifyOption). Para ter mais informações sobre cada configuração, consulte [Definições de opções do plugin de auditoria](#Appendix.MySQL.Options.AuditPlugin.Options). ## Remover o MariaDB Audit Plugin O Amazon RDS não oferece suporte à desativação do registro em log no MariaDB Audit Plugin. No entanto, você pode remover o plugin de uma instância de banco de dados. Quando você remove o MariaDB Audit Plugin, a instância de banco de dados é reiniciada automaticamente para interromper a auditoria. Para remover o MariaDB Audit Plugin de uma instância de banco de dados, siga um destes procedimentos: + Remova a opção MariaDB Audit Plugin do grupo de opções ao qual ela pertence. Essa alteração afeta todas as instâncias de bancos de dados que usam o grupo de opções. Para ter mais informações, consulte [Remover uma opção de um grupo de opções](USER_WorkingWithOptionGroups.md#USER_WorkingWithOptionGroups.RemoveOption) + Modifique a instância de banco de dados e especifique um grupo de opções diferente que não inclua o plugin. Essa alteração afeta uma única instância de banco de dados. Você pode especificar um grupo de opções padrão (vazio) ou criar um grupo de opções personalizado diferente. Para ter mais informações, consulte [Modificar uma instância de banco de dados do Amazon RDS](Overview.DBInstance.Modifying.md). # Suporte a memcached MySQL O Amazon RDS oferece suporte ao uso da interface `memcached` para tabelas do InnoDB introduzido no MySQL 5.6. A API `memcached` permite que os aplicativos usem as tabelas do InnoDB de forma semelhante aos armazenamentos de dados de chave/valor NoSQL. **nota** A interface do memcached não está mais disponível no MySQL 8.4. Ao atualizar suas instâncias de banco de dados para o MySQL 8.4, você deve desativar `memcached` nos grupos de opções existentes. A interface `memcached` é um cache simples baseado em chave. Os aplicativos usam `memcached` para inserir, manipular e recuperar pares de dados de valor/chave do cache. O MySQL 5.6 introduziu um plugin que implementa um serviço de daemon que expõe os dados das tabelas do InnoDB através do protocolo `memcached`. Para ter mais informações sobre o plug-in `memcached` MySQL, consulte [Integração do InnoDB com memcached](https://dev.mysql.com/doc/refman/8.0/en/innodb-memcached.html). **Como habilitar o suporte a memcached para uma instância de banco de dados do RDS para MySQL** 1. Determine o grupo de segurança a ser usado para controlar o acesso à interface de `memcached`. Se o conjunto de aplicações que já estão usando a interface SQL for o mesmo conjunto que acessará a interface `memcached`, você poderá usar o grupo de segurança de VPC existente usado pela interface SQL. Se um conjunto diferente de aplicativos acessar a interface `memcached`, defina um novo grupo de segurança de VPC ou grupo de segurança de banco de dados. Para ter mais informações sobre como gerenciar grupo de seguranças, consulte [Controlar acesso com grupos de segurança](Overview.RDSSecurityGroups.md) 1. Crie um grupo de opções de banco de dados personalizado, selecionando MySQL como o tipo e a versão do mecanismo. Para ter mais informações sobre como criar um grupo de opções, consulte [Criar um grupo de opções](USER_WorkingWithOptionGroups.md#USER_WorkingWithOptionGroups.Create). 1. Adicione a opção `MEMCACHED` ao grupo de opções. Especifique a porta que a interface `memcached` usará e o grupo de segurança a ser usado para controlar o acesso à interface. Para mais informações sobre a adição de opções, consulte [Adicionar uma opção a um grupo de opções](USER_WorkingWithOptionGroups.md#USER_WorkingWithOptionGroups.AddOption). 1. Modifique as configurações de opções para configurar os parâmetros `memcached`, se necessário. Para mais informações sobre como modificar as configurações da opção, consulte [Modificar uma configuração de opção](USER_WorkingWithOptionGroups.md#USER_WorkingWithOptionGroups.ModifyOption). 1. Aplique o grupo de opções a uma instância. O Amazon RDS habilita o suporte ao `memcached` para essa instância quando o grupo de opções for aplicado: + Você habilita o suporte de `memcached` para uma nova instância especificando o grupo de opções personalizado ao executar a instância. Para ter mais informações sobre como executar uma instância MySQL, consulte [Criar uma instância de banco de dados do Amazon RDS](USER_CreateDBInstance.md). + Você habilita o suporte de `memcached` para uma instância existente especificando o grupo de opções personalizado ao modificar a instância. Para ter mais informações sobre a modificação de uma instância de banco de dados , consulte [Modificar uma instância de banco de dados do Amazon RDS](Overview.DBInstance.Modifying.md). 1. Especifique quais colunas em suas tabelas MySQL podem ser acessadas por meio da interface de `memcached`. O plug-in `memcached` cria uma tabela de catálogo chamada `containers` em um banco de dados dedicado chamado `innodb_memcache`. Você insere uma linha na tabela `containers` para mapear uma tabela do InnoDB para acesso via `memcached`. Você especifica uma coluna na tabela do InnoDB que é usada para armazenar os valores das chaves do `memcached` e uma ou mais colunas que são usadas para armazenar os valores de dados associados à chave. Você também especifica um nome que um aplicativo `memcached` usa para se referir a esse conjunto de colunas. Para obter detalhes sobre como inserir linhas na tabela `containers`, consulte [Elementos internos do plug-in memcached do InnoDB](https://dev.mysql.com/doc/refman/8.0/en/innodb-memcached-internals.html). Para obter um exemplo de mapeamento de uma tabela do InnoDB e acessá-la por meio de `memcached`, consulte [Writing applications for the InnoDB memcached plugin](https://dev.mysql.com/doc/refman/8.0/en/innodb-memcached-developing.html). 1. Se as aplicações que acessarem a interface `memcached` estiverem em computadores ou instâncias do EC2 diferentes das aplicações que usam a interface SQL, adicione as informações de conexão desses computadores ao grupo de segurança de VPC associado à instância MySQL. Para ter mais informações sobre como gerenciar grupo de seguranças, consulte [Controlar acesso com grupos de segurança](Overview.RDSSecurityGroups.md). Você desliga o suporte `memcached` para uma instância modificando essa instância e especificando o grupo de opções padrão para sua versão do MySQL. Para ter mais informações sobre a modificação de uma instância de banco de dados , consulte [Modificar uma instância de banco de dados do Amazon RDS](Overview.DBInstance.Modifying.md). ## Considerações sobre segurança do MySQL memcached O protocolo `memcached` não oferece suporte para a autenticação do usuário. Para ter mais informações sobre as considerações de segurança do MySQL `memcached`, consulte [Considerações de segurança para o plug-in memcached do InnoDB](https://dev.mysql.com/doc/refman/8.0/en/innodb-memcached-security.html) na documentação do MySQL. Você pode realizar as seguintes ações para ajudar a aumentar a segurança da interface `memcached`: + Especifique uma porta diferente do padrão de 11211 ao adicionar a opção `MEMCACHED` ao grupo de opções. + Certifique-se de associar a interface `memcached` com um grupo de segurança de VPC que limite o acesso a endereços de clientes conhecidos ou confiáveis e a instâncias do EC2. Para ter mais informações sobre como gerenciar grupo de seguranças, consulte [Controlar acesso com grupos de segurança](Overview.RDSSecurityGroups.md). ## Informações sobre conexão com MySQL memcached Para acessar a interface `memcached`, um aplicativo deve especificar o nome DNS da instância do Amazon RDS e o número da porta `memcached`. Por exemplo, se uma instância tiver um nome DNS `my-cache-instance.cg034hpkmmjt.region.rds.amazonaws.com` e a interface memcached estiver usando a porta 11212, as informações de conexão especificadas no PHP serão: ``` 1. connect('my-cache-instance.cg034hpkmmjt.region.rds.amazonaws.com',11212); 5. ?> ``` **Para encontrar o nome DNS e a porta memcached de uma instância do MySQL** 1. Faça login no Console de gerenciamento da AWS e abra o console do Amazon RDS em [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/). 1. No canto superior direito do Console de gerenciamento da AWS, selecione a região que contém a instância de banco de dados. 1. No painel de navegação, escolha **Databases (Bancos de dados)**. 1. Escolha o nome da instância de banco de dados MySQL para exibir os detalhes. 1. Na seção **Connect (Conectar)**, anote o valor do campo **Endpoint**. O nome do DNS é o mesmo que o do endpoint. Além disso, observe que a porta na seção **Connect (Conectar)** não é usada para acessar a interface `memcached`. 1. Na seção **Details (Detalhes)**, anote o nome listado no campo **Option Group (Grupo de opções)**. 1. No painel de navegação, escolha **Option groups (Grupos de opções)**. 1. Escolha o nome do grupo de opções usado pela instância de banco de dados MySQL para mostrar os detalhes do grupo de opções. Na seção **Options (Opções)**, anote o valor da configuração de **Port (Porta)** na opção **MEMCACHED**. ## Configurações de opções de MySQL memcached O Amazon RDS expõe os parâmetros `memcached` do MySQL como configurações de opções na opção `MEMCACHED` do Amazon RDS. ### Parâmetros de MySQL memcached + `DAEMON_MEMCACHED_R_BATCH_SIZE` – um inteiro que especifica quantas operações de leitura `memcached` devem ser realizadas antes de fazer um COMMIT para iniciar uma nova transação. Os valores permitidos são de 1 a 4294967295; o padrão é 1. A opção não terá efeito até que a instância seja reiniciada. + `DAEMON_MEMCACHED_W_BATCH_SIZE` – um inteiro que especifica quantas operações de gravação `memcached`, como adicionar, definir ou aumentar, devem ser realizadas antes de fazer um COMMIT para iniciar uma nova transação. Os valores permitidos são de 1 a 4294967295; o padrão é 1. A opção não terá efeito até que a instância seja reiniciada. + `INNODB_API_BK_COMMIT_INTERVAL` – um inteiro que especifica com que frequência as conexões inativas de confirmação automática usam a interface `memcached` do InnoDB. Os valores permitidos são de 1 a 1073741824; o padrão é 5. A opção entra em vigor imediatamente, sem exigir que você reinicie a instância. + `INNODB_API_DISABLE_ROWLOCK` – um booliano que desabilita (1 (true)) ou habilita (0 (false)) o uso de bloqueios de linha ao usar a interface `memcached` do InnoDB. O padrão é 0 (false). A opção não terá efeito até que a instância seja reiniciada. + `INNODB_API_ENABLE_MDL` – um booliano que, quando definido como 0 (false), bloqueia a tabela usada pelo plug-in `memcached` do InnoDB, de modo que ela não possa ser descartada ou alterado pela DDL por meio da interface SQL. O padrão é 0 (false). A opção não terá efeito até que a instância seja reiniciada. + `INNODB_API_TRX_LEVEL` – um número inteiro que especifica o nível de isolamento da transação para consultas processadas pela interface `memcached`. Os valores permitidos são de 0 a 3. O padrão é 0. A opção não terá efeito até que a instância seja reiniciada. O Amazon RDS configura esses parâmetros `memcached` MySQL, e eles não podem ser modificados: `DAEMON_MEMCACHED_LIB_NAME`, `DAEMON_MEMCACHED_LIB_PATH` e `INNODB_API_ENABLE_BINLOG`. Os parâmetros que os administradores MySQL definem usando `daemon_memcached_options` estão disponíveis como configurações da opção `MEMCACHED` individuais no Amazon RDS. ### Parâmetros daemon\$1memcached\$1options MySQL + `BINDING_PROTOCOL` – uma string que especifica o protocolo de associação a ser usado. Os valores permitidos são `auto`, `ascii` ou `binary`. O padrão é `auto`, o que significa que o servidor negocia automaticamente o protocolo com o cliente. A opção não terá efeito até que a instância seja reiniciada. + `BACKLOG_QUEUE_LIMIT` – um número inteiro que especifica quantas conexões de rede podem estar aguardando para serem processadas por `memcached`. Aumentar esse limite pode reduzir os erros recebidos por um cliente que não seja capaz de se conectar à instância `memcached`, mas não melhora a performance do servidor. Os valores permitidos são de 1 a 2048; o padrão é 1024. A opção não terá efeito até que a instância seja reiniciada. + `CAS_DISABLED` – um booliano que permite (1 (true)) ou desabilite (0 (false)) o uso do recurso de comparação e permuta (CAS), o que reduz o tamanho por item em 8 bytes. O padrão é 0 (false). A opção não terá efeito até que a instância seja reiniciada. + `CHUNK_SIZE` – um número inteiro que especifica o tamanho mínimo do bloco, em bytes, para alocar a chave, o valor e os sinalizadores do menor item. Os valores permitidos são de 1 a 48. O padrão é 48 e você pode melhorar significativamente a eficiência da memória com um valor menor. A opção não terá efeito até que a instância seja reiniciada. + `CHUNK_SIZE_GROWTH_FACTOR` – um flutuante que controla o tamanho de novos blocos. O tamanho de um novo bloco é o tamanho do bloco anterior vezes `CHUNK_SIZE_GROWTH_FACTOR`. Os valores permitidos são de 1 a 2; o padrão é 1.25. A opção não terá efeito até que a instância seja reiniciada. + `ERROR_ON_MEMORY_EXHAUSTED` – um booliano, quando definido como 1 (true), especifica que `memcached` retornará um erro ao invés de despejar itens quando não houver mais memória para armazenar itens. Se definido como 0 (false), `memcached` expulsará itens se não houver mais memória. O padrão é 0 (false). A opção não terá efeito até que a instância seja reiniciada. + `MAX_SIMULTANEOUS_CONNECTIONS` – um inteiro que especifica o número máximo de conexões simultâneas. Definir esse valor como qualquer coisa abaixo de 10 impede que o MySQL seja iniciado. Os valores permitidos são de 10 a 1024; o padrão é 1024. A opção não terá efeito até que a instância seja reiniciada. + `VERBOSITY` – uma string que especifica o nível de informações registradas no log de erros do MySQL pelo serviço `memcached`. O padrão é v. A opção não terá efeito até que a instância seja reiniciada. Os valores permitidos são: + `v` – registra erros e avisos durante a execução do loop de eventos principal. + `vv` – Além das informações registradas por v, também registra cada comando do cliente e a resposta. + `vvv` – Além das informações registradas por vv, também registra transições de estado internas. O Amazon RDS configura esses parâmetros `DAEMON_MEMCACHED_OPTIONS` MySQL, eles não podem ser modificados: `DAEMON_PROCESS`, `LARGE_MEMORY_PAGES`, `MAXIMUM_CORE_FILE_LIMIT`, `MAX_ITEM_SIZE`, `LOCK_DOWN_PAGE_MEMORY`, `MASK`, `IDFILE`, `REQUESTS_PER_EVENT`, `SOCKET` e `USER`. # Parâmetros do MySQL Por padrão, uma instância de banco de dados MySQL usa um grupo de parâmetros de banco de dados específico para um banco de dados MySQL. Esse grupo de parâmetros contém parâmetros para o mecanismo de banco de dados MySQL. Para obter informações sobre como trabalhar com grupos de parâmetros e definir parâmetros, consulte [Grupos de parâmetros para Amazon RDS](USER_WorkingWithParamGroups.md). Os parâmetros do RDS for MySQL são definidos com os valores padrão do mecanismo de armazenamento que você selecionou. Para obter mais informações sobre os parâmetros do MySQL, consulte a [documentação do MySQL](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html). Para obter mais informações sobre os mecanismos de armazenamento do MySQL, consulte [Suporte aos mecanismos de armazenamento no RDS para MySQL](MySQL.Concepts.FeatureSupport.md#MySQL.Concepts.Storage). Você pode exibir os parâmetros disponíveis para uma versão específica do RDS for MySQL usando o console do RDS ou a AWS CLI. Para obter informações sobre como visualizar os parâmetros em um grupo de parâmetros do MySQL no console do RDS, consulte [Visualizar valores de parâmetros para um grupo de parâmetros de banco de dados no Amazon RDS](USER_WorkingWithParamGroups.Viewing.md). Usando a AWS CLI, você pode visualizar os parâmetros de uma versão do RDS for MySQL executando o comando [https://docs.aws.amazon.com/cli/latest/reference/rds/describe-engine-default-parameters.html](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-engine-default-parameters.html). Especifique um destes valores a seguir para a opção `--db-parameter-group-family`: + `mysql8.4` + `mysql8.0` + `mysql5.7` Por exemplo, para visualizar parâmetros do RDS for MySQL, versão 8.0, execute o comando a seguir. ``` aws rds describe-engine-default-parameters --db-parameter-group-family mysql8.0 ``` O resultado será semelhante ao mostrado a seguir. ``` { "EngineDefaults": { "Parameters": [ { "ParameterName": "activate_all_roles_on_login", "ParameterValue": "0", "Description": "Automatically set all granted roles as active after the user has authenticated successfully.", "Source": "engine-default", "ApplyType": "dynamic", "DataType": "boolean", "AllowedValues": "0,1", "IsModifiable": true }, { "ParameterName": "allow-suspicious-udfs", "Description": "Controls whether user-defined functions that have only an xxx symbol for the main function can be loaded", "Source": "engine-default", "ApplyType": "static", "DataType": "boolean", "AllowedValues": "0,1", "IsModifiable": false }, { "ParameterName": "auto_generate_certs", "Description": "Controls whether the server autogenerates SSL key and certificate files in the data directory, if they do not already exist.", "Source": "engine-default", "ApplyType": "static", "DataType": "boolean", "AllowedValues": "0,1", "IsModifiable": false }, ... ``` Para listar somente os parâmetros modificáveis do RDS for MySQL versão 8.0, execute o comando a seguir. Para Linux, macOS ou Unix: ``` aws rds describe-engine-default-parameters --db-parameter-group-family mysql8.0 \ --query 'EngineDefaults.Parameters[?IsModifiable==`true`]' ``` Para Windows: ``` aws rds describe-engine-default-parameters --db-parameter-group-family mysql8.0 ^ --query "EngineDefaults.Parameters[?IsModifiable==`true`]" ``` # Tarefas comuns de DBA para instâncias de banco de dados MySQL No conteúdo a seguir, é possível encontrar descrições das implementações específicas do Amazon RDS de algumas tarefas de DBA comuns para instâncias de banco de dados que executam o mecanismo de banco de dados MySQL. Para oferecer uma experiência de serviço gerenciada, o Amazon RDS não fornece acesso ao shell para as instâncias de banco de dados. Ele também restringe o acesso a determinados procedimentos e tabelas do sistema que exigem privilégios avançados. Para obter informações sobre como trabalhar com arquivos de log do MySQL no Amazon RDS, consult [Arquivos de log do banco de dados MySQL](USER_LogAccess.Concepts.MySQL.md). ## Noções básicas sobre usuários predefinidos O Amazon RDS cria automaticamente vários usuários predefinidos com novas instâncias de banco de dados do RDS para MySQL. Os usuários predefinidos e seus privilégios não podem ser alterados. Não é possível descartar, renomear ou modificar os privilégios desses usuários predefinidos. Qualquer tentativa de fazer isso gerará um erro. + **rdsadmin**: um usuário criado para lidar com muitas das tarefas de gerenciamento que o administrador com privilégios de `superuser` executaria em um banco de dados MySQL autônomo. Esse usuário é usado internamente pelo RDS para MySQL para várias tarefas de gerenciamento. + **rdsrepladmin**: um usuário usado internamente pelo Amazon RDS para oferecer suporte a atividades de replicação no RDS para instâncias e clusters de banco de dados do MySQL. Consulte informações sobre outras tarefas de comuns de DBA nos tópicos a seguir. **Topics** + [ ## Noções básicas sobre usuários predefinidos ](#Appendix.MySQL.CommonDBATasks.users) + [ # Modelo de privilégios baseados em perfis para o RDS para MySQL ](Appendix.MySQL.CommonDBATasks.privilege-model.md) + [ # Privilégios dinâmicos para o RDS para MySQL ](Appendix.MySQL.CommonDBATasks.dynamic-privileges.md) + [ # Encerrar uma sessão ou consulta do RDS para MySQL ](Appendix.MySQL.CommonDBATasks.End.md) + [ # Ignorar o erro de replicação atual para o RDS para MySQL ](Appendix.MySQL.CommonDBATasks.SkipError.md) + [ # Trabalhar com espaços de tabela do InnoDB para melhorar o tempo de recuperação de falhas do RDS para MySQL ](Appendix.MySQL.CommonDBATasks.Tables.md) + [ # Gerenciar o histórico de status global do RDS para MySQL ](Appendix.MySQL.CommonDBATasks.GoSH.md) + [ # Configuração do tamanho do pool de buffer e a capacidade de log redo no MySQL 8.4 ](Appendix.MySQL.CommonDBATasks.Config.Size.8.4.md) # Modelo de privilégios baseados em perfis para o RDS para MySQL Iniciando com o RDS para MySQL versão 8.0.36, não é possível modificar as tabelas no banco de dados `mysql` diretamente. Especificamente, não é possível criar usuários de banco de dados executando operações de linguagem de manipulação de dados (DML) nas tabelas `grant`. Em vez disso, use declarações de gerenciamento de contas do MySQL, como `CREATE USER`, `GRANT` e `REVOKE`, para conceder privilégios baseados em perfil aos usuários. 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` na instância de banco de dados 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`. Para exportar metadados para usuários de banco de dados durante a migração de um banco de dados MySQL externo, use um dos seguintes comandos: + Use o utilitário de despejo de instância do MySQL Shell com um filtro para excluir usuários, perfis e concessões. O exemplo a seguir mostra a sintaxe de comando a ser usada. Verifique se `outputUrl` está vazio. ``` mysqlsh user@host -- util.dumpInstance(outputUrl,{excludeSchemas:['mysql'],users: true}) ``` Para ter mais informações, consulte [Instance Dump Utility, Schema Dump Utility, and Table Dump Utility](https://dev.mysql.com/doc/mysql-shell/8.0/en/mysql-shell-utilities-dump-instance-schema.html) no MySQL Reference Manual. + Use o utilitário de cliente `mysqlpump`. Este exemplo inclui todas as tabelas, exceto aquelas no banco de dados do sistema `mysql`. Ela também inclui as instruções `CREATE USER` e `GRANT` para reproduzir todos os usuários do MySQL no banco de dados migrado. ``` mysqlpump --exclude-databases=mysql --users ``` O utilitário cliente `mysqlpump` não está mais disponível no MySQL 8.4. Em seu lugar, use `mysqldump`. 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](https://dev.mysql.com/doc/refman/8.0/en/roles.html), 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. Iniciando com a versão 8.0.36, o RDS para MySQL inclui um perfil especial que tem todos os privilégios a seguir. Essa função se chama `rds_superuser_role`. O usuário administrativo principal de cada instância de banco de dados já tem esse perfil concedido. 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` + `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 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. Especificamente, o administrador deve conceder quaisquer privilégios necessários para executar a replicação de logs binários com o cluster do MySQL como destino. **dica** Para ver os detalhes completos das permissões, use a declaração a seguir. ``` SHOW GRANTS FOR rds_superuser_role@'%'; ``` Ao conceder acesso utilizando perfis no RDS para MySQL versão 8.0.36 e posterior, você também ativa o perfil utilizando a declaração `SET ROLE role_name` ou `SET ROLE ALL`. O exemplo a seguir mostra como. Substitua o nome da função apropriado para `CUSTOM_ROLE`. ``` # Grant role to user mysql> GRANT CUSTOM_ROLE TO 'user'@'domain-or-ip-address' # Check the current roles for your user. In this case, the CUSTOM_ROLE 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() | +--------------------------------------------------+ | `CUSTOM_ROLE`@`%`,`rds_superuser_role`@`%` | +--------------------------------------------------+ ``` # Privilégios dinâmicos para o RDS para MySQL Privilégios dinâmicos são privilégios do MySQL que você pode conceder explicitamente usando a declaração `GRANT`. Dependendo da sua versão do RDS para MySQL, o RDS permite que você conceda somente privilégios dinâmicos específicos. O RDS proíbe alguns desses privilégios porque eles podem interferir nas operações específicas do banco de dados, como replicação e backup. A tabela a seguir mostra quais desses privilégios é possível conceder para diferentes versões do MySQL. Se você estiver atualizando de uma versão do MySQL inferior à 8.0.36 para a versão 8.0.36 ou posterior, talvez seja necessário atualizar o código da aplicação se a concessão de um privilégio específico não for mais permitida. | Privilege | MySQL 8.0.35 e anterior | MySQL 8.0.36 e versões secundárias posteriores | MySQL 8.4.3 e posterior | | --- | --- | --- | --- | | [ALLOW\$1NONEXISTENT\$1DEFINER](https://dev.mysql.com/doc/refman/8.4/en/privileges-provided.html#priv_allow-nonexistent-definer) | Não disponível | Não disponível | Não permitido | | [APPLICATION\$1PASSWORD\$1ADMIN](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_application-password-admin) | Permitido | Permitido | Permitido | | [AUDIT\$1ABORT\$1EXEMPT](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_audit-abort-exempt) | Permitido | Não permitido | Não permitido | | [AUDIT\$1ADMIN](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_audit-admin) | Não permitido | Não permitido | Não permitido | | [AUTHENTICATION\$1POLICY\$1ADMIN](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_authentication-policy-admin) | Permitido | Não permitido | Não permitido | | [BACKUP\$1ADMIN](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_backup-admin) | Permitido | Não permitido | Não permitido | | [BINLOG\$1ADMIN](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_binlog-admin) | Permitido | Não permitido | Não permitido | | [BINLOG\$1ENCRYPTION\$1ADMIN](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_binlog-encryption-admin) | Não permitido | Não permitido | Não permitido | | [CLONE\$1ADMIN](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_clone-admin) | Não permitido | Não permitido | Não permitido | | [CONNECTION\$1ADMIN](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_connection-admin) | Permitido | Não permitido | Não permitido | | [ENCRYPTION\$1KEY\$1ADMIN](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_encryption-key-admin) | Não permitido | Não permitido | Não permitido | | [FIREWALL\$1ADMIN](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_firewall-admin) | Não permitido | Não permitido | Não permitido | | [FIREWALL\$1EXEMPT](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_firewall-exempt) | Permitido | Não permitido | Não permitido | | [FIREWALL\$1USER](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_firewall-user) | Não permitido | Não permitido | Não permitido | | [FLUSH\$1OPTIMIZER\$1COSTS](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_flush-optimizer-costs) | Permitido | Permitido | Permitido | | [FLUSH\$1PRIVILEGES](https://dev.mysql.com/doc/refman/8.4/en/privileges-provided.html#priv_flush-privileges) | Não disponível | Não disponível | Permitido | | [FLUSH\$1STATUS](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_flush-status) | Permitido | Permitido | Permitido | | [FLUSH\$1TABLES](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_flush-tables) | Permitido | Permitido | Permitido | | [FLUSH\$1USER\$1RESOURCES](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_flush-user-resources) | Permitido | Permitido | Permitido | | [GROUP\$1REPLICATION\$1ADMIN](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_group-replication-admin) | Não permitido | Não permitido | Não permitido | | [GROUP\$1REPLICATION\$1STREAM](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_group-replication-stream) | Não permitido | Não permitido | Não permitido | | [INNODB\$1REDO\$1LOG\$1ARCHIVE](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_innodb-redo-log-archive) | Não permitido | Não permitido | Não permitido | | [INNODB\$1REDO\$1LOG\$1ENABLE](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_innodb-redo-log-enable) | Não permitido | Não permitido | Não permitido | | [MASKING\$1DICTIONARIES\$1ADMIN](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_masking-dictionaries-admin) | Não permitido | Não permitido | Não permitido | | [NDB\$1STORED\$1USER](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_ndb-stored-user) | Não permitido | Não permitido | Não permitido | | [OPTIMIZE\$1LOCAL\$1TABLE](https://dev.mysql.com/doc/refman/8.4/en/privileges-provided.html#priv_optimize-local-table) | Não disponível | Não disponível | Não permitido | | [PASSWORDLESS\$1USER\$1ADMIN](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_passwordless-user-admin) | Não permitido | Não permitido | Não permitido | | [PERSIST\$1RO\$1VARIABLES\$1ADMIN](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_persist-ro-variables-admin) | Não permitido | Não permitido | Não permitido | | [REPLICATION\$1APPLIER](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_replication-applier) | Permitido | Não permitido | Não permitido | | [REPLICATION\$1SLAVE\$1ADMIN](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_replication-slave-admin) | Não permitido | Não permitido | Não permitido | | [RESOURCE\$1GROUP\$1ADMIN](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_resource-group-admin) | Permitido | Não permitido | Não permitido | | [RESOURCE\$1GROUP\$1USER](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_resource-group-user) | Permitido | Não permitido | Não permitido | | [ROLE\$1ADMIN](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_role-admin) | Permitido | Permitido | Permitido | | [SENSITIVE\$1VARIABLES\$1OBSERVER](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_sensitive-variables-observer) | Permitido | Permitido | Permitido | | [SERVICE\$1CONNECTION\$1ADMIN](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_service-connection-admin) | Permitido | Não permitido | Não permitido | | [SESSION\$1VARIABLES\$1ADMIN](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_session-variables-admin) | Permitido | Permitido | Permitido | | [SET\$1ANY\$1DEFINER](https://dev.mysql.com/doc/refman/8.4/en/privileges-provided.html#priv_set-any-definer) | Não disponível | Não disponível | Permitido | | [SET\$1USER\$1ID](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_set-user-id) | Permitido | Permitido | Indisponível | | [SHOW\$1ROUTINE](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_show-routine) | Permitido | Permitido | Permitido | | [SKIP\$1QUERY\$1REWRITE](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_skip-query-rewrite) | Não permitido | Não permitido | Não permitido | | [SYSTEM\$1USER](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_system-user) | Não permitido | Não permitido | Não permitido | | [SYSTEM\$1VARIABLES\$1ADMIN](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_system-variables-admin) | Não permitido | Não permitido | Não permitido | | [TABLE\$1ENCRYPTION\$1ADMIN](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_table-encryption-admin) | Não permitido | Não permitido | Não permitido | | [TELEMETRY\$1LOG\$1ADMIN](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_telemetry-log-admin) | Permitido | Não permitido | Não permitido | | [TP\$1CONNECTION\$1ADMIN](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_tp-connection-admin) | Não permitido | Não permitido | Não permitido | | [TRANSACTION\$1GTID\$1TAG](https://dev.mysql.com/doc/refman/8.4/en/privileges-provided.html#priv_transaction-gtid-tag) | Não disponível | Não disponível | Não permitido | | [VERSION\$1TOKEN\$1ADMIN](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_version-token-admin) | Não permitido | Não permitido | Não permitido | | [XA\$1RECOVER\$1ADMIN](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_xa-recover-admin) | Permitido | Permitido | Permitido | # Encerrar uma sessão ou consulta do RDS para MySQL É possível encerrar sessões ou consultas de usuários em instâncias de banco de dados usando os comandos `rds_kill` e `rds_kill_query`. Primeiro, conecte-se à sua instância de banco de dados MySQL. Depois disso, emita o comando apropriado, conforme mostrado a seguir. Para obter mais informações, consulte [Conectar-se à instância de banco de dados do MySQL](USER_ConnectToInstance.md). ``` CALL mysql.rds_kill(thread-ID) CALL mysql.rds_kill_query(thread-ID) ``` Por exemplo, para encerrar a sessão que está sendo executada no thread 99, digite o seguinte: ``` CALL mysql.rds_kill(99); ``` Para encerrar a consulta que está sendo executada no thread 99, digite o seguinte: ``` CALL mysql.rds_kill_query(99); ``` # Ignorar o erro de replicação atual para o RDS para MySQL Você pode ignorar um erro na réplica de leitura se ele estiver fazendo com que a réplica de leitura pare de responder e não afetar a integridade dos dados. **nota** Primeiro, você deve verificar se é possível ignorar o erro com segurança. Em um utilitário do MySQL, conecte-se à réplica de leitura e execute o seguinte comando do MySQL. ``` SHOW REPLICA STATUS\G ``` Para obter informações sobre os valores retornados, consulte [a documentação do MySQL](https://dev.mysql.com/doc/refman/8.0/en/show-replica-status.html). As versões anteriores do MySQL usavam `SHOW SLAVE STATUS` em vez de `SHOW REPLICA STATUS`. Se você estiver usando uma versão do MySQL anterior à 8.0.23, use `SHOW SLAVE STATUS`. É possível ignorar um erro na réplica de leitura das seguintes maneiras. **Topics** + [ ## Chamando o procedimento mysql.rds\$1skip\$1repl\$1error ](#Appendix.MySQL.CommonDBATasks.SkipError.procedure) + [ ## Configurar o parâmetro slave\$1skip\$1errors ](#Appendix.MySQL.CommonDBATasks.SkipError.parameter) ## Chamando o procedimento mysql.rds\$1skip\$1repl\$1error O Amazon RDS fornece um procedimento armazenado que é possível chamar para ignorar um erro nas suas réplicas de leitura. Primeiro, conecte-se à sua réplica de leitura. Depois disso, emita os comandos apropriados, conforme mostrado a seguir. Para obter mais informações, consulte [Conectar-se à instância de banco de dados do MySQL](USER_ConnectToInstance.md). Para ignorar o erro, emita o seguinte comando. ``` CALL mysql.rds_skip_repl_error; ``` Esse comando não terá efeito se você o executar na instância de banco de dados de origem ou em uma réplica de leitura que não apresentou um erro de replicação. Para mais informações, como as versões compatíveis com o MySQL `mysql.rds_skip_repl_error`, veja [mysql.rds\$1skip\$1repl\$1error](mysql-stored-proc-replicating.md#mysql_rds_skip_repl_error). **Importante** Se você tentar chamar `mysql.rds_skip_repl_error` e obter o seguinte erro: `ERROR 1305 (42000): PROCEDURE mysql.rds_skip_repl_error does not exist`, faça upgrade da sua instância de banco de dados do MySQL para a versão secundária mais recente ou uma das versões secundárias mínimas listadas em [mysql.rds\$1skip\$1repl\$1error](mysql-stored-proc-replicating.md#mysql_rds_skip_repl_error). ## Configurar o parâmetro slave\$1skip\$1errors Para ignorar um ou mais erros, é possível definir o parâmetro estático `slave_skip_errors` na réplica de leitura. Esse parâmetro pode ser definido para ignorar um ou mais códigos de erro de replicação específicos. Atualmente, é possível definir esse parâmetro somente para instâncias de banco de dados do RDS para MySQL 5.7. Depois de alterar a configuração desse parâmetro, certifique-se de reinicializar sua instância de banco de dados para que a nova configuração entre em vigor. Para obter mais informações sobre definir esse parâmetro, consulte a [documentação do MySQL](https://dev.mysql.com/doc/refman/5.7/en/replication-options-replica.html#sysvar_slave_skip_errors). Convém definir esse parâmetro em um grupo de parâmetros de banco de dados separado. É possível associar esse grupo de parâmetros de banco de dados somente às réplicas de leitura que precisam ignorar erros. Seguir essa prática recomendada reduz o possível impacto em outras instâncias de banco de dados e réplicas de leitura. **Importante** Definir um valor não padrão para esse parâmetro pode resultar em inconsistência de replicação. Apenas defina esse parâmetro como um valor não padrão se você tiver esgotado outras opções para resolver o problema e tiver certeza do impacto potencial sobre os dados da réplica de leitura. # Trabalhar com espaços de tabela do InnoDB para melhorar o tempo de recuperação de falhas do RDS para MySQL Cada tabela no MySQL consiste de uma definição, de dados e de índices de tabela. O mecanismo de armazenamento InnoDB do MySQL armazena dados e índices de tabela em um *espaço de tabela*. O InnoDB cria um tablespace compartilhado global que contém um dicionário de dados e outros metadados relevantes, e pode conter dados e índices de tabela. O InnoDB também pode criar tablespaces separados para cada tabela e partição. Esses tablespaces separados são armazenados em arquivos de extensão .ibd e o cabeçalho de cada tablespaces contém um número que o identifica de forma exclusiva. O Amazon RDS fornece um parâmetro em um grupo de parâmetros do MySQL chamado `innodb_file_per_table`. Esses parâmetros controlam se o InnoDB adiciona novos dados de tabela e índices ao espaço de tabela compartilhado (definindo o valor do parâmetro como 0) ou aos espaços de tabelas individuais (definindo o valor do parâmetro como 1). O Amazon RDS define o valor padrão para `innodb_file_per_table` como 1, o que permite eliminar tabelas individuais do InnoDB e recuperar o armazenamento usado por essas tabelas para a instância de banco de dados. Na maioria dos casos de uso, definir o parâmetro `innodb_file_per_table` como 1 é a configuração recomendada. Você deve definir o parâmetro `innodb_file_per_table` como 0 quando você tiver um grande número de tabelas, por exemplo mais de 1.000 tabelas, ao usar armazenamento SSD padrão (magnético) ou de propósito geral ou mais de 10.000 tabelas ao usar armazenamento de IOPS provisionadas. Quando você define esse parâmetro como 0, os tablespaces individuais não são criados e isso pode melhorar o tempo necessário para a recuperação da falha no banco de dados. O MySQL processa cada arquivo de metadados, que inclui tablespaces, durante o ciclo de recuperação de falhas. O tempo que o MySQL leva para processar as informações de metadados no tablespace compartilhado é insignificante em comparação ao tempo necessário para processar milhares de arquivos de tablespace quando há vários tablespaces. Como o número do tablespace é armazenado no cabeçalho de cada arquivo, o tempo total para ler todos os arquivos do tablespace pode levar até várias horas. Por exemplo, pode levar de cinco a oito horas para processar um milhão de tablespaces do InnoDB no armazenamento padrão durante um ciclo de recuperação de falhas. Em alguns casos, o InnoDB pode determinar que precisa de limpeza adicional após um ciclo de recuperação de falhas para poder começar outro ciclo de recuperação de falhas, o que prolongará o tempo de recuperação. Lembre-se que um ciclo de recuperação de falhas também envolve transações de retorno, correção de páginas com defeito e outras operações além do processamento de informações de tablespace. Como o parâmetro `innodb_file_per_table` reside em um grupo de parâmetros, você pode alterar o valor do parâmetro editando o grupo de parâmetros usado por sua instância de banco de dados sem ter que reiniciar a instância de banco de dados. Após a configuração ser alterada, por exemplo, de 1 (criar tabelas individuais) para 0 (usar tablespace compartilhado), novas tabelas do InnoDB serão adicionadas ao tablespace compartilhado, enquanto as tabelas existentes continuam a ter tablespaces individuais. Para mover uma tabela do InnoDB para o tablespace compartilhado, você deve usar o comando `ALTER TABLE`. ## Migração de vários tablespaces ao tablespace compartilhado Você pode mover os metadados da tabela do InnoDB de seu próprio tablespace ao tablespace compartilhado, que reconstruirá os metadados da tabela de acordo com a configuração do parâmetro `innodb_file_per_table`. Primeiro, conecte-se à sua instância de banco de dados MySQL. Depois disso, emita os comandos apropriados, conforme mostrado a seguir. Para obter mais informações, consulte [Conectar-se à instância de banco de dados do MySQL](USER_ConnectToInstance.md). ``` ALTER TABLE table_name ENGINE = InnoDB, ALGORITHM=COPY; ``` Por exemplo, a seguinte consulta retorna uma instrução `ALTER TABLE` para cada tabela InnoDB que não esteja no espaço de tabela compartilhado. **Para instâncias de banco de dados do MySQL:** ``` SELECT CONCAT('ALTER TABLE `', REPLACE(LEFT(NAME , INSTR((NAME), '/') - 1), '`', '``'), '`.`', REPLACE(SUBSTR(NAME FROM INSTR(NAME, '/') + 1), '`', '``'), '` ENGINE=InnoDB, ALGORITHM=COPY;') AS Query FROM INFORMATION_SCHEMA.INNODB_SYS_TABLES WHERE SPACE <> 0 AND LEFT(NAME, INSTR((NAME), '/') - 1) NOT IN ('mysql',''); ``` **Para instâncias de banco de dados MySQL 8.4 e 8.0:** ``` SELECT CONCAT('ALTER TABLE `', REPLACE(LEFT(NAME , INSTR((NAME), '/') - 1), '`', '``'), '`.`', REPLACE(SUBSTR(NAME FROM INSTR(NAME, '/') + 1), '`', '``'), '` ENGINE=InnoDB, ALGORITHM=COPY;') AS Query FROM INFORMATION_SCHEMA.INNODB_TABLES WHERE SPACE <> 0 AND LEFT(NAME, INSTR((NAME), '/') - 1) NOT IN ('mysql',''); ``` Recriar uma tabela do MySQL para mover os metadados da tabela para o tablespace compartilhado requer temporariamente espaço de armazenamento adicional para recriar a tabela, portanto a instância do banco de dados deve ter espaço de armazenamento disponível. Durante a recriação, a tabela é bloqueada e inacessível para consultas. Para tabelas pequenas ou tabelas que não são acessadas com frequência, isso pode não ser um problema. Para tabelas grandes ou tabelas acessadas com frequência em um ambiente fortemente simultâneo, é possível recriar tabelas em uma réplica de leitura. É possível criar uma réplica de leitura e migrar metadados da tabela para o tablespace compartilhado na réplica de leitura. Embora a instrução ALTER TABLE bloqueie o acesso na réplica de leitura, a instância de banco de dados de origem não é afetada. A instância de banco de dados de origem continuará a gerar seus logs binários enquanto a réplica de leitura apresentar atraso durante o processo de recriação da tabela. Como a recriação requer espaço de armazenamento adicional e o arquivo de log de reprodução pode ficar grande, você deve criar uma réplica de leitura com o armazenamento alocado maior que a instância de banco de dados de origem. Para criar uma réplica de leitura e recriar tabelas do InnoDB a fim de usar o tablespace compartilhado, execute as seguintes etapas: 1. Verifique se a retenção de backup está habilitada na instância do banco de dados de origem, de modo que o registro de log binário esteja habilitado 1. Use o Console de gerenciamento da AWS ou a AWS CLI para criar uma réplica de leitura para a instância de banco de dados de origem. Como a criação de uma réplica de leitura envolve muitos dos mesmos processos que os da recuperação de falhas, o processo de criação pode levar algum tempo se houver um grande número de tablespaces do InnoDB. Aloque mais espaço de armazenamento na réplica de leitura do que é usado atualmente na instância de banco de dados de origem. 1. Quando a réplica de leitura tiver sido criada, crie um grupo de parâmetros com as configurações de parâmetro `read_only = 0` e `innodb_file_per_table = 0`. Depois, associe o grupo de parâmetros à réplica de leitura. 1. Emita a seguinte instrução SQL para todas as tabelas que você deseja migrar na réplica: ``` ALTER TABLE name ENGINE = InnoDB ``` 1. Quando todas as instruções `ALTER TABLE` forem concluídas na réplica de leitura, verifique se a réplica de leitura está conectada à instância de banco de dados de origem e se as duas instâncias estão sincronizadas. 1. Use o console ou a CLI para promover a réplica de leitura para ser a instância. Verifique se o grupo de parâmetros usado para a nova instância de banco de dados autônoma tem o parâmetro `innodb_file_per_table` definido como 0. Altere o nome da nova instância de banco de dados autônoma e aponte todos os aplicativos para a nova instância de banco de dados autônoma. # Gerenciar o histórico de status global do RDS para MySQL **dica** Para analisar a performance do banco de dados, você também pode usar o Insights de Performance no Amazon RDS. Para obter mais informações, consulte [Monitorar a carga de banco de dados com o Performance Insights no Amazon RDS](USER_PerfInsights.md). O MySQL mantém muitas variáveis de status que fornecem informações sobre sua operação. Os valores podem lhe ajudar a detectar problemas de bloqueio ou memória em uma instância de banco de dados. Os valores dessas variáveis de status se acumulam desde a última vez que a instância de banco de dados foi iniciada. Você pode redefinir a maioria das variáveis de status para 0 usando o comando `FLUSH STATUS`. Para permitir o monitoramento desses valores ao longo do tempo, o Amazon RDS fornece um conjunto de procedimentos que fará o snapshot dos valores dessas variáveis de status ao longo do tempo e as registrará em uma tabela, juntamente com quaisquer alterações feitas desde o último snapshot. Esta infraestrutura, denominada GoSH (Histórico de status global), está instalada em todas as instâncias de banco de dados MySQL, desde as versões 5.5.23. O GoSH é desabilitado por padrão. Para habilitar o GoSH, primeiro habilite o programador de eventos por meio de um grupo de parâmetros de banco de dados, definindo o parâmetro `event_scheduler` como `ON`. Para instâncias de banco de dados do MySQL que executam o MySQL 5.7, defina também o parâmetro `show_compatibility_56` para `1`. Para obter informações sobre como criar e modificar um grupo de parâmetros de banco de dados, consulte [Grupos de parâmetros para Amazon RDS](USER_WorkingWithParamGroups.md). Para obter informações sobre os efeitos colaterais da habilitação desse parâmetro, consulte[show\$1compatibility\$156](https://dev.mysql.com/doc/refman/5.7/en/server-system-variables.html#sysvar_show_compatibility_56) no*MySQL 5.7 Reference Manual*. Você poderá, então, usar os procedimentos na tabela a seguir para habilitar e configurar o GoSH. Primeiro, conecte-se à sua instância de banco de dados MySQL. Depois disso, emita os comandos apropriados, conforme mostrado a seguir. Para obter mais informações, consulte [Conectar-se à instância de banco de dados do MySQL](USER_ConnectToInstance.md). Para cada procedimento, execute o comando a seguir e substitua **procedure-name**: ``` CALL procedure-name; ``` A tabela a seguir lista todos os procedimentos que você pode usar para **procedure-name** no comando anterior. | Procedimento | Descrição | | --- | --- | | `mysql.rds_enable_gsh_collector` | Permite que o GoSH faça snapshots padrão em intervalos especificados por `rds_set_gsh_collector`. | | `mysql.rds_set_gsh_collector` | Especifica o intervalo em minutos entre snapshots. O valor padrão é 5. | | `mysql.rds_disable_gsh_collector` | Desabilita os snapshots. | | `mysql.rds_collect_global_status_history` | Faz um snapshot sob demanda. | | `mysql.rds_enable_gsh_rotation` | Permite o revezamento do conteúdo da tabela `mysql.rds_global_status_history` com o da `mysql.rds_global_status_history_old` em intervalos especificados pelo `rds_set_gsh_rotation`. | | `mysql.rds_set_gsh_rotation` | Especifica o intervalo em dias entre os revezamentos de tabelas. O valor padrão é 7. | | `mysql.rds_disable_gsh_rotation` | Desabilita o revezamento de tabelas. | | `mysql.rds_rotate_global_status_history` | Reveza o conteúdo da tabela `mysql.rds_global_status_history` para o da `mysql.rds_global_status_history_old` sob demanda. | Quando o GoSH estiver sendo executado, você pode consultar as tabelas nas quais ele grava. Por exemplo, para consultar a taxa de acerto do grupo de buffer do Innodb, você deve emitir a seguinte consulta: ``` select a.collection_end, a.collection_start, (( a.variable_Delta-b.variable_delta)/a.variable_delta)*100 as "HitRatio" from mysql.rds_global_status_history as a join mysql.rds_global_status_history as b on a.collection_end = b.collection_end where a. variable_name = 'Innodb_buffer_pool_read_requests' and b.variable_name = 'Innodb_buffer_pool_reads' ``` # Configuração do tamanho do pool de buffer e a capacidade de log redo no MySQL 8.4 No MySQL 8.4, o Amazon RDS ativa o parâmetro `innodb_dedicated_server` por padrão. Com o parâmetro `innodb_dedicated_server`, o mecanismo do banco de dados calcula os parâmetros `innodb_buffer_pool_size` e `innodb_redo_log_capacity`. Para obter informações sobre como esses parâmetros são calculados, consulte [Configuração do tamanho do pool de buffer do InnoDB](https://dev.mysql.com/doc/refman/8.4/en/innodb-buffer-pool-resize.html) e [Log Redo](https://dev.mysql.com/doc/refman/8.4/en/innodb-redo-log.html) na documentação do MySQL. Com `innodb_dedicated_server` habilitado, o parâmetro `innodb_buffer_pool_size` é calculado com base na memória da classe da instância de banco de dados. A tabela a seguir exibe a memória do servidor detectada e o tamanho do pool de buffer correspondente. | Memória do servidor detectada | Tamanho do pool de buffer | | --- | --- | | < 1 GB | Valor padrão de 128 MB | | 1 GB a 4 GB | *Memória de servidor detectada* \$1 0,5 | | > 4 GB | *Memória de servidor detectada* \$1 0,75 | O parâmetro `innodb_redo_log_capacity` é escalado automaticamente com a classe da instância para (número de vCPUs/2) GB até um máximo de 16 GB. Classes de instâncias maiores têm uma maior capacidade de log redo, o que pode melhorar o desempenho e a resiliência de workloads com uso intenso de gravação. Antes de atualizar do MySQL 8.0 para o MySQL 8.4, aumente o espaço de armazenamento para acomodar um possível aumento no tamanho dos logs redo que pode ocorrer após a conclusão da atualização. Para obter mais informações, consulte [Aumento da capacidade de armazenamento da instância de banco de dados](USER_PIOPS.ModifyingExisting.md). Se você não quiser que o parâmetro `innodb_dedicated_server` calcule os valores para os parâmetros `innodb_buffer_pool_size` e `innodb_redo_log_capacity`, substitua esses valores definindo valores específicos para eles em um grupo de parâmetros personalizado. Como alternativa, você pode desativar o parâmetro `innodb_dedicated_server` e definir valores para os parâmetros `innodb_buffer_pool_size` e `innodb_redo_log_capacity` em um grupo de parâmetros personalizado. Para obter mais informações, consulte [Grupos de parâmetros padrão e personalizados](parameter-groups-overview.md#parameter-groups-overview.custom). Se você desabilitar o parâmetro `innodb_dedicated_server` definindo-o como `0` e não definir valores para os parâmetros `innodb_buffer_pool_size` e `innodb_redo_log_capacity`, o Amazon RDS definirá os dois últimos parâmetros como 128 MB e 100 MB, respectivamente. Esses padrões resultam em desempenho ruim em classes de instâncias maiores. # Fuso horário local para instâncias de banco de dados MySQL Por padrão, o fuso horário de uma instância de banco de dados MySQL é o Tempo Universal Coordenado (UTC). Você pode definir o fuso horário de sua instância de banco de dados como o fuso horário local de seu aplicativo. Para definir o fuso horário local de uma instância de banco de dados, defina o parâmetro `time_zone` no grupo de parâmetros para sua instância de banco de dados como um dos valores compatíveis listados posteriormente nesta seção. Quando você configura o parâmetro `time_zone` para um grupo de parâmetros, todas as instâncias de banco de dados e as réplicas de leitura que estiverem usando esse grupo de parâmetros mudarão para usar o novo fuso horário local. Para obter informações sobre como configurar parâmetros em um grupo de parâmetros, consulte [Grupos de parâmetros para Amazon RDS](USER_WorkingWithParamGroups.md). Após definir o fuso horário local, todas as novas conexões ao banco de dados refletirão a alteração. Se você tiver conexões abertas em seu banco de dados quando mudar o fuso horário local, você não verá a atualização do fuso horário local até que encerre a conexão e abra uma nova conexão. É possível definir um fuso horário local diferente para uma instância de banco de dados e uma ou mais de suas réplicas de leitura. Para fazer isso, use um grupo de parâmetros diferente para a instância de banco de dados e a(s) replica(s), e defina o parâmetro `time_zone` em cada grupo de parâmetros para um fuso horário local diferente. Se você estiver replicando entre as Regiões da AWS, a instância de banco de dados de origem e a réplica de leitura usarão grupos de parâmetros diferentes (os grupos de parâmetros são exclusivos de cada Região da AWS). Para usar o mesmo fuso horário local a cada instância, é necessário configurar o parâmetro `time_zone` nos grupos de parâmetros da instância e da réplica de leitura. Quando você restaura uma instância de banco de dados de um snapshot de banco de dados, o fuso horário local é definido como UTC. Você pode atualizar o fuso horário para o fuso horário local após a conclusão da restauração. Se você restaurar uma instância de banco de dados para um período específico, o fuso horário local para a instância de banco de dados restaurada representará a configuração de fuso horário do grupo de parâmetros da instância de banco de dados restaurada. A Internet Assigned Numbers Authority (IANA) publica novos fusos horários em [https://www.iana.org/time-zones](https://www.iana.org/time-zones) várias vezes por ano. Toda vez que o RDS lança uma nova versão de manutenção secundária do MySQL, ela vem com os dados de fuso horário mais recentes no momento do lançamento. Ao usar as versões mais recentes do RDS para MySQL, você tem dados de fuso horário recentes do RDS. Para garantir que sua instância de banco de dados tenha dados de fuso horário recentes, recomendamos atualizar para uma versão superior do mecanismo de banco de dados. Como alternativa, você pode modificar as tabelas de fuso horário nas instâncias de banco de dados do MariaDB manualmente. Para fazer isso, você pode usar comandos SQL ou executar a [ferramenta mysql\$1tzinfo\$1to\$1sql](https://dev.mysql.com/doc/refman/8.0/en/mysql-tzinfo-to-sql.html) em um cliente SQL. Depois de atualizar os dados do fuso horário manualmente, reinicialize sua instância de banco de dados para que as alterações tenham efeito. O RDS não modifica nem redefine os dados de fuso horário das instâncias de banco de dados em execução. Os novos dados de fuso horário são instalados somente quando você executa uma atualização da versão do mecanismo de banco de dados. Você pode definir seu fuso horário local para um dos seguintes valores. | Zona | Time zone (Fuso horário) | | --- | --- | | África | África/Cairo, África/Casablanca, África/Harare, África/Monrovia, África/Nairobi, África/Tripoli, África/Windhoek | | América | América/Araguaina, América/Assunção, América/Bogotá, América/Buenos\$1Aires, América/Caracas, América/Chihuahua, América/Cuiabá, América/Denver, América/Fortaleza, América/Guatemala, América/Halifax, América/Manaus, América/Matamoros, América/Monterrey, América/Montevidéu, América/Phoenix, América/Santiago, América/Tijuana | | Ásia | Ásia/Amman, Ásia/Ashgabat, Ásia/Baghdad, Ásia/Baku, Ásia/Bangkok, Ásia/Beirut, Ásia/Calcutta, Ásia/Damascus, Ásia/Dhaka, Ásia/Irkutsk, Ásia/Jerusalem, Ásia/Kabul, Ásia/Karachi, Ásia/Kathmandu, Ásia/Krasnoyarsk, Ásia/Magadan, Ásia/Muscat, Ásia/Novosibirsk, Ásia/Riyadh, Ásia/Seoul, Ásia/Shanghai, Ásia/Singapore, Ásia/Taipei, Ásia/Tehran, Ásia/Tokyo, Ásia/Ulaanbaatar, Ásia/Vladivostok, Ásia/Yakutsk, Ásia/Yerevan | | Atlântico | Atlântico/Açores | | Austrália | Austrália/Adelaide, Austrália/Brisbane, Austrália/Darwin, Austrália/Hobart, Austrália/Perth, Austrália/Sydney | | Brasil | Brasil/DeNoronha, Brasil/Leste | | Canadá | Canadá/Newfoundland, Canadá/Saskatchewan, Canadá/Yukon | | Europa | Europa/Amsterdam, Europa/Athens, Europa/Dublin, Europa/Helsinki, Europa/Istanbul, Europa/Kaliningrad, Europa/Moscow, Europa/Paris, Europa/Prague, Europa/Sarajevo | | Pacífico | Pacífico/Auckland, Pacífico/Fiji, Pacífico/Guam, Pacífico/Honolulu, Pacífico/Samoa | | EUA | EUA/Alasca, EUA/Central, EUA/East-Indiana, EUA/Eastern, EUA/Pacífico | | UTC | UTC | # Problemas conhecidos e limitações do Amazon RDS para MySQL Veja a seguir os problemas e as limitações conhecidos no trabalho com o Amazon RDS para MySQL. **Topics** + [ ## Palavra reservada InnoDB ](#MySQL.Concepts.KnownIssuesAndLimitations.InnodbDatabaseName) + [ ## Comportamento de armazenamento cheio para Amazon RDS para MySQL ](#MySQL.Concepts.StorageFullBehavior) + [ ## Tamanho do grupo de buffers do InnoDB inconsistente ](#MySQL.Concepts.KnownIssuesAndLimitations.InnodbBufferPoolSize) + [ ## A otimização de mesclagem de índice retorna resultados errados ](#MySQL.Concepts.KnownIssuesAndLimitations.IndexMergeOptimization) + [ ## Exceções de parâmetros do MySQL para instâncias de bancos de dados do Amazon RDS ](#MySQL.Concepts.ParameterNotes) + [ ## Limites de tamanho de arquivo do MySQL no Amazon RDS ](#MySQL.Concepts.Limits.FileSize) + [ ## Não há suporte ao plugin Keyring do MySQL ](#MySQL.Concepts.Limits.KeyRing) + [ ## Portas personalizadas ](#MySQL.Concepts.KnownIssuesAndLimitations.CustomPorts) + [ ## Limitações de procedimentos armazenados do MySQL ](#MySQL.Concepts.KnownIssuesAndLimitations.KillProcedures) + [ ## Replicação baseada em GTID com uma instância de origem externa ](#MySQL.Concepts.KnownIssuesAndLimitations.GTID) + [ ## Plug-in de autenticação padrão do MySQL ](#MySQL.Concepts.KnownIssuesAndLimitations.authentication-plugin) + [ ## Substituir innodb\$1buffer\$1pool\$1size ](#MySQL.Concepts.KnownIssuesAndLimitations.innodb-bp-size) + [ ## Atualização do MySQL 5.7 para o MySQL 8.4 ](#MySQL.Concepts.KnownIssuesAndLimitations.upgrade-8-4) + [ ## Compressão de páginas do InnoDB ](#MySQL.Concepts.KnownIssuesAndLimitations.innodb-page-compression) ## Palavra reservada InnoDB `InnoDB` é uma palavra reservada para o RDS para MySQL. Você não pode usar esse nome para um banco de dados MySQL. ## Comportamento de armazenamento cheio para Amazon RDS para MySQL Quando o armazenamento fica cheio em uma instância de banco de dados MySQL, pode haver inconsistências de metadados, incompatibilidade de dicionários e tabelas órfãs. Para evitar esses problemas, o Amazon RDS interrompe automaticamente uma instância de banco de dados que atinja o estado `storage-full`. Uma instância de banco de dados MySQL atinge o estado `storage-full` nos seguintes casos: + A instância de banco de dados tem menos de 20.000 MiB de armazenamento e o armazenamento disponível atinge 200 MiB ou menos. + A instância de banco de dados tem mais de 102.400 MiB de armazenamento e o armazenamento disponível só chega a 1024 MiB ou menos. + A instância de banco de dados tem entre 20.000 MiB e 102.400 MiB de armazenamento e está com menos de 1% de armazenamento disponível. Depois que o Amazon RDS interromper uma instância de banco de dados automaticamente porque ela atingiu o estado `storage-full`, você ainda poderá modificá-la. Para reiniciar a instância de banco de dados, conclua pelo menos um dos seguintes procedimentos: + Modifique a instância de banco de dados para habilitar o autoscaling do armazenamento. Para ter mais informações sobre o autoscaling do armazenamento, consulte [Gerenciar a capacidade automaticamente com a escalabilidade automática de armazenamento do Amazon RDS](USER_PIOPS.Autoscaling.md). + Modifique a instância de banco de dados para aumentar sua capacidade de armazenamento. Para ter mais informações sobre o aumento da capacidade de armazenamento, consulte [Aumento da capacidade de armazenamento da instância de banco de dados](USER_PIOPS.ModifyingExisting.md). Depois de fazer uma dessas alterações, a instância de banco de dados será reiniciada automaticamente. Para mais informações sobre a modificação de uma instância de banco de dados , consulte [Modificar uma instância de banco de dados do Amazon RDS](Overview.DBInstance.Modifying.md). ## Tamanho do grupo de buffers do InnoDB inconsistente Para o MySQL 5.7, existe atualmente um bug na forma como o tamanho do grupo de buffers do InnoDB é gerenciado. O MySQL 5.7 pode ajustar o parâmetro `innodb_buffer_pool_size` para um valor muito grande, que pode fazer com que o grupo de buffers do InnoDB cresça demais e consuma muita memória. Esse efeito pode fazer com que o mecanismo de banco de dados MySQL pare de funcionar ou pode impedir que ele seja iniciado. Esse problema é mais comum para classes de instâncias de banco de dados que têm menos memória disponível. Para resolver esse problema, defina o valor do parâmetro `innodb_buffer_pool_size` como um múltiplo do produto do valor do parâmetro `innodb_buffer_pool_instances` e do valor do parâmetro `innodb_buffer_pool_chunk_size`. Por exemplo, você pode configurar o valor do parâmetro `innodb_buffer_pool_size` como um múltiplo de oito vezes o produto dos valores dos parâmetros `innodb_buffer_pool_instances` e `innodb_buffer_pool_chunk_size`, conforme mostrado no exemplo a seguir. ``` innodb_buffer_pool_chunk_size = 536870912 innodb_buffer_pool_instances = 4 innodb_buffer_pool_size = (536870912 * 4) * 8 = 17179869184 ``` Para obter detalhes sobre esse bug do MySQL 5.7, acesse [https://bugs.mysql.com/bug.php?id=79379](https://bugs.mysql.com/bug.php?id=79379) na documentação do MySQL. ## A otimização de mesclagem de índice retorna resultados errados As consultas que utilizam a otimização de mesclagem de índice podem retornar resultados incorretos devido a um bug no otimizador de consulta MySQL que foi introduzido no MySQL 5.5.37. Ao emitir uma consulta em uma tabela com vários índices, o otimizador verifica intervalos de linhas com base em vários índices, mas não mescla os resultados corretamente. Para ter mais informações sobre o bug do otimizador de consulta, acesse [http://bugs.mysql.com/bug.php?id=72745](https://bugs.mysql.com/bug.php?id=72745) e [http://bugs.mysql.com/bug.php?id=68194](https://bugs.mysql.com/bug.php?id=68194) no banco de dados de bugs do MySQL. Por exemplo, considere uma consulta em uma tabela com dois índices em que os argumentos de pesquisa fazem referência às colunas indexadas. ``` 1. SELECT * FROM table1 2. WHERE indexed_col1 = 'value1' AND indexed_col2 = 'value2'; ``` Nesse caso, o mecanismo de pesquisa pesquisará ambos os índices. No entanto, devido ao erro, os resultados mesclados estão incorretos. Para resolver esse problema, você pode realizar um dos seguintes procedimentos: + Defina o parâmetro `optimizer_switch` como `index_merge=off` no grupo de parâmetros de banco de dados para a sua instância de banco de dados MySQL. Para obter informações sobre como definir os parâmetros do grupo de parâmetros de banco de dados, consulte [Grupos de parâmetros para Amazon RDS](USER_WorkingWithParamGroups.md). + Atualize a instância de banco de dados do MySQL para o MySQL versão 5.7 ou 8.0. Para ter mais informações, consulte [Atualizações do mecanismo de banco de dados do RDS para MySQL](USER_UpgradeDBInstance.MySQL.md). + Se você não puder atualizar sua instância ou alterar o parâmetro `optimizer_switch`, poderá contornar o bug identificando explicitamente um índice para a consulta, por exemplo: ``` 1. SELECT * FROM table1 2. USE INDEX covering_index 3. WHERE indexed_col1 = 'value1' AND indexed_col2 = 'value2'; ``` Para ter mais informações, consulte [Index merge optimization](https://dev.mysql.com/doc/refman/8.0/en/index-merge-optimization.html) (Otimizar a mesclagem de índice) na documentação do MySQL. ## Exceções de parâmetros do MySQL para instâncias de bancos de dados do Amazon RDS Alguns parâmetros do MySQL requerem considerações especiais quando usados com uma instância de banco de dados do Amazon RDS. ### lower\$1case\$1table\$1names Como o Amazon RDS usa um sistema de arquivos que diferencia maiúsculas de minúsculas, não há suporte para definir o valor do parâmetro de servidor `lower_case_table_names` como 2 (nomes armazenados conforme especificados, mas comparados em minúsculas). Veja a seguir os valores compatíveis com as instâncias de banco de dados do Amazon RDS para MySQL: + 0 (nomes armazenados como dados e as comparações diferenciam maiúsculas de minúsculas) é compatível com todas as versões do RDS para MySQL. + 1 (nomes armazenados em letras minúsculas e comparações não diferenciam maiúsculas de minúsculas) é compatível com o RDS para MySQL versão 5.7, versão 8.0.28 e versões 8.0 posteriores, e versão 8.4. Defina o parâmetro `lower_case_table_names` em um grupo de parâmetros de banco de dados personalizado antes de criar uma instância de banco de dados. Em seguida, especifique o grupo de parâmetros de banco de dados personalizado ao criar a instância de banco de dados. Quando um grupo de parâmetros é associado a uma instância de banco de dados MySQL com uma versão inferior a 8.0, recomendamos que você evite alterar o parâmetro `lower_case_table_names` no grupo de parâmetros. Alterá-lo pode causar inconsistências com backups de recuperação para um ponto no tempo e instâncias de bancos de dados de réplica de leitura. Quando um grupo de parâmetros é associado a uma instância de banco de dados MySQL versão 8.0 ou 8.4, não é possível modificar o parâmetro `lower_case_table_names` no grupo de parâmetros. Réplicas de leitura sempre devem usar o mesmo valor de parâmetro `lower_case_table_names` que a instância de banco de dados de origem. ### long\$1query\$1time Você pode definir o parâmetro `long_query_time` como um valor de ponto flutuante para conseguir registrar consultas lentas no log de consultas lentas do MySQL com resolução de microssegundos. Você pode definir um valor como 0,1 segundos, que seria de 100 milissegundos, para ajudar ao depurar transações lentas que demoram menos de um segundo. ## Limites de tamanho de arquivo do MySQL no Amazon RDS Para instâncias de banco de dados do MySQL versões 8.0 e posteriores, o tamanho máximo do arquivo é de 16 TiB. Ao usar espaços de tabela de arquivo por tabela, o tamanho máximo do arquivo limita o tamanho de uma tabela do InnoDB a 16 TiB. Os espaços de tabelas de arquivo por tabela do InnoDB (com cada tabela em seu próprio espaço de tabela) são definidos por padrão para instâncias de bancos de dados MySQL. Consulte mais informações em [InnoDB Limits](https://dev.mysql.com/doc/refman/8.0/en/innodb-limits.html) na documentação do MySQL. **nota** Algumas instâncias de Banco de Dados existentes têm um limite menor. Por exemplo, as instâncias de banco de dados MySQL criadas antes de abril de 2014 têm um limite de tamanho de arquivo e de tabela de 2 TB. Esse limite de tamanho de arquivo de 2 TB também se aplica a instâncias de banco de dados ou a réplicas de leitura criadas de snapshots de banco de dados tirados antes de abril de 2014, independentemente de quando a instância de banco de dados foi criada. Existem vantagens e desvantagens na utilização de espaços de tabela de arquivo por tabela do InnoDB, dependendo do seu aplicativo. Para determinar a melhor abordagem para a aplicação, consulte [File-per-table tablespaces](https://dev.mysql.com/doc/refman/8.0/en/innodb-file-per-table-tablespaces.html) na documentação do MySQL. Não recomendamos permitir que as tabelas cresçam até o tamanho máximo do arquivo. Em geral, uma prática recomendada é particionar dados em tabelas menores, o que pode melhorar a performance e os tempos de recuperação. Uma opção que você pode usar para dividir uma tabela grande em tabelas menores é o particionamento. O particionamento distribui partes da sua tabela grande em arquivos separados com base em regras que você especifica. Por exemplo, se você armazenar transações por data, poderá criar regras de particionamento que distribuem transações antigas em arquivos separados usando o particionamento. Em seguida, periodicamente, você pode arquivar os dados históricos de transações que não precisam estar prontamente disponíveis para o seu aplicativo. Para ter mais informações, consulte [Partitioning](https://dev.mysql.com/doc/refman/8.0/en/partitioning.html) na documentação do MySQL. Como não há uma única tabela ou visualização do sistema que indique o tamanho de todas as tabelas e do espaço de tabela do sistema InnoDB, consulte várias tabelas para definir o tamanho dos espaços de tabela. **Como determinar o tamanho do espaço de tabela do sistema InnoDB e do espaço de tabela do dicionário de dados** + Use o seguinte comando SQL para determinar se alguns dos seus espaços de tabela são muito grandes e são candidatos para particionamento. **nota** O espaço de tabela do dicionário de dados é específico para o MySQL 8.0 e versões posteriores. ``` 1. select FILE_NAME,TABLESPACE_NAME, ROUND(((TOTAL_EXTENTS*EXTENT_SIZE) 2. /1024/1024/1024), 2) as "File Size (GB)" from information_schema.FILES 3. where tablespace_name in ('mysql','innodb_system'); ``` **Como determinar o tamanho das tabelas de usuários do InnoDB fora do espaço de tabela do sistema InnoDB (para versões do MySQL 5.7)** + Use o seguinte comando SQL para determinar se algumas das suas tabelas são muito grandes e são candidatas para particionamento. ``` 1. SELECT SPACE,NAME,ROUND((ALLOCATED_SIZE/1024/1024/1024), 2) 2. as "Tablespace Size (GB)" 3. FROM information_schema.INNODB_SYS_TABLESPACES ORDER BY 3 DESC; ``` **Como determinar o tamanho das tabelas de usuários do InnoDB fora do espaço de tabela do sistema InnoDB (para versões do MySQL 8.0 e posteriores)** + Use o seguinte comando SQL para determinar se algumas das suas tabelas são muito grandes e são candidatas para particionamento. ``` 1. SELECT SPACE,NAME,ROUND((ALLOCATED_SIZE/1024/1024/1024), 2) 2. as "Tablespace Size (GB)" 3. FROM information_schema.INNODB_TABLESPACES ORDER BY 3 DESC; ``` **Como determinar o tamanho das tabelas de usuários que não são do InnoDB** + Use o seguinte comando SQL para determinar se algumas das suas tabelas de usuários que não são do InnoDB são muito grandes. ``` SELECT TABLE_SCHEMA, TABLE_NAME, round(((DATA_LENGTH + INDEX_LENGTH+DATA_FREE) / 1024 / 1024/ 1024), 2) As "Approximate size (GB)" FROM information_schema.TABLES WHERE TABLE_SCHEMA NOT IN ('mysql', 'information_schema', 'performance_schema') and ENGINE<>'InnoDB'; ``` **Para habilitar espaços de tabela de arquivo por tabela do InnoDB** + Defina o parâmetro *innodb\$1file\$1per\$1table* como `1` no grupo de parâmetros da instância de banco de dados. **Para desabilitar espaços de tabela de arquivo por tabela do InnoDB** + Defina o parâmetro *innodb\$1file\$1per\$1table* como `0` no grupo de parâmetros da instância de banco de dados. Para obter informações sobre como atualizar um grupo de parâmetros, consulte [Grupos de parâmetros para Amazon RDS](USER_WorkingWithParamGroups.md). Quando tiver habilitado ou desabilitado espaços de tabelas de arquivo por tabela do InnoDB, você poderá emitir um comando `ALTER TABLE` para mover uma tabela do espaço de tabela global para seu próprio espaço de tabela, ou do seu próprio espaço de tabela para o espaço de tabela global, conforme mostrado no exemplo a seguir: ``` ALTER TABLE table_name TABLESPACE=innodb_file_per_table; ``` ## Não há suporte ao plugin Keyring do MySQL No momento, o Amazon RDS para MySQL não oferece suporte ao plug-in Keyring `keyring_aws` da Amazon Web Services do MySQL. ## Portas personalizadas O Amazon RDS bloqueia conexões com a porta personalizada 33060 para o mecanismo MySQL. Escolha uma porta diferente para o seu mecanismo MySQL. ## Limitações de procedimentos armazenados do MySQL Os procedimentos armazenados [mysql.rds\$1kill](mysql-stored-proc-ending.md#mysql_rds_kill) e [mysql.rds\$1kill\$1query](mysql-stored-proc-ending.md#mysql_rds_kill_query) não podem encerrar sessões ou consultas pertencentes a usuários do MySQL que tenham nomes de usuário com mais de 16 caracteres nas seguintes versões do RDS para MySQL: + Versão 8.0.32 e versões 8 anteriores + Versão 5.7.41 e versões 5.7 anteriores ## Replicação baseada em GTID com uma instância de origem externa O Amazon RDS comporta a replicação baseada em identificadores de transação global (GTIDs) de uma instância externa do MySQL externa em uma instância de banco de dados do Amazon RDS para MySQL que exija a definição de GTID\$1PURGED durante a configuração. No entanto, somente o RDS para MySQL 8.0.37 e versões posteriores comportam essa funcionalidade. ## Plug-in de autenticação padrão do MySQL O RDS para MySQL versão 8.0.34 e 8.0 posteriores e posterior usam o plug-in `mysql_native_password`. Você não pode alterar a configuração `default_authentication_plugin`. O RDS para MySQL versão 8.4 e versões posteriores usam o plug-in `caching_sha2_password` como o plug-in de autenticação padrão. Você pode alterar o plug-in de autenticação padrão para o MySQL 8.4. O plug-in `mysql_native_password` ainda funciona com o MySQL 8.4, mas o suporte a esse plug-in termina com o MySQL 8.4. Para alterar o plug-in de autenticação padrão, crie um grupo de parâmetros personalizado e modifique o valor do parâmetro `authentication_policy`. Para obter mais informações, consulte [Grupos de parâmetros padrão e personalizados](parameter-groups-overview.md#parameter-groups-overview.custom). ## Substituir innodb\$1buffer\$1pool\$1size Com classes de instância de banco de dados micro ou small, o valor padrão do parâmetro `innodb_buffer_pool_size` pode ser diferente do valor exibido ao executar o seguinte comando: ``` mysql> SELECT @@innodb_buffer_pool_size; ``` Essa diferença pode ocorrer quando o Amazon RDS precisa substituir o valor padrão como parte do gerenciamento das classes de instância de banco de dados. Se necessário, você poderá substituir o valor padrão e defini-lo como um valor compatível com a classe de instância de banco de dados. Para determinar um valor válido, adicione o uso da memória e a memória total disponível na instância de banco de dados. Para ter mais informações, consulte [Tipos de instâncias do Amazon RDS](https://aws.amazon.com/rds/instance-types/). Se a instância de banco de dados tiver apenas 4 GB de memória, você não poderá definir `innodb_buffer_pool_size` como 8 GB, mas poderá defini-lo como 3 GB, dependendo da quantidade de memória alocada a outros parâmetros. Se o valor inserido for muito grande, o Amazon RDS o reduzirá para os seguintes limites: + Classes de instância de banco de dados micro: 256 MB + Classes de instância de banco de dados db.t4g.micro: 128 MB ## Atualização do MySQL 5.7 para o MySQL 8.4 Você não pode atualizar diretamente do MySQL 5.7 para o MySQL 8.4. Primeiro, você deve atualizar do MySQL 5.7 para o MySQL 8.0 e, em seguida, do MySQL 8.0 para o MySQL 8.4. Para obter mais informações, consulte [Atualizações da versão principal do RDS para MySQL](USER_UpgradeDBInstance.MySQL.Major.md). ## Compressão de páginas do InnoDB A compressão de páginas do InnoDB não funciona com instâncias de banco de dados do Amazon RDS que têm um tamanho de bloco do sistema de arquivos de 16k porque o tamanho do bloco do sistema de arquivos deve ser menor que o tamanho da página do InnoDB. A partir de fevereiro de 2024, todas as instâncias de banco de dados recém-criadas têm um tamanho de bloco do sistema de arquivos de 16k, o que aumenta o throughput e diminui o consumo de IOPS durante a liberação de páginas. # Referência de procedimentos armazenados do RDS para MySQL Esses tópicos descrevem procedimentos armazenados no sistema que estão disponíveis para instâncias do Amazon RDS que executam o mecanismo de banco de dados MySQL. O usuário primário deve executar esses procedimentos. **Topics** + [ # Coletar e manter o histórico de status global ](mysql-stored-proc-gsh.md) + [ # Configurar, iniciar e interromper a replicação de logs binários (binlogs) ](mysql-stored-proc-replicating.md) + [ # Encerrar uma sessão ou consulta ](mysql-stored-proc-ending.md) + [ # Gerenciar clusters ativos-ativos ](mysql-stored-proc-active-active-clusters.md) + [ # Gerenciar a replicação de várias fontes ](mysql-stored-proc-multi-source-replication.md) + [ # Replicar transações com GTIDs ](mysql-stored-proc-gtid.md) + [ # Alternar os logs de consulta ](mysql-stored-proc-logging.md) + [ # Definir e mostrar a configuração de logs binários ](mysql-stored-proc-configuring.md) + [ # Aquecer o armazenamento em cache do InnoDB ](mysql-stored-proc-warming.md) # Coletar e manter o histórico de status global O Amazon RDS fornece um conjunto de procedimentos que gera snapshots dos valores dessas variáveis de status ao longo do tempo e as grava em uma tabela, juntamente com quaisquer alterações feitas desde o último snapshot. Essa infraestrutura é chamada de histórico de status global. Para obter mais informações, consulte [Gerenciar o histórico de status global do RDS para MySQL](Appendix.MySQL.CommonDBATasks.GoSH.md). Os procedimentos armazenados a seguir gerenciam a forma como o histórico de status global é coletado e mantido. **Topics** + [ ## mysql.rds\$1collect\$1global\$1status\$1history ](#mysql_rds_collect_global_status_history) + [ ## mysql.rds\$1disable\$1gsh\$1collector ](#mysql_rds_disable_gsh_collector) + [ ## mysql.rds\$1disable\$1gsh\$1rotation ](#mysql_rds_disable_gsh_rotation) + [ ## mysql.rds\$1enable\$1gsh\$1collector ](#mysql_rds_enable_gsh_collector) + [ ## mysql.rds\$1enable\$1gsh\$1rotation ](#mysql_rds_enable_gsh_rotation) + [ ## mysql.rds\$1rotate\$1global\$1status\$1history ](#mysql_rds_rotate_global_status_history) + [ ## mysql.rds\$1set\$1gsh\$1collector ](#mysql_rds_set_gsh_collector) + [ ## mysql.rds\$1set\$1gsh\$1rotation ](#mysql_rds_set_gsh_rotation) ## mysql.rds\$1collect\$1global\$1status\$1history Gera um snapshot sob demanda para o histórico de status global. ### Sintaxe ``` CALL mysql.rds_collect_global_status_history; ``` ## mysql.rds\$1disable\$1gsh\$1collector Desativa os snapshots gerados pelo histórico de status global. ### Sintaxe ``` CALL mysql.rds_disable_gsh_collector; ``` ## mysql.rds\$1disable\$1gsh\$1rotation Desativa a rotação da tabela `mysql.global_status_history`. ### Sintaxe ``` CALL mysql.rds_disable_gsh_rotation; ``` ## mysql.rds\$1enable\$1gsh\$1collector Ativa o histórico de status global para gerar snapshots padrão em intervalos especificados por `rds_set_gsh_collector`. ### Sintaxe ``` CALL mysql.rds_enable_gsh_collector; ``` ## mysql.rds\$1enable\$1gsh\$1rotation Ativa a rotação do conteúdo da tabela `mysql.global_status_history` com o da `mysql.global_status_history_old` em intervalos especificados por `rds_set_gsh_rotation`. ### Sintaxe ``` CALL mysql.rds_enable_gsh_rotation; ``` ## mysql.rds\$1rotate\$1global\$1status\$1history Reveza o conteúdo da tabela `mysql.global_status_history` para o da `mysql.global_status_history_old` sob demanda. ### Sintaxe ``` CALL mysql.rds_rotate_global_status_history; ``` ## mysql.rds\$1set\$1gsh\$1collector Especifica o intervalo em minutos entre os snapshots gerados pelo histórico de status global. ### Sintaxe ``` CALL mysql.rds_set_gsh_collector(intervalPeriod); ``` ### Parâmetros *intervalPeriod* O intervalo em minutos entre snapshots. O valor padrão é `5`. ## mysql.rds\$1set\$1gsh\$1rotation Especifica o intervalo em dias entre os revezamentos da tabela `mysql.global_status_history`. ### Sintaxe ``` CALL mysql.rds_set_gsh_rotation(intervalPeriod); ``` ### Parâmetros *intervalPeriod* O intervalo em dias entre os revezamentos da tabela. O valor padrão é `7`. # Configurar, iniciar e interromper a replicação de logs binários (binlogs) Os procedimentos armazenados a seguir controlam como as transações são replicadas de um banco de dados externo para o RDS para MySQL, ou do RDS para MySQL para um banco de dados externo. Ao usar esses procedimentos armazenados para gerenciar a replicação com um usuário de replicação configurado com `caching_sha2_password`, você deve configurar o TLS especificando `SOURCE_SSL=1`. `caching_sha2_password` é o plugin de autenticação padrão do RDS para MySQL 8.4. Para obter mais informações, consulte [Criptografia com SSL/TLS](mysql-ssl-connections.md). Para obter informações sobre como configurar, usar e gerenciar réplicas de leitura, consulte [Trabalhar com réplicas de leitura do MySQL](USER_MySQL.Replication.ReadReplicas.md). **Topics** + [ ## mysql.rds\$1next\$1master\$1log (RDS para MariaDB e versões principais 8.0 e anteriores do RDS para MySQL) ](#mysql_rds_next_master_log) + [ ## mysql.rds\$1next\$1source\$1log (RDS para MySQL versões principais 8.4 e posteriores) ](#mysql_rds_next_source_log) + [ ## mysql.rds\$1reset\$1external\$1master (RDS para MariaDB e RDS para MySQL versões principais 8.0 e anteriores) ](#mysql_rds_reset_external_master) + [ ## mysql.rds\$1reset\$1external\$1source (RDS para MySQL versões principais 8.4 e posteriores) ](#mysql_rds_reset_external_source) + [ ## mysql.rds\$1set\$1external\$1master (RDS para MariaDB e RDS para MySQL versões principais 8.0 e anteriores) ](#mysql_rds_set_external_master) + [ ## mysql.rds\$1set\$1external\$1source (RDS para MySQL versões principais 8.4 e posteriores) ](#mysql_rds_set_external_source) + [ ## mysql.rds\$1set\$1external\$1master\$1with\$1auto\$1position (RDS para MySQL versões principais 8.0 e anteriores) ](#mysql_rds_set_external_master_with_auto_position) + [ ## mysql.rds\$1set\$1external\$1source\$1with\$1auto\$1position (RDS para MySQL versões principais 8.4 e posteriores) ](#mysql_rds_set_external_source_with_auto_position) + [ ## mysql.rds\$1set\$1external\$1master\$1with\$1delay (RDS para MariaDB e RDS para MySQL versões principais 8.0 e anteriores) ](#mysql_rds_set_external_master_with_delay) + [ ## mysql.rds\$1set\$1external\$1source\$1with\$1delay (RDS para MySQL versões principais 8.4 e superiores) ](#mysql_rds_set_external_source_with_delay) + [ ## mysql.rds\$1set\$1external\$1source\$1gtid\$1purged ](#mysql_rds_set_external_source_gtid_purged) + [ ## mysql.rds\$1set\$1master\$1auto\$1position (versões principais 8.0 e anteriores do RDS para MySQL) ](#mysql_rds_set_master_auto_position) + [ ## mysql.rds\$1set\$1source\$1auto\$1position (RDS para MySQL versões principais 8.4 e posteriores) ](#mysql_rds_set_source_auto_position) + [ ## mysql.rds\$1set\$1source\$1delay ](#mysql_rds_set_source_delay) + [ ## mysql.rds\$1skip\$1repl\$1error ](#mysql_rds_skip_repl_error) + [ ## mysql.rds\$1start\$1replication ](#mysql_rds_start_replication) + [ ## mysql.rds\$1start\$1replication\$1until ](#mysql_rds_start_replication_until) + [ ## mysql.rds\$1stop\$1replication ](#mysql_rds_stop_replication) ## mysql.rds\$1next\$1master\$1log (RDS para MariaDB e versões principais 8.0 e anteriores do RDS para MySQL) Altera a posição do log da instância de banco de dados de origem para o início do próximo log binário na instância de banco de dados de origem. Use este procedimento somente se estiver recebendo o erro 1236 de E/S de replicação em uma réplica de leitura. ### Sintaxe ``` CALL mysql.rds_next_master_log( curr_master_log ); ``` ### Parâmetros *curr\$1master\$1log* O índice do arquivo de log mestre atual. Por exemplo, se o arquivo atual dor denominado `mysql-bin-changelog.012345`, o índice será 12345. Para determinar o nome do arquivo de log do mestre, execute o comando `SHOW REPLICA STATUS` e veja o campo `Master_Log_File`. ### Observações de uso O usuário mestre deve executar o procedimento `mysql.rds_next_master_log`. **Atenção** Chame `mysql.rds_next_master_log` somente se a replicação falhar após um failover de uma instância de banco de dados multi-AZ que for a origem da replicação, e o campo `Last_IO_Errno` do `SHOW REPLICA STATUS` reportar o erro 1236 de E/S. Chamar `mysql.rds_next_master_log` pode resultar em perda de dados na réplica de leitura caso as transações na instância de origem não tenham sido gravadas no log binário no disco antes do evento de failover. Você pode reduzir a chance de que isso aconteça configurando os parâmetros `sync_binlog` e `innodb_support_xa` da instância de origem como `1`, embora isso possa reduzir o desempenho. Para obter mais informações, consulte [Solucionar problemas de uma réplica de leitura do MySQL](USER_ReadRepl.Troubleshooting.md). ### Exemplos Suponha que a replicação falhe em uma réplica de leitura do RDS para MySQL. A execução de `SHOW REPLICA STATUS\G` na réplica de leitura retorna o seguinte resultado: ``` *************************** 1. row *************************** Replica_IO_State: Source_Host: myhost.XXXXXXXXXXXXXXX.rr-rrrr-1.rds.amazonaws.com Source_User: MasterUser Source_Port: 3306 Connect_Retry: 10 Source_Log_File: mysql-bin-changelog.012345 Read_Source_Log_Pos: 1219393 Relay_Log_File: relaylog.012340 Relay_Log_Pos: 30223388 Relay_Source_Log_File: mysql-bin-changelog.012345 Replica_IO_Running: No Replica_SQL_Running: Yes Replicate_Do_DB: Replicate_Ignore_DB: Replicate_Do_Table: Replicate_Ignore_Table: Replicate_Wild_Do_Table: Replicate_Wild_Ignore_Table: Last_Errno: 0 Last_Error: Skip_Counter: 0 Exec_Source_Log_Pos: 30223232 Relay_Log_Space: 5248928866 Until_Condition: None Until_Log_File: Until_Log_Pos: 0 Source_SSL_Allowed: No Source_SSL_CA_File: Source_SSL_CA_Path: Source_SSL_Cert: Source_SSL_Cipher: Source_SSL_Key: Seconds_Behind_Master: NULL Source_SSL_Verify_Server_Cert: No Last_IO_Errno: 1236 Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'Client requested master to start replication from impossible position; the first event 'mysql-bin-changelog.013406' at 1219393, the last event read from '/rdsdbdata/log/binlog/mysql-bin-changelog.012345' at 4, the last byte read from '/rdsdbdata/log/binlog/mysql-bin-changelog.012345' at 4.' Last_SQL_Errno: 0 Last_SQL_Error: Replicate_Ignore_Server_Ids: Source_Server_Id: 67285976 ``` O campo `Last_IO_Errno` mostra que a instância está recebendo o erro 1236 de E/S. O campo `Master_Log_File` mostra que o nome do arquivo é `mysql-bin-changelog.012345`, o que significa que o índice de arquivos de log é `12345`. Para resolver o erro, chame `mysql.rds_next_master_log` com o seguinte parâmetro: ``` CALL mysql.rds_next_master_log(12345); ``` ## mysql.rds\$1next\$1source\$1log (RDS para MySQL versões principais 8.4 e posteriores) Altera a posição do log da instância de banco de dados de origem para o início do próximo log binário na instância de banco de dados de origem. Use este procedimento somente se estiver recebendo o erro 1236 de E/S de replicação em uma réplica de leitura. ### Sintaxe ``` CALL mysql.rds_next_source_log( curr_source_log ); ``` ### Parâmetros *curr\$1source\$1log* O índice do arquivo de log de origem atual. Por exemplo, se o arquivo atual dor denominado `mysql-bin-changelog.012345`, o índice será 12345. Para determinar o nome do arquivo de log de origem atual, execute o comando `SHOW REPLICA STATUS` e veja o campo `Source_Log_File`. ### Observações de uso O usuário administrativo precisa executar o procedimento `mysql.rds_next_source_log`. **Atenção** Chame `mysql.rds_next_source_log` somente se a replicação falhar após um failover de uma instância de banco de dados multi-AZ que for a origem da replicação, e o campo `Last_IO_Errno` do `SHOW REPLICA STATUS` reportar o erro 1236 de E/S. Chamar `mysql.rds_next_source_log` pode resultar em perda de dados na réplica de leitura caso as transações na instância de origem não tenham sido gravadas no log binário no disco antes do evento de failover. Você pode reduzir a chance de que isso aconteça configurando os parâmetros `sync_binlog` e `innodb_support_xa` da instância de origem como `1`, embora isso possa reduzir o desempenho. Para obter mais informações, consulte [Solucionar problemas de uma réplica de leitura do MySQL](USER_ReadRepl.Troubleshooting.md). ### Exemplos Suponha que a replicação falhe em uma réplica de leitura do RDS para MySQL. A execução de `SHOW REPLICA STATUS\G` na réplica de leitura retorna o seguinte resultado: ``` *************************** 1. row *************************** Replica_IO_State: Source_Host: myhost.XXXXXXXXXXXXXXX.rr-rrrr-1.rds.amazonaws.com Source_User: MasterUser Source_Port: 3306 Connect_Retry: 10 Source_Log_File: mysql-bin-changelog.012345 Read_Source_Log_Pos: 1219393 Relay_Log_File: relaylog.012340 Relay_Log_Pos: 30223388 Relay_Source_Log_File: mysql-bin-changelog.012345 Replica_IO_Running: No Replica_SQL_Running: Yes Replicate_Do_DB: Replicate_Ignore_DB: Replicate_Do_Table: Replicate_Ignore_Table: Replicate_Wild_Do_Table: Replicate_Wild_Ignore_Table: Last_Errno: 0 Last_Error: Skip_Counter: 0 Exec_Source_Log_Pos: 30223232 Relay_Log_Space: 5248928866 Until_Condition: None Until_Log_File: Until_Log_Pos: 0 Source_SSL_Allowed: No Source_SSL_CA_File: Source_SSL_CA_Path: Source_SSL_Cert: Source_SSL_Cipher: Source_SSL_Key: Seconds_Behind_Source: NULL Source_SSL_Verify_Server_Cert: No Last_IO_Errno: 1236 Last_IO_Error: Got fatal error 1236 from source when reading data from binary log: 'Client requested source to start replication from impossible position; the first event 'mysql-bin-changelog.013406' at 1219393, the last event read from '/rdsdbdata/log/binlog/mysql-bin-changelog.012345' at 4, the last byte read from '/rdsdbdata/log/binlog/mysql-bin-changelog.012345' at 4.' Last_SQL_Errno: 0 Last_SQL_Error: Replicate_Ignore_Server_Ids: Source_Server_Id: 67285976 ``` O campo `Last_IO_Errno` mostra que a instância está recebendo o erro 1236 de E/S. O campo `Source_Log_File` mostra que o nome do arquivo é `mysql-bin-changelog.012345`, o que significa que o índice de arquivos de log é `12345`. Para resolver o erro, chame `mysql.rds_next_source_log` com o seguinte parâmetro: ``` CALL mysql.rds_next_source_log(12345); ``` ## mysql.rds\$1reset\$1external\$1master (RDS para MariaDB e RDS para MySQL versões principais 8.0 e anteriores) Reconfigura uma instância de banco de dados do RDS para MySQL para que não seja mais uma réplica de leitura de uma instância do MySQL executada fora do Amazon RDS. **Importante** Para executar esse procedimento, `autocommit` deve estar habilitado. Para habilitá-lo, defina o parâmetro `autocommit` como `1`. Para obter informações sobre como modificar parâmetros, consulte [Modificar parâmetros em um grupo de parâmetros de banco de dados no Amazon RDS](USER_WorkingWithParamGroups.Modifying.md). ### Sintaxe ``` CALL mysql.rds_reset_external_master; ``` ### Observações de uso O usuário mestre deve executar o procedimento `mysql.rds_reset_external_master`. Esse procedimento deve ser executado na instância de banco de dados MySQL a ser removida como a réplica de leitura de uma instância do MySQL sendo executada externamente ao Amazon RDS. **nota** Recomendamos que você use réplicas de leitura para gerenciar a replicação entre duas instâncias de banco de dados do Amazon RDS, sempre que possível. Quando você o fizer, recomendamos o uso somente desse e de outros procedimentos armazenados relacionados a replicação. Essas práticas permitem o uso de topologias de replicação mais complexas entre as instâncias de banco de dados do Amazon RDS. Oferecemos esses procedimentos armazenados principalmente para permitir a replicação com instâncias do MySQL externas ao Amazon RDS. Para obter informações sobre como gerenciar a replicação entre instâncias de banco de dados do Amazon RDS, consulte [Trabalhar com réplicas de leitura de instância de banco de dados](USER_ReadRepl.md). Para obter mais informações sobre como usar a replicação para importar dados de uma instância do MySQL sendo executada externamente ao Amazon RDS, consulte [Configurar a replicação da posição do arquivo de log binário com uma instância de origem externa](MySQL.Procedural.Importing.External.Repl.md). ## mysql.rds\$1reset\$1external\$1source (RDS para MySQL versões principais 8.4 e posteriores) Reconfigura uma instância de banco de dados do RDS para MySQL para que não seja mais uma réplica de leitura de uma instância do MySQL executada fora do Amazon RDS. **Importante** Para executar esse procedimento, `autocommit` deve estar habilitado. Para habilitá-lo, defina o parâmetro `autocommit` como `1`. Para obter informações sobre como modificar parâmetros, consulte [Modificar parâmetros em um grupo de parâmetros de banco de dados no Amazon RDS](USER_WorkingWithParamGroups.Modifying.md). ### Sintaxe ``` CALL mysql.rds_reset_external_source; ``` ### Observações de uso O usuário administrativo precisa executar o procedimento `mysql.rds_reset_external_source`. Esse procedimento deve ser executado na instância de banco de dados MySQL a ser removida como a réplica de leitura de uma instância do MySQL sendo executada externamente ao Amazon RDS. **nota** Recomendamos que você use réplicas de leitura para gerenciar a replicação entre duas instâncias de banco de dados do Amazon RDS, sempre que possível. Quando você o fizer, recomendamos o uso somente desse e de outros procedimentos armazenados relacionados a replicação. Essas práticas permitem o uso de topologias de replicação mais complexas entre as instâncias de banco de dados do Amazon RDS. Oferecemos esses procedimentos armazenados principalmente para permitir a replicação com instâncias do MySQL externas ao Amazon RDS. Para obter informações sobre como gerenciar a replicação entre instâncias de banco de dados do Amazon RDS, consulte [Trabalhar com réplicas de leitura de instância de banco de dados](USER_ReadRepl.md). Para obter mais informações sobre como usar a replicação para importar dados de uma instância do MySQL sendo executada externamente ao Amazon RDS, consulte [Configurar a replicação da posição do arquivo de log binário com uma instância de origem externa](MySQL.Procedural.Importing.External.Repl.md). ## mysql.rds\$1set\$1external\$1master (RDS para MariaDB e RDS para MySQL versões principais 8.0 e anteriores) Configura uma instância de banco de dados do RDS para MySQL para que seja uma réplica de leitura de uma instância do MySQL executada fora do Amazon RDS. **Importante** Para executar esse procedimento, `autocommit` deve estar habilitado. Para habilitá-lo, defina o parâmetro `autocommit` como `1`. Para obter informações sobre como modificar parâmetros, consulte [Modificar parâmetros em um grupo de parâmetros de banco de dados no Amazon RDS](USER_WorkingWithParamGroups.Modifying.md). **nota** É possível usar o procedimento armazenado [mysql.rds\$1set\$1external\$1master\$1with\$1delay (RDS para MariaDB e RDS para MySQL versões principais 8.0 e anteriores)](#mysql_rds_set_external_master_with_delay) para configurar uma instância de banco de dados de origem externa e uma replicação atrasada. ### Sintaxe ``` CALL mysql.rds_set_external_master ( host_name , host_port , replication_user_name , replication_user_password , mysql_binary_log_file_name , mysql_binary_log_file_location , ssl_encryption ); ``` ### Parâmetros *host\$1name* O nome de host ou o endereço IP da instância do MySQL executada externamente ao Amazon RDS que se tornará a instância de banco de dados de origem. *host\$1port* A porta usada para executar a instância do MySQL executada externamente ao Amazon RDS a ser configurada como a instância de banco de dados de origem. Se sua configuração de rede inclui replicação de porta Secure Shell (SSH) que converte o número da porta, especifique o número da porta exposto pelo SSH. *replication\$1user\$1name* O ID de um usuário com as permissões `REPLICATION CLIENT` e `REPLICATION SLAVE` na instância do MySQL executada externamente ao Amazon RDS. Recomendamos que você forneça uma conta que seja usada unicamente para a replicação com a instância externa. *replication\$1user\$1password* A senha do ID de usuário especificada em `replication_user_name`. *mysql\$1binary\$1log\$1file\$1name* O nome do log binário na instância de banco de dados de origem que contém as informações de replicação. *mysql\$1binary\$1log\$1file\$1location* O local no log binário `mysql_binary_log_file_name` no qual a replicação começa a ler as informações de replicação. É possível determinar o nome e a localização do arquivo de binlog executando `SHOW MASTER STATUS` na instância do banco de dados de origem. *ssl\$1encryption* Um valor que especifica se a criptografia do Secure Sockets Layer (SSL) será usada na conexão de replicação. 1 especifica para usar criptografia de SSL, 0 especifica para não usar criptografia. O padrão é 0. A opção `MASTER_SSL_VERIFY_SERVER_CERT` não tem suporte. Essa opção é definida como 0, o que significa que a conexão é criptografada, mas os certificados não são verificados. ### Observações de uso O usuário mestre deve executar o procedimento `mysql.rds_set_external_master`. Esse procedimento deve ser executado na instância de banco de dados MySQL que será configurada como a réplica de leitura de uma instância do MySQL externa ao Amazon RDS. Antes de executar `mysql.rds_set_external_master`, é necessário configurar a instância do MySQL executada externamente ao Amazon RDS para ser uma instância de banco de dados de origem. Para conectar-se à instância do MySQL sendo executada externamente ao Amazon RDS, você deve especificar valores de `replication_user_name` e `replication_user_password` que indicam um usuário de replicação com permissões de `REPLICATION CLIENT` e `REPLICATION SLAVE` na instância externa do MySQL. **Como configurar uma instância externa do MySQL como uma instância de banco de dados de origem** 1. Usando o cliente do MySQL de sua escolha, conecte-se à instância externa do MySQL e crie uma conta de usuário a ser usada para a replicação. Veja um exemplo a seguir. **MySQL 5.7** ``` CREATE USER 'repl_user'@'mydomain.com' IDENTIFIED BY 'password'; ``` **MySQL 8.0** ``` CREATE USER 'repl_user'@'mydomain.com' IDENTIFIED WITH mysql_native_password BY 'password'; ``` **nota** Especifique uma senha diferente do prompt mostrado aqui como prática recomendada de segurança. 1. Na instância externa do MySQL, conceda privilégios de `REPLICATION CLIENT` e `REPLICATION SLAVE` para seu usuário de replicação. O exemplo a seguir concede privilégios de `REPLICATION CLIENT` e `REPLICATION SLAVE` ao usuário 'repl\$1user' em todos os bancos de dados de seu domínio. **MySQL 5.7** ``` GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'mydomain.com' IDENTIFIED BY 'password'; ``` **MySQL 8.0** ``` GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'mydomain.com'; ``` Para usar a replicação criptografada, configure a instância de banco de dados de origem para usar conexões SSL. **nota** Recomendamos que você use réplicas de leitura para gerenciar a replicação entre duas instâncias de banco de dados do Amazon RDS, sempre que possível. Quando você o fizer, recomendamos o uso somente desse e de outros procedimentos armazenados relacionados a replicação. Essas práticas permitem o uso de topologias de replicação mais complexas entre as instâncias de banco de dados do Amazon RDS. Oferecemos esses procedimentos armazenados principalmente para permitir a replicação com instâncias do MySQL externas ao Amazon RDS. Para obter informações sobre como gerenciar a replicação entre instâncias de banco de dados do Amazon RDS, consulte [Trabalhar com réplicas de leitura de instância de banco de dados](USER_ReadRepl.md). Depois de chamar `mysql.rds_set_external_master` para configurar uma instância de banco de dados do Amazon RDS, é possível chamar [mysql.rds\$1start\$1replication](#mysql_rds_start_replication) na réplica de leitura para iniciar o processo de replicação. É possível chamar [mysql.rds\$1reset\$1external\$1master (RDS para MariaDB e RDS para MySQL versões principais 8.0 e anteriores)](#mysql_rds_reset_external_master) para remover a configuração da réplica de leitura. Quando `mysql.rds_set_external_master` é chamado, o Amazon RDS grava a hora, o usuário e uma ação do `set master` nas tabelas `mysql.rds_history` e `mysql.rds_replication_status`. ### Exemplos Ao executar em uma instância de banco de dados MySQL, o exemplo a seguir configura a instância do banco de dados para ser uma réplica de leitura de uma instância do MySQL que é executada externamente ao Amazon RDS. ``` call mysql.rds_set_external_master( 'Externaldb.some.com', 3306, 'repl_user', 'password', 'mysql-bin-changelog.0777', 120, 1); ``` ## mysql.rds\$1set\$1external\$1source (RDS para MySQL versões principais 8.4 e posteriores) Configura uma instância de banco de dados do RDS para MySQL para que seja uma réplica de leitura de uma instância do MySQL executada fora do Amazon RDS. **Importante** Para executar esse procedimento, `autocommit` deve estar habilitado. Para habilitá-lo, defina o parâmetro `autocommit` como `1`. Para obter informações sobre como modificar parâmetros, consulte [Modificar parâmetros em um grupo de parâmetros de banco de dados no Amazon RDS](USER_WorkingWithParamGroups.Modifying.md). ### Sintaxe ``` CALL mysql.rds_set_external_source ( host_name , host_port , replication_user_name , replication_user_password , mysql_binary_log_file_name , mysql_binary_log_file_location , ssl_encryption ); ``` ### Parâmetros *host\$1name* O nome de host ou o endereço IP da instância do MySQL executada externamente ao Amazon RDS que se tornará a instância de banco de dados de origem. *host\$1port* A porta usada para executar a instância do MySQL executada externamente ao Amazon RDS a ser configurada como a instância de banco de dados de origem. Se sua configuração de rede inclui replicação de porta Secure Shell (SSH) que converte o número da porta, especifique o número da porta exposto pelo SSH. *replication\$1user\$1name* O ID de um usuário com as permissões `REPLICATION CLIENT` e `REPLICATION SLAVE` na instância do MySQL executada externamente ao Amazon RDS. Recomendamos que você forneça uma conta que seja usada unicamente para a replicação com a instância externa. *replication\$1user\$1password* A senha do ID de usuário especificada em `replication_user_name`. *mysql\$1binary\$1log\$1file\$1name* O nome do log binário na instância de banco de dados de origem que contém as informações de replicação. *mysql\$1binary\$1log\$1file\$1location* O local no log binário `mysql_binary_log_file_name` no qual a replicação começa a ler as informações de replicação. É possível determinar o nome e a localização do arquivo de binlog executando `SHOW MASTER STATUS` na instância do banco de dados de origem. *ssl\$1encryption* Um valor que especifica se a criptografia do Secure Sockets Layer (SSL) será usada na conexão de replicação. 1 especifica para usar criptografia de SSL, 0 especifica para não usar criptografia. O padrão é 0. A opção `SOURCE_SSL_VERIFY_SERVER_CERT` não tem suporte. Essa opção é definida como 0, o que significa que a conexão é criptografada, mas os certificados não são verificados. ### Observações de uso O usuário administrativo precisa executar o procedimento `mysql.rds_set_external_source`. Esse procedimento deve ser executado na instância de banco de dados do RDS para MySQL que será configurada como a réplica de leitura de uma instância do MySQL externa ao Amazon RDS. Antes de executar `mysql.rds_set_external_source`, é necessário configurar a instância do MySQL executada externamente ao Amazon RDS para ser uma instância de banco de dados de origem. Para conectar-se à instância do MySQL sendo executada externamente ao Amazon RDS, você deve especificar valores de `replication_user_name` e `replication_user_password` que indicam um usuário de replicação com permissões de `REPLICATION CLIENT` e `REPLICATION SLAVE` na instância externa do MySQL. **Como configurar uma instância externa do MySQL como uma instância de banco de dados de origem** 1. Usando o cliente do MySQL de sua escolha, conecte-se à instância externa do MySQL e crie uma conta de usuário a ser usada para a replicação. Veja um exemplo a seguir. ``` CREATE USER 'repl_user'@'mydomain.com' IDENTIFIED BY 'password'; ``` **nota** Especifique uma senha diferente do prompt mostrado aqui como prática recomendada de segurança. 1. Na instância externa do MySQL, conceda privilégios de `REPLICATION CLIENT` e `REPLICATION SLAVE` para seu usuário de replicação. O exemplo a seguir concede privilégios de `REPLICATION CLIENT` e `REPLICATION SLAVE` ao usuário 'repl\$1user' em todos os bancos de dados de seu domínio. ``` GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'mydomain.com'; ``` Para usar a replicação criptografada, configure a instância de banco de dados de origem para usar conexões SSL. Além disso, importe o certificado de autoridade de certificação, o certificado e a chave de clientes na instância de banco de dados ou no cluster de banco de dados usando o procedimento [mysql.rds\$1import\$1binlog\$1ssl\$1material](url-rds-user;mysql_rds_import_binlog_ssl_material.html). **nota** Recomendamos que você use réplicas de leitura para gerenciar a replicação entre duas instâncias de banco de dados do Amazon RDS, sempre que possível. Quando você o fizer, recomendamos o uso somente desse e de outros procedimentos armazenados relacionados a replicação. Essas práticas permitem o uso de topologias de replicação mais complexas entre as instâncias de banco de dados do Amazon RDS. Oferecemos esses procedimentos armazenados principalmente para permitir a replicação com instâncias do MySQL externas ao Amazon RDS. Para obter informações sobre como gerenciar a replicação entre instâncias de banco de dados do Amazon RDS, consulte [Trabalhar com réplicas de leitura de instância de banco de dados](USER_ReadRepl.md). Depois de chamar `mysql.rds_set_external_source` para configurar uma instância de banco de dados do RDS para MySQL, é possível chamar [mysql.rds\$1start\$1replication](#mysql_rds_start_replication) na réplica de leitura para iniciar o processo de replicação. É possível chamar [mysql.rds\$1reset\$1external\$1source (RDS para MySQL versões principais 8.4 e posteriores)](#mysql_rds_reset_external_source) para remover a configuração da réplica de leitura. Quando `mysql.rds_set_external_source` é chamado, o Amazon RDS grava a hora, o usuário e uma ação do `set master` nas tabelas `mysql.rds_history` e `mysql.rds_replication_status`. ### Exemplos Quando executado em uma instância de banco de dados do RDS para MySQL, o exemplo a seguir configura a instância de banco de dados para ser uma réplica de leitura de uma instância do MySQL que é executada externamente ao Amazon RDS. ``` call mysql.rds_set_external_source( 'Externaldb.some.com', 3306, 'repl_user', 'password', 'mysql-bin-changelog.0777', 120, 1); ``` ## mysql.rds\$1set\$1external\$1master\$1with\$1auto\$1position (RDS para MySQL versões principais 8.0 e anteriores) Configura uma instância de banco de dados do RDS para MySQL para ser uma réplica de leitura de uma instância do MySQL executada externamente em relação ao Amazon RDS. Esse procedimento também configura a replicação atrasada e a replicação baseada em identificadores de transações globais (GTIDs). **Importante** Para executar esse procedimento, `autocommit` deve estar habilitado. Para habilitá-lo, defina o parâmetro `autocommit` como `1`. Para obter informações sobre como modificar parâmetros, consulte [Modificar parâmetros em um grupo de parâmetros de banco de dados no Amazon RDS](USER_WorkingWithParamGroups.Modifying.md). ### Sintaxe ``` CALL mysql.rds_set_external_master_with_auto_position ( host_name , host_port , replication_user_name , replication_user_password , ssl_encryption , delay ); ``` ### Parâmetros *host\$1name* O nome de host ou o endereço IP da instância do MySQL executada externamente ao Amazon RDS que se tornará a instância de banco de dados de origem. *host\$1port* A porta usada para executar a instância do MySQL executada externamente ao Amazon RDS a ser configurada como a instância de banco de dados de origem. Se sua configuração de rede inclui replicação de porta Secure Shell (SSH) que converte o número da porta, especifique o número da porta exposto pelo SSH. *replication\$1user\$1name* O ID de um usuário com as permissões `REPLICATION CLIENT` e `REPLICATION SLAVE` na instância do MySQL executada externamente ao Amazon RDS. Recomendamos que você forneça uma conta que seja usada unicamente para a replicação com a instância externa. *replication\$1user\$1password* A senha do ID de usuário especificada em `replication_user_name`. *ssl\$1encryption* Um valor que especifica se a criptografia do Secure Sockets Layer (SSL) será usada na conexão de replicação. 1 especifica para usar criptografia de SSL, 0 especifica para não usar criptografia. O padrão é 0. A opção `MASTER_SSL_VERIFY_SERVER_CERT` não tem suporte. Essa opção é definida como 0, o que significa que a conexão é criptografada, mas os certificados não são verificados. *delay* O número mínimo de segundos para atrasar a replicação da instância de banco de dados de origem. O limite para esse parâmetro é de um dia (86.400 segundos). ### Observações de uso O usuário mestre deve executar o procedimento `mysql.rds_set_external_master_with_auto_position`. Esse procedimento deve ser executado na instância de banco de dados MySQL que será configurada como a réplica de leitura de uma instância do MySQL externa ao Amazon RDS. Esse procedimento é compatível com todas as versões 5.7 do RDS para MySQL e com o RDS para MySQL 8.0.26 e versões 8.0 posteriores. Antes de executar `mysql.rds_set_external_master_with_auto_position`, é necessário configurar a instância do MySQL executada externamente ao Amazon RDS para ser uma instância de banco de dados de origem. Para conectar-se à instância do MySQL que é externa ao Amazon RDS, você deve especificar os valores de `replication_user_name` e `replication_user_password`. Esses valores devem indicar um usuário de replicação que tenha as permissões `REPLICATION CLIENT` e `REPLICATION SLAVE` na instância externa do MySQL. **Como configurar uma instância externa do MySQL como uma instância de banco de dados de origem** 1. Usando o cliente do MySQL de sua escolha, conecte-se à instância externa do MySQL e crie uma conta de usuário a ser usada para a replicação. Veja um exemplo a seguir. ``` CREATE USER 'repl_user'@'mydomain.com' IDENTIFIED BY 'SomePassW0rd' ``` 1. Na instância externa do MySQL, conceda privilégios de `REPLICATION CLIENT` e `REPLICATION SLAVE` para seu usuário de replicação. O exemplo a seguir concede privilégios de `REPLICATION CLIENT` e `REPLICATION SLAVE` ao usuário `'repl_user'` em todos os bancos de dados de seu domínio. ``` GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'mydomain.com' IDENTIFIED BY 'SomePassW0rd' ``` Para obter mais informações, consulte [Configurar a replicação da posição do arquivo de log binário com uma instância de origem externa](MySQL.Procedural.Importing.External.Repl.md). **nota** Recomendamos que você use réplicas de leitura para gerenciar a replicação entre duas instâncias de banco de dados do Amazon RDS, sempre que possível. Quando você o fizer, recomendamos o uso somente desse e de outros procedimentos armazenados relacionados a replicação. Essas práticas permitem o uso de topologias de replicação mais complexas entre as instâncias de banco de dados do Amazon RDS. Oferecemos esses procedimentos armazenados principalmente para permitir a replicação com instâncias do MySQL externas ao Amazon RDS. Para obter informações sobre como gerenciar a replicação entre instâncias de banco de dados do Amazon RDS, consulte [Trabalhar com réplicas de leitura de instância de banco de dados](USER_ReadRepl.md). Antes de chamar `mysql.rds_set_external_master_with_auto_position`, chame [mysql.rds\$1set\$1external\$1source\$1gtid\$1purged](#mysql_rds_set_external_source_gtid_purged) para definir a variável de sistema `gtid_purged` com um intervalo GTID especificado de uma fonte externa. Depois de chamar `mysql.rds_set_external_master_with_auto_position` para configurar uma instância de banco de dados do Amazon RDS, é possível chamar [mysql.rds\$1start\$1replication](#mysql_rds_start_replication) na réplica de leitura para iniciar o processo de replicação. É possível chamar [mysql.rds\$1reset\$1external\$1master (RDS para MariaDB e RDS para MySQL versões principais 8.0 e anteriores)](#mysql_rds_reset_external_master) para remover a configuração da réplica de leitura. Ao chamar `mysql.rds_set_external_master_with_auto_position`, o Amazon RDS registra a hora, o usuário e uma ação do `set master` nas tabelas `mysql.rds_history` e `mysql.rds_replication_status`. Para a recuperação de desastres, você pode usar esse procedimento com o procedimento armazenado [mysql.rds\$1start\$1replication\$1until](#mysql_rds_start_replication_until) ou o [mysql.rds\$1start\$1replication\$1until\$1gtid](mysql-stored-proc-gtid.md#mysql_rds_start_replication_until_gtid). Para efetuar roll forward de alterações para uma réplica de leitura atrasada no momento imediatamente antes de um desastre, é possível executar o procedimento `mysql.rds_set_external_master_with_auto_position`. Depois que o procedimento `mysql.rds_start_replication_until_gtid` interromper a replicação, é possível promover a réplica de leitura para ser a nova instância de banco de dados primária usando as instruções em [Promoção de uma réplica de leitura a uma instância de banco de dados autônoma](USER_ReadRepl.Promote.md). Para usar o procedimento `mysql.rds_rds_start_replication_until_gtid`, a replicação baseada em GTID deve estar habilitada. Para ignorar uma transação específica baseada em GTID que seja conhecida por causar desastres, use o procedimento armazenado [mysql.rds\$1skip\$1transaction\$1with\$1gtid](mysql-stored-proc-gtid.md#mysql_rds_skip_transaction_with_gtid). Para obter mais informações sobre como trabalhar com a replicação baseada em GTID, consulte [Usar a replicação baseada em GTID](mysql-replication-gtid.md). ### Exemplos Ao executar em uma instância de banco de dados MySQL, o exemplo a seguir configura a instância do banco de dados para ser uma réplica de leitura de uma instância do MySQL que é executada externamente ao Amazon RDS. Ele define o atraso mínimo de replicação como uma hora (3.600 segundos) na instância de banco de dados MySQL. Uma alteração da instância do banco de dados de origem MySQL executada externamente ao Amazon RDS não é aplicada à réplica de leitura da instância de banco de dados MySQL por pelo menos uma hora. ``` call mysql.rds_set_external_master_with_auto_position( 'Externaldb.some.com', 3306, 'repl_user', 'SomePassW0rd', 1, 3600); ``` ## mysql.rds\$1set\$1external\$1source\$1with\$1auto\$1position (RDS para MySQL versões principais 8.4 e posteriores) Configura uma instância de banco de dados do RDS para MySQL para ser uma réplica de leitura de uma instância do MySQL executada externamente em relação ao Amazon RDS. Esse procedimento também configura a replicação atrasada e a replicação baseada em identificadores de transações globais (GTIDs). **Importante** Para executar esse procedimento, `autocommit` deve estar habilitado. Para habilitá-lo, defina o parâmetro `autocommit` como `1`. Para obter informações sobre como modificar parâmetros, consulte [Modificar parâmetros em um grupo de parâmetros de banco de dados no Amazon RDS](USER_WorkingWithParamGroups.Modifying.md). ### Sintaxe ``` CALL mysql.rds_set_external_source_with_auto_position ( host_name , host_port , replication_user_name , replication_user_password , ssl_encryption , delay ); ``` ### Parâmetros *host\$1name* O nome de host ou o endereço IP da instância do MySQL executada externamente ao Amazon RDS que se tornará a instância de banco de dados de origem. *host\$1port* A porta usada para executar a instância do MySQL executada externamente ao Amazon RDS a ser configurada como a instância de banco de dados de origem. Se sua configuração de rede inclui replicação de porta Secure Shell (SSH) que converte o número da porta, especifique o número da porta exposto pelo SSH. *replication\$1user\$1name* O ID de um usuário com as permissões `REPLICATION CLIENT` e `REPLICATION SLAVE` na instância do MySQL executada externamente ao Amazon RDS. Recomendamos que você forneça uma conta que seja usada unicamente para a replicação com a instância externa. *replication\$1user\$1password* A senha do ID de usuário especificada em `replication_user_name`. *ssl\$1encryption* Um valor que especifica se a criptografia do Secure Sockets Layer (SSL) será usada na conexão de replicação. 1 especifica para usar criptografia de SSL, 0 especifica para não usar criptografia. O padrão é 0. A opção `SOURCE_SSL_VERIFY_SERVER_CERT` não tem suporte. Essa opção é definida como 0, o que significa que a conexão é criptografada, mas os certificados não são verificados. *delay* O número mínimo de segundos para atrasar a replicação da instância de banco de dados de origem. O limite para esse parâmetro é de um dia (86.400 segundos). ### Observações de uso O usuário administrativo precisa executar o procedimento `mysql.rds_set_external_source_with_auto_position`. Esse procedimento deve ser executado na instância de banco de dados MySQL que será configurada como a réplica de leitura de uma instância do MySQL externa ao Amazon RDS. Antes de executar `mysql.rds_set_external_source_with_auto_position`, é necessário configurar a instância do MySQL executada externamente ao Amazon RDS para ser uma instância de banco de dados de origem. Para conectar-se à instância do MySQL que é externa ao Amazon RDS, você deve especificar os valores de `replication_user_name` e `replication_user_password`. Esses valores devem indicar um usuário de replicação que tenha as permissões `REPLICATION CLIENT` e `REPLICATION SLAVE` na instância externa do MySQL. **Como configurar uma instância externa do MySQL como uma instância de banco de dados de origem** 1. Usando o cliente do MySQL de sua escolha, conecte-se à instância externa do MySQL e crie uma conta de usuário a ser usada para a replicação. Veja um exemplo a seguir. ``` CREATE USER 'repl_user'@'mydomain.com' IDENTIFIED BY 'SomePassW0rd' ``` 1. Na instância externa do MySQL, conceda privilégios de `REPLICATION CLIENT` e `REPLICATION SLAVE` para seu usuário de replicação. O exemplo a seguir concede privilégios de `REPLICATION CLIENT` e `REPLICATION SLAVE` ao usuário `'repl_user'` em todos os bancos de dados de seu domínio. ``` GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'mydomain.com' IDENTIFIED BY 'SomePassW0rd' ``` Para obter mais informações, consulte [Configurar a replicação da posição do arquivo de log binário com uma instância de origem externa](MySQL.Procedural.Importing.External.Repl.md). **nota** Recomendamos que você use réplicas de leitura para gerenciar a replicação entre duas instâncias de banco de dados do Amazon RDS, sempre que possível. Quando você o fizer, recomendamos o uso somente desse e de outros procedimentos armazenados relacionados a replicação. Essas práticas permitem o uso de topologias de replicação mais complexas entre as instâncias de banco de dados do Amazon RDS. Oferecemos esses procedimentos armazenados principalmente para permitir a replicação com instâncias do MySQL externas ao Amazon RDS. Para obter informações sobre como gerenciar a replicação entre instâncias de banco de dados do Amazon RDS, consulte [Trabalhar com réplicas de leitura de instância de banco de dados](USER_ReadRepl.md). Antes de chamar `mysql.rds_set_external_source_with_auto_position`, chame [mysql.rds\$1set\$1external\$1source\$1gtid\$1purged](#mysql_rds_set_external_source_gtid_purged) para definir a variável de sistema `gtid_purged` com um intervalo GTID especificado de uma fonte externa. Depois de chamar `mysql.rds_set_external_source_with_auto_position` para configurar uma instância de banco de dados do Amazon RDS, é possível chamar [mysql.rds\$1start\$1replication](#mysql_rds_start_replication) na réplica de leitura para iniciar o processo de replicação. É possível chamar [mysql.rds\$1reset\$1external\$1source (RDS para MySQL versões principais 8.4 e posteriores)](#mysql_rds_reset_external_source) para remover a configuração da réplica de leitura. Ao chamar `mysql.rds_set_external_source_with_auto_position`, o Amazon RDS registra a hora, o usuário e uma ação do `set master` nas tabelas `mysql.rds_history` e `mysql.rds_replication_status`. Para a recuperação de desastres, você pode usar esse procedimento com o procedimento armazenado [mysql.rds\$1start\$1replication\$1until](#mysql_rds_start_replication_until) ou o [mysql.rds\$1start\$1replication\$1until\$1gtid](mysql-stored-proc-gtid.md#mysql_rds_start_replication_until_gtid). Para efetuar roll forward de alterações para uma réplica de leitura atrasada no momento imediatamente antes de um desastre, é possível executar o procedimento `mysql.rds_set_external_source_with_auto_position`. Depois que o procedimento `mysql.rds_start_replication_until_gtid` interromper a replicação, é possível promover a réplica de leitura para ser a nova instância de banco de dados primária usando as instruções em [Promoção de uma réplica de leitura a uma instância de banco de dados autônoma](USER_ReadRepl.Promote.md). Para usar o procedimento `mysql.rds_rds_start_replication_until_gtid`, a replicação baseada em GTID deve estar habilitada. Para ignorar uma transação específica baseada em GTID que seja conhecida por causar desastres, use o procedimento armazenado [mysql.rds\$1skip\$1transaction\$1with\$1gtid](mysql-stored-proc-gtid.md#mysql_rds_skip_transaction_with_gtid). Para obter mais informações sobre como trabalhar com a replicação baseada em GTID, consulte [Usar a replicação baseada em GTID](mysql-replication-gtid.md). ### Exemplos Ao executar em uma instância de banco de dados MySQL, o exemplo a seguir configura a instância do banco de dados para ser uma réplica de leitura de uma instância do MySQL que é executada externamente ao Amazon RDS. Ele define o atraso mínimo de replicação como uma hora (3.600 segundos) na instância de banco de dados MySQL. Uma alteração da instância do banco de dados de origem MySQL executada externamente ao Amazon RDS não é aplicada à réplica de leitura da instância de banco de dados MySQL por pelo menos uma hora. ``` call mysql.rds_set_external_source_with_auto_position( 'Externaldb.some.com', 3306, 'repl_user', 'SomePassW0rd', 1, 3600); ``` ## mysql.rds\$1set\$1external\$1master\$1with\$1delay (RDS para MariaDB e RDS para MySQL versões principais 8.0 e anteriores) Configura uma instância de banco de dados do RDS para MySQL para ser uma réplica de leitura de uma instância do MySQL executada externamente em relação ao Amazon RDS e configura a replicação atrasada. **Importante** Para executar esse procedimento, `autocommit` deve estar habilitado. Para habilitá-lo, defina o parâmetro `autocommit` como `1`. Para obter informações sobre como modificar parâmetros, consulte [Modificar parâmetros em um grupo de parâmetros de banco de dados no Amazon RDS](USER_WorkingWithParamGroups.Modifying.md). ### Sintaxe ``` CALL mysql.rds_set_external_master_with_delay( host_name , host_port , replication_user_name , replication_user_password , mysql_binary_log_file_name , mysql_binary_log_file_location , ssl_encryption , delay ); ``` ### Parâmetros *host\$1name* O nome de host ou o endereço IP da instância do MySQL executada externamente ao Amazon RDS que se tornará a instância de banco de dados de origem. *host\$1port* A porta usada para executar a instância do MySQL executada externamente ao Amazon RDS a ser configurada como a instância de banco de dados de origem. Se sua configuração de rede inclui replicação de porta SSH que converte o número da porta, especifique o número da porta exposto pelo SSH. *replication\$1user\$1name* O ID de um usuário com as permissões `REPLICATION CLIENT` e `REPLICATION SLAVE` na instância do MySQL executada externamente ao Amazon RDS. Recomendamos que você forneça uma conta que seja usada unicamente para a replicação com a instância externa. *replication\$1user\$1password* A senha do ID de usuário especificada em `replication_user_name`. *mysql\$1binary\$1log\$1file\$1name* O nome do log binário na instância de banco de dados de origem contém as informações de replicação. *mysql\$1binary\$1log\$1file\$1location* O local no log binário `mysql_binary_log_file_name` no qual a replicação começará a ler as informações de replicação. É possível determinar o nome e a localização do arquivo de binlog executando `SHOW MASTER STATUS` na instância do banco de dados de origem. *ssl\$1encryption* Um valor que especifica se a criptografia do Secure Sockets Layer (SSL) será usada na conexão de replicação. 1 especifica para usar criptografia de SSL, 0 especifica para não usar criptografia. O padrão é 0. A opção `MASTER_SSL_VERIFY_SERVER_CERT` não tem suporte. Essa opção é definida como 0, o que significa que a conexão é criptografada, mas os certificados não são verificados. *delay* O número mínimo de segundos para atrasar a replicação da instância de banco de dados de origem. O limite para esse parâmetro é de um dia (86.400 segundos). ### Observações de uso O usuário mestre deve executar o procedimento `mysql.rds_set_external_master_with_delay`. Esse procedimento deve ser executado na instância de banco de dados MySQL que será configurada como a réplica de leitura de uma instância do MySQL externa ao Amazon RDS. Antes de executar `mysql.rds_set_external_master_with_delay`, é necessário configurar a instância do MySQL executada externamente ao Amazon RDS para ser uma instância de banco de dados de origem. Para conectar-se à instância do MySQL que é externa ao Amazon RDS, você deve especificar os valores de `replication_user_name` e `replication_user_password`. Esses valores devem indicar um usuário de replicação que tenha as permissões `REPLICATION CLIENT` e `REPLICATION SLAVE` na instância externa do MySQL. **Como configurar uma instância externa do MySQL como uma instância de banco de dados de origem** 1. Usando o cliente do MySQL de sua escolha, conecte-se à instância externa do MySQL e crie uma conta de usuário a ser usada para a replicação. Veja um exemplo a seguir. ``` CREATE USER 'repl_user'@'mydomain.com' IDENTIFIED BY 'SomePassW0rd' ``` 1. Na instância externa do MySQL, conceda privilégios de `REPLICATION CLIENT` e `REPLICATION SLAVE` para seu usuário de replicação. O exemplo a seguir concede privilégios de `REPLICATION CLIENT` e `REPLICATION SLAVE` ao usuário `'repl_user'` em todos os bancos de dados de seu domínio. ``` GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'mydomain.com' IDENTIFIED BY 'SomePassW0rd' ``` Para obter mais informações, consulte [Configurar a replicação da posição do arquivo de log binário com uma instância de origem externa](MySQL.Procedural.Importing.External.Repl.md). **nota** Recomendamos que você use réplicas de leitura para gerenciar a replicação entre duas instâncias de banco de dados do Amazon RDS, sempre que possível. Quando você o fizer, recomendamos o uso somente desse e de outros procedimentos armazenados relacionados a replicação. Essas práticas permitem o uso de topologias de replicação mais complexas entre as instâncias de banco de dados do Amazon RDS. Oferecemos esses procedimentos armazenados principalmente para permitir a replicação com instâncias do MySQL externas ao Amazon RDS. Para obter informações sobre como gerenciar a replicação entre instâncias de banco de dados do Amazon RDS, consulte [Trabalhar com réplicas de leitura de instância de banco de dados](USER_ReadRepl.md). Depois de chamar `mysql.rds_set_external_master_with_delay` para configurar uma instância de banco de dados do Amazon RDS, é possível chamar [mysql.rds\$1start\$1replication](#mysql_rds_start_replication) na réplica de leitura para iniciar o processo de replicação. É possível chamar [mysql.rds\$1reset\$1external\$1master (RDS para MariaDB e RDS para MySQL versões principais 8.0 e anteriores)](#mysql_rds_reset_external_master) para remover a configuração da réplica de leitura. Ao chamar `mysql.rds_set_external_master_with_delay`, o Amazon RDS registra a hora, o usuário e uma ação do `set master` nas tabelas `mysql.rds_history` e `mysql.rds_replication_status`. Para a recuperação de desastres, você pode usar esse procedimento com o procedimento armazenado [mysql.rds\$1start\$1replication\$1until](#mysql_rds_start_replication_until) ou o [mysql.rds\$1start\$1replication\$1until\$1gtid](mysql-stored-proc-gtid.md#mysql_rds_start_replication_until_gtid). Para efetuar roll forward de alterações para uma réplica de leitura atrasada no momento imediatamente antes de um desastre, é possível executar o procedimento `mysql.rds_set_external_master_with_delay`. Depois que o procedimento `mysql.rds_start_replication_until` interromper a replicação, é possível promover a réplica de leitura para ser a nova instância de banco de dados primária usando as instruções em [Promoção de uma réplica de leitura a uma instância de banco de dados autônoma](USER_ReadRepl.Promote.md). Para usar o procedimento `mysql.rds_rds_start_replication_until_gtid`, a replicação baseada em GTID deve estar habilitada. Para ignorar uma transação específica baseada em GTID que seja conhecida por causar desastres, use o procedimento armazenado [mysql.rds\$1skip\$1transaction\$1with\$1gtid](mysql-stored-proc-gtid.md#mysql_rds_skip_transaction_with_gtid). Para obter mais informações sobre como trabalhar com a replicação baseada em GTID, consulte [Usar a replicação baseada em GTID](mysql-replication-gtid.md). O procedimento `mysql.rds_set_external_master_with_delay` está disponível nestas versões do RDS para MySQL: + MySQL 8.0.26 e versões 8.0 posteriores + Todas as versões 5.7 ### Exemplos Ao executar em uma instância de banco de dados MySQL, o exemplo a seguir configura a instância do banco de dados para ser uma réplica de leitura de uma instância do MySQL que é executada externamente ao Amazon RDS. Ele define o atraso mínimo de replicação como uma hora (3.600 segundos) na instância de banco de dados MySQL. Uma alteração da instância do banco de dados de origem MySQL executada externamente ao Amazon RDS não é aplicada à réplica de leitura da instância de banco de dados MySQL por pelo menos uma hora. ``` call mysql.rds_set_external_master_with_delay( 'Externaldb.some.com', 3306, 'repl_user', 'SomePassW0rd', 'mysql-bin-changelog.000777', 120, 1, 3600); ``` ## mysql.rds\$1set\$1external\$1source\$1with\$1delay (RDS para MySQL versões principais 8.4 e superiores) Configura uma instância de banco de dados do RDS para MySQL para ser uma réplica de leitura de uma instância do MySQL executada externamente em relação ao Amazon RDS e configura a replicação atrasada. **Importante** Para executar esse procedimento, `autocommit` deve estar habilitado. Para habilitá-lo, defina o parâmetro `autocommit` como `1`. Para obter informações sobre como modificar parâmetros, consulte [Modificar parâmetros em um grupo de parâmetros de banco de dados no Amazon RDS](USER_WorkingWithParamGroups.Modifying.md). ### Sintaxe ``` CALL mysql.rds_set_external_source_with_delay ( host_name , host_port , replication_user_name , replication_user_password , mysql_binary_log_file_name , mysql_binary_log_file_location , ssl_encryption , delay ); ``` ### Parâmetros *host\$1name* O nome de host ou o endereço IP da instância do MySQL executada externamente ao Amazon RDS que se tornará a instância de banco de dados de origem. *host\$1port* A porta usada para executar a instância do MySQL executada externamente ao Amazon RDS a ser configurada como a instância de banco de dados de origem. Se sua configuração de rede inclui replicação de porta SSH que converte o número da porta, especifique o número da porta exposto pelo SSH. *replication\$1user\$1name* O ID de um usuário com as permissões `REPLICATION CLIENT` e `REPLICATION SLAVE` na instância do MySQL executada externamente ao Amazon RDS. Recomendamos que você forneça uma conta que seja usada unicamente para a replicação com a instância externa. *replication\$1user\$1password* A senha do ID de usuário especificada em `replication_user_name`. *mysql\$1binary\$1log\$1file\$1name* O nome do log binário na instância de banco de dados de origem contém as informações de replicação. *mysql\$1binary\$1log\$1file\$1location* O local no log binário `mysql_binary_log_file_name` no qual a replicação começará a ler as informações de replicação. É possível determinar o nome e a localização do arquivo de binlog executando `SHOW MASTER STATUS` na instância do banco de dados de origem. *ssl\$1encryption* Um valor que especifica se a criptografia do Secure Sockets Layer (SSL) será usada na conexão de replicação. 1 especifica para usar criptografia de SSL, 0 especifica para não usar criptografia. O padrão é 0. A opção `SOURCE_SSL_VERIFY_SERVER_CERT` não tem suporte. Essa opção é definida como 0, o que significa que a conexão é criptografada, mas os certificados não são verificados. *delay* O número mínimo de segundos para atrasar a replicação da instância de banco de dados de origem. O limite para esse parâmetro é de um dia (86.400 segundos). ### Observações de uso O usuário administrativo precisa executar o procedimento `mysql.rds_set_external_source_with_delay`. Esse procedimento deve ser executado na instância de banco de dados MySQL que será configurada como a réplica de leitura de uma instância do MySQL externa ao Amazon RDS. Antes de executar `mysql.rds_set_external_source_with_delay`, é necessário configurar a instância do MySQL executada externamente ao Amazon RDS para ser uma instância de banco de dados de origem. Para conectar-se à instância do MySQL que é externa ao Amazon RDS, você deve especificar os valores de `replication_user_name` e `replication_user_password`. Esses valores devem indicar um usuário de replicação que tenha as permissões `REPLICATION CLIENT` e `REPLICATION SLAVE` na instância externa do MySQL. **Como configurar uma instância externa do MySQL como uma instância de banco de dados de origem** 1. Usando o cliente do MySQL de sua escolha, conecte-se à instância externa do MySQL e crie uma conta de usuário a ser usada para a replicação. Veja um exemplo a seguir. ``` CREATE USER 'repl_user'@'mydomain.com' IDENTIFIED BY 'SomePassW0rd' ``` 1. Na instância externa do MySQL, conceda privilégios de `REPLICATION CLIENT` e `REPLICATION SLAVE` para seu usuário de replicação. O exemplo a seguir concede privilégios de `REPLICATION CLIENT` e `REPLICATION SLAVE` ao usuário `'repl_user'` em todos os bancos de dados de seu domínio. ``` GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'mydomain.com' IDENTIFIED BY 'SomePassW0rd' ``` Para obter mais informações, consulte [Configurar a replicação da posição do arquivo de log binário com uma instância de origem externa](MySQL.Procedural.Importing.External.Repl.md). **nota** Recomendamos que você use réplicas de leitura para gerenciar a replicação entre duas instâncias de banco de dados do Amazon RDS, sempre que possível. Quando você o fizer, recomendamos o uso somente desse e de outros procedimentos armazenados relacionados a replicação. Essas práticas permitem o uso de topologias de replicação mais complexas entre as instâncias de banco de dados do Amazon RDS. Oferecemos esses procedimentos armazenados principalmente para permitir a replicação com instâncias do MySQL externas ao Amazon RDS. Para obter informações sobre como gerenciar a replicação entre instâncias de banco de dados do Amazon RDS, consulte [Trabalhar com réplicas de leitura de instância de banco de dados](USER_ReadRepl.md). Depois de chamar `mysql.rds_set_external_source_with_delay` para configurar uma instância de banco de dados do Amazon RDS, é possível chamar [mysql.rds\$1start\$1replication](#mysql_rds_start_replication) na réplica de leitura para iniciar o processo de replicação. É possível chamar [mysql.rds\$1reset\$1external\$1source (RDS para MySQL versões principais 8.4 e posteriores)](#mysql_rds_reset_external_source) para remover a configuração da réplica de leitura. Ao chamar `mysql.rds_set_external_source_with_delay`, o Amazon RDS registra a hora, o usuário e uma ação do `set master` nas tabelas `mysql.rds_history` e `mysql.rds_replication_status`. Para a recuperação de desastres, você pode usar esse procedimento com o procedimento armazenado [mysql.rds\$1start\$1replication\$1until](#mysql_rds_start_replication_until) ou o [mysql.rds\$1start\$1replication\$1until\$1gtid](mysql-stored-proc-gtid.md#mysql_rds_start_replication_until_gtid). Para efetuar roll forward de alterações para uma réplica de leitura atrasada no momento imediatamente antes de um desastre, é possível executar o procedimento `mysql.rds_set_external_source_with_delay`. Depois que o procedimento `mysql.rds_start_replication_until` interromper a replicação, é possível promover a réplica de leitura para ser a nova instância de banco de dados primária usando as instruções em [Promoção de uma réplica de leitura a uma instância de banco de dados autônoma](USER_ReadRepl.Promote.md). Para usar o procedimento `mysql.rds_rds_start_replication_until_gtid`, a replicação baseada em GTID deve estar habilitada. Para ignorar uma transação específica baseada em GTID que seja conhecida por causar desastres, use o procedimento armazenado [mysql.rds\$1skip\$1transaction\$1with\$1gtid](mysql-stored-proc-gtid.md#mysql_rds_skip_transaction_with_gtid). Para obter mais informações sobre como trabalhar com a replicação baseada em GTID, consulte [Usar a replicação baseada em GTID](mysql-replication-gtid.md). ### Exemplos Ao executar em uma instância de banco de dados MySQL, o exemplo a seguir configura a instância do banco de dados para ser uma réplica de leitura de uma instância do MySQL que é executada externamente ao Amazon RDS. Ele define o atraso mínimo de replicação como uma hora (3.600 segundos) na instância de banco de dados MySQL. Uma alteração da instância do banco de dados de origem MySQL executada externamente ao Amazon RDS não é aplicada à réplica de leitura da instância de banco de dados MySQL por pelo menos uma hora. ``` call mysql.rds_set_external_source_with_delay( 'Externaldb.some.com', 3306, 'repl_user', 'SomePassW0rd', 'mysql-bin-changelog.000777', 120, 1, 3600); ``` ## mysql.rds\$1set\$1external\$1source\$1gtid\$1purged Define a variável de sistema [gtid\$1purged](https://dev.mysql.com/doc/refman/8.0/en/replication-options-gtids.html#sysvar_gtid_purged) com um intervalo GTID especificado de uma fonte externa. O valor `gtid_purged` é necessário para configurar a replicação baseada em GTID para retomar a replicação usando posicionamento automático. **Importante** Para executar esse procedimento, `autocommit` deve estar habilitado. Para habilitá-lo, defina o parâmetro `autocommit` como `1`. Para obter informações sobre como modificar parâmetros, consulte [Modificar parâmetros em um grupo de parâmetros de banco de dados no Amazon RDS](USER_WorkingWithParamGroups.Modifying.md). ### Sintaxe ``` CALL mysql.rds_set_external_source_gtid_purged( server_uuid , start_pos , end_pos ); ``` ### Parâmetros *server\$1uuid* O identificador universalmente exclusivo (UID) do servidor externo do qual o intervalo GTID está sendo importado. *start\$1pos* A posição inicial do intervalo GTID a ser definida. *end\$1pos* A posição final do intervalo GTID a ser definida. ### Observações de uso O procedimento `mysql.rds_set_external_source_gtid_purged` só está disponível com o MySQL 8.0.37 e versões 8.0 posteriores. Chame `mysql.rds_set_external_source_gtid_purged` antes de chamar [mysql.rds\$1set\$1external\$1master\$1with\$1auto\$1position (RDS para MySQL versões principais 8.0 e anteriores)](#mysql_rds_set_external_master_with_auto_position), [mysql.rds\$1set\$1external\$1source\$1with\$1auto\$1position (RDS para MySQL versões principais 8.4 e posteriores)](#mysql_rds_set_external_source_with_auto_position) ou [mysql.rds\$1set\$1external\$1source\$1with\$1auto\$1position\$1for\$1channel](mysql-stored-proc-multi-source-replication.md#mysql_rds_set_external_source_with_auto_position_for_channel). Antes de chamar `mysql.rds_set_external_source_gtid_purged`, interrompa todos os canais de replicação ativos do banco de dados. Para conferir o status de um canal, use a declaração `SHOW REPLICA STATUS` MySQL. Para interromper a replicação em um canal, chame [mysql.rds\$1stop\$1replication\$1for\$1channel](mysql-stored-proc-multi-source-replication.md#mysql_rds_stop_replication_for_channel). O intervalo GTID especificado deverá ser um superconjunto do valor `GTID_PURGED` existente. Esse procedimento armazenado confere os seguintes valores antes de definir o valor `GTID_PURGED`: + O `server_uuid` é válido. + O valor de `start_pos` é maior que `0` e menor que o valor de `end_pos`. + O valor de `end_pos` é maior ou igual ao valor de `start_pos`. Se o conjunto de GTID no servidor externo contiver vários intervalos de valores, pense em chamar o procedimento várias vezes com valores de conjunto de GTID diferentes. Ao chamar `mysql.rds_set_external_source_gtid_purged`, o Amazon RDS registra a hora, o usuário e uma ação do `set gtid_purged` na tabela `mysql.rds_history`. Se você não definir o valor `gtid_purged` adequadamente para o backup utilizado para replicação, isso poderá gerar transações perdidas ou duplicadas durante o processo de replicação. Execute as etapas a seguir para corrigir o valor `gtid_purged`. **Como definir o valor gtid\$1purged na réplica** 1. Determine o ponto no tempo ou o arquivo de backup específico a ser usado como ponto de partida para a replicação. Pode ser um backup lógico (um arquivo mysqldump) ou físico (um snapshot do Amazon RDS). 1. Determine o valor `gtid_executed`. Esse valor representa o conjunto de todos os GTIDs que foram confirmados no servidor. Para recuperar esse valor, na instância de origem, faça o seguinte: + Execute a declaração `SELECT @@GLOBAL.GTID_EXECUTED;` SQL no momento em que o backup foi feito. + Se alguma opção relacionada estiver incluída no respectivo utilitário de backup, extraia o valor do arquivo de backup. Para ter mais informações, consulte a opção [set-gtid-purged](https://dev.mysql.com/doc/refman/8.4/en/mysqldump.html#option_mysqldump_set-gtid-purged) na documentação do MySQL. 1. Determine o valor `gtid_purged` a ser usado para a chamada para `mysql.rds_set_external_source_gtid_purged`. O valor `gtid_purged` deve incluir todos os GTIDs que foram executados na instância de origem e que não são mais necessários para a replicação. Portanto, o valor `gtid_purged` deve ser um subconjunto do valor `gtid_executed` recuperado na etapa anterior. Para determinar o valor `gtid_purged`, identifique os GTIDs que não estão incluídos no backup e não são mais necessários para a replicação. É possível fazer isso analisando os logs binários ou usando uma ferramenta, como mysqlbinlog, para encontrar os GTIDs que foram removidos dos logs binários. Se você tiver um backup consistente que inclua todos os logs binários até o ponto de backup, também será possível definir o valor `gtid_purged` como igual ao valor `gtid_executed` no ponto de backup. 1. Depois de determinar o valor `gtid_purged` apropriado que seja consistente com o backup, chame o procedimento armazenado `mysql.rds_set_external_source_gtid_purged` na sua instância de banco de dados do RDS para MySQL para definir o valor. ### Exemplos Quando executado em uma instância de banco de dados do MySQL, o exemplo a seguir define o intervalo GTID de um servidor MySQL externo com o UUID `12345678-abcd-1234-efgh-123456789abc`, uma posição inicial de `1` e uma posição final de `100`. O valor do GTID resultante é definido como `+12345678-abcd-1234-efgh-123456789abc:1-100`. ``` CALL mysql.rds_set_external_source_gtid_purged('12345678-abcd-1234-efgh-123456789abc', 1, 100); ``` ## mysql.rds\$1set\$1master\$1auto\$1position (versões principais 8.0 e anteriores do RDS para MySQL) Define o modo de replicação de base nas posições do arquivo de log binário ou nos identificadores de transações globais (GTIDs). ### Sintaxe ``` CALL mysql.rds_set_master_auto_position ( auto_position_mode ); ``` ### Parâmetros *auto\$1position\$1mode* Um valor que indica se será usada a replicação de posição do arquivo de log ou a replicação com base no GTID: + `0`: usar o método de replicação com base na posição do arquivo de log binário. O padrão é `0`. + `1`: usar o método de replicação com base no GTID. ### Observações de uso O usuário principal deve executar o procedimento `mysql.rds_set_master_auto_position`. Esse procedimento é compatível com todas as versões 5.7 do RDS para MySQL e com o RDS para MySQL 8.0.26 e versões 8.0 posteriores. ## mysql.rds\$1set\$1source\$1auto\$1position (RDS para MySQL versões principais 8.4 e posteriores) Define o modo de replicação de base nas posições do arquivo de log binário ou nos identificadores de transações globais (GTIDs). ### Sintaxe ``` CALL mysql.rds_set_source_auto_position (auto_position_mode); ``` ### Parâmetros *auto\$1position\$1mode* Um valor que indica se será usada a replicação de posição do arquivo de log ou a replicação com base no GTID: + `0`: usar o método de replicação com base na posição do arquivo de log binário. O padrão é `0`. + `1`: usar o método de replicação com base no GTID. ### Observações de uso O usuário administrativo precisa executar o procedimento `mysql.rds_set_source_auto_position`. ## mysql.rds\$1set\$1source\$1delay Define o número mínimo de segundos para atrasar a replicação da instância de banco de dados de origem para a réplica de leitura atual. Use esse procedimento quando estiver conectado a uma réplica de leitura para atrasar a replicação da instância de banco de dados de origem. ### Sintaxe ``` CALL mysql.rds_set_source_delay( delay ); ``` ### Parâmetros *delay* O número mínimo de segundos para atrasar a replicação da instância de banco de dados de origem. O limite para esse parâmetro é de um dia (86.400 segundos). ### Observações de uso O usuário mestre deve executar o procedimento `mysql.rds_set_source_delay`. Para a recuperação de desastres, você pode usar esse procedimento com o procedimento armazenado [mysql.rds\$1start\$1replication\$1until](#mysql_rds_start_replication_until) ou o [mysql.rds\$1start\$1replication\$1until\$1gtid](mysql-stored-proc-gtid.md#mysql_rds_start_replication_until_gtid). Para efetuar roll forward de alterações para uma réplica de leitura atrasada no momento imediatamente antes de um desastre, é possível executar o procedimento `mysql.rds_set_source_delay`. Depois que o procedimento `mysql.rds_start_replication_until` ou `mysql.rds_start_replication_until_gtid` interromper a replicação, é possível promover a réplica de leitura para ser a nova instância de banco de dados primária usando as instruções em [Promoção de uma réplica de leitura a uma instância de banco de dados autônoma](USER_ReadRepl.Promote.md). Para usar o procedimento `mysql.rds_rds_start_replication_until_gtid`, a replicação baseada em GTID deve estar habilitada. Para ignorar uma transação específica baseada em GTID que seja conhecida por causar desastres, use o procedimento armazenado [mysql.rds\$1skip\$1transaction\$1with\$1gtid](mysql-stored-proc-gtid.md#mysql_rds_skip_transaction_with_gtid). Para obter mais informações sobre a replicação baseada em GTID, consulte [Usar a replicação baseada em GTID](mysql-replication-gtid.md). O procedimento `mysql.rds_set_source_delay` está disponível nestas versões do RDS para MySQL: + Todas as versões do RDS para MySQL 8.4 + MySQL 8.0.26 e versões 8.0 posteriores + Todas as versões 5.7 ### Exemplos Para atrasar a replicação da instância de banco de dados de origem para a réplica de leitura atual por pelo menos uma hora (3.600 segundos), é possível chamar `mysql.rds_set_source_delay` com o seguinte parâmetro: ``` CALL mysql.rds_set_source_delay(3600); ``` ## mysql.rds\$1skip\$1repl\$1error Ignora e exclui um erro de replicação em uma réplica de leitura de banco de dados MySQL. ### Sintaxe ``` CALL mysql.rds_skip_repl_error; ``` ### Observações de uso O usuário principal deve executar o procedimento `mysql.rds_skip_repl_error` em uma réplica de leitura. Para obter mais informações sobre esse procedimento, consulte [Chamando o procedimento mysql.rds\$1skip\$1repl\$1error](Appendix.MySQL.CommonDBATasks.SkipError.md#Appendix.MySQL.CommonDBATasks.SkipError.procedure). Para determinar se há erros, execute o comando `SHOW REPLICA STATUS\G` do MySQL. Se um erro de replicação não for crítico, execute `mysql.rds_skip_repl_error` para ignorá-lo. Se houver vários, `mysql.rds_skip_repl_error` exclui o primeiro erro, depois avisa que há outros ainda. Assim, você pode usar `SHOW REPLICA STATUS\G` para determinar o plano de ação correto para o próximo erro. Para obter informações sobre os valores retornados, consulte [Instrução SHOW REPLICA STATUS](https://dev.mysql.com/doc/refman/8.0/en/show-replica-status.html) na documentação do MySQL. Para obter mais informações sobre como lidar com erros de replicação no Amazon RDS, consulte [Solucionar problemas de uma réplica de leitura do MySQL](USER_ReadRepl.Troubleshooting.md). #### Erro de replicação interrompida Ao chamar o procedimento `mysql.rds_skip_repl_error`, você pode receber uma mensagem de erro informando que a réplica está inativa ou desativada. Essa mensagem de erro aparece quando você executa o procedimento na instância primária em vez da réplica de leitura. Você deve executar esse procedimento na réplica de leitura para que o procedimento funcione. Essa mensagem de erro também poderá aparecer se você executar o procedimento na réplica de leitura, mas a replicação não poderá ser reiniciada com êxito. Se você precisar ignorar um grande número de erros, o atraso de replicação poderá aumentar além do período de retenção padrão para arquivos de log binário (binlog). Nesse caso, você poderá encontrar um erro fatal, com os arquivos binlog sendo limpos antes de sua reprodução na réplica de leitura. Essa remoção faz com que a replicação pare, e você não consegue chamar o comando `mysql.rds_skip_repl_error` para ignorar erros de replicação. É possível mitigar esse problema aumentando o número de horas em que os arquivos binlog são retidos na instância de banco de dados de origem. Após aumentar o período de retenção de log binário, você pode reiniciar a replicação e chamar o comando `mysql.rds_skip_repl_error` conforme necessário. Para definir o período de retenção do binlog, use o procedimento [mysql.rds\$1set\$1configuration](mysql-stored-proc-configuring.md#mysql_rds_set_configuration) e especifique um parâmetro de configuração `'binlog retention hours'`, juntamente com o número de horas de retenção dos arquivos binlog no cluster do banco de dados. O exemplo a seguir define o período de retenção para arquivos de log binário em 48 horas. ``` CALL mysql.rds_set_configuration('binlog retention hours', 48); ``` ## mysql.rds\$1start\$1replication Inicia a replicação de uma instância de banco de dados do RDS para MySQL. **nota** Você pode usar o procedimento armazenado [mysql.rds\$1start\$1replication\$1until](#mysql_rds_start_replication_until) ou [mysql.rds\$1start\$1replication\$1until\$1gtid](mysql-stored-proc-gtid.md#mysql_rds_start_replication_until_gtid) para iniciar a replicação de uma instância de banco de dados do RDS para MySQL e interromper a replicação no local do arquivo de log binário especificado. ### Sintaxe ``` CALL mysql.rds_start_replication; ``` ### Observações de uso O usuário principal deve executar o procedimento `mysql.rds_start_replication`. Para importar dados de uma instância do MySQL fora do Amazon RDS, chame `mysql.rds_start_replication` na réplica de leitura para iniciar o processo de replicação depois de ter chamado [mysql.rds\$1set\$1external\$1master (RDS para MariaDB e RDS para MySQL versões principais 8.0 e anteriores)](#mysql_rds_set_external_master) ou [mysql.rds\$1set\$1external\$1source (RDS para MySQL versões principais 8.4 e posteriores)](#mysql_rds_set_external_source) para criar a configuração de replicação. Para obter mais informações, consulte [Restaurar um backup em uma instância de banco de dados do Amazon RDS para MySQL](MySQL.Procedural.Importing.md). Para exportar dados para uma instância do MySQL fora do Amazon RDS, chame `mysql.rds_start_replication` e `mysql.rds_stop_replication` na réplica de leitura para controlar algumas ações de replicação, como a remoção de logs binários. Para obter mais informações, consulte [Exportar dados de uma instância de banco de dados MySQL usando replicação](MySQL.Procedural.Exporting.NonRDSRepl.md). Também é possível chamar `mysql.rds_start_replication` na réplica de leitura para reiniciar qualquer processo de replicação que tenha sido interrompido anteriormente chamando `mysql.rds_stop_replication`. Para obter mais informações, consulte [Trabalhar com réplicas de leitura de instância de banco de dados](USER_ReadRepl.md). ## mysql.rds\$1start\$1replication\$1until Inicia a replicação de uma instância de banco de dados do RDS para MySQL e interrompe a replicação no local do arquivo de log binário especificado. ### Sintaxe ``` CALL mysql.rds_start_replication_until ( replication_log_file , replication_stop_point ); ``` ### Parâmetros *replication\$1log\$1file* O nome do log binário na instância de banco de dados de origem que contém as informações de replicação. *replication\$1stop\$1point * O local no log binário `replication_log_file` no qual a replicação será interrompida. ### Observações de uso O usuário mestre deve executar o procedimento `mysql.rds_start_replication_until`. O procedimento `mysql.rds_start_replication_until` está disponível nestas versões do RDS for MySQL: + Todas as versões do RDS para MySQL 8.4 + MySQL 8.0.26 e versões 8.0 posteriores + Todas as versões 5.7 Você pode usar esse procedimento com a replicação atrasada para recuperação de desastres. Se você tiver a replicação atrasada configurada, use esse procedimento para efetuar roll forward de alterações em uma réplica de leitura atrasada para o momento imediatamente antes de um desastre. Depois que esse procedimento interromper a replicação, é possível promover a réplica de leitura para ser a nova instância de banco de dados primária usando as instruções em [Promoção de uma réplica de leitura a uma instância de banco de dados autônoma](USER_ReadRepl.Promote.md). Você pode configurar a replicação atrasada usando os seguintes procedimentos armazenados: + [mysql.rds\$1set\$1configuration](mysql-stored-proc-configuring.md#mysql_rds_set_configuration) + [mysql.rds\$1set\$1external\$1master\$1with\$1delay (RDS para MariaDB e RDS para MySQL versões principais 8.0 e anteriores)](#mysql_rds_set_external_master_with_delay) + [mysql.rds\$1set\$1external\$1source\$1with\$1delay (RDS para MySQL versões principais 8.4 e superiores)](#mysql_rds_set_external_source_with_delay) + [mysql.rds\$1set\$1source\$1delay](#mysql_rds_set_source_delay) O nome do arquivo especificado para o parâmetro `replication_log_file` deve corresponder ao nome do arquivo do log binário da instância de banco de dados de origem. Quando o parâmetro `replication_stop_point` especifica um local de parada no passado, a replicação é interrompida imediatamente. ### Exemplos O exemplo a seguir inicia a replicação e replica as alterações até que ela atinja o local `120` no arquivo de log binário `mysql-bin-changelog.000777`. ``` call mysql.rds_start_replication_until( 'mysql-bin-changelog.000777', 120); ``` ## mysql.rds\$1stop\$1replication Interrompe a replicação de uma instância de banco de dados MySQL. ### Sintaxe ``` CALL mysql.rds_stop_replication; ``` ### Observações de uso O usuário mestre deve executar o procedimento `mysql.rds_stop_replication`. Se você estiver configurando a replicação para importar dados de uma instância do MySQL em execução externamente ao Amazon RDS, chame `mysql.rds_stop_replication` na réplica de leitura para encerrar o processo de replicação após a importação ter sido concluída. Para obter mais informações, consulte [Restaurar um backup em uma instância de banco de dados do Amazon RDS para MySQL](MySQL.Procedural.Importing.md). Se estiver configurando a replicação para exportar dados para uma instância do MySQL externa ao Amazon RDS, chame `mysql.rds_start_replication` e `mysql.rds_stop_replication` na réplica de leitura para controlar algumas ações de replicação, como a remoção de logs binários. Para obter mais informações, consulte [Exportar dados de uma instância de banco de dados MySQL usando replicação](MySQL.Procedural.Exporting.NonRDSRepl.md). Você também pode usar `mysql.rds_stop_replication` para parar uma replicação entre duas instâncias de banco de dados do Amazon RDS. Normalmente, você interrompe a replicação para executar uma operação de execução longa na réplica de leitura, como ao criar um índice grande na réplica de leitura. Também é possível reiniciar qualquer processo de replicação que tenha sido interrompido chamando [mysql.rds\$1start\$1replication](#mysql_rds_start_replication) na réplica de leitura. Para obter mais informações, consulte [Trabalhar com réplicas de leitura de instância de banco de dados](USER_ReadRepl.md). # Encerrar uma sessão ou consulta Os procedimentos armazenados a seguir encerram uma sessão ou consulta. **Topics** + [ ## mysql.rds\$1kill ](#mysql_rds_kill) + [ ## mysql.rds\$1kill\$1query ](#mysql_rds_kill_query) ## mysql.rds\$1kill Encerra uma conexão ao servidor MySQL. ### Sintaxe ``` CALL mysql.rds_kill(processID); ``` ### Parâmetros *processID* A identidade do thread de conexão a ser encerrada. ### Observações de uso Cada conexão ao servidor do MySQL é executada em um thread separado. Para encerrar uma conexão, use o procedimento `mysql.rds_kill` e passe o ID de thread dessa conexão. Para obter o ID de thread, use o comando [SHOW PROCESSLIST](https://dev.mysql.com/doc/refman/8.0/en/show-processlist.html) do MySQL. Para receber informações sobre limitações, consulte [Limitações de procedimentos armazenados do MySQL](MySQL.KnownIssuesAndLimitations.md#MySQL.Concepts.KnownIssuesAndLimitations.KillProcedures). ### Exemplos O exemplo a seguir encerra uma conexão com um ID de thread de 4243: ``` CALL mysql.rds_kill(4243); ``` ## mysql.rds\$1kill\$1query Encerra uma consulta em execução no servidor MySQL. ### Sintaxe ``` CALL mysql.rds_kill_query(processID); ``` ### Parâmetros *processID* A identidade do processo ou thread que está executando a consulta a ser encerrada. ### Observações de uso Para encerrar uma consulta em execução no servidor MySQL, use o procedimento `mysql_rds_kill_query` e passe o ID do thread que está executando a consulta. O procedimento então encerra a conexão. Para obter o ID, consulte a [tabela INFORMATION\$1SCHEMA PROCESSLIST](https://dev.mysql.com/doc/refman/8.0/en/information-schema-processlist-table.html) do MySQL ou use o comando [SHOW PROCESSLIST](https://dev.mysql.com/doc/refman/8.0/en/show-processlist.html) do MySQL. O valor na coluna ID de `SHOW PROCESSLIST` ou `SELECT * FROM INFORMATION_SCHEMA.PROCESSLIST` é *processID*. Para receber informações sobre limitações, consulte [Limitações de procedimentos armazenados do MySQL](MySQL.KnownIssuesAndLimitations.md#MySQL.Concepts.KnownIssuesAndLimitations.KillProcedures). ### Exemplos O seguinte exemplo encerra uma consulta com um ID de thread de consulta 230040: ``` CALL mysql.rds_kill_query(230040); ``` # Gerenciar clusters ativos-ativos Os procedimentos armazenados a seguir configuram e gerenciam clusters ativos-ativos do RDS para MySQL. Para ter mais informações, consulte [Configurar clusters ativos-ativos para RDS para MySQL](mysql-active-active-clusters.md). Esses procedimentos armazenados só estão disponíveis com as instâncias de banco de dados do RDS para MySQL que executam as seguintes versões: + Todas as versões do MySQL 8.4 + MySQL 8.0.35 e versões secundárias posteriores **Topics** + [ ## mysql.rds\$1group\$1replication\$1advance\$1gtid ](#mysql_rds_group_replication_advance_gtid) + [ ## mysql.rds\$1group\$1replication\$1create\$1user ](#mysql_rds_group_replication_create_user) + [ ## mysql.rds\$1group\$1replication\$1set\$1recovery\$1channel ](#mysql_rds_group_replication_set_recovery_channel) + [ ## mysql.rds\$1group\$1replication\$1start ](#mysql_rds_group_replication_start) + [ ## mysql.rds\$1group\$1replication\$1stop ](#mysql_rds_group_replication_stop) ## mysql.rds\$1group\$1replication\$1advance\$1gtid Cria GTIDs de espaço reservado na instância de banco de dados atual. ### Sintaxe ``` CALL mysql.rds_group_replication_advance_gtid( begin_id , end_id , server_uuid ); ``` ### Parâmetros *begin\$1id* O ID da transação inicial a ser criado. *end\$1id* O ID da transação final a ser criado. *begin\$1id* O `group_replication_group_name` da transação final a ser criado. O `group_replication_group_name` é especificada como um UUID no grupo de parâmetros de banco de dados associado à instância de banco de dados. ### Observações de uso Em um cluster ativo-ativo, para que uma instância de banco de dados ingresse em um grupo, todas as transações GTID executadas na nova instância de banco de dados devem existir nos outros membros do cluster. Em casos incomuns, uma nova instância de banco de dados pode ter mais transações a serem agrupadas quando as transações são executadas antes de ingressar na instância. Nesse caso, não é possível remover nenhuma transação existente, mas é possível usar esse procedimento para criar os GTIDs de espaço reservado correspondentes nas outras instâncias de banco de dados do grupo. Antes de fazer isso, verifique se as transações *não afetam os dados replicados*. Ao chamar esse procedimento, as transações GTID do `server_uuid:begin_id-end_id` são criadas com conteúdo vazio. Para evitar problemas de replicação, não use esse procedimento em nenhuma outra condição. **Importante** Evite chamar esse procedimento quando o cluster ativo-ativo estiver funcionando normalmente. Não chame esse procedimento a menos que você entenda as possíveis consequências das transações que está criando. Chamar esse procedimento pode gerar dados inconsistentes. ### Exemplo O seguinte exemplo cria GTIDs de espaço reservado na instância de banco de dados atual: ``` CALL mysql.rds_group_replication_advance_gtid(5, 6, '11111111-2222-3333-4444-555555555555'); ``` ## mysql.rds\$1group\$1replication\$1create\$1user Cria o usuário de replicação `rdsgrprepladmin` para replicação do grupo na instância de banco de dados. ### Sintaxe ``` CALL mysql.rds_group_replication_create_user( replication_user_password ); ``` ### Parâmetros *replication\$1user\$1password* A senha do usuário de replicação `rdsgrprepladmin`. ### Observações de uso + A senha do usuário de replicação `rdsgrprepladmin` deve ser a mesma em todas as instâncias de banco de dados em um cluster ativo-ativo. + O nome do usuário `rdsgrprepladmin` é reservado para conexões da replicação do grupo. Nenhum outro usuário, incluindo o usuário principal, pode ter esse nome de usuário. ### Exemplo O seguinte exemplo cria o usuário de replicação `rdsgrprepladmin` para replicação do grupo na instância de banco de dados: ``` CALL mysql.rds_group_replication_create_user('password'); ``` ## mysql.rds\$1group\$1replication\$1set\$1recovery\$1channel Define o canal `group_replication_recovery` para um cluster ativo-ativo. O procedimento utiliza o usuário reservado `rdsgrprepladmin` para configurar o canal. ### Sintaxe ``` CALL mysql.rds_group_replication_set_recovery_channel( replication_user_password); ``` ### Parâmetros *replication\$1user\$1password* A senha do usuário de replicação `rdsgrprepladmin`. ### Observações de uso A senha do usuário de replicação `rdsgrprepladmin` deve ser a mesma em todas as instâncias de banco de dados em um cluster ativo-ativo. Uma chamada para o `mysql.rds_group_replication_create_user` especifica a senha. ### Exemplo O seguinte exemplo define o canal `group_replication_recovery` para um cluster ativo-ativo: ``` CALL mysql.rds_group_replication_set_recovery_channel('password'); ``` ## mysql.rds\$1group\$1replication\$1start Inicia a replicação do grupo na instância de banco de dados atual. ### Sintaxe ``` CALL mysql.rds_group_replication_start( bootstrap ); ``` ### Parâmetros *bootstrap* Um valor que especifica se deve inicializar um novo grupo ou ingressar em um grupo existente. `1` inicializa um novo grupo com a instância de banco de dados atual. `0` insere a instância de banco de dados atual em um grupo existente conectando-se aos endpoints definidos no parâmetro `group_replication_group_seeds` no grupo de parâmetros do banco de dados associado à instância de banco de dados. ### Exemplo O seguinte exemplo inicializa um novo grupo com a instância de banco de dados atual: ``` CALL mysql.rds_group_replication_start(1); ``` ## mysql.rds\$1group\$1replication\$1stop Interrompe a replicação do grupo na instância de banco de dados atual. ### Sintaxe ``` CALL mysql.rds_group_replication_stop(); ``` ### Observações de uso A interrupção da replicação em uma instância de banco de dados não afeta nenhuma outra instância de banco de dados no cluster ativo-ativo. # Gerenciar a replicação de várias fontes Os procedimentos armazenados a seguir configuram e gerenciam canais de replicação em uma réplica de várias fontes do RDS para MySQL. Para ter mais informações, consulte [Configurar a replicação de várias fontes do Amazon RDS para MySQL](mysql-multi-source-replication.md). Esses procedimentos armazenados só estão disponíveis com as instâncias de banco de dados do RDS para MySQL que executam as seguintes versões de mecanismo: + Todas as versões 8.4 + 8.0.35 e versões secundárias posteriores + 5.7.44 e versões secundárias posteriores Ao usar procedimentos armazenados para gerenciar a replicação com um usuário de replicação configurado com `caching_sha2_passwword`, você deve configurar o TLS especificando `SOURCE_SSL=1`. `caching_sha2_password` é o plugin de autenticação padrão do RDS para MySQL 8.4. **nota** Embora essa documentação se refira às instâncias de banco de dados de origem como instâncias de banco de dados do RDS para MySQL, esses procedimentos também funcionam para instâncias do MySQL executadas fora do Amazon RDS. **Topics** + [ ## mysql.rds\$1next\$1source\$1log\$1for\$1channel ](#mysql_rds_next_source_log_for_channel) + [ ## mysql.rds\$1reset\$1external\$1source\$1for\$1channel ](#mysql_rds_reset_external_source_for_channel) + [ ## mysql.rds\$1set\$1external\$1source\$1for\$1channel ](#mysql_rds_set_external_source_for_channel) + [ ## mysql.rds\$1set\$1external\$1source\$1with\$1auto\$1position\$1for\$1channel ](#mysql_rds_set_external_source_with_auto_position_for_channel) + [ ## mysql.rds\$1set\$1external\$1source\$1with\$1delay\$1for\$1channel ](#mysql_rds_set_external_source_with_delay_for_channel) + [ ## mysql.rds\$1set\$1source\$1auto\$1position\$1for\$1channel ](#mysql_rds_set_source_auto_position_for_channel) + [ ## mysql.rds\$1set\$1source\$1delay\$1for\$1channel ](#mysql_rds_set_source_delay_for_channel) + [ ## mysql.rds\$1skip\$1repl\$1error\$1for\$1channel ](#mysql_rds_skip_repl_error_for_channel) + [ ## mysql.rds\$1start\$1replication\$1for\$1channel ](#mysql_rds_start_replication_for_channel) + [ ## mysql.rds\$1start\$1replication\$1until\$1for\$1channel ](#mysql_rds_start_replication_until_for_channel) + [ ## mysql.rds\$1start\$1replication\$1until\$1gtid\$1for\$1channel ](#mysql_rds_start_replication_until_gtid_for_channel) + [ ## mysql.rds\$1stop\$1replication\$1for\$1channel ](#mysql_rds_stop_replication_for_channel) ## mysql.rds\$1next\$1source\$1log\$1for\$1channel Altera a posição do log da instância de banco de dados de origem para o início do próximo log binário na instância de banco de dados de origem. Use esse procedimento somente se estiver recebendo o erro 1236 de E/S de replicação em uma réplica de várias fontes. ### Sintaxe ``` CALL mysql.rds_next_source_log_for_channel( curr_master_log, channel_name ); ``` ### Parâmetros *curr\$1master\$1log* O índice do arquivo de log de origem atual. Por exemplo, se o arquivo atual dor denominado `mysql-bin-changelog.012345`, o índice será 12345. Para determinar o nome do arquivo de log de origem atual, execute o comando `SHOW REPLICA STATUS FOR CHANNEL 'channel_name'` e veja o campo `Source_Log_File`. *channel\$1name* O nome do canal de replicação na réplica de várias fontes. Cada canal de replicação recebe os eventos de logs binários de uma única instância de banco de dados do RDS para MySQL de origem executada em uma porta e um host específicos. ### Observações de uso O usuário principal deve executar o procedimento `mysql.rds_next_source_log_for_channel`. Se houver um erro IO\$1thread, por exemplo, será possível usar esse procedimento para ignorar todos os eventos no arquivo de log binário atual e retomar a replicação do próximo arquivo de log binário para o canal especificado em `channel_name`. ### Exemplo Suponha que a replicação falhe em um canal em uma réplica de várias fontes. A execução de `SHOW REPLICA STATUS FOR CHANNEL 'channel_1'\G` na réplica de leitura exibe o seguinte resultado: ``` mysql> SHOW REPLICA STATUS FOR CHANNEL 'channel_1'\G *************************** 1. row *************************** Replica_IO_State: Waiting for source to send event Source_Host: myhost.XXXXXXXXXXXXXXX.rr-rrrr-1.rds.amazonaws.com Source_User: ReplicationUser Source_Port: 3306 Connect_Retry: 60 Source_Log_File: mysql-bin-changelog.012345 Read_Source_Log_Pos: 1219393 Relay_Log_File: replica-relay-bin.000003 Relay_Log_Pos: 30223388 Relay_Source_Log_File: mysql-bin-changelog.012345 Replica_IO_Running: No Replica_SQL_Running: Yes Replicate_Do_DB:. . . Last_IO_Errno: 1236 Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'Client requested master to start replication from impossible position; the first event 'mysql-bin-changelog.013406' at 1219393, the last event read from '/rdsdbdata/log/binlog/mysql-bin-changelog.012345' at 4, the last byte read from '/rdsdbdata/log/binlog/mysql-bin-changelog.012345' at 4.' Last_SQL_Errno: 0 Last_SQL_Error: . . Channel_name: channel_1 . . -- Some fields are omitted in this example output ``` O campo `Last_IO_Errno` mostra que a instância está recebendo o erro 1236 de E/S. O campo `Source_Log_File` mostra que o nome do arquivo é `mysql-bin-changelog.012345`, o que significa que o índice de arquivos de log é `12345`. Para resolver o erro, chame `mysql.rds_next_source_log_for_channel` com os seguintes parâmetros: ``` CALL mysql.rds_next_source_log_for_channel(12345,'channel_1'); ``` ## mysql.rds\$1reset\$1external\$1source\$1for\$1channel Interrompe o processo de replicação no canal especificado e remove o canal e as configurações associadas da réplica de várias fontes. **Importante** Para executar esse procedimento, `autocommit` deve estar habilitado. Para habilitá-lo, defina o parâmetro `autocommit` como `1`. Para obter informações sobre como modificar parâmetros, consulte [Modificar parâmetros em um grupo de parâmetros de banco de dados no Amazon RDS](USER_WorkingWithParamGroups.Modifying.md). ### Sintaxe ``` CALL mysql.rds_reset_external_source_for_channel (channel_name); ``` ### Parâmetros *channel\$1name* O nome do canal de replicação na réplica de várias fontes. Cada canal de replicação recebe os eventos de logs binários de uma única instância de banco de dados do RDS para MySQL de origem executada em uma porta e um host específicos. ### Observações de uso O usuário principal deve executar o procedimento `mysql.rds_reset_external_source_for_channel`. Esse procedimento exclui todos os registros de retransmissão pertencentes ao canal que está sendo removido. ## mysql.rds\$1set\$1external\$1source\$1for\$1channel Configura um canal de replicação em uma instância de banco de dados do RDS para MySQL para replicar os dados de outra instância de banco de dados do RDS para MySQL. **Importante** Para executar esse procedimento, `autocommit` deve estar habilitado. Para habilitá-lo, defina o parâmetro `autocommit` como `1`. Para obter informações sobre como modificar parâmetros, consulte [Modificar parâmetros em um grupo de parâmetros de banco de dados no Amazon RDS](USER_WorkingWithParamGroups.Modifying.md). **nota** Em vez disso, é possível usar o procedimento armazenado [mysql.rds\$1set\$1external\$1source\$1with\$1delay\$1for\$1channel](#mysql_rds_set_external_source_with_delay_for_channel) para configurar esse canal com replicação atrasada. ### Sintaxe ``` CALL mysql.rds_set_external_source_for_channel ( host_name , host_port , replication_user_name , replication_user_password , mysql_binary_log_file_name , mysql_binary_log_file_location , ssl_encryption , channel_name ); ``` ### Parâmetros *host\$1name* O nome de host ou o endereço IP da instância de banco de dados do RDS para MySQL. *host\$1port* A porta usada pela instância de banco de dados do RDS para MySQL. Se sua configuração de rede inclui replicação de porta Secure Shell (SSH) que converte o número da porta, especifique o número da porta exposto pelo SSH. *replication\$1user\$1name* O ID de um usuário com as permissões `REPLICATION CLIENT` e `REPLICATION SLAVE` na instância de banco de dados de origem do RDS para MySQL. Recomendamos fornecer uma conta que seja usada unicamente para a replicação com a instância de banco de dados de origem. *replication\$1user\$1password* A senha do ID de usuário especificada em `replication_user_name`. *mysql\$1binary\$1log\$1file\$1name* O nome do log binário na instância de banco de dados de origem que contém as informações de replicação. *mysql\$1binary\$1log\$1file\$1location* O local no log binário `mysql_binary_log_file_name` no qual a replicação começa a ler as informações de replicação. É possível determinar o nome e a localização do arquivo de binlog executando `SHOW BINARY LOG STATUS` na instância do banco de dados de origem. As versões anteriores do MySQL usavam `SHOW MASTER STATUS` em vez de `SHOW BINARY LOG STATUS`. Se você estiver usando uma versão do MySQL anterior à 8.4, use `SHOW MASTER STATUS`. *ssl\$1encryption* Um valor que especifica se a criptografia do Secure Sockets Layer (SSL) será usada na conexão de replicação. 1 especifica para usar criptografia de SSL, 0 especifica para não usar criptografia. O padrão é 0. A opção `SOURCE_SSL_VERIFY_SERVER_CERT` não tem suporte. Essa opção é definida como 0, o que significa que a conexão é criptografada, mas os certificados não são verificados. *channel\$1name* O nome da instância de replicação. Cada canal de replicação recebe os eventos de logs binários de uma única instância de banco de dados do RDS para MySQL de origem executada em uma porta e um host específicos. ### Observações de uso O usuário principal deve executar o procedimento `mysql.rds_set_external_source_for_channel`. Esse procedimento deve ser executado na instância de banco de dados do RDS para MySQL de destino na qual você está criando o canal de replicação. Antes de executar `mysql.rds_set_external_source_for_channel`, configure um usuário de replicação na instância de banco de dados de origem com os privilégios necessários para a réplica de várias fontes. Para conectar a réplica de várias fontes à instância de banco de dados de origem, é necessário especificar os valores `replication_user_name` e `replication_user_password` de um usuário de replicação que tenha as permissões `REPLICATION CLIENT` e `REPLICATION SLAVE` na instância de banco de dados de origem. **Como configurar um usuário de replicação na instância de banco de dados de origem** 1. Usando o cliente MySQL de sua preferência, conecte-se à instância de banco de dados de origem e crie uma conta de usuário a ser usada para a replicação. Veja um exemplo a seguir. **Importante** Como prática recomendada de segurança, especifique uma senha diferente do valor do espaço reservado mostrado nos exemplos a seguir. ``` CREATE USER 'repl_user'@'example.com' IDENTIFIED BY 'password'; ``` 1. Na instância de banco de dados de origem, conceda os privilégios `REPLICATION CLIENT` e `REPLICATION SLAVE` para o usuário de replicação. O exemplo a seguir concede privilégios de `REPLICATION CLIENT` e `REPLICATION SLAVE` ao usuário 'repl\$1user' em todos os bancos de dados de seu domínio. ``` GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'example.com'; ``` Para usar a replicação criptografada, configure a instância de banco de dados de origem para usar conexões SSL. Depois de chamar `mysql.rds_set_external_source_for_channel` para configurar esse canal de replicação, será possível chamar [mysql.rds\$1start\$1replication\$1for\$1channel](#mysql_rds_start_replication_for_channel) na réplica para iniciar o processo de replicação no canal. É possível chamar [mysql.rds\$1reset\$1external\$1source\$1for\$1channel](#mysql_rds_reset_external_source_for_channel) para interromper a replicação no canal e remover a configuração do canal da réplica. Ao chamar `mysql.rds_set_external_source_for_channel`, o Amazon RDS grava a hora, o usuário e uma ação de `set channel source` na tabela `mysql.rds_history` sem detalhes específicos do canal e na tabela `mysql.rds_replication_status` com o nome do canal. Essas informações são registradas apenas para fins internos de uso e monitoramento. Para registrar a chamada de procedimento completa para fins de auditoria, pense em habilitar logs gerais ou de auditoria, com base nos requisitos específicos da aplicação. ### Exemplos Quando executado em uma instância de banco de dados do RDS para MySQL, o exemplo a seguir configura um canal de replicação denominado `channel_1` nessa instância de banco de dados para replicar dados da fonte especificada pelo host `sourcedb.example.com` e pela porta `3306`. ``` call mysql.rds_set_external_source_for_channel( 'sourcedb.example.com', 3306, 'repl_user', 'password', 'mysql-bin-changelog.0777', 120, 0, 'channel_1'); ``` ## mysql.rds\$1set\$1external\$1source\$1with\$1auto\$1position\$1for\$1channel Configura um canal de replicação em uma instância de banco de dados do RDS para MySQL com um atraso de replicação opcional. A replicação se baseia em identificadores de transação global (GTIDs). **Importante** Para executar esse procedimento, `autocommit` deve estar habilitado. Para habilitá-lo, defina o parâmetro `autocommit` como `1`. Para obter informações sobre como modificar parâmetros, consulte [Modificar parâmetros em um grupo de parâmetros de banco de dados no Amazon RDS](USER_WorkingWithParamGroups.Modifying.md). ### Sintaxe ``` CALL mysql.rds_set_external_source_with_auto_position_for_channel ( host_name , host_port , replication_user_name , replication_user_password , ssl_encryption , delay , channel_name ); ``` ### Parâmetros *host\$1name* O nome de host ou o endereço IP da instância de banco de dados do RDS para MySQL. *host\$1port* A porta usada pela instância de banco de dados do RDS para MySQL. Se sua configuração de rede inclui replicação de porta Secure Shell (SSH) que converte o número da porta, especifique o número da porta exposto pelo SSH. *replication\$1user\$1name* O ID de um usuário com as permissões `REPLICATION CLIENT` e `REPLICATION SLAVE` na instância de banco de dados de origem do RDS para MySQL. Recomendamos fornecer uma conta que seja usada unicamente para a replicação com a instância de banco de dados de origem. *replication\$1user\$1password* A senha do ID de usuário especificada em `replication_user_name`. *ssl\$1encryption* Um valor que especifica se a criptografia do Secure Sockets Layer (SSL) será usada na conexão de replicação. 1 especifica para usar criptografia de SSL, 0 especifica para não usar criptografia. O padrão é 0. A opção `SOURCE_SSL_VERIFY_SERVER_CERT` não tem suporte. Essa opção é definida como 0, o que significa que a conexão é criptografada, mas os certificados não são verificados. *delay* O número mínimo de segundos para atrasar a replicação da instância de banco de dados de origem. O limite para esse parâmetro é de um dia (86.400 segundos). *channel\$1name* O nome da instância de replicação. Cada canal de replicação recebe os eventos de logs binários de uma única instância de banco de dados do RDS para MySQL de origem executada em uma porta e um host específicos. ### Observações de uso O usuário principal deve executar o procedimento `mysql.rds_set_external_source_with_auto_position_for_channel`. Esse procedimento deve ser executado na instância de banco de dados do RDS para MySQL de destino na qual você está criando o canal de replicação. Antes de executar `rds_set_external_source_with_auto_position_for_channel`, configure um usuário de replicação na instância de banco de dados de origem com os privilégios necessários para a réplica de várias fontes. Para conectar a réplica de várias fontes à instância de banco de dados de origem, é necessário especificar os valores `replication_user_name` e `replication_user_password` de um usuário de replicação que tenha as permissões `REPLICATION CLIENT` e `REPLICATION SLAVE` na instância de banco de dados de origem. **Como configurar um usuário de replicação na instância de banco de dados de origem** 1. Usando o cliente MySQL de sua preferência, conecte-se à instância de banco de dados de origem e crie uma conta de usuário a ser usada para a replicação. Veja um exemplo a seguir. **Importante** Como prática recomendada de segurança, especifique uma senha diferente do valor do espaço reservado mostrado nos exemplos a seguir. ``` CREATE USER 'repl_user'@'example.com' IDENTIFIED BY 'password'; ``` 1. Na instância de banco de dados de origem, conceda os privilégios `REPLICATION CLIENT` e `REPLICATION SLAVE` para o usuário de replicação. O exemplo a seguir concede privilégios de `REPLICATION CLIENT` e `REPLICATION SLAVE` ao usuário 'repl\$1user' em todos os bancos de dados de seu domínio. ``` GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'example.com'; ``` Para usar a replicação criptografada, configure a instância de banco de dados de origem para usar conexões SSL. Antes de chamar `mysql.rds_set_external_source_with_auto_position_for_channel`, chame [mysql.rds\$1set\$1external\$1source\$1gtid\$1purged](mysql-stored-proc-replicating.md#mysql_rds_set_external_source_gtid_purged) para definir a variável de sistema `gtid_purged` com um intervalo GTID especificado de uma fonte externa. Depois de chamar `mysql.rds_set_external_source_with_auto_position_for_channel` para configurar uma instância de banco de dados do Amazon RDS como réplica de leitura em um canal específico, é possível chamar [mysql.rds\$1start\$1replication\$1for\$1channel](#mysql_rds_start_replication_for_channel) na réplica de leitura para iniciar o processo de replicação nesse canal. Depois de chamar `mysql.rds_set_external_source_with_auto_position_for_channel` para configurar esse canal de replicação, será possível chamar [mysql.rds\$1start\$1replication\$1for\$1channel](#mysql_rds_start_replication_for_channel) na réplica para iniciar o processo de replicação no canal. É possível chamar [mysql.rds\$1reset\$1external\$1source\$1for\$1channel](#mysql_rds_reset_external_source_for_channel) para interromper a replicação no canal e remover a configuração do canal da réplica. ### Exemplos Quando executado em uma instância de banco de dados do RDS para MySQL, o exemplo a seguir configura um canal de replicação denominado `channel_1` nessa instância de banco de dados para replicar dados da fonte especificada pelo host `sourcedb.example.com` e pela porta `3306`. Ele define o atraso de replicação mínimo como uma hora (3.600 segundos). Isso significa que uma alteração da instância de banco de dados do RDS para MySQL não é aplicada à réplica de várias fontes por pelo menos uma hora. ``` call mysql.rds_set_external_source_with_auto_position_for_channel( 'sourcedb.example.com', 3306, 'repl_user', 'password', 1, 3600, 'channel_1'); ``` ## mysql.rds\$1set\$1external\$1source\$1with\$1delay\$1for\$1channel Configura um canal de replicação em uma instância de banco de dados do RDS para MySQL com um atraso de replicação especificado. **Importante** Para executar esse procedimento, `autocommit` deve estar habilitado. Para habilitá-lo, defina o parâmetro `autocommit` como `1`. Para obter informações sobre como modificar parâmetros, consulte [Modificar parâmetros em um grupo de parâmetros de banco de dados no Amazon RDS](USER_WorkingWithParamGroups.Modifying.md). ### Sintaxe ``` CALL mysql.rds_set_external_source_with_delay_for_channel ( host_name , host_port , replication_user_name , replication_user_password , mysql_binary_log_file_name , mysql_binary_log_file_location , ssl_encryption , delay , channel_name ); ``` ### Parâmetros *host\$1name* O nome de host ou o endereço IP da instância de banco de dados do RDS para MySQL. *host\$1port* A porta usada pela instância de banco de dados do RDS para MySQL. Se sua configuração de rede inclui replicação de porta Secure Shell (SSH) que converte o número da porta, especifique o número da porta exposto pelo SSH. *replication\$1user\$1name* O ID de um usuário com as permissões `REPLICATION CLIENT` e `REPLICATION SLAVE` na instância de banco de dados de origem do RDS para MySQL. Recomendamos fornecer uma conta que seja usada unicamente para a replicação com a instância de banco de dados de origem. *replication\$1user\$1password* A senha do ID de usuário especificada em `replication_user_name`. *mysql\$1binary\$1log\$1file\$1name* O nome do log binário na instância de banco de dados de origem contém as informações de replicação. *mysql\$1binary\$1log\$1file\$1location* O local no log binário `mysql_binary_log_file_name` no qual a replicação começará a ler as informações de replicação. É possível determinar o nome e a localização do arquivo de binlog executando `SHOW BINARY LOG STATUS` na instância do banco de dados de origem. As versões anteriores do MySQL usavam `SHOW MASTER STATUS` em vez de `SHOW BINARY LOG STATUS`. Se você estiver usando uma versão do MySQL anterior à 8.4, use `SHOW MASTER STATUS`. *ssl\$1encryption* Um valor que especifica se a criptografia do Secure Sockets Layer (SSL) será usada na conexão de replicação. 1 especifica para usar criptografia de SSL, 0 especifica para não usar criptografia. O padrão é 0. A opção `SOURCE_SSL_VERIFY_SERVER_CERT` não tem suporte. Essa opção é definida como 0, o que significa que a conexão é criptografada, mas os certificados não são verificados. *delay* O número mínimo de segundos para atrasar a replicação da instância de banco de dados de origem. O limite para esse parâmetro é de um dia (86.400 segundos). *channel\$1name* O nome da instância de replicação. Cada canal de replicação recebe os eventos de logs binários de uma única instância de banco de dados do RDS para MySQL de origem executada em uma porta e um host específicos. ### Observações de uso O usuário principal deve executar o procedimento `mysql.rds_set_external_source_with_delay_for_channel`. Esse procedimento deve ser executado na instância de banco de dados do RDS para MySQL de destino na qual você está criando o canal de replicação. Antes de executar `mysql.rds_set_external_source_with_delay_for_channel`, configure um usuário de replicação na instância de banco de dados de origem com os privilégios necessários para a réplica de várias fontes. Para conectar a réplica de várias fontes à instância de banco de dados de origem, é necessário especificar os valores `replication_user_name` e `replication_user_password` de um usuário de replicação que tenha as permissões `REPLICATION CLIENT` e `REPLICATION SLAVE` na instância de banco de dados de origem. **Como configurar um usuário de replicação na instância de banco de dados de origem** 1. Usando o cliente MySQL de sua preferência, conecte-se à instância de banco de dados de origem e crie uma conta de usuário a ser usada para a replicação. Veja um exemplo a seguir. **Importante** Como prática recomendada de segurança, especifique uma senha diferente do valor do espaço reservado mostrado nos exemplos a seguir. ``` CREATE USER 'repl_user'@'example.com' IDENTIFIED BY 'password'; ``` 1. Na instância de banco de dados de origem, conceda os privilégios `REPLICATION CLIENT` e `REPLICATION SLAVE` para o usuário de replicação. O exemplo a seguir concede privilégios de `REPLICATION CLIENT` e `REPLICATION SLAVE` ao usuário 'repl\$1user' em todos os bancos de dados de seu domínio. ``` GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'example.com'; ``` Para usar a replicação criptografada, configure a instância de banco de dados de origem para usar conexões SSL. Depois de chamar `mysql.rds_set_external_source_with_delay_for_channel` para configurar esse canal de replicação, será possível chamar [mysql.rds\$1start\$1replication\$1for\$1channel](#mysql_rds_start_replication_for_channel) na réplica para iniciar o processo de replicação no canal. É possível chamar [mysql.rds\$1reset\$1external\$1source\$1for\$1channel](#mysql_rds_reset_external_source_for_channel) para interromper a replicação no canal e remover a configuração do canal da réplica. Ao chamar `mysql.rds_set_external_source_with_delay_for_channel`, o Amazon RDS grava a hora, o usuário e uma ação de `set channel source` na tabela `mysql.rds_history` sem detalhes específicos do canal e na tabela `mysql.rds_replication_status` com o nome do canal. Essas informações são registradas apenas para fins internos de uso e monitoramento. Para registrar a chamada de procedimento completa para fins de auditoria, pense em habilitar logs gerais ou de auditoria, com base nos requisitos específicos da aplicação. ### Exemplos Quando executado em uma instância de banco de dados do RDS para MySQL, o exemplo a seguir configura um canal de replicação denominado `channel_1` nessa instância de banco de dados para replicar dados da fonte especificada pelo host `sourcedb.example.com` e pela porta `3306`. Ele define o atraso de replicação mínimo como uma hora (3.600 segundos). Isso significa que uma alteração da instância de banco de dados do RDS para MySQL não é aplicada à réplica de várias fontes por pelo menos uma hora. ``` call mysql.rds_set_external_source_with_delay_for_channel( 'sourcedb.example.com', 3306, 'repl_user', 'password', 'mysql-bin-changelog.000777', 120, 1, 3600, 'channel_1'); ``` ## mysql.rds\$1set\$1source\$1auto\$1position\$1for\$1channel Define o modo de replicação para o canal especificado como baseado nas posições do arquivo de log binário ou nos identificadores de transações globais (GTIDs). ### Sintaxe ``` CALL mysql.rds_set_source_auto_position_for_channel ( auto_position_mode , channel_name ); ``` ### Parâmetros *auto\$1position\$1mode* Um valor que indica se será usada a replicação de posição do arquivo de log ou a replicação com base no GTID: + `0`: usar o método de replicação com base na posição do arquivo de log binário. O padrão é `0`. + `1`: usar o método de replicação com base no GTID. *channel\$1name* O nome do canal de replicação na réplica de várias fontes. Cada canal de replicação recebe os eventos de logs binários de uma única instância de banco de dados do RDS para MySQL de origem executada em uma porta e um host específicos. ### Observações de uso O usuário principal deve executar o procedimento `mysql.rds_set_source_auto_position_for_channel`. Esse procedimento reinicia a replicação no canal especificado para aplicar o modo de posição automática especificado. ### Exemplos O exemplo a seguir define o modo de posição automática para channel\$11 usar o método de replicação baseado em GTID. ``` call mysql.rds_set_source_auto_position_for_channel(1,'channel_1'); ``` ## mysql.rds\$1set\$1source\$1delay\$1for\$1channel Define o número mínimo de segundos para atrasar a replicação da instância de banco de dados de origem para a réplica de várias fontes para o canal especificado. ### Sintaxe ``` CALL mysql.rds_set_source_delay_for_channel(delay, channel_name); ``` ### Parâmetros *delay* O número mínimo de segundos para atrasar a replicação da instância de banco de dados de origem. O limite para esse parâmetro é de um dia (86.400 segundos). *channel\$1name* O nome do canal de replicação na réplica de várias fontes. Cada canal de replicação recebe os eventos de logs binários de uma única instância de banco de dados do RDS para MySQL de origem executada em uma porta e um host específicos. ### Observações de uso O usuário principal deve executar o procedimento `mysql.rds_set_source_delay_for_channel`. Para usar o procedimento, primeiro chame `mysql.rds_stop_replication_for_channel` para interromper a replicação. Depois, chame esse procedimento para definir o valor do atraso de replicação. Quando o atraso estiver definido, chame `mysql.rds_start_replication_for_channel` para reiniciar a replicação. ### Exemplos O exemplo a seguir define o atraso da replicação da instância de banco de dados de origem no `channel_1` da réplica de várias fontes por pelo menos uma hora (3.600 segundos). ``` CALL mysql.rds_set_source_delay_for_channel(3600,'channel_1'); ``` ## mysql.rds\$1skip\$1repl\$1error\$1for\$1channel Ignora um evento de logs binários e exclui um erro de replicação em uma réplica de várias fontes de banco de dados do MySQL para o canal especificado. ### Sintaxe ``` CALL mysql.rds_skip_repl_error_for_channel(channel_name); ``` ### Parâmetros *channel\$1name* O nome do canal de replicação na réplica de várias fontes. Cada canal de replicação recebe os eventos de logs binários de uma única instância de banco de dados do RDS para MySQL de origem executada em uma porta e um host específicos. ### Observações de uso O usuário principal deve executar o procedimento `mysql.rds_skip_repl_error_for_channel` em uma réplica de leitura. É possível usar esse procedimento praticamente da mesma forma que o `mysql.rds_skip_repl_error` é usado para ignorar um erro em uma réplica de leitura. Para ter mais informações, consulte [Chamando o procedimento mysql.rds\$1skip\$1repl\$1error](Appendix.MySQL.CommonDBATasks.SkipError.md#Appendix.MySQL.CommonDBATasks.SkipError.procedure). **nota** Para ignorar erros na replicação baseada em GTID, recomendamos usar o procedimento [mysql.rds\$1skip\$1transaction\$1with\$1gtid](mysql-stored-proc-gtid.md#mysql_rds_skip_transaction_with_gtid). Para determinar se há erros, execute o comando `SHOW REPLICA STATUS FOR CHANNEL 'channel_name'\G` do MySQL. Se um erro de replicação não for crítico, execute `mysql.rds_skip_repl_error_for_channel` para ignorá-lo. Se houver vários erros, `mysql.rds_skip_repl_error_for_channel` excluirá o primeiro erro no canal de replicação especificado e, depois, avisará que há outros. Assim, você pode usar `SHOW REPLICA STATUS FOR CHANNEL 'channel_name'\G` para determinar o plano de ação correto para o próximo erro. Para obter informações sobre os valores retornados, consulte [Instrução SHOW REPLICA STATUS](https://dev.mysql.com/doc/refman/8.0/en/show-replica-status.html) na documentação do MySQL. ## mysql.rds\$1start\$1replication\$1for\$1channel Inicia a replicação de uma instância de banco de dados do RDS para MySQL para uma réplica de várias fontes no canal especificado. **nota** Você pode usar o procedimento armazenado [mysql.rds\$1start\$1replication\$1until\$1for\$1channel](#mysql_rds_start_replication_until_for_channel) ou [mysql.rds\$1start\$1replication\$1until\$1gtid\$1for\$1channel](#mysql_rds_start_replication_until_gtid_for_channel) para iniciar a replicação de uma instância de banco de dados do RDS para MySQL interromper a replicação no local do arquivo de log binário especificado. ### Sintaxe ``` CALL mysql.rds_start_replication_for_channel(channel_name); ``` ### Parâmetros *channel\$1name* O nome do canal de replicação na réplica de várias fontes. Cada canal de replicação recebe os eventos de logs binários de uma única instância de banco de dados do RDS para MySQL de origem executada em uma porta e um host específicos. ### Observações de uso O usuário principal deve executar o procedimento `mysql.rds_start_replication_for_channel`. Depois de importar os dados da instância de banco de dados do RDS para MySQL de origem, execute esse comando na réplica de várias fontes para iniciar a replicação no canal especificado. ### Exemplos O exemplo a seguir inicia a replicação em `channel_1` de várias fontes. ``` CALL mysql.rds_start_replication_for_channel('channel_1'); ``` ## mysql.rds\$1start\$1replication\$1until\$1for\$1channel Inicia a replicação de uma instância de banco de dados do RDS para MySQL no canal especificado e interrompe a replicação no local do arquivo de log binário especificado. ### Sintaxe ``` CALL mysql.rds_start_replication_until_for_channel ( replication_log_file , replication_stop_point , channel_name ); ``` ### Parâmetros *replication\$1log\$1file* O nome do log binário na instância de banco de dados de origem contém as informações de replicação. *replication\$1stop\$1point * O local no log binário `replication_log_file` no qual a replicação será interrompida. *channel\$1name* O nome do canal de replicação na réplica de várias fontes. Cada canal de replicação recebe os eventos de logs binários de uma única instância de banco de dados do RDS para MySQL de origem executada em uma porta e um host específicos. ### Observações de uso O usuário principal deve executar o procedimento `mysql.rds_start_replication_until_for_channel`. Com esse procedimento, a replicação começa e depois é interrompida quando a posição especificada do arquivo de log binário é atingida. Esse procedimento interrompe tanto o `SQL_THREAD` quanto o `IO_THREAD`. O nome do arquivo especificado para o parâmetro `replication_log_file` deve corresponder ao nome do arquivo do log binário da instância de banco de dados de origem. Quando o parâmetro `replication_stop_point` especifica um local de parada no passado, a replicação é interrompida imediatamente. ### Exemplos O exemplo a seguir inicia a replicação em `channel_1` e replica as alterações até atingir o local `120` no arquivo de log binário `mysql-bin-changelog.000777`. ``` call mysql.rds_start_replication_until_for_channel( 'mysql-bin-changelog.000777', 120, 'channel_1' ); ``` ## mysql.rds\$1start\$1replication\$1until\$1gtid\$1for\$1channel Inicia a replicação no canal especificado de uma instância de banco de dados do RDS para MySQL e interrompe a replicação no identificador de transação global (GTID) especificado. ### Sintaxe ``` CALL mysql.rds_start_replication_until_gtid_for_channel(gtid,channel_name); ``` ### Parâmetros *gtid* O GTID após o qual a replicação será interrompida. *channel\$1name* O nome do canal de replicação na réplica de várias fontes. Cada canal de replicação recebe os eventos de logs binários de uma única instância de banco de dados do RDS para MySQL de origem executada em uma porta e um host específicos. ### Observações de uso O usuário principal deve executar o procedimento `mysql.rds_start_replication_until_gtid_for_channel`. O procedimento inicia a replicação no canal especificado e aplica todas as alterações até o valor de GTID especificado. Depois, ele interrompe a replicação no canal. Quando o parâmetro `gtid` especifica uma transação que já tenha sido executada pela réplica, a replicação é interrompida imediatamente. Antes de executar esse procedimento, você deve desabilitar a replicação multiencadeada definindo o valor de `replica_parallel_workers` ou `slave_parallel_workers` como `0`. ### Exemplos O exemplo a seguir inicia a replicação em `channel_1` e replica as alterações até atingir o GTID `3E11FA47-71CA-11E1-9E33-C80AA9429562:23`. ``` call mysql.rds_start_replication_until_gtid_for_channel('3E11FA47-71CA-11E1-9E33-C80AA9429562:23','channel_1'); ``` ## mysql.rds\$1stop\$1replication\$1for\$1channel Interrompe a replicação de uma instância de banco de dados do MySQL no canal especificado. ### Sintaxe ``` CALL mysql.rds_stop_replication_for_channel(channel_name); ``` ### Parâmetros *channel\$1name* O nome do canal de replicação na réplica de várias fontes. Cada canal de replicação recebe os eventos de logs binários de uma única instância de banco de dados do RDS para MySQL de origem executada em uma porta e um host específicos. ### Observações de uso O usuário principal deve executar o procedimento `mysql.rds_stop_replication_for_channel`. ### Exemplos O exemplo a seguir interrompe a replicação em `channel_1` da réplica de várias fontes. ``` CALL mysql.rds_stop_replication_for_channel('channel_1'); ``` # Replicar transações com GTIDs Os procedimentos armazenados a seguir controlam como as transações são replicadas usando identificadores de transações globais (GTIDs) com o RDS para MySQL. Para ter mais informações sobre replicação com base em GTIDs com o RDS para MySQL, consulte [Usar a replicação baseada em GTID](mysql-replication-gtid.md). Ao usar procedimentos armazenados para gerenciar a replicação com um usuário de replicação configurado com `caching_sha2_password`, você deve configurar o TLS especificando `SOURCE_SSL=1`. `caching_sha2_password` é o plugin de autenticação padrão do RDS para MySQL 8.4. **Topics** + [ ## mysql.rds\$1skip\$1transaction\$1with\$1gtid ](#mysql_rds_skip_transaction_with_gtid) + [ ## mysql.rds\$1start\$1replication\$1until\$1gtid ](#mysql_rds_start_replication_until_gtid) ## mysql.rds\$1skip\$1transaction\$1with\$1gtid Ignora a replicação de uma transação com o identificador de transação global (GTID) especificado em uma instância de banco de dados MySQL. Você pode usar esse procedimento para a recuperação de desastres, quando uma transação baseada em GTID específica for conhecida por causar desastres. Use esse procedimento armazenado para ignorar a transação problemática. Exemplos de transações problemáticas incluem transações que desabilitam a replicação, excluem dados importantes ou fazem com que a instância de banco de dados se torne indisponível. ### Sintaxe ``` CALL mysql.rds_skip_transaction_with_gtid ( gtid_to_skip ); ``` ### Parâmetros *gtid\$1to\$1skip* O GTID da transação de replicação a ser ignorada. ### Observações de uso O usuário principal deve executar o procedimento `mysql.rds_skip_transaction_with_gtid`. Esse procedimento é compatível com todas as versões 5.7 do RDS para MySQL, todas as versões 8.0 do RDS para MySQL e todas as versões do RDS para MySQL 8.4. ### Exemplos O exemplo a seguir ignora a replicação da transação com o GTID `3E11FA47-71CA-11E1-9E33-C80AA9429562:23`. ``` CALL mysql.rds_skip_transaction_with_gtid('3E11FA47-71CA-11E1-9E33-C80AA9429562:23'); ``` ## mysql.rds\$1start\$1replication\$1until\$1gtid Inicia a replicação de uma instância de banco de dados do RDS para MySQL e interrompe a replicação logo depois do identificador de transação global (GTID) especificado. ### Sintaxe ``` CALL mysql.rds_start_replication_until_gtid(gtid); ``` ### Parâmetros *gtid* O GTID após o qual a replicação será interrompida. ### Observações de uso O usuário principal deve executar o procedimento `mysql.rds_start_replication_until_gtid`. Esse procedimento é compatível com todas as versões 5.7 do RDS para MySQL, todas as versões 8.0 do RDS para MySQL e todas as versões do RDS para MySQL 8.4. Você pode usar esse procedimento com a replicação atrasada para recuperação de desastres. Se você tiver a replicação atrasada configurada, use esse procedimento para efetuar roll forward de alterações em uma réplica de leitura atrasada para o momento imediatamente antes de um desastre. Depois que esse procedimento interromper a replicação, é possível promover a réplica de leitura para ser a nova instância de banco de dados primária usando as instruções em [Promoção de uma réplica de leitura a uma instância de banco de dados autônoma](USER_ReadRepl.Promote.md). Você pode configurar a replicação atrasada usando os seguintes procedimentos armazenados: + [mysql.rds\$1set\$1configuration](mysql-stored-proc-configuring.md#mysql_rds_set_configuration) + [mysql.rds\$1set\$1external\$1master\$1with\$1delay (RDS para MariaDB e RDS para MySQL versões principais 8.0 e anteriores)](mysql-stored-proc-replicating.md#mysql_rds_set_external_master_with_delay) + [mysql.rds\$1set\$1external\$1source\$1with\$1delay (RDS para MySQL versões principais 8.4 e superiores)](mysql-stored-proc-replicating.md#mysql_rds_set_external_source_with_delay) + [mysql.rds\$1set\$1source\$1delay](mysql-stored-proc-replicating.md#mysql_rds_set_source_delay) Quando o parâmetro `gtid` especifica uma transação que já tenha sido executada pela réplica, a replicação é interrompida imediatamente. ### Exemplos O exemplo a seguir inicia a replicação e replica as alterações até atingir o GTID `3E11FA47-71CA-11E1-9E33-C80AA9429562:23`. ``` call mysql.rds_start_replication_until_gtid('3E11FA47-71CA-11E1-9E33-C80AA9429562:23'); ``` # Alternar os logs de consulta Os procedimentos armazenados a seguir fazem a rotação dos logs do MySQL para tabelas de backup. Para ter mais informações, consulte [Arquivos de log do banco de dados MySQL](USER_LogAccess.Concepts.MySQL.md). **Topics** + [ ## mysql.rds\$1rotate\$1general\$1log ](#mysql_rds_rotate_general_log) + [ ## mysql.rds\$1rotate\$1slow\$1log ](#mysql_rds_rotate_slow_log) ## mysql.rds\$1rotate\$1general\$1log Reveza a tabela `mysql.general_log` com uma tabela de backup. ### Sintaxe ``` CALL mysql.rds_rotate_general_log; ``` ### Observações de uso Você pode revezar a tabela `mysql.general_log` com uma tabela de backup, chamando o procedimento `mysql.rds_rotate_general_log`. Quando as tabelas de log são revezadas, a tabela de log atual é copiada para uma tabela de log de backup e as entradas na tabela de log atual são removidas. Se uma tabela de log de backup já existir, então ela será excluída antes que a tabela de log atual seja copiada ao backup. Você pode consultar a tabela de log de backup, se necessário. A tabela de log de backup para a tabela `mysql.general_log` é denominada `mysql.general_log_backup`. É possível executar esse procedimento somente quando o parâmetro `log_output` está definido como `TABLE`. ## mysql.rds\$1rotate\$1slow\$1log Reveza a tabela `mysql.slow_log` com uma tabela de backup. ### Sintaxe ``` CALL mysql.rds_rotate_slow_log; ``` ### Observações de uso Você pode revezar a tabela `mysql.slow_log` com uma tabela de backup, chamando o procedimento `mysql.rds_rotate_slow_log`. Quando as tabelas de log são revezadas, a tabela de log atual é copiada para uma tabela de log de backup e as entradas na tabela de log atual são removidas. Se uma tabela de log de backup já existir, então ela será excluída antes que a tabela de log atual seja copiada ao backup. Você pode consultar a tabela de log de backup, se necessário. A tabela de log de backup para a tabela `mysql.slow_log` é denominada `mysql.slow_log_backup`. # Definir e mostrar a configuração de logs binários Os procedimentos armazenados a seguir definem e mostram parâmetros de configuração, como para retenção de arquivos de log binários. **Topics** + [ ## mysql.rds\$1set\$1configuration ](#mysql_rds_set_configuration) + [ ## mysql.rds\$1show\$1configuration ](#mysql_rds_show_configuration) ## mysql.rds\$1set\$1configuration Especifica o número de horas para retenção de logs binários ou o número de segundos para atrasar a replicação. ### Sintaxe ``` CALL mysql.rds_set_configuration(name,value); ``` ### Parâmetros *name* (Opcional) O nome do parâmetro de configuração a definir. *value* O valor do parâmetro de configuração. ### Observações de uso O procedimento `mysql.rds_set_configuration` oferece suporte aos seguintes parâmetros de configuração: + [horas de retenção do log binário](#mysql_rds_set_configuration-usage-notes.binlog-retention-hours) + [atraso na origem](#mysql_rds_set_configuration-usage-notes.source-delay) + [atraso de destino](#mysql_rds_set_configuration-usage-notes.target-delay) Os parâmetros de configuração são armazenados permanentemente e sobrevivem a qualquer reinicialização ou failover da instância de banco de dados. #### horas de retenção do log binário O parâmetro `binlog retention hours` é usado para especificar o número de horas para reter arquivos de log binários. O Amazon RDS normalmente elimina um log binário o mais rápido possível, mas o log binário ainda pode ser necessário para a replicação com um banco de dados MySQL externo ao RDS. O valor padrão de `binlog retention hours` é `NULL`. Para o RDS para MySQL, `NULL` significa que os logs binários não são retidos (0 horas). Para especificar o número de horas para reter os logs binários em uma instância de banco de dados, use o procedimento armazenado `mysql.rds_set_configuration` e especifique um período com tempo suficiente para que a replicação ocorra, conforme exibido no exemplo a seguir. `call mysql.rds_set_configuration('binlog retention hours', 24);` **nota** Não é possível usar o valor `0` para `binlog retention hours`. Para instâncias de banco de dados MySQL, o valor máximo de `binlog retention hours` é de 168 (7 dias). Após configurar o período de retenção, monitore o uso de armazenamento da instância de banco de dados para garantir que os logs binários retidos não consumam muito armazenamento. Para implantações de cluster de banco de dados multi-AZ, você só pode configurar a retenção de log binário da instância de banco de dados de gravador, e a configuração é propagada para todas as instâncias de banco de dados de leitor de forma assíncrona. Se os logs binários no cluster de banco de dados excederem a metade do espaço total de armazenamento local, o Amazon RDS moverá automaticamente os logs obsoletos para o volume do EBS. No entanto, os logs mais recentes permanecem no armazenamento local e, portanto, poderão ser perdidos se houver uma falha que exija a substituição do host ou se você aumentar ou reduzir a escala do banco de dados verticalmente. #### atraso na origem Use o parâmetro `source delay` em uma réplica de leitura para especificar o número de segundos para atrasar a replicação da réplica de leitura para a instância de banco de dados de origem. O Amazon RDS replica as alterações o mais rápido possível, mas talvez você queira que alguns ambientes atrasem a replicação. Por exemplo, quando a replicação é atrasada, você pode efetuar roll forward de uma réplica de leitura atrasada para o momento imediatamente antes de um desastre. Se uma tabela for descartada acidentalmente, use a replicação atrasada para recuperá-la rapidamente. O valor padrão de `target delay` é `0` (não atrasar a replicação). Quando você usa esse parâmetro, ele executa [mysql.rds\$1set\$1source\$1delay](mysql-stored-proc-replicating.md#mysql_rds_set_source_delay) e aplica CHANGE primary TO MASTER\$1DELAY = valor de entrada. Se for bem-sucedido, o procedimento salvará o parâmetro `source delay` na tabela `mysql.rds_configuration`. Para especificar o número de segundos em que o Amazon RDS atrasará a replicação de uma instância de banco de dados de origem, use o procedimento armazenado `mysql.rds_set_configuration` e especifique o número de segundos de atraso da replicação. No exemplo a seguir, a replicação é atrasada por pelo menos uma hora (3.600 segundos). `call mysql.rds_set_configuration('source delay', 3600);` Depois, o procedimento executa `mysql.rds_set_source_delay(3600)`. O limite do parâmetro `source delay` é de um dia (86.400 segundos). #### atraso de destino Use o parâmetro `target delay` para especificar o número de segundos para atrasar a replicação entre uma instância de banco de dados e quaisquer réplicas de leitura gerenciadas pelo RDS criadas futuramente com base nessa instância. Esse parâmetro é ignorado para réplicas de leitura não gerenciadas pelo RDS. O Amazon RDS replica as alterações o mais rápido possível, mas talvez você queira que alguns ambientes atrasem a replicação. Por exemplo, quando a replicação é atrasada, você pode efetuar roll forward de uma réplica de leitura atrasada para o momento imediatamente antes de um desastre. Se uma tabela for descartada acidentalmente, use a replicação atrasada para recuperá-la rapidamente. O valor padrão de `target delay` é `0` (não atrasar a replicação). Para a recuperação de desastres, você pode usar esse parâmetro de configuração com o procedimento armazenado [mysql.rds\$1start\$1replication\$1until](mysql-stored-proc-replicating.md#mysql_rds_start_replication_until) ou o [mysql.rds\$1start\$1replication\$1until\$1gtid](mysql-stored-proc-gtid.md#mysql_rds_start_replication_until_gtid). Para efetuar roll forward de alterações para uma réplica de leitura atrasada no momento imediatamente antes de um desastre, é possível executar o procedimento `mysql.rds_set_configuration` com esse conjunto de parâmetros. Depois que o procedimento `mysql.rds_start_replication_until` ou `mysql.rds_start_replication_until_gtid` interromper a replicação, é possível promover a réplica de leitura para ser a nova instância de banco de dados primária usando as instruções em [Promoção de uma réplica de leitura a uma instância de banco de dados autônoma](USER_ReadRepl.Promote.md). Para usar o procedimento `mysql.rds_rds_start_replication_until_gtid`, a replicação baseada em GTID deve estar habilitada. Para ignorar uma transação específica baseada em GTID que seja conhecida por causar desastres, use o procedimento armazenado [mysql.rds\$1skip\$1transaction\$1with\$1gtid](mysql-stored-proc-gtid.md#mysql_rds_skip_transaction_with_gtid). Para ter mais informações sobre como trabalhar com a replicação baseada em GTID, consulte [Usar a replicação baseada em GTID](mysql-replication-gtid.md). Para especificar o número de segundos em que o Amazon RDS atrasará a replicação de uma réplica de leitura, use o procedimento armazenado `mysql.rds_set_configuration` e especifique o número de segundos de atraso da replicação. O exemplo a seguir especifica que a replicação é atrasada por pelo menos uma hora (3.600 segundos). `call mysql.rds_set_configuration('target delay', 3600);` O limite do parâmetro `target delay` é de um dia (86.400 segundos). ## mysql.rds\$1show\$1configuration A quantidade de horas em que os logs binários são mantidos. ### Sintaxe ``` CALL mysql.rds_show_configuration; ``` ### Observações de uso Para verificar o número de horas durante as quais o Amazon RDS vai reter os logs binários, use o procedimento armazenado `mysql.rds_show_configuration`. ### Exemplos O exemplo a seguir mostra exibe o período de retenção: ``` call mysql.rds_show_configuration; name value description binlog retention hours 24 binlog retention hours specifies the duration in hours before binary logs are automatically deleted. ``` # Aquecer o armazenamento em cache do InnoDB Os procedimentos armazenados a seguir salvam, carregam ou cancelam o carregamento do pool de buffers do InnoDB no RDS para instâncias de banco de dados MySQL. Para obter mais informações, consulte [Aquecimento de cache do InnoDB para o MySQL no Amazon RDS](MySQL.Concepts.FeatureSupport.md#MySQL.Concepts.InnoDBCacheWarming). **Topics** + [ ## mysql.rds\$1innodb\$1buffer\$1pool\$1dump\$1now ](#mysql_rds_innodb_buffer_pool_dump_now) + [ ## mysql.rds\$1innodb\$1buffer\$1pool\$1load\$1abort ](#mysql_rds_innodb_buffer_pool_load_abort) + [ ## mysql.rds\$1innodb\$1buffer\$1pool\$1load\$1now ](#mysql_rds_innodb_buffer_pool_load_now) ## mysql.rds\$1innodb\$1buffer\$1pool\$1dump\$1now Descarrega o estado atual do grupo de buffer no disco. ### Sintaxe ``` CALL mysql.rds_innodb_buffer_pool_dump_now(); ``` ### Observações de uso O usuário mestre deve executar o procedimento `mysql.rds_innodb_buffer_pool_dump_now`. ## mysql.rds\$1innodb\$1buffer\$1pool\$1load\$1abort Cancela um carregamento do estado salvo do grupo de buffer em andamento. ### Sintaxe ``` CALL mysql.rds_innodb_buffer_pool_load_abort(); ``` ### Observações de uso O usuário mestre deve executar o procedimento `mysql.rds_innodb_buffer_pool_load_abort`. ## mysql.rds\$1innodb\$1buffer\$1pool\$1load\$1now Carrega o estado salvo do grupo de buffer a partir do disco. ### Sintaxe ``` CALL mysql.rds_innodb_buffer_pool_load_now(); ``` ### Observações de uso O usuário mestre deve executar o procedimento `mysql.rds_innodb_buffer_pool_load_now`.