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) - Amazon Aurora
Configurar a replicação com MySQL ou outro cluster de banco de dados do AuroraComo sincronizar senhas entre a fonte e o destino da replicaçãoComo interromper a replicação entre o Aurora e o MySQL ou entre o Aurora e outro cluster de banco de dados AuroraComo usar o Amazon Aurora para escalar leituras para seu banco de dados MySQLOtimização da replicação de log binárioConfigurar o log binário avançado

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.

No Aurora MySQL versão 3, a replicação de logs binários não é realizada no banco de dados do sistema mysql. As senhas e as contas não são replicadas pela replicação de log binário no Aurora MySQL versão 3. Portanto, instruções em linguagem de controle de dados (DCL) como CREATE USER, GRANT e REVOKE não são replicadas.

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.

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.

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. 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_assign_gtids_to_anonymous_transactions (Aurora MySQL versão 3).

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 <schema>.<table_name> engine=innodb, algorithm=copy;

Configurar a replicação com MySQL ou outro cluster de banco de dados do Aurora

Configurar a replicação do MySQL com o Aurora MySQL envolve as seguintes etapas, que são abordadas em detalhes:

1. Habilitar o registro em log binário na origem de replicação

2. Retenha os logs binários na origem da replicação até que não seja necessário

3. Crie um snapshot ou despejo da origem da replicação

4. Carregue o snapshot ou despejo em seu destino de réplica

5. Criar um usuário de replicação em sua origem de replicação

6. Habilitar a replicação no seu destino de réplica

7. Monitore sua réplica

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.

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.

3. Crie um snapshot ou despejo da origem da replicação

Use um snapshot ou despejo da origem da replicação para carregar uma cópia da linha de base dos dados na réplica e comece a replicar a partir desse ponto.

Use as instruções a seguir para criar um snapshot ou despejo da origem da replicação para o mecanismo do seu banco de dados.

4. Carregue o snapshot ou despejo em seu destino de réplica

Se você planeja carregar dados de um despejo de um banco de dados MySQL que seja externo ao Amazon RDS, você poderia criar uma instância do EC2 para copiar os arquivos de despejo e, em seguida, carregar os dados em seu cluster de banco de dados ou 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.

Use as instruções a seguir sobre como carregar o snapshot ou despejo da origem da replicação no destino de réplica para o mecanismo do seu banco de dados.

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

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_reset_external_master (Aurora MySQL versão 2) ou mysql.rds_reset_external_source (Aurora MySQL versão 3) 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_start_replication_until (Aurora MySQL versão 3) 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.

  2. Execute o procedimento armazenado mysql.rds_start_replication_until (Aurora MySQL versão 3).

    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_start_replication_until_gtid (Aurora MySQL versão 3) em vez do procedimento armazenado mysql.rds_start_replication_until (Aurora MySQL versão 3). Para obter mais informações sobre a replicação baseada em GTID, consulte Usar a replicação baseada em GTID.

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.

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.

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 AWS Management Console, 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.

Como interromper a replicação entre o Aurora e o MySQL ou entre o Aurora e outro cluster de banco de dados Aurora

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

2. Desabilitar o registro em log binário na origem da replicação

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.

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.

Como usar o Amazon Aurora para escalar leituras para seu banco de dados MySQL

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.

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.

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_set_external_master (Aurora MySQL versão 2) ou mysql.rds_set_external_source (Aurora MySQL versão 3) e 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;

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

  3. 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 Importar dados para uma instância de banco de dados MariaDB ou MySQL do Amazon RDS com tempo de inatividade reduzido no Guia do usuário do Amazon Relational Database Service.

    Para Linux, macOS ou Unix:

    mysqldump \
    --databases <database_name> \
    --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 <database_name> ^
    --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.

  4. 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 Backing up a source or replica by making it read only na documentação do MySQL.

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

  6. 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'@'mydomain.com' IDENTIFIED BY 'password';

  7. 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'@'mydomain.com'
    IDENTIFIED BY 'password';

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

  9. 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 o banco de dados principal da replicação usando os procedimentos mysql.rds_set_external_master (Aurora MySQL versão 2) ou mysql.rds_set_external_source (Aurora MySQL versão 3) e mysql.rds_start_replication.

    Use o nome do arquivo de log mestre e a posição do log mestre que você determinou na Etapa 2. Veja um exemplo a seguir.

    For Aurora MySQL version 2:
