Configurar a replicação de logs binários para o Aurora MySQL - Amazon Aurora

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:

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

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.

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.

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.

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