# Replicação com o Amazon Aurora MySQL Os recursos de replicação do Aurora MySQL são fundamentais para a alta disponibilidade e a performance do cluster. O Aurora facilita criar ou redimensionar clusters com até 15 réplicas do Aurora. Todas as réplicas funcionam pelos mesmos dados subjacentes. Se algumas instâncias de banco de dados ficarem offline, outras permanecerão disponíveis para continuar o processamento de consultas ou para assumir a gravação, caso necessário. O Aurora distribui automaticamente as conexões somente leitura entre várias instâncias de banco de dados, ajudando o cluster do Aurora a dar suporte a workloads que exigem muitas consultas. Nos tópicos a seguir, é possível encontrar informações sobre como a replicação do Aurora MySQL funciona e como ajustar as configurações de replicação tendo em vista disponibilidade e performance melhores. **Topics** + [Usar réplicas do Aurora](#AuroraMySQL.Replication.Replicas) + [Opções de replicação para Amazon Aurora MySQL](#AuroraMySQL.Replication.Options) + [Considerações sobre performance da replicação do Amazon Aurora MySQL](#AuroraMySQL.Replication.Performance) + [Zero-downtime restart (ZDR – Reinício com tempo de inatividade zero) para Amazon Aurora MySQL](AuroraMySQL.Replication.Availability.md) + [Configurar filtros de replicação com o Aurora MySQL](AuroraMySQL.Replication.Filters.md) + [Monitorar a replicação do Amazon Aurora MySQL](#AuroraMySQL.Replication.Monitoring) + [Replicar clusters de banco de dados do Amazon Aurora MySQL entre Regiões da AWS](AuroraMySQL.Replication.CrossRegion.md) + [Replicação entre Aurora e o MySQL ou entre Aurora e outro cluster de banco de dados do Aurora (replicação de log binário)](AuroraMySQL.Replication.MySQL.md) + [Usar a replicação baseada em GTID](mysql-replication-gtid.md) ## Usar réplicas do Aurora As réplicas do Aurora são endpoints independentes em um cluster de banco de dados do Aurora, cuja melhor utilidade é dimensionar operações de leitura e aumentar a disponibilidade. É possível distribuir até 15 réplicas do Aurora entre as zonas de disponibilidade que um cluster de banco de dados abrange em uma Região da AWS. Embora o volume do cluster de banco de dados seja composto de várias cópias dos dados para o cluster de banco de dados, os dados no volume do cluster são representados como um único volume lógico para a instância primária e para as réplicas do Aurora no cluster de banco de dados. Para obter mais informações sobre réplicas do Aurora, consulte [Réplicas do Aurora](Aurora.Replication.md#Aurora.Replication.Replicas). As réplicas do Aurora funcionam bem para a escalabilidade de leitura porque são totalmente dedicadas a operações de leitura no seu volume de cluster. As operações de gravação são gerenciadas pela instância principal. Como o volume do cluster é compartilhado entre todas as instâncias no seu cluster de banco de dados do Aurora MySQL, nenhum trabalho adicional é necessário para replicar uma cópia dos dados para cada réplica do Aurora. Por outro lado, as réplicas de leitura do MySQL devem reproduzir, em um único thread, todas as operações de gravação da instância de banco de dados de origem no armazenamento de dados local. Essa limitação pode afetar a possibilidade de réplicas de leitura do MySQL de dar suporte a grandes volumes de tráfego de leitura. Com o Aurora MySQL, quando a réplica do Aurora é excluída, o endpoint da instância é removido imediatamente, e a réplica do Aurora é removida do endpoint leitor. Se houver instruções em execução na réplica do Aurora que está sendo excluída, haverá um período de carência de três minutos. As instruções existentes podem ser concluídas durante o período de carência. Quando o período de carência termina, a réplica do Aurora é fechada e excluída. **Importante** As réplicas do Aurora para o Aurora MySQL usam sempre o nível de isolamento de transação padrão `REPEATABLE READ` para operações nas tabelas do InnoDB. Você pode usar o comando `SET TRANSACTION ISOLATION LEVEL` para alterar o nível de transação somente para a instância primária de um cluster de banco de dados do Aurora MySQL. Essa restrição evita bloqueios no nível do usuário nas réplicas do Aurora e permite que elas escalem para oferecer suporte a milhares de conexões de usuários ativos ainda que com um mínimo de atraso na réplica. **nota** As instruções DDL executadas na instância principal podem interromper conexões de banco de dados nas réplicas do Aurora associadas. Se uma conexão de réplica do Aurora estiver usando um objeto de banco de dados ativamente (por exemplo, uma tabela) e esse objeto for modificado na instância principal usando uma instrução DDL, a conexão de réplica do Aurora será interrompida. **nota** A região China (Ningxia) não oferece suporte a réplicas de leitura entre regiões. ## Opções de replicação para Amazon Aurora MySQL Você pode configurar a replicação entre qualquer uma das seguintes opções: + Dois clusters de banco de dados do Aurora MySQL em diferentes Regiões da AWS, criando uma réplica de leitura entre regiões de um cluster de banco de dados do Aurora MySQL. Para obter mais informações, consulte [Replicar clusters de banco de dados do Amazon Aurora MySQL entre Regiões da AWS](AuroraMySQL.Replication.CrossRegion.md). + Dois clusters de banco de dados do Aurora MySQL na mesma Região da AWS usando a replicação do log binário (binlog) do MySQL. Para obter mais informações, consulte [Replicação entre Aurora e o MySQL ou entre Aurora e outro cluster de banco de dados do Aurora (replicação de log binário)](AuroraMySQL.Replication.MySQL.md). + Uma instância de banco de dados RDS para MySQL como a fonte de um cluster de banco de dados do Aurora MySQL, criando uma réplica de leitura do Aurora de uma instância de banco de dados RDS para MySQL. Você pode usar essa abordagem para trazer mudanças de dados existentes e contínuas Aurora MySQL durante a migração para Aurora. Para ter mais informações, consulte [Migrar de uma instância de banco de dados do RDS para MySQL para um cluster de banco de dados do Amazon Aurora MySQL usando uma réplica de leitura do Aurora](AuroraMySQL.Migrating.RDSMySQL.Replica.md). Você também pode usar essa abordagem para aumentar a escalabilidade das consultas de leitura para seus dados. É possível consultar os dados usando uma ou mais instâncias de banco de dados dentro de um cluster de Aurora MySQL somente leitura. Para obter mais informações, consulte [Escalar leituras para o banco de dados MySQL com o Amazon Aurora](AuroraMySQL.Replication.ReadScaling.md). + Um cluster de banco de dados do Aurora MySQL em uma Região da AWS e até cinco clusters de banco de dados do Aurora somente leitura Aurora MySQL em diferentes regiões, criando um banco de dados global do Aurora. Você pode usar um banco de dados global do Aurora para comportar aplicações presentes ao redor do mundo. O cluster de banco de dados do Aurora MySQL primário tem uma instância gravador e até 15 réplicas do Aurora. Os clusters de banco de dados secundários do Aurora MySQL somente leitura podem ser compostos de até 16 réplicas de Aurora. Para obter mais informações, consulte [Usar o Amazon Aurora Global Database](aurora-global-database.md). **nota** Reinicializar a instância primária de um cluster de banco de dados do Amazon Aurora também reinicia automaticamente as réplicas do Aurora desse cluster de banco de dados para restabelecer um ponto de entrada que garante a consistência de leitura/gravação em todo o cluster de banco de dados. ## Considerações sobre performance da replicação do Amazon Aurora MySQL Os recursos a seguir ajudam você a ajustar a performance da replicação do Aurora MySQL. O recurso de compactação do log de réplicas reduz a largura de banda da rede para mensagens de replicação. Como cada mensagem é transmitida para todas as réplicas do Aurora, os benefícios são maiores para cluster maiores. Esse recurso envolve certa sobrecarga da CPU no nó gravador para realizar a compactação. Ele está sempre habilitado no Aurora MySQL versão 2 e versão 3. O recurso de filtragem de logs binários reduz a largura de banda da rede para mensagens de replicação. Como as réplicas do Aurora não usam as informações de log binário incluídas nas mensagens de replicação, esses dados são omitidos das mensagens enviadas para esses nós. No Aurora MySQL versão 2, você pode controlar esse recurso alterando o valor do parâmetro `aurora_enable_repl_bin_log_filtering`. Por padrão, esse parâmetro está ativado. Como essa otimização destina-se a ser transparente, você pode desativar essa configuração somente durante operações de diagnóstico ou solução de problemas relacionadas a replicação. Por exemplo, você pode fazer isso para corresponder o comportamento de um cluster do Aurora MySQL mais antigo no qual esse recurso não estava disponível. A filtragem do log binário está sempre habilitada no Aurora MySQL versão 3. # Zero-downtime restart (ZDR – Reinício com tempo de inatividade zero) para Amazon Aurora MySQL O recurso Zero-downtime restart (ZDR – Reinício com tempo de inatividade zero) pode preservar algumas ou todas as conexões ativas com instâncias de banco de dados durante determinados tipos de reinicializações. O ZDR se aplica a reinicializações que o Aurora executa automaticamente para resolver condições de erro, por exemplo, quando uma réplica começa a ficar muito atrasada em relação à origem. **Importante** O mecanismo ZDR opera com base no melhor esforço. As versões, as classes de instância, as condições de erro, operações SQL compatíveis e outros fatores do Aurora MySQL que determinam onde o ZDR se aplica estão sujeitos a alterações a qualquer momento. O ZDR para Aurora MySQL 2.x requer a versão 2.10 e posterior. O ZDR está disponível em todas as versões secundárias do Aurora MySQL 3.x. No Aurora MySQL versões 2 e 3, o mecanismo ZDR está habilitado por padrão, e o Aurora não usa o parâmetro `aurora_enable_zdr`. Na página **Events** (Eventos), o Aurora informa atividades relacionadas ao reinício do tempo de inatividade zero. O Aurora registra um evento quando tenta reiniciar usando o mecanismo ZDR. Esse evento indica por que o Aurora executa a reinicialização. Em seguida, o Aurora registra outro evento quando a reinicialização for concluída. Esse evento final relata quanto tempo o processo demorou e quantas conexões foram preservadas ou descartadas durante a reinicialização. Você pode consultar o log de erros do banco de dados para ver mais detalhes sobre o que aconteceu durante a reinicialização. Embora as conexões permaneçam intactas após uma operação ZDR bem-sucedida, algumas variáveis e recursos são reinicializados. Os seguintes tipos de informações não são preservados por meio de uma reinicialização causada pela reinicialização do tempo de inatividade zero: + Variáveis globais. O Aurora restaura variáveis de sessão, mas não restaura variáveis globais após a reinicialização. + Variáveis de status. Em particular, o valor do tempo de atividade informado pelo status do mecanismo é redefinido. + `LAST_INSERT_ID`. + Estado de `auto_increment` na memória para tabelas. O estado de incremento automático na memória é reinicializado. Para ter mais informações sobre valores de incremento automático, consulte o [Guia de referência do MySQL](https://dev.mysql.com/doc/refman/8.0/en/innodb-auto-increment-handling.html#innodb-auto-increment-initialization). + Informações diagnósticas das tabelas `INFORMATION_SCHEMA` e `PERFORMANCE_SCHEMA`. Essas informações de diagnóstico também aparecem na saída de comandos como `SHOW PROFILE` e `SHOW PROFILES`. A tabela a seguir mostra as versões, os perfis de instância e outras circunstâncias que determinam se o Aurora pode ou não usar o mecanismo ZDR ao reiniciar instâncias de banco de dados no cluster. | Aurora MySQL versão | O ZDR se aplica ao gravador? | O ZDR se aplica aos leitores? | O ZDR está sempre habilitado? | Observações | | --- | --- | --- | --- | --- | | 2.x, anterior a 2.10.0 | Não | Não | N/D | O ZDR não está disponível para essas versões. | | 2.10.0 a 2.11.0 | Sim | Sim | Sim | O Aurora reverte todas as transações que estão em andamento em conexões ativas. Sua aplicação deve tentar executar as transações novamente. O Aurora cancela todas as conexões que usam TLS/SSL, tabelas temporárias, bloqueios de tabela ou bloqueios de usuário. | | 2.11.1 e posterior | Sim | Sim | Sim | O Aurora reverte todas as transações que estão em andamento em conexões ativas. Sua aplicação deve tentar executar as transações novamente. O Aurora cancela todas as conexões que usam tabelas temporárias, bloqueios de tabela ou bloqueios de usuário. | | 3.01 a 3.03 | Sim | Sim | Sim | O Aurora reverte todas as transações que estão em andamento em conexões ativas. Sua aplicação deve tentar executar as transações novamente. O Aurora cancela todas as conexões que usam TLS/SSL, tabelas temporárias, bloqueios de tabela ou bloqueios de usuário. | | 3.04 e posterior | Sim | Sim | Sim | O Aurora reverte todas as transações que estão em andamento em conexões ativas. Sua aplicação deve tentar executar as transações novamente. O Aurora cancela todas as conexões que usam tabelas temporárias, bloqueios de tabela ou bloqueios de usuário. | # Configurar filtros de replicação com o Aurora 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 um cluster 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. + Para especificar quais bancos de dados e tabelas serão replicados com um cluster de banco de dados do Aurora MySQL configurado como uma réplica em uma topologia de replicação de entrada. Para obter mais informações sobre essa configuração, consulte [Replicação entre Aurora e o MySQL ou entre Aurora e outro cluster de banco de dados do Aurora (replicação de log binário)](AuroraMySQL.Replication.MySQL.md). **Topics** + [Configurar parâmetros de filtragem de replicação para o Aurora MySQL](#AuroraMySQL.Replication.Filters.Configuring) + [Limitações de filtragem de replicação para o Aurora MySQL](#AuroraMySQL.Replication.Filters.Limitations) + [Exemplos de filtragem de replicação para o Aurora MySQL](#AuroraMySQL.Replication.Filters.Examples) + [Visualizar os filtros de replicação para uma réplica de leitura](#AuroraMySQL.Replication.Filters.Viewing) ## Configurar parâmetros de filtragem de replicação para o Aurora MySQL Para configurar filtros de replicação, defina os seguintes parâmetros: + `binlog-do-db`: replicar alterações para os logs binários especificados. Ao definir esse parâmetro para um cluster de origem do log binário, somente os logs binários especificados no parâmetro são replicados. + `binlog-ignore-db`: não replicar alterações para os logs binários especificados. Quando o parâmetro `binlog-do-db` é definido para um cluster de origem do log binário, esse parâmetro não é avaliado. + `replicate-do-db` – Replicar alterações nos bancos de dados especificados. Ao definir esse parâmetro para um cluster de réplica do log binário, 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 um cluster de réplica do log binário, 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, inclua o banco de dados que contém as tabelas especificadas na replicação com o cluster de réplica do log binário. + `replicate-ignore-table` – Não replique as alterações nas tabelas especificadas. Quando o parâmetro `replicate-do-table` é definido para um cluster de réplica do log binário, 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, inclua o banco de dados que contém as tabelas especificadas na replicação com o cluster de réplica do log binário. + `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 um cluster de réplica do log binário, 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 cluster de log binário, é possível 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 Aurora 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 para o Aurora MySQL As seguintes limitações se aplicam à filtragem de replicação para o Aurora MySQL: + Os filtros de replicação são compatíveis somente com o Aurora MySQL versão 3. + Cada parâmetro de filtragem de replicação tem um limite de 2.000 caracteres. + As vírgulas não são compatíveis em filtros de replicação. + 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 para o Aurora 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 do cluster de banco de dados associado à réplica de leitura. **nota** Não é possível modificar um grupo de parâmetros de cluster de banco de dados 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 os grupos de parâmetros de cluster de banco de dados, consulte [Grupos de parâmetros para Amazon Aurora](USER_WorkingWithParamGroups.md). Você pode definir parâmetros em um grupo de parâmetros de cluster de banco de dados usando o 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 Aurora](USER_WorkingWithParamGroups.Modifying.md). Quando você define parâmetros em um grupo de parâmetros de cluster de banco de dados, todos os clusters de banco de dados associados ao grupo de parâmetros usam as configurações de parâmetros. Se você definir os parâmetros de filtragem de replicação em um grupo de parâmetros de cluster de banco de dados, verifique se o grupo de parâmetros está associado apenas a clusters de réplica 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-ams) + [Including tables in replication](#rep-filter-in-tables-ams) + [Including tables in replication with wildcard characters](#rep-filter-in-tables-wildcards-ams) + [Excluding databases from replication](#rep-filter-ex-dbs-ams) + [Excluding tables from replication](#rep-filter-ex-tables-ams) + [Excluding tables from replication using wildcard characters](#rep-filter-ex-tables-wildcards-ams) **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-cluster-parameter-group \ --db-cluster-parameter-group-name myparametergroup \ --parameters "ParameterName=replicate-do-db,ParameterValue='mydb1,mydb2',ApplyMethod=immediate" ``` Para Windows: ``` aws rds modify-db-cluster-parameter-group ^ --db-cluster-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-cluster-parameter-group \ --db-cluster-parameter-group-name myparametergroup \ --parameters "ParameterName=replicate-do-table,ParameterValue='mydb1.table1,mydb1.table2',ApplyMethod=immediate" ``` Para Windows: ``` aws rds modify-db-cluster-parameter-group ^ --db-cluster-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-cluster-parameter-group \ --db-cluster-parameter-group-name myparametergroup \ --parameters "ParameterName=replicate-wild-do-table,ParameterValue='mydb.order%,mydb.return%',ApplyMethod=immediate" ``` Para Windows: ``` aws rds modify-db-cluster-parameter-group ^ --db-cluster-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-cluster-parameter-group \ --db-cluster-parameter-group-name myparametergroup \ --parameters "ParameterName=replicate-ignore-db,ParameterValue='mydb5,mydb6',ApplyMethod=immediate" ``` Para Windows: ``` aws rds modify-db-cluster-parameter-group ^ --db-cluster-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-cluster-parameter-group \ --db-cluster-parameter-group-name myparametergroup \ --parameters "ParameterName=replicate-ignore-table,ParameterValue='mydb5.table1,mydb6.table2',ApplyMethod=immediate" ``` Para Windows: ``` aws rds modify-db-cluster-parameter-group ^ --db-cluster-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-cluster-parameter-group \ --db-cluster-parameter-group-name myparametergroup \ --parameters "ParameterName=replicate-wild-ignore-table,ParameterValue='mydb7.order%,mydb7.return%',ApplyMethod=immediate" ``` Para Windows: ``` aws rds modify-db-cluster-parameter-group ^ --db-cluster-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 Aurora](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: + `Binlog_Do_DB` + `Binlog_Ignore_DB` + `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. ## Monitorar a replicação do Amazon Aurora MySQL A escalabilidade de leitura e a alta disponibilidade dependem de um tempo de atraso mínimo. É possível monitorar até que ponto uma réplica do Aurora está atrasada em relação à instância primária do cluster de banco de dados do Aurora MySQL, monitorando a métrica `AuroraReplicaLag` do Amazon CloudWatch. A métrica `AuroraReplicaLag` é registrada em cada réplica do Aurora. A instância de banco de dados principal também registra as métricas `AuroraReplicaLagMaximum` e `AuroraReplicaLagMinimum` do Amazon CloudWatch. A métrica `AuroraReplicaLagMaximum` registra a quantidade máxima de atraso entre a instância de banco de dados principal e cada réplica do Aurora no cluster de banco de dados. A métrica `AuroraReplicaLagMinimum` registra a quantidade mínima de atraso entre a instância de banco de dados principal e cada réplica do Aurora no cluster de banco de dados. Se você precisar do valor mais atual para o atraso da réplica do Aurora, confira a métrica `AuroraReplicaLag` no Amazon CloudWatch. O atraso da réplica do Aurora também é registrado em cada réplica do Aurora do cluster de banco de dados do Aurora MySQL na tabela `information_schema.replica_host_status`. Para obter mais informações sobre essa tabela, consulte [information\$1schema.replica\$1host\$1status](AuroraMySQL.Reference.ISTables.md#AuroraMySQL.Reference.ISTables.replica_host_status). Para obter mais informações sobre como monitorar as instâncias do RDS e as métricas do CloudWatch, consulte [Monitorar métricas em um cluster do Amazon Aurora](MonitoringAurora.md). # Replicar clusters de banco de dados do Amazon Aurora MySQL entre Regiões da AWS Você pode criar um cluster de banco de dados do Amazon Aurora MySQL como uma réplica de leitura em uma Região da AWS diferente do cluster de banco de dados de origem. O uso dessa abordagem pode melhorar sua capacidade de recuperação de desastres, permite que você aumente as operações de leitura em uma Região da AWS mais próxima a seus usuários e facilita a migração de uma Região da AWS para outra. Você pode criar réplicas de leitura de clusters de banco de dados criptografados e descriptografados. A réplica de leitura deverá ser criptografada se o cluster de banco de dados de origem estiver criptografado. Para cada cluster de banco de dados de origem, você só pode ter até cinco clusters de banco de dados entre regiões que são réplicas de leitura. **nota** Como alternativa a réplicas de leitura entre regiões, é possível escalar as operações de leitura com o tempo de atraso mínimo utilizando um banco de dados global Aurora. Um Aurora Global Database tem um cluster de banco de dados primário do Aurora em uma Região da AWS e até dez clusters de banco de dados somente leitura secundários em diferentes regiões. Cada cluster de banco de dados secundário pode incluir até 16 réplicas (em vez de 15) de Aurora. A replicação do cluster de banco de dados primário para todos os secundários é tratada pela camada de armazenamento de Aurora e não pelo mecanismo de banco de dados. Portanto, o tempo de atraso para replicar as alterações é mínimo, geralmente menos de 1 segundo. Manter o mecanismo de banco de dados fora do processo de replicação significa que o mecanismo de banco de dados é dedicado ao processamento de workloads. Isso também significa que você não precisa configurar ou gerenciar a replicação de log binário do Aurora MySQL. Para saber mais, consulte [Usar o Amazon Aurora Global Database](aurora-global-database.md). Ao criar uma réplica de leitura de cluster de banco de dados do Aurora MySQL em outra Região da AWS, esteja ciente de que: + Tanto o cluster de banco de dados de origem quanto o cluster de banco de dados da réplica de leitura entre regiões podem ter até 15 réplicas do Aurora em conjunto com a instância primária para o cluster de banco de dados. Usando essa funcionalidade, é possível melhorar as operações de leitura para sua Região da AWS de origem e de sua Região da AWS de replicação de destino. + Em um cenário entre regiões, há mais tempo de atraso entre o cluster de banco de dados de origem e a réplica de leitura devido aos canais de rede mais longos entre as Regiões da AWS. + Os dados transferidos para a replicação entre regiões incorrem em cobranças de transferência de dados do Amazon RDS. As seguintes ações de replicação entre regiões geram cobranças referentes aos dados transferidos da Região da AWS de origem: + Quando você cria a réplica de leitura, o Amazon RDS gera um snapshot do cluster de origem e transfere esse snapshot para a Região da AWS que contém a réplica de leitura. + Para cada modificação de dados feita nos bancos de dados de origem, o Amazon RDS transfere os dados da região de origem para a Região da AWS que contém a réplica de leitura. Para obter mais informações sobre a definição de preço da transferência de dados do Amazon RDS, consulte [Definição de preço do Amazon Aurora](https://aws.amazon.com/rds/aurora/pricing/). + Você pode executar várias ações simultâneas de criação ou exclusão para réplicas de leitura que referenciam o mesmo cluster de bando de dados de origem. No entanto, você deve permanecer dentro do limite de cinco réplicas de leitura para cada cluster de banco de dados de origem. + 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 o cluster de banco de dados de origem. Se você dimensionar o cluster de banco de dados de origem, também deverá dimensionar as réplicas de leitura. **Topics** + [Antes de começar](#AuroraMySQL.Replication.CrossRegion.Prerequisites) + [Criar um cluster de banco de dados de réplica de leitura entre regiões para o Aurora MySQL](AuroraMySQL.Replication.CrossRegion.Creating.md) + [Promover uma réplica de leitura a um cluster de banco de dados para o Aurora MySQL](AuroraMySQL.Replication.CrossRegion.Promote.md) + [Solucionar problemas de réplicas entre regiões do Amazon Aurora MySQL](AuroraMySQL.Replication.CrossRegion.Troubleshooting.md) ## Antes de começar Para que você possa criar um cluster de banco de dados do Aurora MySQL que seja uma réplica de leitura entre regiões, precisa habilitar o registro em log binário no seu cluster de banco de dados do Aurora MySQL de origem. A replicação entre regiões do Aurora MySQL usa a replicação binária do MySQL para reproduzir as mudanças no cluster de banco de dados da réplica de leitura entre regiões. Para habilitar o registro em log binário em um cluster de banco de dados do Aurora MySQL, atualize o parâmetro `binlog_format` para o seu cluster de banco de dados de origem. O parâmetro `binlog_format` é um parâmetro em nível de cluster que se encontra no parameter group de cluster padrão. Se seu cluster de banco de dados usar o grupo de parâmetros do cluster de banco de dados padrão, crie um novo grupo de parâmetro do cluster de banco de dados para modificar as configurações do `binlog_format`. Recomendamos que você defina `binlog_format` como `MIXED`. No entanto, você também pode definir `binlog_format` como `ROW` ou `STATEMENT` se precisar de um formato específico de log binário. Reinicie seu cluster de banco de dados Aurora para que a alteração entre em vigor. Para obter mais informações sobre o registro em log binário com o Aurora MySQL, consulte [Replicação entre Aurora e o MySQL ou entre Aurora e outro cluster de banco de dados do Aurora (replicação de log binário)](AuroraMySQL.Replication.MySQL.md). Para obter mais informações sobre como modificar parâmetros de configuração do Aurora MySQL, consulte [Parâmetros do cluster de banco de dados e da instância de bancos de dados Amazon Aurora](USER_WorkingWithDBClusterParamGroups.md#Aurora.Managing.ParameterGroups) e [Grupos de parâmetros para Amazon Aurora](USER_WorkingWithParamGroups.md). # Criar um cluster de banco de dados de réplica de leitura entre regiões para o Aurora MySQL Você pode criar um cluster de banco de dados do Aurora que seja uma réplica de leitura entre regiões usando o Console de gerenciamento da AWS , a AWS Command Line Interface (AWS CLI) ou a API do Amazon RDS. Você pode criar réplicas de leitura entre regiões de clusters de banco de dados criptografados e descriptografados. Quando você cria uma réplica de leitura entre Regiões para o Aurora MySQL usando o Console de gerenciamento da AWS, o Amazon RDS cria um cluster de banco de dados na Região da AWS de destino e depois cria automaticamente uma instância de banco de dados que passa a ser a instância principal desse cluster de banco de dados. Quando você cria uma réplica de leitura entre Regiões usando a AWS CLI ou a API do RDS, crie primeiro o cluster de banco de dados na Região da AWS de destino e aguarde até que fique ativo. Assim que estiver ativo, crie uma instância de banco de dados que seja a instância primária desse cluster de banco de dados. A replicação começará quando a instância primária do cluster de banco de dados da réplica de leitura estiver disponível. Use os seguintes procedimentos para criar uma réplica de leitura entre regiões a partir de um cluster de banco de dados do Aurora MySQL. Esses procedimentos funcionam para criar réplicas de leitura a partir de clusters de banco de dados criptografados ou descriptografados. ## Console **Para criar um cluster de banco de dados do Aurora MySQL que seja uma réplica de leitura entre regiões com o 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 canto superior direito do Console de gerenciamento da AWS, escolha a Região da AWS que hospeda seu cluster de banco de dados de origem. 1. No painel de navegação, escolha **Bancos de dados**. 1. Escolha o cluster de banco de dados de origem para o qual você deseja criar uma réplica de leitura entre Regiões. 1. Para **Actions** (Ações), escolha **Create cross region read replica** (Criar réplica de leitura entre Regiões). 1. Na página **Create cross region read replica (Criar réplica de leitura entre regiões)**, escolha as configurações das opções de seu cluster de banco de dados da réplica de leitura entre regiões, conforme descrito na tabela a seguir. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.CrossRegion.Creating.html) 1. Escolha **Create (Criar)** para criar sua réplica de leitura entre regiões para o Aurora. ## AWS CLI **Para criar um cluster de banco de dados do Aurora MySQL que seja uma réplica de leitura entre regiões com a CLI** 1. Chame o comando [create-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-cluster.html) da AWS CLI na Região da AWS em que você deseja criar um cluster de banco de dados de réplica de leitura. Inclua a opção `--replication-source-identifier` e especifique o nome de recurso da Amazon (ARN) do cluster de banco de dados de origem para o qual criar uma réplica de leitura. Para replicação entre regiões em que o cluster de banco de dados identificado por `--replication-source-identifier` é criptografado, especifique as opções `--kms-key-id` e `--storage-encrypted`. **nota** Você pode configurar a replicação entre regiões de um cluster de banco de dados descriptografado para uma réplica de leitura criptografada, especificando `--storage-encrypted` e fornecendo um valor para `--kms-key-id`. Não é possível especificar os parâmetros `--master-username` e `--master-user-password`. Esses valores são obtidos do cluster de banco de dados de origem. O exemplo de código a seguir cria uma réplica de leitura na região us-east-1 de um snapshot de cluster de banco de dados descriptografado na região us-west-2. O comando é chamado na região us-east-1. Este exemplo especifica a opção `--manage-master-user-password` para gerar a senha mestra do usuário e gerenciá-la no Secrets Manager. Para ter mais informações, consulte [Gerenciamento de senhas com Amazon Aurora e AWS Secrets Manager](rds-secrets-manager.md). Como alternativa, você pode usar a opção `--master-password` para especificar e gerenciar a senha por conta própria. Para Linux, macOS ou Unix: ``` aws rds create-db-cluster \ --db-cluster-identifier sample-replica-cluster \ --engine aurora-mysql \ --engine-version 8.0.mysql_aurora.3.08.0 \ --replication-source-identifier arn:aws:rds:us-west-2:123456789012:cluster:sample-master-cluster ``` Para Windows: ``` aws rds create-db-cluster ^ --db-cluster-identifier sample-replica-cluster ^ --engine aurora-mysql ^ --engine-version 8.0.mysql_aurora.3.08.0 ^ --replication-source-identifier arn:aws:rds:us-west-2:123456789012:cluster:sample-master-cluster ``` O exemplo de código a seguir cria uma réplica de leitura na região us-east-1 de um snapshot de cluster de banco de dados criptografado na região us-west-2. O comando é chamado na região us-east-1. Para Linux, macOS ou Unix: ``` aws rds create-db-cluster \ --db-cluster-identifier sample-replica-cluster \ --engine aurora-mysql \ --engine-version 8.0.mysql_aurora.3.08.0 \ --replication-source-identifier arn:aws:rds:us-west-2:123456789012:cluster:sample-master-cluster \ --kms-key-id my-us-east-1-key \ --storage-encrypted ``` Para Windows: ``` aws rds create-db-cluster ^ --db-cluster-identifier sample-replica-cluster ^ --engine aurora-mysql ^ --engine-version 8.0.mysql_aurora.3.08.0 ^ --replication-source-identifier arn:aws:rds:us-west-2:123456789012:cluster:sample-master-cluster ^ --kms-key-id my-us-east-1-key ^ --storage-encrypted ``` A opção `--source-region` é necessária para a replicação entre as regiões GovCloud (Leste dos EUA) da AWS e GovCloud (Oeste dos EUA) da AWS, em que o cluster de banco de dados identificado por `--replication-source-identifier` é criptografado. Em `--source-region`, especifique a Região da AWS do cluster de banco de dados de origem. Se a `--source-region` não estiver especificada, especifique um valor de `--pre-signed-url`. *URL pré-assinado* é aquele que contém uma solicitação assinada do Signature Versão 4 para o comando `create-db-cluster` chamado na Região da AWS de origem. Para saber mais sobre a opção `pre-signed-url`, consulte [create-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-cluster.html) na *Referência de comandos da AWS CLI*. 1. Verifique se o cluster de banco de dados está disponível para ser usado com o comando [describe-db-clusters](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-clusters.html) da AWS CLI, conforme mostrado no exemplo a seguir. ``` aws rds describe-db-clusters --db-cluster-identifier sample-replica-cluster ``` Quando os resultados do **`describe-db-clusters`** mostram um status de `available`, crie a instância primária para o cluster de banco de dados para que a replicação possa começar. Para fazer isso, use o comando [create-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html) da AWS CLI, conforme mostrado no exemplo a seguir. Para Linux, macOS ou Unix: ``` aws rds create-db-instance \ --db-cluster-identifier sample-replica-cluster \ --db-instance-class db.r5.large \ --db-instance-identifier sample-replica-instance \ --engine aurora-mysql ``` Para Windows: ``` aws rds create-db-instance ^ --db-cluster-identifier sample-replica-cluster ^ --db-instance-class db.r5.large ^ --db-instance-identifier sample-replica-instance ^ --engine aurora-mysql ``` Quando a instância de banco de dados for criada e estiver disponível, a replicação começará. É possível determinar se a instância de banco de dados está disponível chamando o comando [describe-db-instances](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-instances.html) da AWS CLI. ## API do RDS **Para criar um cluster de banco de dados do Aurora MySQL que seja uma réplica de leitura entre regiões com a API** 1. Chame a operação [CreateDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBCluster.html) da API do RDS na Região da AWS em que você deseja criar o cluster de banco de dados da réplica de leitura. Inclua o parâmetro `ReplicationSourceIdentifier` e especifique o nome de recurso da Amazon (ARN) do cluster de banco de dados de origem para o qual criar uma réplica de leitura. Para replicação entre regiões em que o cluster de banco de dados identificado por `ReplicationSourceIdentifier` é criptografado, especifique o parâmetro `KmsKeyId` e defina o parâmetro `StorageEncrypted` como `true`. **nota** Você pode configurar a replicação entre regiões de um cluster de banco de dados descriptografado para uma réplica de leitura criptografada, especificando `StorageEncrypted` como **true** e fornecendo um valor para `KmsKeyId`. Nesse caso, você não precisa especificar `PreSignedUrl`. Você não precisa incluir os parâmetros `MasterUsername` e `MasterUserPassword`, pois os valores são obtidos do cluster de banco de dados de origem. O exemplo de código a seguir cria uma réplica de leitura na região us-east-1 de um snapshot de cluster de banco de dados descriptografado na região us-west-2. A ação é chamada na região us-east-1. ``` https://rds.us-east-1.amazonaws.com/ ?Action=CreateDBCluster &ReplicationSourceIdentifier=arn:aws:rds:us-west-2:123456789012:cluster:sample-master-cluster &DBClusterIdentifier=sample-replica-cluster &Engine=aurora-mysql &SignatureMethod=HmacSHA256 &SignatureVersion=4 &Version=2014-10-31 &X-Amz-Algorithm=AWS4-HMAC-SHA256 &X-Amz-Credential=AKIADQKE4SARGYLE/20161117/us-east-1/rds/aws4_request &X-Amz-Date=20160201T001547Z &X-Amz-SignedHeaders=content-type;host;user-agent;x-amz-content-sha256;x-amz-date &X-Amz-Signature=a04c831a0b54b5e4cd236a90dcb9f5fab7185eb3b72b5ebe9a70a4e95790c8b7 ``` O exemplo de código a seguir cria uma réplica de leitura na região us-east-1 de um snapshot de cluster de banco de dados criptografado na região us-west-2. A ação é chamada na região us-east-1. ``` https://rds.us-east-1.amazonaws.com/ ?Action=CreateDBCluster &KmsKeyId=my-us-east-1-key &StorageEncrypted=true &PreSignedUrl=https%253A%252F%252Frds.us-west-2.amazonaws.com%252F %253FAction%253DCreateDBCluster %2526DestinationRegion%253Dus-east-1 %2526KmsKeyId%253Dmy-us-east-1-key %2526ReplicationSourceIdentifier%253Darn%25253Aaws%25253Ards%25253Aus-west-2%25253A123456789012%25253Acluster%25253Asample-master-cluster %2526SignatureMethod%253DHmacSHA256 %2526SignatureVersion%253D4 %2526Version%253D2014-10-31 %2526X-Amz-Algorithm%253DAWS4-HMAC-SHA256 %2526X-Amz-Credential%253DAKIADQKE4SARGYLE%252F20161117%252Fus-west-2%252Frds%252Faws4_request %2526X-Amz-Date%253D20161117T215409Z %2526X-Amz-Expires%253D3600 %2526X-Amz-SignedHeaders%253Dcontent-type%253Bhost%253Buser-agent%253Bx-amz-content-sha256%253Bx-amz-date %2526X-Amz-Signature%253D255a0f17b4e717d3b67fad163c3ec26573b882c03a65523522cf890a67fca613 &ReplicationSourceIdentifier=arn:aws:rds:us-west-2:123456789012:cluster:sample-master-cluster &DBClusterIdentifier=sample-replica-cluster &Engine=aurora-mysql &SignatureMethod=HmacSHA256 &SignatureVersion=4 &Version=2014-10-31 &X-Amz-Algorithm=AWS4-HMAC-SHA256 &X-Amz-Credential=AKIADQKE4SARGYLE/20161117/us-east-1/rds/aws4_request &X-Amz-Date=20160201T001547Z &X-Amz-SignedHeaders=content-type;host;user-agent;x-amz-content-sha256;x-amz-date &X-Amz-Signature=a04c831a0b54b5e4cd236a90dcb9f5fab7185eb3b72b5ebe9a70a4e95790c8b7 ``` Para a replicação entre as regiões GovCloud (Leste dos EUA) da AWS e GovCloud (Oeste dos EUA) da AWS, em que o cluster de banco de dados identificado por `ReplicationSourceIdentifier` é criptografado, especifique também o parâmetro `PreSignedUrl`. O URL pré-assinado deve ser uma solicitação válida para a operação `CreateDBCluster` da API que pode ser executada na Região da AWS de origem que contém o cluster de banco de dados criptografado a ser replicado. O identificador da chave do KMS é usado para criptografar a réplica de leitura e deve ser uma chave do KMS válida para a Região da AWS de destino. Para gerar um URL pré-assinado automaticamente, em vez de manualmente, use o comando [copy-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-cluster.html) da AWS CLI com a opção `--source-region`. 1. Verifique se o cluster de banco de dados está disponível para ser usado com a operação [DescribeDBClusters](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBClusters.html) da API do RDS, conforme mostrado no exemplo a seguir. ``` https://rds.us-east-1.amazonaws.com/ ?Action=DescribeDBClusters &DBClusterIdentifier=sample-replica-cluster &SignatureMethod=HmacSHA256 &SignatureVersion=4 &Version=2014-10-31 &X-Amz-Algorithm=AWS4-HMAC-SHA256 &X-Amz-Credential=AKIADQKE4SARGYLE/20161117/us-east-1/rds/aws4_request &X-Amz-Date=20160201T002223Z &X-Amz-SignedHeaders=content-type;host;user-agent;x-amz-content-sha256;x-amz-date &X-Amz-Signature=84c2e4f8fba7c577ac5d820711e34c6e45ffcd35be8a6b7c50f329a74f35f426 ``` Quando os resultados de `DescribeDBClusters` mostrarem um status de `available`, crie a instância primária para o cluster de banco de dados para que a replicação possa ser iniciada. Para fazer isso, use a ação [CreateDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBInstance.html) da API do RDS, conforme mostrado no exemplo a seguir. ``` https://rds.us-east-1.amazonaws.com/ ?Action=CreateDBInstance &DBClusterIdentifier=sample-replica-cluster &DBInstanceClass=db.r5.large &DBInstanceIdentifier=sample-replica-instance &Engine=aurora-mysql &SignatureMethod=HmacSHA256 &SignatureVersion=4 &Version=2014-10-31 &X-Amz-Algorithm=AWS4-HMAC-SHA256 &X-Amz-Credential=AKIADQKE4SARGYLE/20161117/us-east-1/rds/aws4_request &X-Amz-Date=20160201T003808Z &X-Amz-SignedHeaders=content-type;host;user-agent;x-amz-content-sha256;x-amz-date &X-Amz-Signature=125fe575959f5bbcebd53f2365f907179757a08b5d7a16a378dfa59387f58cdb ``` Quando a instância de banco de dados for criada e estiver disponível, a replicação começará. É possível determinar se a instância de banco de dados está disponível chamando o comando [DescribeDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBInstances.html) da AWS CLI. ## Visualizar réplicas entre regiões do Amazon Aurora MySQL É possível visualizar as relações de replicação entre regiões de seus clusters de banco de dados do Amazon Aurora MySQL chamando o comando [describe-db-clusters](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-clusters.html) da AWS CLI ou a operação [DescribeDBClusters](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBClusters.html) da API do RDS. Na resposta, consulte o campo `ReadReplicaIdentifiers` para obter os identificadores de cluster de banco de dados de qualquer cluster de banco de dados de réplica de leitura entre regiões. Consulte o elemento `ReplicationSourceIdentifier` para obter o ARN do cluster de banco de dados de origem que é a origem da replicação. # Promover uma réplica de leitura a um cluster de banco de dados para o Aurora MySQL Você pode promover uma réplica de leitura do Aurora MySQL para um cluster de banco de dados autônomo. Quando você promove uma réplica de leitura do Aurora MySQL, suas instâncias de banco de dados são reiniciadas antes de se tornarem disponíveis. Normalmente, você promove uma réplica de leitura do Aurora MySQL para um cluster de banco de dados autônomo como um esquema de recuperação de dados se houver uma falha no cluster de banco de dados de origem. Para isso, primeiro crie uma réplica de leitura e monitore o cluster de banco de dados de origem para identificar se há falhas. Em caso de falha, faça o seguinte: 1. Promova a réplica de leitura. 1. Direcione o tráfego do banco de dados para o cluster de banco de dados promovido. 1. Crie uma réplica de leitura de substituição com o cluster de banco de dados promovido como origem. Quando você promove uma réplica de leitura, a réplica de leitura se torna um cluster de banco de dados do Aurora autônomo. O processo de promoção pode levar vários minutos ou mais para ser concluído, dependendo do tamanho da réplica de leitura. Depois da promoção da réplica de leitura para um novo cluster de banco de dados, ela será semelhante a qualquer outro cluster de banco de dados. Por exemplo, você pode criar réplicas de leitura dele e executar operações de recuperação pontuais. Você também pode criar réplicas do Aurora para o cluster de banco de dados. Como o cluster de banco de dados promovido não é mais uma réplica de leitura, não é possível usá-lo como um destino de replicação. As etapas a seguir mostram o processo geral para promover uma réplica de leitura para um cluster de banco de dados: 1. Interrompa a gravação de todas as transações no cluster de banco de dados de origem da réplica de leitura e aguarde todas as atualizações a serem feitas na réplica de leitura. As atualizações do banco de dados ocorrem na réplica de leitura após terem ocorrido no cluster de banco de dados de origem e esse atraso de replicação pode variar significativamente. Use a métrica `ReplicaLag` para determinar quando todas as atualizações foram feitas na réplica de leitura. A métrica `ReplicaLag` registra a quantidade de tempo que uma instância de banco de dados de réplica de leitura atrasa em relação à instância de banco de dados de origem. Quando a métrica `ReplicaLag` chega a `0`, isso mostra que a réplica de leitura alcançou a instância do banco de dados de origem. 1. Promova a réplica de leitura usando a opção **Promote** (Promover) no console do Amazon RDS, o comando [promote-read-replica-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/promote-read-replica-db-cluster.html) da AWS CLI ou a operação [PromoteReadReplicaDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_PromoteReadReplicaDBCluster.html) da API do Amazon RDS. Você escolhe uma instância de banco de dados do Aurora MySQL para promover a réplica de leitura. Depois que a réplica de leitura é promovida, o cluster de banco de dados do Aurora MySQL é promovido para um cluster de banco de dados autônomo. A instância de banco de dados com a prioridade de failover mais alta é promovida para a instância de banco de dados principal para o cluster de banco de dados. As outras instâncias de banco de dados se tornam réplicas do Aurora. **nota** O processo de promoção leva alguns minutos para ser concluído. Ao promover uma réplica de leitura, a replicação é interrompida, e as instâncias de banco de dados são reiniciadas. Quando a reinicialização é concluída, a réplica de leitura está disponível como um novo cluster de banco de dados. ## Console **Para promover uma réplica de leitura do Aurora MySQL para um cluster 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 console, escolha **Instances (Instâncias)**. O painel **Instance (Instância)** é exibido. 1. No painel **Instances (Instâncias)**, escolha a réplica de leitura que você deseja promover. As réplicas de leitura aparecem como instâncias de banco de dados do Aurora MySQL. 1. Em **Actions (Ações)**, escolha **Promote read replica (Promover réplica de leitura)**. 1. Na página de confirmação, escolha **Promote read replica (Promover réplica de leitura)**. ## AWS CLI Para promover uma réplica de leitura para um cluster de banco de dados, use o comando [promote-read-replica-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/promote-read-replica-db-cluster.html) da AWS CLI. **Example** Para Linux, macOS ou Unix: ``` aws rds promote-read-replica-db-cluster \ --db-cluster-identifier mydbcluster ``` Para Windows: ``` aws rds promote-read-replica-db-cluster ^ --db-cluster-identifier mydbcluster ``` ## API do RDS Para promover uma réplica de leitura para um cluster de banco de dados, chame [PromoteReadReplicaDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_PromoteReadReplicaDBCluster.html). # Solucionar problemas de réplicas entre regiões do Amazon Aurora MySQL A seguir, você pode encontrar uma lista de mensagens de erro comuns que podem ocorrer ao criar uma réplica de leitura entre regiões do Amazon Aurora, e como resolver os erros especificados. ## O cluster de origem [ARN de cluster do banco de dados] não possui logs binários ativados Para resolver esse problema, habilite o registro em log binário no cluster de banco de dados de origem. Para obter mais informações, consulte [Antes de começar](AuroraMySQL.Replication.CrossRegion.md#AuroraMySQL.Replication.CrossRegion.Prerequisites). ## O cluster de origem [ARN do cluster de banco de dados] não apresenta um grupo de parâmetros de cluster em sincronia no gravador Você encontrará esse erro caso tenha atualizado o parâmetro do cluster de banco de dados `binlog_format`, mas não tenha reiniciado a instância primária do cluster de banco de dados. Reinicie a instância primária (ou seja, o gravador) do cluster de banco de dados e tente novamente. ## O cluster de origem [ARN do cluster de banco de dados] já possui uma réplica de leitura nesta região É possível ter até cinco clusters de banco de dados entre regiões que são réplicas de leitura para cada cluster de banco de dados de origem em qualquer Região da AWS. Se você já tiver o número máximo de réplicas de leitura para um cluster de banco de dados em uma determinada Região da AWS, será necessário excluir um existente, para poder criar um novo cluster de banco de dados entre regiões nessa região. ## O cluster de banco de dados [ARN do cluster de banco de dados] requer uma atualização do mecanismo de banco de dados para oferecer suporte à replicação entre regiões Para resolver esse problema, atualize a versão do mecanismo de banco de dados de todas as instâncias no cluster de banco de dados de origem para a versão mais recente do mecanismo de banco de dados e depois tente criar um banco de dados da réplica de leitura entre regiões novamente. # Replicação entre Aurora e o MySQL ou entre Aurora e outro cluster de banco de dados do Aurora (replicação de log binário) Como o Amazon Aurora MySQL é compatível com o MySQL, você pode configurar a replicação entre um banco de dados MySQL e um cluster de banco de dados do Amazon Aurora MySQL. Esse tipo de replicação usa a replicação de log binário do MySQL e também referido como *replicação de log binário*. Se você usar a replicação de log binário com o Aurora, recomendamos que o banco de dados MySQL execute o MySQL versão 5.5 ou superior. É possível configurar a replicação em que o cluster de banco de dados do Aurora MySQL é a origem da replicação ou a réplica. É possível replicar com uma instância de banco de dados MySQL do Amazon RDS, um banco de dados MySQL externo ao Amazon RDS ou outro cluster de banco de dados do Aurora MySQL. **nota** Você não pode usar a replicação de log binário de/para determinados tipos de clusters de banco de dados Aurora. Em particular, a replicação de log binário não está disponível para clusters do Aurora Serverless v1. Se as instruções `SHOW MASTER STATUS` e `SHOW SLAVE STATUS` (Aurora MySQL versão 2) ou a instrução `SHOW REPLICA STATUS` (Aurora MySQL versão 3) não retornarem uma saída, verifique se o cluster em uso oferece suporte à replicação de log binário. Também é possível replicar com uma instância de banco de dados do RDS para MySQL ou com um cluster de banco de dados do Aurora MySQL em outra Região da AWS. Quando estiver executando a replicação entre Regiões da AWS, verifique se os clusters e as instâncias de banco de dados estão acessíveis publicamente. Se os clusters de banco de dados do Aurora MySQL estiverem em sub-redes privadas em sua VPC, use o emparelhamento de VPC entre as Regiões da AWS. Para ter mais informações, consulte [Um cluster de banco de dados em uma VPC acessada por uma instância do EC2 em uma VPC diferente](USER_VPC.Scenarios.md#USER_VPC.Scenario3). Se você quiser configurar a replicação entre um cluster de banco de dados do Aurora MySQL e um cluster de banco de dados do Aurora MySQL em outra Região da AWS, poderá criar um cluster de banco de dados do Aurora MySQL como uma réplica de leitura em uma Região da AWS diferente da região do cluster de banco de dados de origem. Para ter mais informações, consulte [Replicar clusters de banco de dados do Amazon Aurora MySQL entre Regiões da AWS](AuroraMySQL.Replication.CrossRegion.md). Com o Aurora MySQL versões 2 e 3, é possível replicar entre o Aurora MySQL e uma origem ou um destino externo que utilize identificadores de transação global (GTIDs) para replicação. Certifique-se de que os parâmetros relacionados ao GTID no cluster de banco de dados do Aurora MySQL tenham configurações compatíveis com o status de GTID do banco de dados externo. Para aprender a fazer isso, consulte [Usar a replicação baseada em GTID](mysql-replication-gtid.md). No Aurora MySQL versão 3.01 e posteriores, é possível escolher como atribuir GTIDs a transações replicadas de uma origem que não utiliza GTIDs. Para saber mais sobre o procedimento armazenado que controla essa configuração, consulte [mysql.rds\$1assign\$1gtids\$1to\$1anonymous\$1transactions (Aurora MySQL versão 3)](mysql-stored-proc-gtid.md#mysql_assign_gtids_to_anonymous_transactions). **Atenção** Ao replicar entre o Aurora MySQL e o MySQL, lembre-se de usar apenas tabelas do InnoDB. Se você tiver tabelas do MyISAM que deseja replicar, poderá convertê-las no formato do InnoDB antes de configurar a replicação, com o seguinte comando. ``` alter table . engine=innodb, algorithm=copy; ``` Nas seções a seguir, configure a replicação, interrompa a replicação, escale as leituras para o banco de dados, otimize a replicação de logs binários e configure o log binário avançado. **Topics** + [Configurar a replicação de logs binários para o Aurora MySQL](AuroraMySQL.Replication.MySQL.SettingUp.md) + [Interromper a replicação de logs binários para o Aurora MySQL](AuroraMySQL.Replication.MySQL.Stopping.md) + [Escalar leituras para o banco de dados MySQL com o Amazon Aurora](AuroraMySQL.Replication.ReadScaling.md) + [Otimizar a replicação de logs binários para Aurora MySQL](binlog-optimization.md) + [Configurar o log binário avançado para Aurora MySQL](AuroraMySQL.Enhanced.binlog.md) # Configurar a replicação de logs binários para o Aurora MySQL Configurar a replicação do MySQL com o Aurora MySQL envolve as seguintes etapas, que são abordadas em detalhes: **Contents** + [1. Habilitar o registro em log binário na origem de replicação](#AuroraMySQL.Replication.MySQL.EnableBinlog) + [2. Retenha os logs binários na origem da replicação até que não seja necessário](#AuroraMySQL.Replication.MySQL.RetainBinlogs) + [3. Criar uma cópia ou um despejo da origem da replicação](#AuroraMySQL.Replication.MySQL.CreateSnapshot) + [4. Carregue o despejo em seu destino de réplica (se necessário).](#AuroraMySQL.Replication.MySQL.LoadSnapshot) + [5. Criar um usuário de replicação em sua origem de replicação](#AuroraMySQL.Replication.MySQL.CreateReplUser) + [6. Habilitar a replicação no seu destino de réplica](#AuroraMySQL.Replication.MySQL.EnableReplication) + [Configurar um local para interromper a replicação para uma réplica de leitura](#AuroraMySQL.Replication.StartReplicationUntil) + [7. Monitore sua réplica](#AuroraMySQL.Replication.MySQL.Monitor) + [Como sincronizar senhas entre a fonte e o destino da replicação](#AuroraMySQL.Replication.passwords) ## 1. Habilitar o registro em log binário na origem de replicação Encontre instruções a seguir sobre como habilitar o registro em log binário na origem de replicação para seu o mecanismo de banco de dados. | Mecanismo do banco de dados | Instruções | | --- | --- | | Aurora MySQL | **Para habilitar o registro em log binário em um cluster de banco de dados do Aurora MySQL** Defina o parâmetro de cluster de banco de dados `binlog_format` como `ROW`, `STATEMENT` ou `MIXED`. `MIXED` é recomendável, a menos que você precise de um formato de log binário específico. (O valor padrão é `OFF`.) Para alterar o parâmetro `binlog_format`, crie um grupo de parâmetros de cluster de banco de dados personalizado e associe esse grupo ao seu cluster de banco de dados. Não é possível alterar os parâmetros no grupo de parâmetros de cluster de banco de dados padrão. Se você estiver alterando o parâmetro `binlog_format` de `OFF` para outro valor, reinicialize o cluster de banco de dados Aurora para que a alteração entre em vigor. Para obter mais informações, consulte [Parâmetros do cluster de banco de dados e da instância de bancos de dados Amazon Aurora](USER_WorkingWithDBClusterParamGroups.md#Aurora.Managing.ParameterGroups) e [Grupos de parâmetros para Amazon Aurora](USER_WorkingWithParamGroups.md). | | RDS para MySQL | **Para habilitar o registro em log binário em uma instância de banco de dados do Amazon RDS** Não é possível habilitar o registro em log binário diretamente para uma instância de banco de dados do Amazon RDS, mas é possível habilitá-lo seguindo um destes procedimentos: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) | | MySQL (externo) | **Para configurar replicação criptografada** Para replicar dados de forma segura com o Aurora MySQL versão 2, você pode usar a replicação criptografada. Se você não precisar usar a replicação criptografada, você pode pular essas etapas. Veja a seguir os pré-requisitos para usar a replicação criptografada: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) Durante a replicação criptografada, o cluster do banco de dados de Aurora MySQL age como um cliente para o servidor de banco de dados do MySQL. Os certificados e chaves do cliente Aurora MySQL estão nos arquivos em formato .pem. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) **Para habilitar o registro em log binário em um banco de dados MySQL externo** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) | ## 2. Retenha os logs binários na origem da replicação até que não seja necessário Quando você usa a replicação de log binário do MySQL, o Amazon RDS não gerencia o processo de replicação. Como resultado, é necessário garantir que os arquivos de log binário na origem da replicação sejam retidos até que as alterações tenham sido aplicadas à réplica. Esta manutenção ajuda você a restaurar o banco de dados de origem em caso de falha. Use as instruções a seguir para manter os logs binários para o mecanismo do seu banco de dados. | Mecanismo do banco de dados | Instruções | | --- | --- | | Aurora MySQL | **Para manter os logs binários em um cluster de banco de dados do Aurora MySQL** Você não tem acesso aos arquivos de log binário de um cluster de banco de dados do Aurora MySQL. Como resultado, é necessário escolher um período para reter os arquivos de log binário na origem da replicação o suficiente para garantir que as alterações tenham sido aplicadas à réplica antes que o arquivo de log binário seja excluído pelo Amazon RDS. Você pode manter arquivos de log binário em um cluster de banco de dados do Aurora MySQL por até 90 dias. Se você for configurar a replicação com um banco de dados MySQL ou instância de banco de dados do RDS para MySQL como a réplica e o banco de dados para o qual você estiver criando uma réplica for muito grande, escolha um período longo para manter arquivos de log binário até que a cópia inicial do banco de dados para a réplica seja concluída e o atraso da réplica chegue a 0. Para definir o período de retenção do log binário, 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 de log binário no cluster do banco de dados. O valor máximo para o Aurora MySQL versão 2.11.0 e posterior e versão 3 é de 2.160 (90 dias). O exemplo a seguir define o período de retenção para arquivos de log binário em seis dias: 
CALL mysql.rds_set_configuration('binlog retention hours', 144);
Após a replicação ter sido iniciada, você poderá verificar se as mudanças foram aplicadas à sua réplica executando o comando `SHOW SLAVE STATUS` (Aurora MySQL versão 2) ou `SHOW REPLICA STATUS` (Aurora MySQL versão 3) na sua réplica e verificando o campo `Seconds behind master`. Se o campo `Seconds behind master` for 0, não haverá atraso de réplica. Quando não há atraso de réplica, reduza o período em que os arquivos de log binário são mantidos definindo o parâmetro de configuração `binlog retention hours` para um período menor. Se essa configuração não for especificada, o padrão de Aurora MySQL será 24 (1 dia). Se você especificar um valor para `'binlog retention hours'` que seja maior que o valor máximo, o Aurora MySQL usará o valor máximo. | | RDS para MySQL | **Para manter os logs binários em uma instância de banco de dados do Amazon RDS** É possível manter arquivos de log binário em uma instância de banco de dados do Amazon RDS definindo os horários de retenção do log binário, assim como é feito com o cluster de banco de dados do Aurora MySQL descrito na seção anterior. Você também pode manter arquivos de log binário em uma instância de banco de dados do Amazon RDS criando uma réplica de leitura para a instância de banco de dados. Esta réplica de leitura é temporária e tem como finalidade exclusiva manter os arquivos de log binário. Depois de criar a réplica de leitura, chame o procedimento [mysql.rds\$1stop\$1replication](mysql-stored-proc-replicating.md#mysql_rds_stop_replication) nela. Enquanto a replicação estiver interrompida, o Amazon RDS não excluirá nenhum dos arquivos de log binário na origem da replicação. Após configurar a replicação com a réplica permanente, você poderá excluir a réplica de leitura quando o atraso da réplica (campo `Seconds behind master`) entre a origem da replicação e a réplica permanente chegar a 0. | | MySQL (externo) | **Para manter os logs binários em um banco de dados MySQL externo** Como os arquivos de log binário em um banco de dados MySQL externo não são gerenciados pelo Amazon RDS, eles serão mantidos até você os exclua. Após a replicação ter sido iniciada, você poderá verificar se as mudanças foram aplicadas à sua réplica executando o comando `SHOW SLAVE STATUS` (Aurora MySQL versão 2) ou `SHOW REPLICA STATUS` (Aurora MySQL versão 3) na sua réplica e verificando o campo `Seconds behind master`. Se o campo `Seconds behind master` for 0, não haverá atraso de réplica. Quando não há atraso de réplica, você pode excluir arquivos de log binário antigos. | ## 3. Criar uma cópia ou um despejo da origem da replicação Use um snapshot, clone ou despejo da origem da replicação para carregar uma cópia da linha de base dos dados na réplica. Então você começa a replicar a partir desse ponto. Use as instruções a seguir para criar uma cópia ou um despejo da origem da replicação para o mecanismo do banco de dados. | Mecanismo do banco de dados | Instruções | | --- | --- | | Aurora MySQL | **Como criar uma cópia de um cluster de banco de dados do Aurora MySQL** Use um dos seguintes métodos: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) **Como determinar o nome e a posição do arquivo de log binário** Use um dos seguintes métodos: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) **Como criar um despejo de um cluster de banco de dados do Aurora MySQL** Se o destino da réplica for um banco de dados externo do MySQL ou uma instância de banco de dados do RDS para MySQL, será necessário criar um arquivo de despejo do cluster de banco de dados do Aurora. Execute o comando `mysqldump` na cópia do cluster de banco de dados de origem que você criou. Isso evita considerações de bloqueio durante o despejo. Se o despejo fosse feito diretamente no cluster de banco de dados de origem, seria necessário bloquear as tabelas de origem para evitar gravações simultâneas nelas durante o despejo. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) | | RDS para MySQL | **Para criar um snapshot da instância de banco de dados do Amazon RDS** Crie uma réplica de leitura de sua instância de banco de dados do Amazon RDS. Para ter mais informações, consulte [Criar uma réplica de leitura](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html#USER_ReadRepl.Create) no *Guia do usuário do Amazon Relational Database Service*. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) | | MySQL (externo) | **Como criar um despejo de um banco de dados MySQL externo** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) | ## 4. Carregue o despejo em seu destino de réplica (se necessário). Se você planeja carregar dados de um despejo de um banco de dados do MySQL que seja externo ao Amazon RDS, é recomendável criar uma instância do EC2 na qual copiar os arquivos de despejo. Depois, é possível carregar os dados no cluster de banco de dados ou na instância de banco de dados a partir dessa instância do EC2. Com essa abordagem, você pode compactar o(s) arquivo(s) de despejo antes de copiá-los na instância do EC2 para reduzir os custos de rede associados à cópia de dados para o Amazon RDS. Você também pode criptografar o arquivo ou arquivos de despejo para proteger os dados à medida que são transferidos pela rede. **nota** Se você criar um cluster de banco de dados do Aurora MySQL como o destino da réplica, não precisará carregar um arquivo de despejo. É possível restaurar de um snapshot de cluster de banco de dados para criar um cluster de banco de dados. Para obter mais informações, consulte [Restauração de um snapshot de um cluster de banco de dados](aurora-restore-snapshot.md). É possível clonar o cluster de banco de dados de origem para criar um cluster de banco de dados. Para obter mais informações, consulte [Clonar um volume para um cluster de banco de dados do Amazon Aurora](Aurora.Managing.Clone.md). É possível migrar os dados de um snapshot de instância de banco de dados para um novo cluster de banco de dados. Para obter mais informações, consulte [Migrar dados para um cluster de banco de dados do Amazon Aurora MySQL](AuroraMySQL.Migrating.md). Use as instruções a seguir para carregar o despejo da origem da replicação no destino de réplica para o mecanismo do banco de dados. | Mecanismo do banco de dados | Instruções | | --- | --- | | Aurora MySQL | **Como carregar um despejo em um cluster de banco de dados do Aurora MySQL** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) | | RDS para MySQL | **Como carregar um despejo em uma instância de banco de dados do Amazon RDS** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) | | MySQL (externo) | **Como carregar um despejo em um banco de dados MySQL externo** Você não pode carregar um snapshot de banco de dados ou um snapshot de cluster de banco de dados em um banco de dados MySQL externo. Em vez disso, você deve usar o resultado do comando `mysqldump`. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) | ## 5. Criar um usuário de replicação em sua origem de replicação Crie um ID de usuário na origem usado exclusivamente para replicação. O exemplo a seguir é relacionado ao RDS para MySQL ou bancos de dados de origem externa do MySQL. ``` mysql> CREATE USER 'repl_user'@'domain_name' IDENTIFIED BY 'password'; ``` Para bancos de dados de origem do Aurora MySQL, o parâmetro do cluster de banco de dados `skip_name_resolve` é definido como `1` (`ON`) e não pode ser modificado, então é necessário usar um endereço IP para o host em vez de um nome de domínio. Para ter mais informações, consulte [skip\$1name\$1resolve](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_skip_name_resolve) na documentação do MySQL. ``` mysql> CREATE USER 'repl_user'@'IP_address' IDENTIFIED BY 'password'; ``` O usuário requer os privilégios `REPLICATION CLIENT` e `REPLICATION SLAVE`. Concede esses privilégios ao usuário. Se você precisar usar replicação criptografada, exija conexões SSL para o usuário de replicação. Por exemplo, é possível usar uma das declarações a seguir para solicitar conexões SSL na conta de usuário `repl_user`. ``` GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'IP_address'; ``` ``` GRANT USAGE ON *.* TO 'repl_user'@'IP_address' REQUIRE SSL; ``` **nota** Se `REQUIRE SSL` não está incluído, a conexão de replicação pode silenciosamente cair de volta para uma conexão não criptografada. ## 6. Habilitar a replicação no seu destino de réplica Antes de habilitar a replicação, convém obter um snapshot manual do destino de réplica do cluster de banco de dados do Aurora MySQL ou da instância de banco de dados do RDS para MySQL. Se surgir um problema e for preciso restabelecer a replicação com o cluster de banco de dados ou o destino de réplica da instância de banco de dados, você poderá restaurar o cluster de banco de dados ou a instância de banco de dados desse snapshot em vez de precisar importar os dados em seu destino de réplica novamente. Use as instruções a seguir para habilitar a replicação do mecanismo do seu banco de dados. | Mecanismo do banco de dados | Instruções | | --- | --- | | Aurora MySQL | **Para habilitar a replicação de um cluster de banco de dados do Aurora MySQL** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) Para usar a criptografia SSL, defina o valor final como `1` em vez de `0`. | | RDS para MySQL | **Para habilitar a replicação de uma instância de banco de dados do Amazon RDS** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) Para usar a criptografia SSL, defina o valor final como `1` em vez de `0`. | | MySQL (externo) | **Para habilitar a replicação a partir de um banco de dados MySQL externo** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) | Se a replicação falhar, isso pode resultar em um grande aumento na E/S não intencional na réplica, o que pode prejudicar a performance. Se a replicação falhar ou não for mais necessária, você poderá executar o procedimento armazenado [mysql.rds\$1reset\$1external\$1master (Aurora MySQL versão 2)](mysql-stored-proc-replicating.md#mysql_rds_reset_external_master) ou [mysql.rds\$1reset\$1external\$1source (Aurora MySQL versão 3)](mysql-stored-proc-replicating.md#mysql_rds_reset_external_source) para remover a configuração de replicação. ### Configurar um local para interromper a replicação para uma réplica de leitura No Aurora MySQL versão 3.04 e posterior, você pode iniciar a replicação e interrompê-la em um local especificado do arquivo de log binário usando o procedimento [mysql.rds\$1start\$1replication\$1until(Aurora MySQL versão 3)](mysql-stored-proc-replicating.md#mysql_rds_start_replication_until) armazenado. **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 ao cluster de banco de dados do Aurora MySQL de réplica como o usuário mestre. 1. Execute o procedimento armazenado [mysql.rds\$1start\$1replication\$1until(Aurora MySQL versão 3)](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`. Caso você use a replicação baseada em GTID, use o procedimento armazenado [mysql.rds\$1start\$1replication\$1until\$1gtid(Aurora MySQL versão 3)](mysql-stored-proc-gtid.md#mysql_rds_start_replication_until_gtid) em vez do procedimento armazenado [mysql.rds\$1start\$1replication\$1until(Aurora MySQL versão 3)](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). ## 7. Monitore sua réplica Ao configurar a replicação do MySQL com um cluster de banco de dados do Aurora MySQL, você deve monitorar eventos de failover para o cluster de banco de dados do Aurora MySQL quando se tratar do destino da réplica. Se ocorrer um failover, o cluster de banco de dados que for seu destino de réplica poderá ser recriado 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). Também é possível monitorar até que ponto o destino da réplica está atrasado em relação à origem da replicação conectando-se a esse destino e executando o comando `SHOW SLAVE STATUS` (Aurora MySQL versão 2) ou `SHOW REPLICA STATUS` (Aurora MySQL versão 3). No resultado do comando, o campo `Seconds Behind Master` indica quanto o destino da réplica está atrasado em relação à origem. **Importante** Se você atualizar o cluster de banco de dados e especificar um grupo de parâmetros personalizado, será necessário reinicializar manualmente o cluster após a conclusão da atualização. Fazer isso faz com que o cluster use as novas configurações de parâmetros personalizados e reinicie a replicação do log binário. ## Como sincronizar senhas entre a fonte e o destino da replicação Ao alterar contas e senhas de usuário na fonte de replicação usando instruções SQL, as alterações são automaticamente replicadas para o destino de replicação. Se você usar o Console de gerenciamento da AWS, a AWS CLI ou a API do RDS para alterar a senha primária na fonte de replicação, essas alterações não serão replicadas automaticamente para o destino de replicação. Se quiser sincronizar o usuário primário e a senha primária entre os sistemas de fonte e de destino, você deverá fazer a mesma alteração no destino de replicação por conta própria. # Interromper a replicação de logs binários para o Aurora MySQL Para interromper a replicação do log binário com uma instância de banco de dados MySQL, um banco de dados MySQL externo ou outro cluster de banco de dados Aurora, siga estas etapas, abordadas a fundo no tópico a seguir. [1. Interrompa a replicação do log binário no destino da réplica](#AuroraMySQL.Replication.MySQL.Stopping.StopReplication) [2. Desabilitar o registro em log binário na origem da replicação](#AuroraMySQL.Replication.MySQL.Stopping.DisableBinaryLogging) ## 1. Interrompa a replicação do log binário no destino da réplica Use as instruções a seguir para interromper a replicação de log binário para o mecanismo do seu banco de dados. | Mecanismo do banco de dados | Instruções | | --- | --- | | Aurora MySQL | **Para interromper a replicação de log binário em um destino de réplica de cluster de banco de dados do Aurora MySQL** Conecte-se ao cluster de banco de dados Aurora que é o destino da réplica e chame o procedimento [mysql.rds\$1stop\$1replication](mysql-stored-proc-replicating.md#mysql_rds_stop_replication). | | RDS para MySQL | **Para interromper a replicação de log binário em uma instância de banco de dados do Amazon RDS** Conecte-se à instância de banco de dados RDS que é o destino da réplica e chame o procedimento [mysql.rds\$1stop\$1replication](mysql-stored-proc-replicating.md#mysql_rds_stop_replication). | | MySQL (externo) | **Para interromper a replicação de um log binário em um banco de dados MySQL externo** Conecte-se ao banco de dados MySQL e execute o comando `STOP SLAVE` (versão 5.7) ou `STOP REPLICA` (versão 8.0). | ## 2. Desabilitar o registro em log binário na origem da replicação Use as instruções da tabela a seguir para desativar o registro em log binário na origem da replicação para o mecanismo do seu banco de dados. | Mecanismo do banco de dados | Instruções | | --- | --- | | Aurora MySQL | **Para desabilitar o registro em log binário em um cluster de banco de dados do Amazon Aurora** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.Stopping.html) | | RDS para MySQL | **Para desabilitar o registro em log binário em uma instância de banco de dados do Amazon RDS** Não é possível desabilitar o registro em log binário diretamente para uma instância de banco de dados do Amazon RDS, mas é possível desabilitá-lo seguindo um destes procedimentos: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.Stopping.html) | | MySQL (externo) | **Para desabilitar o registro em log binário em um banco de dados MySQL externo** Conecte-se ao banco de dados MySQL e chame o comando `STOP REPLICATION`. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.Stopping.html) | # Escalar leituras para o banco de dados MySQL com o Amazon Aurora Você pode usar o Amazon Aurora com sua instância de banco de dados MySQL para aproveitar os recursos de escalabilidade de leitura do Amazon Aurora e expandir a workload de leitura de sua instância do banco de dados MySQL. Para usar o Aurora com a intenção de dimensionar as leituras da instância de banco de dados MySQL, crie um cluster de banco de dados do Amazon Aurora MySQL e faça dele uma réplica de leitura da instância de banco de dados MySQL. Isso se aplica a uma instância de banco de dados do RDS para MySQL ou a um banco de dados MySQL executado externamente em relação ao Amazon RDS. Para obter informações sobre como criar com um cluster de banco de dados do Amazon Aurora, consulte [Criar um cluster de bancos de dados do Amazon Aurora](Aurora.CreateInstance.md). Ao configurar a replicação entre sua instância de banco de dados MySQL e seu cluster de banco de dados Amazon Aurora, certifique-se de seguir estas diretrizes: + Use o endereço de endpoint do cluster de banco de dados do Amazon Aurora ao fazer referência a seu cluster de banco de dados do Amazon Aurora MySQL. Se ocorrer um failover, a réplica do Aurora promovida a instância primária para o cluster de banco de dados do Aurora MySQL continuará a usar o endereço do endpoint do cluster de banco de dados. + Retenha os logs binários na instância de gravador até confirmar que eles foram aplicados à réplica do Aurora. Essa manutenção garante que você possa restaurar a instância de gravador em caso de falha. **Importante** Ao usar a replicação autogerenciada, você será responsável por monitorar e resolver quaisquer problemas de replicação que possam ocorrer. Para ter mais informações, consulte [Diagnosticar e resolver atrasos entre réplicas de leitura](CHAP_Troubleshooting.md#CHAP_Troubleshooting.MySQL.ReplicaLag). **nota** As permissões necessárias para iniciar a replicação em um cluster de banco de dados do Aurora MySQL são restritas e não estão disponíveis ao seu usuário principal do Amazon RDS. Portanto, você deve usar os procedimentos [mysql.rds\$1set\$1external\$1master (Aurora MySQL versão 2)](mysql-stored-proc-replicating.md#mysql_rds_set_external_master) ou [mysql.rds\$1set\$1external\$1source (Aurora MySQL versão 3)](mysql-stored-proc-replicating.md#mysql_rds_set_external_source) e [mysql.rds\$1start\$1replication](mysql-stored-proc-replicating.md#mysql_rds_start_replication) para configurar a replicação entre o cluster de banco de dados do Aurora MySQL e a instância de banco de dados MySQL. ## Iniciar a replicação entre uma instância de origem externa e um cluster de banco de dados do Aurora MySQL 1. Confirme que a instância do banco de dados MySQL é 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 banco de dados MySQL 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 de banco de dados MySQL externa para o cluster de banco de dados do Amazon Aurora MySQL usando `mysqldump`. Para bancos de dados muito grandes, pode ser conveniente usar o procedimento descrito em [Importing data to an Amazon RDS for MySQL database with reduced downtime](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/mysql-importing-data-reduced-downtime.html) no *Guia do usuário do Amazon Relational Database Service*. Para Linux, macOS ou Unix: ``` mysqldump \ --databases \ --single-transaction \ --compress \ --order-by-primary \ -u local_user \ -p local_password | mysql \ --host aurora_cluster_endpoint_address \ --port 3306 \ -u RDS_user_name \ -p RDS_password ``` Para Windows: ``` mysqldump ^ --databases ^ --single-transaction ^ --compress ^ --order-by-primary ^ -u local_user ^ -p local_password | mysql ^ --host aurora_cluster_endpoint_address ^ --port 3306 ^ -u RDS_user_name ^ -p RDS_password ``` **nota** Confirme que não há um espaço entre a opção `-p` e a senha inserida. Use as opções `--host`, `--user (-u)`, `--port` e `-p` no comando `mysql` para especificar o nome do host, o nome do usuário, a porta e a senha para conectar-se ao cluster de banco de dados do Aurora. O nome do host é o nome de DNS do endpoint do cluster de banco de dados do Amazon Aurora, por exemplo, `mydbcluster.cluster-123456789012.us-east-1.rds.amazonaws.com`. Você pode encontrar o valor do endpoint nos detalhes do cluster no Console de gerenciamento do Amazon RDS. 1. Confirme que é possível gravar na instância do banco de dados MySQL novamente: ``` mysql> SET GLOBAL read_only = OFF; mysql> UNLOCK TABLES; ``` Para ter mais informações sobre como fazer backups para usar com a replicação, consulte [http://dev.mysql.com/doc/refman/8.0/en/replication-solutions-backups-read-only.html](http://dev.mysql.com/doc/refman/8.0/en/replication-solutions-backups-read-only.html) na documentação do MySQL. 1. No Console de gerenciamento do Amazon RDS, adicione o endereço IP do servidor que hospeda o banco de dados MySQL de origem ao grupo de segurança da VPC para o cluster de banco de dados do Amazon Aurora. Para ter 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*. Você também pode precisar configurar sua rede local para permitir conexões com o endereço IP de seu cluster de banco de dados Amazon Aurora, para que ele possa se comunicar com sua instância MySQL de origem. Para encontrar o endereço IP do cluster de banco de dados do Amazon Aurora, use o comando `host`. ``` host aurora_endpoint_address ``` O nome do host é o nome de DNS do endpoint do cluster de banco de dados Amazon Aurora. 1. Usando o cliente de sua preferência, conecte-se à instância externa do MySQL e crie um usuário do MySQL 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. Veja um exemplo a seguir. ``` CREATE USER 'repl_user'@'example.com' IDENTIFIED BY 'password'; ``` 1. Para a instância externa do MySQL, conceda privilégios de `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'@'example.com' IDENTIFIED BY 'password'; ``` 1. Faça um snapshot manual do cluster de banco de dados do Aurora MySQL para ser a réplica de leitura antes de configurar a replicação. Se for necessário restabelecer a replicação com o cluster de banco de dados como uma réplica de leitura, você poderá restaurar o cluster de banco de dados do Aurora MySQL desse snapshot, em vez de precisar importar os dados da instância de banco de dados MySQL para um novo cluster de banco de dados do Aurora MySQL. 1. Faça do cluster de banco Amazon Aurora a réplica. Conecte-se ao cluster de banco de dados do Amazon Aurora como o usuário principal e identifique o banco de dados MySQL de origem como a origem da replicação usando os procedimentos [mysql.rds\$1set\$1external\$1master (Aurora MySQL versão 2)](mysql-stored-proc-replicating.md#mysql_rds_set_external_master) ou [mysql.rds\$1set\$1external\$1source (Aurora MySQL versão 3)](mysql-stored-proc-replicating.md#mysql_rds_set_external_source) e [mysql.rds\$1start\$1replication](mysql-stored-proc-replicating.md#mysql_rds_start_replication). Use o nome do arquivo de log binário e a posição que você determinou na Etapa 2. Veja um exemplo a seguir. ``` For Aurora MySQL version 2: CALL mysql.rds_set_external_master ('mymasterserver.example.com', 3306, 'repl_user', 'password', 'mysql-bin-changelog.000031', 107, 0); For Aurora MySQL version 3: CALL mysql.rds_set_external_source ('mymasterserver.example.com', 3306, 'repl_user', 'password', 'mysql-bin-changelog.000031', 107, 0); ``` 1. No cluster de banco de dados do Amazon Aurora, chame o procedimento [mysql.rds\$1start\$1replication](mysql-stored-proc-replicating.md#mysql_rds_start_replication) para iniciar a replicação. ``` CALL mysql.rds_start_replication; ``` Após ter estabelecido a replicação entre sua instância de banco de dados MySQL e seu cluster de banco de dados do Amazon Aurora, você poderá adicionar réplicas do Aurora ao seu cluster de banco de dados do Amazon Aurora. Você poderá então se conectar às réplicas do Aurora para fazer a escalabilidade de leitura de seus dados. Para obter informações sobre como criar uma réplica do Aurora, consulte [Adicionar réplicas do Aurora a um cluster de banco de dados](aurora-replicas-adding.md). # Otimizar a replicação de logs binários para Aurora MySQL A seguir, você pode aprender como otimizar a performance da replicação de log binário e solucionar problemas relacionados no Aurora MySQL. **dica** Esta discussão presume que você esteja familiarizado com o mecanismo de replicação de log binário do MySQL e como funciona. Para obter informações anteriores, consulte [Implementação de replicação](https://dev.mysql.com/doc/refman/8.0/en/replication-implementation.html) na documentação do MySQL. ## Replicação de logs binários de vários threads Com a replicação de logs binários de vários threads, um thread SQL faz a leitura de eventos do log de retransmissão e coloca esses eventos em fila para que os threads de operador SQL sejam aplicados. Os threads de trabalho SQL são gerenciados pelo thread coordenador. Os eventos de log binário são aplicados em paralelo sempre que possível. O nível de paralelismo depende de alguns fatores, como versão, parâmetros, design do esquema e características da workload. A replicação de logs binários de vários threads não é compatível com o Aurora MySQL versão 3, o Aurora MySQL versão 2.12.1 e posterior. Para que uma réplica de vários threads processe eficientemente eventos de log binário em paralelo, você deve configurar a origem para replicação de log binário de vários threads, e a origem deve usar uma versão que inclua as informações de paralelismo nos respectivos arquivos de log binário. Quando uma instância de banco de dados do Aurora MySQL está configurada para utilizar a replicação de logs binários, por padrão a instância de réplica utiliza a replicação de um único thread para o Aurora MySQL versões anteriores a 3.04. Para habilitar a replicação de vários threads, atualize o parâmetro `replica_parallel_workers` para um valor superior a `1` no seu grupo de parâmetros personalizado. Para o Aurora MySQL versão 3.04 e posterior, a replicação tem vários threads por padrão, com `replica_parallel_workers` definido como `4`. É possível modificar esse parâmetro no grupo de parâmetros personalizado. Para aumentar a resiliência do banco de dados contra paradas inesperadas, recomendamos habilitar a replicação de GTID na origem e permitir GTIDs na réplica. Para permitir a replicação de GTID, defina `gtid_mode` como `ON_PERMISSIVE` na origem e na réplica. Para obter mais informações sobre a replicação baseada em GTID, consulte [Usar a replicação baseada em GTID](mysql-replication-gtid.md). As opções de configuração a seguir ajudam a ajustar a replicação de vários threads. Para obter informações sobre uso, consulte o tópico sobre [Opções e variáveis de replicação e registro em log binário](https://dev.mysql.com/doc/refman/8.0/en/replication-options.html), no *Guia de referência do MySQL*. Para ter mais informações sobre a replicação de vários threads, consulte [https://dev.mysql.com/blog-archive/improving-the-parallel-applier-with-writeset-based-dependency-tracking/](https://dev.mysql.com/blog-archive/improving-the-parallel-applier-with-writeset-based-dependency-tracking/) no blog do MySQL. Os valores ideais dos parâmetros dependem de diversos fatores. Por exemplo, a performance da replicação de log binário é influenciada pelas características da workload do seu banco de dados e pela classe de instância de banco de dados na qual a réplica está sendo executada. Por isso, recomendamos testar completamente todas as alterações nesses parâmetros de configuração antes de aplicar novas configurações de parâmetros a uma instância de produção: + `binlog_format recommended value` – definir como `ROW` + `binlog_group_commit_sync_delay` + `binlog_group_commit_sync_no_delay_count` + `binlog_transaction_dependency_history_size` + `binlog_transaction_dependency_tracking`: o valor recomendado é `WRITESET`. + `replica_preserve_commit_order` + `replica_parallel_type`: o valor recomendado é `LOGICAL_CLOCK`. + `replica_parallel_workers` + `replica_pending_jobs_size_max` + `transaction_write_set_extraction`: o valor recomendado é `XXHASH64`. As características do esquema e da workload são fatores que afetam a replicação em paralelo. Os fatores mais comuns são apresentados a seguir. + Ausência de chaves primárias: o RDS não pode estabelecer dependência de writeset para tabelas sem chaves primárias. Com o formato `ROW`, uma única instrução de várias linhas pode ser realizada com uma única verificação de tabela completa na origem, mas isso gera uma verificação de tabela completa por linha modificada na réplica. A ausência de chaves primárias diminui significativamente o throughput da replicação. + Existência de chaves estrangeiras: se houver chaves estrangeiras (FKs), o Amazon RDS não poderá usar a dependência de writeset para paralelismo de tabelas com a relação de FK. + Tamanho das transações: se uma única transação abranger dezenas ou centenas de megabytes ou gigabytes, o thread coordenador e um dos threads de trabalho podem passar um longo tempo processando somente essa transação. Durante esse período, todos os outros threads de trabalho podem permanecer inativos depois de concluírem o processamento das transações anteriores. No Aurora MySQL versão 3.06 e posterior, é possível melhorar o desempenho de réplicas de log binários ao replicar transações para tabelas grandes com mais de um índice secundário. Esse recurso introduz um grupo de threads para aplicar alterações de índice secundário em paralelo em uma réplica de log binário. O recurso é controlado pelo parâmetro `aurora_binlog_replication_sec_index_parallel_workers` do cluster de banco de dados, que controla o número total de threads paralelos disponíveis para aplicar as alterações do índice secundário. O parâmetro é definido como `0` (desabilitado) por padrão. A habilitação desse recurso não exige a reinicialização da instância. Para habilitar esse recurso, interrompa a replicação contínua, defina o número desejado de threads de operadores paralelos e inicie a replicação novamente. ## Otimizar a replicação de log binário No Aurora MySQL 2.10 e posteriores, o Aurora aplica automaticamente uma otimização conhecida como cache de E/S de binlog à replicação de log binário. Ao armazenar em cache os eventos de binlog confirmados mais recentemente, essa otimização foi projetada para melhorar a performance do processo de despejo de binlog, limitando o impacto nas transações em primeiro plano na instância de origem do binlog. **nota** Essa memória usada para esse recurso é independente da configuração `binlog_cache` do MySQL. Esse recurso não se aplica a instâncias de banco de dados do Aurora que usam as classes de instância `db.t2` e `db.t3`. Você não precisa ajustar nenhum parâmetro de configuração para ativar essa otimização. Especificamente, se você tiver ajustado o parâmetro de configuração `aurora_binlog_replication_max_yield_seconds` para um valor diferente de zero em versões anteriores do Aurora MySQL, defina-o de volta para zero nas versões atualmente disponíveis. As variáveis de status `aurora_binlog_io_cache_reads` e `aurora_binlog_io_cache_read_requests` ajudam você a monitorar a frequência com que os dados são lidos do cache de E/S do binlog. + `aurora_binlog_io_cache_read_requests`: mostra o número de solicitações de leitura de E/S para binlog provenientes do cache. + `aurora_binlog_io_cache_reads`: mostra o número de leituras de E/S para binlog que recuperam informações do cache. A consulta SQL a seguir calcula a porcentagem de solicitações de leitura de binlog que aproveitam as informações armazenadas em cache. Nesse caso, quanto mais próxima a proporção for de 100, melhor ela é. ``` mysql> SELECT (SELECT VARIABLE_VALUE FROM INFORMATION_SCHEMA.GLOBAL_STATUS WHERE VARIABLE_NAME='aurora_binlog_io_cache_reads') / (SELECT VARIABLE_VALUE FROM INFORMATION_SCHEMA.GLOBAL_STATUS WHERE VARIABLE_NAME='aurora_binlog_io_cache_read_requests') * 100 as binlog_io_cache_hit_ratio; +---------------------------+ | binlog_io_cache_hit_ratio | +---------------------------+ | 99.99847949080622 | +---------------------------+ ``` O recurso de cache de E/S de binlog também inclui novas métricas relacionadas aos processos de despejo de binlog. *Processos de despejo* são os processos criados quando novas réplicas de binlog são conectadas à instância de origem de binlog. As métricas de processos de despejo são impressas no log do banco de dados a cada 60 segundos com o prefixo `[Dump thread metrics]`. As métricas incluem informações para cada réplica de binlog `Secondary_id`, como `Secondary_uuid`, nome do arquivo de binlog e a posição que cada réplica está lendo. As métricas também incluem `Bytes_behind_primary`, que representa a distância em bytes entre a origem da replicação e a réplica. Essa métrica mede o atraso do processo de E/S da réplica. Essa figura é diferente do lag do processo do aplicador SQL da réplica, que é representado pela métrica `seconds_behind_master` na réplica do binlog. Você pode determinar se as réplicas de binlog estão alcançando a origem ou ficando para trás, verificando se a distância diminui ou aumenta. ## Log de retransmissão na memória No Aurora MySQL versão 3.10 e posterior, o Aurora introduz uma otimização conhecida como log de retransmissão na memória para melhorar o throughput de replicação. Essa otimização melhora o desempenho de E/S do log de retransmissão ao armazenar em cache todo o conteúdo intermediário do log de retransmissão na memória. Desse modo, ela reduz a latência de confirmação ao minimizar as operações de E/S de armazenamento, pois o conteúdo do log de retransmissão pode ser facilmente acessado na memória. Por padrão, o recurso de log de retransmissão na memória é habilitado automaticamente para cenários de replicação gerenciados pelo Aurora (como implantações azul-verde, replicação do Aurora para o Aurora e réplicas entre regiões) quando a réplica atende a qualquer uma destas configurações: + Modo de replicação de thread único (replica\$1parallel\$1workers = 0) + Replicação de vários threads com o modo de GTID habilitado: + Posicionamento automático habilitado + Modo de GTID definido como ON na réplica + Replicação baseada em arquivos com replica\$1preserve\$1commit\$1order = ON O recurso de log de retransmissão na memória é compatível com classes de instância maiores que t3.large, mas não está disponível em instâncias do Aurora Serverless. O buffer circular do log de retransmissão tem um tamanho fixo de 128 MB. Para monitorar o consumo de memória desse recurso, você pode executar a seguinte consulta: ``` SELECT event_name, current_alloc FROM sys.memory_global_by_current_bytes WHERE event_name = 'memory/sql/relaylog_io_cache'; ``` O recurso de log de retransmissão na memória é controlado pelo parâmetro aurora\$1in\$1memory\$1relaylog, que pode ser definido em nível de cluster ou de instância de banco de dados. Você pode habilitar ou desabilitar esse recurso dinamicamente sem reiniciar a instância: 1. Interrompa a replicação em andamento. 1. Defina aurora\$1in\$1memory\$1relaylog como ON (para habilitá-lo) ou OFF (para desabilitá-lo) no grupo de parâmetros 1. Reinicie a replicação. Exemplo: ``` CALL mysql.rds_stop_replication; set aurora_in_memory_relaylog to ON to enable or OFF to disable in cluster parameter group CALL mysql.rds_start_replication; ``` Mesmo que aurora\$1in\$1memory\$1relaylog esteja definido como ON, em determinadas condições o recurso de log de retransmissão na memória ainda pode estar desabilitado. Para verificar o status atual do recurso, você pode usar o seguinte comando: ``` SHOW GLOBAL STATUS LIKE 'Aurora_in_memory_relaylog_status'; ``` Se o recurso for desabilitado inesperadamente, você pode identificar o motivo executando: ``` SHOW GLOBAL STATUS LIKE 'Aurora_in_memory_relaylog_disabled_reason'; ``` Esse comando exibe uma mensagem explicando por que o recurso está desabilitado no momento. # Configurar o log binário avançado para Aurora MySQL O log binário avançado reduz a sobrecarga de performance computacional causada pela ativação do log binário, que pode chegar a até 50% em certos casos. Com o log binário avançado, essa sobrecarga pode ser reduzida para cerca de 13%. Para reduzir a sobrecarga, o log binário avançado grava os registros binários e de transações no armazenamento em paralelo, o que minimiza os dados gravados no momento da confirmação da transação. O uso do log binário avançado também melhora o tempo de recuperação do banco de dados após reinicializações e failovers em até 99% em comparação com o log binário do MySQL da comunidade. O log binário avançado é compatível com as workloads existentes baseadas em log binário e você interage com ele da mesma forma que interage com o log binário do MySQL da comunidade. O log binário avançado está disponível no Aurora MySQL versão 3.03.1 e posterior. **Topics** + [Configuração de parâmetros de log binário avançado](#AuroraMySQL.Enhanced.binlog.enhancedbinlog.parameters) + [Outros parâmetros relacionados](#AuroraMySQL.Enhanced.binlog.other.parameters) + [Diferenças entre o log binário avançado e o log binário do MySQL da comunidade](#AuroraMySQL.Enhanced.binlog.differences) + [Métricas do Amazon CloudWatch para o log binário avançado](#AuroraMySQL.Enhanced.binlog.cloudwatch.metrics) + [Limitações de log binário avançado](#AuroraMySQL.Enhanced.binlog.limitations) ## Configuração de parâmetros de log binário avançado Você pode alternar entre o log binário do MySQL da comunidade e o log binário avançado ativando/desativando os parâmetros aprimorados do log binário. Os consumidores de log binário existentes podem continuar lendo e consumindo os arquivos de log binário sem nenhuma lacuna na sequência do arquivo de log binário. Para ativar o log binário avançado, defina os seguintes parâmetros: | Parameter | Padrão | Descrição | | --- | --- | --- | | binlog\$1format | – | Defina o binlog\$1format parâmetro no formato de registro em log binário escolhido para ativar o log binário avançado. Garanta que binlog\$1format parameter não esteja definido como DESLIGADO. Para obter mais informações, consulte [Configurar o registro em log binário do Aurora MySQL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_LogAccess.MySQL.BinaryFormat.html). | | aurora\$1enhanced\$1binlog | 0 | Defina o valor desse parâmetro como 1 no grupo de parâmetros do cluster de banco de dados associado ao cluster do Aurora MySQL. Ao alterar o valor desse parâmetro, você deve reinicializar a instância do gravador quando o valor DBClusterParameterGroupStatus for exibido como pending-reboot. | | binlog\$1backup | 1 | Desative esse parâmetro para ativar o log binário avançado. Para fazer isso, defina o valor deste parâmetro como 0. | | binlog\$1replication\$1globaldb | 1 | Desative esse parâmetro para ativar o log binário avançado. Para fazer isso, defina o valor deste parâmetro como 0. | **Importante** É possível desativar os parâmetros `binlog_backup` e `binlog_replication_globaldb` somente ao usar o log binário avançado. Para desativar o log binário avançado, defina os seguintes parâmetros: | Parameter | Descrição | | --- | --- | | aurora\$1enhanced\$1binlog | Defina o valor desse parâmetro como 0 no grupo de parâmetros do cluster de banco de dados associado ao cluster do Aurora MySQL. Sempre que você alterar o valor desse parâmetro, reinicialize a instância do gravador quando o valor DBClusterParameterGroupStatus for exibido como pending-reboot. | | binlog\$1backup | Ative esse parâmetro ao desativar o log binário avançado. Para fazer isso, defina o valor deste parâmetro como 1. | | binlog\$1replication\$1globaldb | Ative esse parâmetro ao desativar o log binário avançado. Para fazer isso, defina o valor deste parâmetro como 1. | Para verificar se o log binário avançado está ativado, use o seguinte comando no cliente MySQL: ``` mysql>show status like 'aurora_enhanced_binlog'; +------------------------+--------+ | Variable_name | Value | +------------------------+--------+ | aurora_enhanced_binlog | ACTIVE | +------------------------+--------+ 1 row in set (0.00 sec) ``` Quando o log binário avançado está ativado, a saída mostra `ACTIVE` para `aurora_enhanced_binlog`. ## Outros parâmetros relacionados Quando você ativa o log binário avançado, os seguintes parâmetros são afetados: + O parâmetro `max_binlog_size` é visível, mas não pode ser modificado. O valor padrão `134217728` é automaticamente ajustado para `268435456` quando o log binário avançado é ativado. + Ao contrário do log binário do MySQL da comunidade, o `binlog_checksum` não atua como um parâmetro dinâmico quando o log binário avançado está ativado. Para que a alteração desse parâmetro tenha efeito, você deverá reinicializar manualmente o cluster de banco de dados mesmo quando `ApplyMethod` for `immediate`. + O valor definido no parâmetro `binlog_order_commits` não tem efeito na ordem das confirmações quando o log binário avançado é ativado. As confirmações são sempre ordenadas sem implicações adicionais na performance. ## Diferenças entre o log binário avançado e o log binário do MySQL da comunidade O log binário avançado interage de forma diferente com clones, backups e o banco de dados global do Aurora quando comparado ao log binário do MySQL da comunidade. Recomendamos que você entenda as seguintes diferenças antes de usar o log binário avançado. + Os arquivos de log binário avançado do cluster de banco de dados de origem não estão disponíveis em um cluster de banco de dados clonado. + Os arquivos de log binário avançado não estão incluídos nos backups do Aurora. Portanto, os arquivos de log binário avançado do cluster de banco de dados de origem não estão disponíveis após a restauração de um cluster de banco de dados, apesar de qualquer período de retenção definido nele. + Quando usados com um banco de dados global do Aurora, os arquivos de log binário avançado do cluster de banco de dados primário não são replicados para o cluster de banco de dados nas regiões secundárias. ****Exemplos**** Os exemplos a seguir ilustram as diferenças entre o log binário avançado e o log binário do MySQL da comunidade. **Em um cluster de banco de dados restaurado ou clonado** Quando o log binário avançado está ativado, os arquivos de log binário históricos não estão disponíveis no cluster de banco de dados restaurado ou clonado. Depois de uma operação de restauração ou clonagem, se o log binário estiver ativado, o novo cluster de banco de dados começará a gravar sua própria sequência de arquivos de log binário, começando com 1 (mysql-bin-changelog.000001). Para ativar o log binário avançado após uma operação de restauração ou clonagem, defina os parâmetros necessários do cluster de banco de dados no cluster de banco de dados restaurado ou clonado. Para ter mais informações, consulte [Configuração de parâmetros de log binário avançado](#AuroraMySQL.Enhanced.binlog.enhancedbinlog.parameters). **Example Exemplo: operação de clonagem ou de restauração executada quando o log binário avançado está ativado** Cluster de banco de dados de origem: ``` mysql> show binary logs; +----------------------------+-----------+-----------+ | Log_name | File_size | Encrypted | +----------------------------+-----------+-----------+ | mysql-bin-changelog.000001 | 156 | No | | mysql-bin-changelog.000002 | 156 | No | | mysql-bin-changelog.000003 | 156 | No | | mysql-bin-changelog.000004 | 156 | No | --> Enhanced Binlog turned on | mysql-bin-changelog.000005 | 156 | No | --> Enhanced Binlog turned on | mysql-bin-changelog.000006 | 156 | No | --> Enhanced Binlog turned on +----------------------------+-----------+-----------+ 6 rows in set (0.00 sec) ``` Em um cluster de banco de dados restaurado ou clonado, os arquivos de log binário não são copiados quando o log binário avançado é ativado. Para evitar a descontinuidade nos dados do log binário, os arquivos de log avançado gravados antes de ativar o log binário aprimorado também não estão disponíveis. ``` mysql>show binary logs; +----------------------------+-----------+-----------+ | Log_name | File_size | Encrypted | +----------------------------+-----------+-----------+ | mysql-bin-changelog.000001 | 156 | No | --> New sequence of Binlog files +----------------------------+-----------+-----------+ 1 row in set (0.00 sec) ``` **Example Exemplo: operação de clonagem ou de restauração executada quando o log binário avançado está desativado** Cluster de banco de dados de origem: ``` mysql>show binary logs; +----------------------------+-----------+-----------+ | Log_name | File_size | Encrypted | +----------------------------+-----------+-----------+ | mysql-bin-changelog.000001 | 156 | No | | mysql-bin-changelog.000002 | 156 | No | --> Enhanced Binlog enabled | mysql-bin-changelog.000003 | 156 | No | --> Enhanced Binlog enabled | mysql-bin-changelog.000004 | 156 | No | | mysql-bin-changelog.000005 | 156 | No | | mysql-bin-changelog.000006 | 156 | No | +----------------------------+-----------+-----------+ 6 rows in set (0.00 sec) ``` O log binário aprimorado é desativado depois de `mysql-bin-changelog.000003`. Em um cluster de banco de dados restaurado ou clonado, os arquivos de log binário gravados após a desativação do log binário avançado estão disponíveis. ``` mysql>show binary logs; +----------------------------+-----------+-----------+ | Log_name | File_size | Encrypted | +----------------------------+-----------+-----------+ | mysql-bin-changelog.000004 | 156 | No | | mysql-bin-changelog.000005 | 156 | No | | mysql-bin-changelog.000006 | 156 | No | +----------------------------+-----------+-----------+ 1 row in set (0.00 sec) ``` **Em um Amazon Aurora Global Database** Em um Amazon Aurora Global Database, os dados de log binário do cluster de banco de dados primário não são replicados para os clusters de banco de dados secundários. Após um processo de failover entre regiões, os dados do log binário não estão disponíveis no cluster de banco de dados primário recém-promovido. Se o log binário estiver ativado, o cluster de banco de dados recém-promovido iniciará sua própria sequência de arquivos de log binário, começando com 1 (mysql-bin-changelog.000001). Para ativar o log binário avançado após o failover, defina os parâmetros necessários do cluster de banco de dados no cluster de banco de dados secundário. Para ter mais informações, consulte [Configuração de parâmetros de log binário avançado](#AuroraMySQL.Enhanced.binlog.enhancedbinlog.parameters). **Example Exemplo: a operação global de failover do banco de dados é executada quando o log binário avançado é ativado** Cluster de banco de dados primário antigo (antes do failover): ``` mysql>show binary logs; +----------------------------+-----------+-----------+ | Log_name | File_size | Encrypted | +----------------------------+-----------+-----------+ | mysql-bin-changelog.000001 | 156 | No | | mysql-bin-changelog.000002 | 156 | No | | mysql-bin-changelog.000003 | 156 | No | | mysql-bin-changelog.000004 | 156 | No | --> Enhanced Binlog enabled | mysql-bin-changelog.000005 | 156 | No | --> Enhanced Binlog enabled | mysql-bin-changelog.000006 | 156 | No | --> Enhanced Binlog enabled +----------------------------+-----------+-----------+ 6 rows in set (0.00 sec) ``` Novo cluster de banco de dados primário (após o failover): Os arquivos de log binário não são replicados para regiões secundárias quando o log binário avançado está ativado. Para evitar a descontinuidade nos dados do log binário, os arquivos de log binário gravados antes de ativar o log binário avançado não estão disponíveis. ``` mysql>show binary logs; +----------------------------+-----------+-----------+ | Log_name | File_size | Encrypted | +----------------------------+-----------+-----------+ | mysql-bin-changelog.000001 | 156 | No | --> Fresh sequence of Binlog files +----------------------------+-----------+-----------+ 1 row in set (0.00 sec) ``` **Example Exemplo: a operação global de failover do banco de dados é executada quando o log binário avançado é desativado** Cluster de banco de dados de origem: ``` mysql>show binary logs; +----------------------------+-----------+-----------+ | Log_name | File_size | Encrypted | +----------------------------+-----------+-----------+ | mysql-bin-changelog.000001 | 156 | No | | mysql-bin-changelog.000002 | 156 | No | --> Enhanced Binlog enabled | mysql-bin-changelog.000003 | 156 | No | --> Enhanced Binlog enabled | mysql-bin-changelog.000004 | 156 | No | | mysql-bin-changelog.000005 | 156 | No | | mysql-bin-changelog.000006 | 156 | No | +----------------------------+-----------+-----------+ 6 rows in set (0.00 sec) ``` **Cluster de banco de dados restaurado ou clonado:** O log binário aprimorado é desativado depois de `mysql-bin-changelog.000003`. Os arquivos de log binário gravados após a desativação do log binário avançado são replicados e estão disponíveis no cluster de banco de dados recém-promovido. ``` mysql>show binary logs; +----------------------------+-----------+-----------+ | Log_name | File_size | Encrypted | +----------------------------+-----------+-----------+ | mysql-bin-changelog.000004 | 156 | No | | mysql-bin-changelog.000005 | 156 | No | | mysql-bin-changelog.000006 | 156 | No | +----------------------------+-----------+-----------+ 3 rows in set (0.00 sec) ``` ## Métricas do Amazon CloudWatch para o log binário avançado As métricas a seguir do Amazon CloudWatch são publicadas somente quando o binlog avançado está ativado. | Métrica do CloudWatch | Descrição | Unidades | | --- | --- | --- | | ChangeLogBytesUsed | A quantidade de armazenamento usada pelo log binário avançado. | Bytes | | ChangeLogReadIOPs | O número de operações de E/S de leitura executadas no log binário avançado em um intervalo de cinco minutos. | Contagem a cada 5 minutos | | ChangeLogWriteIOPs | O número de operações de E/S de disco de gravação executadas no log binário avançado em um intervalo de cinco minutos. | Contagem a cada 5 minutos | ## Limitações de log binário avançado As limitações a seguir se aplicam aos clusters de banco de dados Amazon Aurora quando o log binário avançado é ativado. + O log binário avançado é aceito apenas no Aurora MySQL versão 3.03.1 e posterior. + Os arquivos de log binário avançado gravados no cluster de banco de dados primário não são copiados para os clusters de banco de dados clonados ou restaurados. + Quando usados com o Amazon Aurora Global Database, os arquivos de log binário avançado do cluster de banco de dados primário não são replicados para os clusters de banco de dados secundários. Portanto, após o processo de failover, os dados históricos do log binário não estão disponíveis no novo cluster de banco de dados primário. + Os seguintes parâmetros de configuração do log binário são ignorados: + `binlog_group_commit_sync_delay` + `binlog_group_commit_sync_no_delay_count` + `binlog_max_flush_queue_time` + Você não pode eliminar ou renomear uma tabela corrompida em um banco de dados. Para eliminar essas tabelas, você pode entrar em contato com o Suporte. + O cache de E/S do log binário é desabilitado quando o registro binário avançado é ativado. Para ter mais informações, consulte [Otimizar a replicação de logs binários para Aurora MySQL](binlog-optimization.md). **nota** O log binário avançado fornece melhorias de performance de leitura semelhantes ao cache de E/S do log binário e avanços melhores na performance de gravação. + O recurso de retrocesso não é compatível. O log binário avançado não pode ser ativado em um cluster de banco de dados nas seguintes condições: + Cluster de banco de dados com o recurso de retrocesso atualmente habilitado. + O cluster de banco de dados com o recurso de retrocesso era habilitado anteriormente, mas agora está desabilitado. + Cluster de banco de dados restaurado com base em um cluster de banco de dados de origem ou de um snapshot com o recurso de retrocesso habilitado. # 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 um cluster do Aurora MySQL e uma fonte externa. **nota** Para o Aurora, você só pode usar esse recurso com clusters do Aurora MySQL que usem replicação de logs binários para ou de um banco de dados MySQL externo. O outro banco de dados pode ser uma instância do Amazon RDS MySQL, um banco de dados MySQL on-premises ou um cluster de banco de dados do Aurora em uma Região da AWS diferente. Para saber mais sobre como configurar esse tipo de replicação, consulte [Replicação entre Aurora e o MySQL ou entre Aurora e outro cluster de banco de dados do Aurora (replicação de log binário)](AuroraMySQL.Replication.MySQL.md). 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 o Aurora MySQL versões 2 e 3. **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 um cluster do Aurora MySQL](mysql-replication-gtid.configuring-aurora.md) + [Desabilitação da replicação baseada em GTID para um cluster de banco de dados do Aurora MySQL](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. **nota** Quando o Aurora sincroniza dados entre as instâncias de banco de dados em um cluster, esse mecanismo de replicação não envolve o log binário (binlog). Para o Aurora MySQL, a replicação baseada em GTID somente é aplicável quando você também usa a replicação de log binário para replicar dentro ou fora de um cluster de banco de dados do Aurora MySQL a partir de um banco de dados externo compatível com MySQL. 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. Normalmente, você usa a replicação baseada em GTID com o Aurora ao replicar de um banco de dados externo compatível com MySQL para um cluster do Aurora. É possível configurar essa configuração de replicação como parte de uma migração de um banco de dados no local ou do Amazon RDS para o Aurora MySQL. Se o banco de dados externo já usa GTIDs, a ativação da replicação baseada em GTID para o cluster do Aurora simplificará o processo de replicação. Você configura a replicação baseada em GTID para um cluster do Aurora MySQL definindo primeiro os parâmetros de configuração relevantes em um grupo de parâmetros de cluster de banco de dados. Em seguida, você associa esse grupo de parâmetros ao cluster. ## 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 essas configurações para o grupo de parâmetros de cluster de banco de dados do seu cluster de banco de dados do Aurora MySQL: + `ON` e `ON_PERMISSIVE` somente são aplicáveis à replicação de saída de um cluster do Aurora MySQL. Esses dois valores fazem com que o seu cluster de banco de dados do Aurora use GTIDs para transações que são replicadas para um banco de dados externo. O `ON` requer que o banco de dados externo também use a replicação baseada em GTID. O `ON_PERMISSIVE` torna a replicação baseada em GTID opcional no banco de dados externo. + `OFF_PERMISSIVE`, se definido, significa que o cluster de banco de dados do Aurora pode aceitar a replicação de entrada de um banco de dados externo. Ele pode fazer isso independentemente de o banco de dados externo usar a replicação baseada em GTID ou não. + `OFF`, se definido, significa que seu cluster de banco de dados do Aurora apenas aceita a replicação de entrada de bancos de dados externos que não usam a replicação baseada em GTID. **dica** A replicação de entrada é o cenário de replicação de log binário mais comum para clusters do Aurora MySQL. Para a replicação de entrada, recomendamos definir o modo de GTID como `OFF_PERMISSIVE`. Essa configuração permite a replicação de entrada de bancos de dados externos, independentemente das configurações de GTID na origem de replicação. Para obter mais informações sobre parameter groups, consulte [Grupos de parâmetros para Amazon Aurora](USER_WorkingWithParamGroups.md). # Ativar a replicação baseada em GTID para um cluster do Aurora MySQL Quando a replicação baseada em GTID está habilitada para um cluster de banco de dados do Aurora MySQL, as configurações de GTID aplicam-se à replicação de log binário de entrada e saída. **Para habilitar a replicação baseada em GTID para um cluster do Aurora MySQL** 1. Crie ou edite um grupo de parâmetros de cluster de banco de dados usando as seguintes configurações de parâmetros: + `gtid_mode` – `ON` ou `ON_PERMISSIVE` + `enforce_gtid_consistency` – `ON` 1. Associe o grupo de parâmetros de cluster de banco de dados ao cluster do Aurora MySQL. Para isso, siga o procedimento em [Grupos de parâmetros para Amazon Aurora](USER_WorkingWithParamGroups.md). 1. (Opcional) Especifique como atribuir GTIDs a transações que não os incluem. Para isso, chame o procedimento armazenado em [mysql.rds\$1assign\$1gtids\$1to\$1anonymous\$1transactions (Aurora MySQL versão 3)](mysql-stored-proc-gtid.md#mysql_assign_gtids_to_anonymous_transactions). # Desabilitação da replicação baseada em GTID para um cluster de banco de dados do Aurora MySQL Você pode desabilitar a replicação baseada em GTID para um cluster de banco de dados do Aurora MySQL. Isso significa que o cluster do Aurora não pode realizar a replicação de log binário de entrada ou saída com bancos de dados externos que usam a replicação baseada em GTID. **nota** No procedimento a seguir, *réplica de leitura* significa o destino de replicação em uma configuração do Aurora com replicação de log binário para ou de um banco de dados externo. O termo não significa as instâncias de banco de dados de réplica somente leitura do Aurora. Por exemplo, quando um cluster do Aurora aceita a replicação de entrada de uma origem externa, a instância primária do Aurora atua como a réplica de leitura para replicação de log binário. Para obter mais detalhes sobre os procedimentos armazenados mencionados nesta seção, consulte [Referência de procedimentos armazenados do Aurora MySQL](AuroraMySQL.Reference.StoredProcs.md). **Para desabilitar a replicação baseada em GTID para um cluster de banco de dados do Aurora MySQL** 1. Nas réplicas do Aurora, execute o seguinte procedimento: Para a versão 3 ``` CALL mysql.rds_set_source_auto_position(0); ``` Para a versão 2 ``` CALL mysql.rds_set_master_auto_position(0); ``` 1. Redefina o `gtid_mode` como `ON_PERMISSIVE`. 1. Certifique-se que o grupo de parâmetros de cluster de banco de dados associado ao cluster do Aurora MySQL tenha `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 Aurora](USER_WorkingWithParamGroups.md). 1. Reinicie o cluster de banco de dados do Aurora MySQL. 1. Redefina o `gtid_mode` como `OFF_PERMISSIVE`. 1. Certifique-se que o grupo de parâmetros de cluster de banco de dados associado ao cluster do Aurora MySQL tenha `gtid_mode` definido como `OFF_PERMISSIVE`. 1. Reinicie o cluster de banco de dados do Aurora MySQL. 1. Aguarde a aplicação de todas as transações de GTID na instância primária do Aurora. Para conferir se elas foram aplicadas, siga estas etapas: 1. Na instância de primária do Aurora, execute o comando `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: Para a versão 3 ``` SELECT SOURCE_POS_WAIT('file', position); ``` Para a versão 2 ``` 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: Para a versão 3 ``` SELECT SOURCE_POS_WAIT('mysql-bin-changelog.000031', 107); ``` Para a versão 2 ``` 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 de cluster de banco de dados associado ao cluster do Aurora MySQL tem as seguintes configurações de parâmetros: + `gtid_mode` – `OFF` + `enforce_gtid_consistency` – `OFF` 1. Reinicie o cluster de banco de dados do Aurora MySQL.