CALL mysql.rds_set_external_master ('mymasterserver.mydomain.com', 3306,
    'repl_user', 'password', 'mysql-bin-changelog.000031', 107, 0);

For Aurora MySQL version 3:
CALL mysql.rds_set_external_source ('mymasterserver.mydomain.com', 3306,
    'repl_user', 'password', 'mysql-bin-changelog.000031', 107, 0);

  10. No cluster de banco de dados do Amazon Aurora, chame o procedimento 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.

Otimização da replicação de log binário

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 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 operador SQL são gerenciados por um thread coordenador. Os eventos de log binário são aplicados em paralelo sempre que possível.

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.

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

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, no Guia de referência do MySQL.

A configuração ideal depende 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_group_commit_sync_delay

  • binlog_group_commit_sync_no_delay_count

  • binlog_transaction_dependency_history_size

  • binlog_transaction_dependency_tracking

  • replica_preserve_commit_order

  • replica_parallel_type

  • replica_parallel_workers

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.

Também é possível usar esse parâmetro como uma variável global, em que n é o número de threads de operadores paralelos:

SET global aurora_binlog_replication_sec_index_parallel_workers=n;

Otimizar a replicação de binlog (Aurora MySQL 2,10 e posteriores)

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ê ajustar 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 no Aurora MySQL 2.10 e posteriores.

As variáveis de status aurora_binlog_io_cache_reads e aurora_binlog_io_cache_read_requests estão disponíveis no Aurora MySQL 2.10 e posteriores. Essas variáveis de status 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.

Otimizar a replicação de log binário (Aurora MySQL versão 2 até a versão 2.09)

Para otimizar a replicação de log binário para Aurora MySQL, ajuste os seguintes parâmetros de otimização no nível do cluster. Esses parâmetros ajudam você a especificar o equilíbrio correto entre a latência na instância de origem do log binário e o atraso de replicação.

  • aurora_binlog_use_large_read_buffer

  • aurora_binlog_read_buffer_size

  • aurora_binlog_replication_max_yield_seconds

nota

Para clusters compatíveis com o MySQL 5.7, você pode usar esses parâmetros no Aurora MySQL versão 2 até a versão 2.09.*. No Aurora MySQL 2.10.0 e posteriores, esses parâmetros são substituídos pela otimização do cache de E/S de binlog e você não precisa usá-los.

Visão geral do grande buffer de leitura e otimizações de rendimento máximo

Você pode observar performance reduzida da replicação de log binário quando o thread de despejo de log binário acessa o volume do Aurora cluster enquanto o cluster processa um número elevado de transações. Você pode usar os parâmetros aurora_binlog_use_large_read_buffer, aurora_binlog_replication_max_yield_seconds e aurora_binlog_read_buffer_size para ajudar a minimizar esse tipo de contenção.

Suponha uma situação em que aurora_binlog_replication_max_yield_seconds está definido como maior que 0, e o arquivo de log binário atual do thread de despejo está ativo. Nesse caso, o thread de despejo de log binário aguarda até um número específico de segundos para que o arquivo de binlog atual seja preenchido por transações. Esse período de espera evita a disputa que pode surgir da replicação de cada evento de log binário individualmente. No entanto, isso aumenta o atraso da réplica para réplicas de log binário. Essas réplicas podem ficar atrás da origem pelo mesmo número de segundos que a configuração de aurora_binlog_replication_max_yield_seconds.

