View a markdown version of this page

Configurar a replicação atrasada com o Amazon Aurora MySQL - Amazon Aurora
Casos de uso para replicação atrasadaConfigurar a replicação externa com um atrasoModificar a replicação atrasada para uma réplica de leitura existenteDefinir um local para interromper a replicação para uma réplica de leituraPromover uma réplica de leituraTópicos relacionados

Configurar a replicação atrasada com o Amazon Aurora MySQL

Você pode usar a replicação atrasada como uma estratégia para a recuperação de desastres com o Aurora MySQL. Com a replicação atrasada, você especifica o tempo mínimo, em segundos, para atrasar a replicação da origem para a réplica de leitura. Em caso de um desastre, como uma tabela excluída acidentalmente, você executa as seguintes etapas para recuperar-se rapidamente do desastre:

  1. Interrompa a replicação da réplica de leitura antes que a origem envie alteração que causou o desastre. Use o procedimento armazenado mysql.rds_stop_replication para interromper a replicação.

  2. Inicie a replicação e especifique que a replicação deve ser interrompida automaticamente em um local do arquivo de log. Especifique um local imediatamente antes do desastre usando o procedimento armazenado mysql.rds_start_replication_until(Aurora MySQL versão 3).

  3. Promova a réplica de leitura para ser o novo cluster de banco de dados de origem usando as instruções em Promover uma réplica de leitura a um cluster de banco de dados para o Aurora MySQL.

nota

O Aurora MySQL oferece suporte à replicação atrasada para a versão 8.4.8 e superior.

  • Use procedimentos armazenados para configurar a replicação atrasada. Você não pode configurar a replicação atrasada com o Console de gerenciamento da AWS, a AWS CLI ou a API do Amazon RDS.

  • Você pode usar a replicação com base em identificadores de transação global (GTIDs) em uma configuração de replicação atrasada no Aurora MySQL versão 8.4.8 e superior.

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

  • O Aurora MySQL oferece suporte à replicação de várias origens com até 15 canais. Use as variantes do procedimento _for_channel para configurar a replicação atrasada em canais específicos.

Casos de uso para replicação atrasada

A replicação atrasada no Aurora MySQL se aplica à replicação baseada em log binário. Isso inclui a replicação de um cluster de banco de dados de gravação do Aurora MySQL para uma réplica de log binário, de uma origem externa do MySQL para um cluster de banco de dados do Aurora MySQL ou em canais de replicação de várias origens. Ela não se aplica às réplicas do Aurora em um único cluster de banco de dados, porque elas leem do armazenamento compartilhado do cluster e não do log binário. Entre os casos de uso comuns estão os seguintes:

  • Recuperação de desastres após erro do operador: mantenha uma réplica de log binário que atrasa a origem em um intervalo definido. Se uma instrução destrutiva for executada acidentalmente (por exemplo, descartar uma tabela), interrompa a replicação na réplica atrasada antes que a origem aplique a alteração. Em seguida, avance para um pouco antes do evento usando mysql.rds_start_replication_until(Aurora MySQL versão 3) ou mysql.rds_start_replication_until_gtid(Aurora MySQL versão 3). Por fim, promova a réplica. Essa abordagem fornece um caminho de recuperação mais rápido do que a recuperação pontual, que requer recuperação de falhas e repetição de log binário.

  • Proteção contra corrupção lógica de dados: uma réplica atrasada também protege contra uma implantação ou migração com defeito de aplicativos que gradualmente corrompe os dados. Como a réplica mantém o estado de pré-corrupção durante o atraso, você pode se recuperar antes que as transações com defeito sejam aplicadas.

  • Versão principal e atualizações em azul/verde: mantenha uma réplica atrasada do log binário durante uma atualização ou implantação azul/verde como uma rede de segurança, para que você possa voltar a um estado em boas condições se a atualização apresentar problemas.

  • Captura de dados de alterações (CDC) de uma origem externa: quando você ingere alterações em um cluster de banco de dados Aurora MySQL a partir de uma origem MySQL externa, um atraso intencional fornece um buffer controlado antes que as alterações sejam aplicadas posteriormente.

  • Inspeção histórica sem restauração: consulte a réplica atrasada para ver como eram seus dados em um momento anterior. Isso é útil para depurar, auditar ou investigar o que mudou, sem provisionar um clone ou executar uma restauração pontual.

  • Teste do comportamento do aplicativo sob atraso de replicação: use um atraso inflado artificialmente para validar como o aplicativo se comporta quando uma réplica está atrasada e para executar testes de regressão para condições sensíveis ao atraso, sem precisar gerar uma carga pesada para reproduzir o atraso.

Configurar a replicação externa com um atraso

