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:
Sumário
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
4. Carregue o despejo em seu destino de réplica (se necessário).
5. Criar um usuário de replicação em sua origem de replicação
Como sincronizar senhas entre a fonte e o destino da replicação
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 Para alterar o parâmetro Se você estiver alterando o parâmetro Para ter mais informações, consulte Parâmetros do cluster de banco de dados e da instância de bancos de dados Amazon Aurora e Grupos de parâmetros para Amazon Aurora. |
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:
|
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. notaSe 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:
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.
Para habilitar o registro em log binário em um banco de dados MySQL externo
|
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_set_configuration e especifique um parâmetro de configuração O exemplo a seguir define o período de retenção para arquivos de log binário em seis dias:
Após a replicação ter sido iniciada, você poderá verificar se as mudanças foram aplicadas à sua réplica executando o comando Se essa configuração não for especificada, o padrão de Aurora MySQL será 24 (1 dia). Se você especificar um valor para |
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_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 |
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 |
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:
Como determinar o nome e a posição do arquivo de log binário Use um dos seguintes métodos:
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
|
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 no Guia do usuário do Amazon Relational Database Service.
|
MySQL (externo) |
Como criar um despejo de um banco de dados MySQL externo
|
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 ter mais informações, consulte Restauração de um snapshot de um cluster de banco de dados.
-
É possível clonar o cluster de banco de dados de origem para criar um cluster de banco de dados. Para ter mais informações, consulte Clonar um volume para um cluster de banco de dados do Amazon Aurora.
-
É possível migrar os dados de um snapshot de instância de banco de dados para um novo cluster de banco de dados. Para ter mais informações, consulte Migrar dados para um cluster de banco de dados do Amazon Aurora MySQL.
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
|
RDS para MySQL |
Como carregar um despejo em uma instância de banco de dados do Amazon RDS
|
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
|
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
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
Para usar a criptografia SSL, defina o valor final como |
RDS para MySQL |
Para habilitar a replicação de uma instância de banco de dados do Amazon RDS
Para usar a criptografia SSL, defina o valor final como |
MySQL (externo) |
Para habilitar a replicação a partir de um banco de dados MySQL externo
|
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
-
Usando um cliente do MySQL, conecte-se ao cluster de banco de dados do Aurora MySQL de réplica como o usuário mestre.
-
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áriomysql-bin-changelog.000777
. Em um cenário de recuperação de desastres, suponha que o local120
é 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.