O arquivo de log binário atual significa o arquivo de log binário que o thread de despejo está fazendo a leitura atualmente para executar a replicação. Consideramos que um arquivo de log binário está ativo quando o arquivo de log binário está atualizando ou aberto para ser atualizado por transações recebidas. Depois de Aurora MySQL preencher o arquivo de log binário ativo, o MySQL cria e muda para um novo arquivo de log binário. O arquivo de log de binário antigo fica inativo. Ele não é mais atualizado por transações recebidas.

nota

Antes de ajustar esses parâmetros, meça a latência e a taxa de transferência da transação ao longo do tempo. Você pode achar que a performance de replicação de log binário é estável e tem baixa latência, mesmo que haja contenção ocasional.

aurora_binlog_use_large_read_buffer

Se esse parâmetro for definido como 1, Aurora MySQL otimiza a replicação de log binário com base nas configurações dos parâmetros aurora_binlog_read_buffer_size e aurora_binlog_replication_max_yield_seconds. Se aurora_binlog_use_large_read_buffer for 0, Aurora MySQL ignora os valores dos parâmetros aurora_binlog_read_buffer_size e aurora_binlog_replication_max_yield_seconds.

aurora_binlog_read_buffer_size

Os threads de despejo de log binário com buffer de leitura maior minimizam o número de operações de E/S de leitura lendo mais eventos para cada E/S. O parâmetro aurora_binlog_read_buffer_size define o tamanho do buffer de leitura. O buffer de leitura grande pode reduzir a disputa de log binário para workloads que geram uma grande quantidade de dados de log binário.

nota

Este parâmetro só tem um efeito quando o cluster também tem a configuração aurora_binlog_use_large_read_buffer=1.

Aumentar o tamanho do buffer de leitura não afeta a performance da replicação de log binário. Os threads de despejo de log binário não esperam a atualização de transações para preencher o buffer de leitura.

aurora_binlog_replication_max_yield_seconds

Se a workload exigir baixa latência de transação e você pode suportar algum atraso de replicação, é possível aumentar o parâmetro de aurora_binlog_replication_max_yield_seconds. Esse parâmetro controla a propriedade de rendimento máximo da replicação de log binário no cluster.

nota

Este parâmetro só tem um efeito quando o cluster também tem a configuração aurora_binlog_use_large_read_buffer=1.

Aurora MySQL reconhece qualquer alteração no valor do parâmetro aurora_binlog_replication_max_yield_seconds imediatamente. Você não precisa reiniciar a instância de banco de dados. No entanto, quando você habilita essa configuração, o thread de despejo apenas começa a gerar resultados quando o arquivo de binlog atual atinge seu tamanho máximo de 128 MB e é alternado para um novo arquivo.

Parâmetros relacionados

Utilize os seguintes parâmetros de cluster de banco de dados para ativar a otimização de log binário.

Parâmetro Padrão Valores válidos Descrição
aurora_binlog_use_large_read_buffer 1 0, 1 Alterne para ativar o recurso de melhoria de replicação. Quando seu valor é 1, o thread de despejo de log binário usa aurora_binlog_read_buffer_size para a replicação do log binário; caso contrário, o tamanho do buffer padrão (8K) é usado. Não utilizado no Aurora MySQL versão 3.
aurora_binlog_read_buffer_size 5242880 8192-536870912 Leia o tamanho do buffer usado pelo thread de despejo de log binário quando o parâmetro aurora_binlog_use_large_read_buffer é definido como 1. Não utilizado no Aurora MySQL versão 3.
aurora_binlog_replication_max_yield_seconds 0 0-36000

Para o Aurora MySQL versão 2.07.*, o valor máximo aceito é 45. Você pode ajustá-lo para um valor mais alto na versão 2.09 e em versões posteriores.

Para a versão 2, esse parâmetro só funciona quando o parâmetro aurora_binlog_use_large_read_buffer é definido como 1.

Habilitar o mecanismo de rendimento máximo para replicação de log binário

Você pode ativar a otimização de rendimento máximo de replicação de log binário da seguinte forma. Isso minimiza a latência para transações na instância de origem do log binário. No entanto, você pode ter maior atraso de replicação.

