# 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.