É possível usar o procedimento armazenado mysql.rds_set_external_source_with_delay (Aurora MySQL versão 8.4.8 e posteriores) para configurar uma origem externa com replicação atrasada. Para obter mais informações sobre todos os procedimentos armazenados de replicação, consulte Configurar, iniciar e interromper a replicação de logs binários (binlogs).

Exemplo (canal padrão):

CALL mysql.rds_set_external_source_with_delay(
  'source-host.example.com',
  3306,
  'repl_user',
  'repl_password',
  'mysql-bin-changelog.000001',
  120,
  0,
  3600);

Exemplo (canal específico):

CALL mysql.rds_set_external_source_with_delay_for_channel(
  'source-host.example.com',
  3306,
  'repl_user',
  'repl_password',
  'mysql-bin-changelog.000001',
  120,
  0,
  3600,
  'channel_1');

Parâmetros:

host_name

O nome do host ou endereço IP da origem externa.

host_port

O número da porta da origem externa.

replication_user_name

O usuário de replicação na origem externa.

replication_user_password

A senha do usuário de replicação.

mysql_binary_log_file_name

O nome do arquivo de log binário na origem externa.

mysql_binary_log_file_location

A posição no arquivo de log binário para iniciar a replicação.

ssl_encryption

Defina esse parâmetro como 1 para habilitar a criptografia SSL para a conexão de replicação ou como 0 para desabilitar a criptografia SSL.

delay

O atraso mínimo em segundos (0–259.200).

canal

(somente variante for_channel) O nome do canal para replicação de várias origens.

Restrições:

  • O Aurora MySQL oferece suporte a, no máximo, 15 canais de replicação.

  • Cada canal deve ser replicado de uma origem diferente (combinação host:porta).

  • O atraso deve ser entre 0 e 259.200 segundos (72 horas).

  • Pare a replicação antes de modificar a configuração do canal.

Modificar a replicação atrasada para uma réplica de leitura existente

Para modificar a replicação atrasada para uma réplica de leitura existente, execute o procedimento armazenado mysql.rds_set_source_delay (Aurora MySQL versão 8.4.8 e posteriores). Para obter mais informações sobre todos os procedimentos armazenados de replicação, consulte Configurar, iniciar e interromper a replicação de logs binários (binlogs).

Para modificar a replicação atrasada para uma réplica de leitura existente:

  1. Usando um cliente do MySQL, conecte-se à réplica de leitura como o usuário administrador.

  2. Use o procedimento armazenado mysql.rds_stop_replication para interromper a replicação.

  3. Execute o procedimento armazenado mysql.rds_set_source_delay (Aurora MySQL versão 8.4.8 e posteriores).

  4. Use o procedimento armazenado mysql.rds_start_replication para iniciar a replicação.

Exemplo (canal padrão):

CALL mysql.rds_set_source_delay(3600);

Exemplo (canal específico):

CALL mysql.rds_set_source_delay_for_channel(3600, 'channel_1');

Isso especifica que a replicação para a réplica de leitura é atrasada por pelo menos uma hora (3.600 segundos). O valor de atraso deve ser entre 0 e 259.200 segundos (72 horas).

nota

Pare a replicação antes de definir o atraso. Se a replicação estiver em execução, você receberá um erro solicitando que você chame primeiro mysql.rds_stop_replication (ou mysql.rds_stop_replication_for_channel para um canal específico).

Definir um local para interromper a replicação para uma réplica de leitura

Após interromper a replicação para a réplica de leitura, você pode começar a replicação e interrompê-la em um local especificado do arquivo de log binário usando o procedimento armazenado mysql.rds_start_replication_until(Aurora MySQL versão 3).

Para iniciar a replicação e parar em um local específico:

  1. Usando um cliente do MySQL, conecte-se à réplica de leitura como o usuário administrador.

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

Exemplo:

CALL mysql.rds_start_replication_until(
  'mysql-bin-changelog.000777',
  120);

Isso 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 seja imediatamente antes do desastre.

A replicação é interrompida automaticamente quando o Aurora MySQL atinge o ponto de interrupção. O Aurora MySQL gera o seguinte evento: Replication has been stopped since the replica reached the stop point specified by the rds_start_replication_until stored procedure.

Caso você esteja usando a replicação baseada em GTID, use o procedimento armazenado mysql.rds_start_replication_until_gtid(Aurora MySQL versão 3).

Promover uma réplica de leitura

Após a replicação ser interrompida, em um cenário de recuperação de desastres, você pode promover uma réplica de leitura para ser o novo cluster de banco de dados de origem. Para obter informações sobre como promover uma réplica de leitura, consulte Promover uma réplica de leitura a um cluster de banco de dados para o Aurora MySQL.

Tópicos relacionados