Para habilitar a otimização de binlog com rendimento máximo 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:

    • aurora_binlog_use_large_read_buffer: ative um valor de ON ou 1.

    • aurora_binlog_replication_max_yield_seconds: especifique um valor maior que 0.

  2. Associe o grupo de parâmetro do cluster de banco de dados ao cluster de Aurora MySQL que funciona como a origem do log binário. Para isso, siga o procedimento em Trabalhar com grupos de parâmetros.

  3. Confirme se a alteração do parâmetro entra em vigor. Para isso, execute a seguinte consulta na instância de origem do log binário. 

    SELECT @@aurora_binlog_use_large_read_buffer, @@aurora_binlog_replication_max_yield_seconds;

    Sua saída deve ser similar à seguinte. 

    +---------------------------------------+-----------------------------------------------+
| @@aurora_binlog_use_large_read_buffer | @@aurora_binlog_replication_max_yield_seconds |
+---------------------------------------+-----------------------------------------------+
|                                     1 |                                            45 |
+---------------------------------------+-----------------------------------------------+

Desativar a otimização de rendimento máximo de replicação de log binário

Você pode desativar a otimização de rendimento máximo de replicação de log binário da seguinte forma. Isso minimiza o atraso de replicação. No entanto, você pode ter maior latência para transações na instância de origem do log binário.

Para desativar a otimização de rendimento máximo de um cluster de Aurora MySQL

  1. Certifique-se que o grupo de parâmetros de cluster de banco de dados associado ao cluster do Aurora MySQL tenha aurora_binlog_replication_max_yield_seconds definido como 0. Para ter mais informações sobre a definição de parâmetros de configuração usando grupos de parâmetros, consulte Trabalhar com grupos de parâmetros.

  2. Confirme se a alteração do parâmetro entra em vigor. Para isso, execute a seguinte consulta na instância de origem do log binário. 

    SELECT @@aurora_binlog_replication_max_yield_seconds;

    Sua saída deve ser similar à seguinte. 

    +-----------------------------------------------+
| @@aurora_binlog_replication_max_yield_seconds |
+-----------------------------------------------+
|                                             0 |
+-----------------------------------------------+

Desativando o grande buffer de leitura

É possível desabilitar todo o recurso de buffer de leitura grande da seguinte maneira.

Para desativar o buffer de leitura de log binário grande para um cluster de Aurora MySQL

  1. Redefina o aurora_binlog_use_large_read_buffer para OFF ou 0.

    Certifique-se que o grupo de parâmetros de cluster de banco de dados associado ao cluster do Aurora MySQL tenha aurora_binlog_use_large_read_buffer definido como 0. Para ter mais informações sobre a definição de parâmetros de configuração usando grupos de parâmetros, consulte Trabalhar com grupos de parâmetros.

  2. Na instância de origem do log binário, execute a seguinte consulta. 

    SELECT @@ aurora_binlog_use_large_read_buffer;

    Sua saída deve ser similar à seguinte. 

    +---------------------------------------+
| @@aurora_binlog_use_large_read_buffer |
+---------------------------------------+
|                                     0 |
+---------------------------------------+

Configurar o log binário avançado

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.

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
Parâmetro Padrão Descrição
binlog_format – Defina o binlog_format parâmetro no formato de registro em log binário escolhido para ativar o log binário avançado. Garanta que binlog_format parameter não esteja definido como DESLIGADO. Para obter mais informações, consulte Configurar o registro em log binário do Aurora MySQL.
aurora_enhanced_binlog 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_backup 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_replication_globaldb 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
Parâmetro Descrição
aurora_enhanced_binlog 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_backup Ative esse parâmetro ao desativar o log binário avançado. Para fazer isso, defina o valor deste parâmetro como 1.
binlog_replication_globaldb 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.

exemplo Operação de clonagem ou 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)
exemplo Operação de clonagem ou restauração 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)

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.

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)
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:

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 AWS Support.

  • O cache de E/S do log binário é desabilitado quando o registro binário avançado é ativado. Para ter mais informações, consulte Otimização da replicação de log binário.

    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.