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.