Configuração de Replicação MySQL Assíncrona: Um Guia Passo a Passo

A replicação MySQL assíncrona ainda é um dos blocos de construção mais úteis em uma configuração de banco de dados. Você pode usá-la para réplicas de leitura, backups mais seguros, cópias de relatórios, preparação de migração e recuperação de desastres. A palavra importante é "assíncrona": a fonte confirma uma transação sem esperar que a réplica a aplique. Isso impede que a fonte bloqueie em cada gravação da réplica, mas também significa que a réplica pode ficar atrasada.

A terminologia antiga em muitos comandos MySQL diz "master" e "slave". Versões mais recentes do MySQL usam "source" e "replica" em comandos como SHOW REPLICA STATUS e CHANGE REPLICATION SOURCE TO. Você ainda pode ver os comandos antigos em sistemas, exemplos e scripts mais antigos. Este guia usa source e replica na explicação e mostra a forma mais recente do comando primeiro, com notas onde a sintaxe antiga difere.

O exemplo usa dois servidores:

• Fonte: 192.168.1.100
• Réplica: 192.168.1.101
• Usuário de replicação: repl_user
• Escopo: todos os bancos de dados, a menos que você filtre intencionalmente

Faça isso primeiro em um ambiente de teste se você nunca executou o procedimento antes. A configuração de replicação é simples quando tudo está limpo. Torna-se estressante quando a fonte está ocupada, o dump é inconsistente ou a réplica já contém dados antigos.

Antes de Tocar na Configuração

Confirme o básico:

• Ambos os servidores executam versões compatíveis do MySQL.
• A réplica pode alcançar a fonte na porta MySQL, geralmente 3306.
• Você tem acesso administrativo a ambas as instâncias MySQL.
• Você pode editar o arquivo de configuração do MySQL e reiniciar o MySQL, se necessário.
• A réplica está vazia ou você sabe exatamente quais dados existentes devem ser substituídos.
• A fonte tem espaço em disco suficiente para logs binários.

No host da réplica, teste o acesso básico à rede:

nc -vz 192.168.1.100 3306

Se nc não estiver disponível, use telnet ou as ferramentas de conectividade do seu provedor de nuvem. Corrija firewalls, grupos de segurança, endereços de bind e roteamento antes de configurar a replicação. Um usuário de replicação não ajudará se o caminho TCP estiver bloqueado.

Configurar o Servidor Fonte

A fonte deve gravar alterações em logs binários. A réplica lê esses eventos e os armazena em logs de retransmissão antes de aplicá-los.

Edite o arquivo de configuração do MySQL na fonte. Locais comuns são /etc/mysql/mysql.conf.d/mysqld.cnf, /etc/my.cnf ou um arquivo incluído desses caminhos. Adicione ou verifique estas configurações sob [mysqld]:

[mysqld]
server-id=1
log-bin=mysql-bin
binlog_format=ROW

server-id deve ser único em todos os servidores na topologia de replicação. log-bin ativa o log binário. binlog_format=ROW é um padrão prático para a maioria das configurações modernas de replicação porque registra alterações de linha em vez de depender do comportamento de reexecução de instruções.

Tenha cuidado com binlog-do-db e binlog-ignore-db. A filtragem parece conveniente, mas pode surpreendê-lo porque o comportamento baseado em instruções depende do banco de dados padrão selecionado pela sessão. Se você precisar de replicação filtrada, projete e teste deliberadamente. Para uma primeira configuração confiável, replique tudo.

Reinicie o MySQL na fonte:

sudo systemctl restart mysql
# ou, em alguns sistemas
sudo systemctl restart mysqld

Verifique as configurações:

SHOW VARIABLES LIKE 'server_id';
SHOW VARIABLES LIKE 'log_bin';
SHOW VARIABLES LIKE 'binlog_format';

log_bin deve ser ON. O server_id deve ser diferente de zero e único.

Criar um Usuário de Replicação

Crie uma conta dedicada na fonte que a réplica usará. Limite o host ao endereço da réplica se seu design de rede permitir:

CREATE USER 'repl_user'@'192.168.1.101' IDENTIFIED BY 'use_a_real_secret_here';
GRANT REPLICATION SLAVE ON *.* TO 'repl_user'@'192.168.1.101';

O nome do privilégio ainda é REPLICATION SLAVE nas concessões do MySQL, mesmo que a documentação mais recente geralmente diga "replica" em outros lugares.

Teste o login do host da réplica:

mysql -h 192.168.1.100 -u repl_user -p

Se isso falhar, corrija a autenticação e a rede agora. Causas comuns são bind-address na fonte, regras de firewall, incompatibilidade de host do usuário, DNS resolvendo para um endereço diferente e incompatibilidade de plugin de autenticação com um cliente mais antigo.

Configurar o Servidor Réplica

Na réplica, configure um server-id diferente. Logs de retransmissão geralmente são ativados automaticamente para replicação, mas nomeá-los explicitamente pode tornar as operações mais claras:

[mysqld]
server-id=2
relay_log=mysql-relay-bin
read_only=ON

Para proteção mais forte, considere super_read_only=ON após a configuração. read_only não impede que todas as contas privilegiadas escrevam. super_read_only é mais seguro para réplicas que nunca devem aceitar gravações de aplicativos, mas você pode precisar desativá-lo temporariamente para certas tarefas administrativas.

Reinicie o MySQL na réplica e verifique:

sudo systemctl restart mysql

SHOW VARIABLES LIKE 'server_id';
SHOW VARIABLES LIKE 'read_only';

Fazer um Snapshot Inicial Consistente

A réplica deve começar a partir de uma cópia de dados que corresponda a uma posição específica do log binário. Se o snapshot e a posição não corresponderem, a replicação pode iniciar e ainda estar errada.

Para bancos de dados com muitos InnoDB, mysqldump --single-transaction é geralmente o método consistente mais simples. Ele evita um bloqueio de leitura global longo para tabelas transacionais. Inclua --source-data=2 nas versões mais recentes do MySQL para que o dump registre o arquivo de log binário da fonte e a posição como uma linha comentada. Versões mais antigas usam --master-data=2.

Execute isso em um host confiável que possa se conectar à fonte:

mysqldump -h 192.168.1.100 -u root -p \
  --all-databases \
  --single-transaction \
  --routines \
  --triggers \
  --events \
  --source-data=2 \
  > source_dump.sql

Se sua versão do MySQL não suportar --source-data, use:

mysqldump -h 192.168.1.100 -u root -p \
  --all-databases \
  --single-transaction \
  --routines \
  --triggers \
  --events \
  --master-data=2 \
  > source_dump.sql

--single-transaction é seguro para consistência do InnoDB, mas não torna as tabelas MyISAM não transacionais consistentes da mesma forma. Se você ainda tiver tabelas MyISAM, planeje uma janela de manutenção ou use outro método de backup que forneça um snapshot consistente.

Verifique o dump para as coordenadas de replicação registradas:

grep -m 1 -E "CHANGE (MASTER|REPLICATION SOURCE)" source_dump.sql

Você deve ver uma linha comentada contendo um arquivo de log binário e posição. Guarde-a. Você a usará ao apontar a réplica para a fonte, a menos que escolha replicação baseada em GTID.

Importar o Snapshot na Réplica

Transfira o dump para a réplica usando seu método seguro normal:

scp source_dump.sql db-replica:/tmp/source_dump.sql

Na réplica, certifique-se de não estar escrevendo acidentalmente em um conjunto de dados existente semelhante ao de produção. Se esta réplica deve ser uma cópia limpa, descarte e recrie apenas o que seu plano de migração diz para substituir. Em seguida, importe:

mysql -u root -p < /tmp/source_dump.sql

Para dumps grandes, execute a importação em screen ou tmux e monitore o espaço em disco. Uma importação com falha porque /var/lib/mysql ou /tmp encheu perde tempo e pode deixá-lo com uma réplica meio carregada.

Apontar a Réplica para a Fonte

No MySQL 8.0.23 e mais recente, use CHANGE REPLICATION SOURCE TO:

CHANGE REPLICATION SOURCE TO
  SOURCE_HOST='192.168.1.100',
  SOURCE_USER='repl_user',
  SOURCE_PASSWORD='use_a_real_secret_here',
  SOURCE_LOG_FILE='mysql-bin.000001',
  SOURCE_LOG_POS=1234;

Substitua o arquivo e a posição pelos valores do dump. Se você estiver usando sintaxe antiga, o equivalente é:

CHANGE MASTER TO
  MASTER_HOST='192.168.1.100',
  MASTER_USER='repl_user',
  MASTER_PASSWORD='use_a_real_secret_here',
  MASTER_LOG_FILE='mysql-bin.000001',
  MASTER_LOG_POS=1234;

Se seu ambiente usa GTIDs, a configuração é diferente. Você normalmente configura o modo GTID em ambos os servidores, restaura um dump que preserva o estado GTID e usa SOURCE_AUTO_POSITION=1 em vez de um arquivo e posição. Não misture instruções GTID e de posição de arquivo casualmente; escolha uma abordagem e teste-a.

Uma Breve Nota sobre Replicação GTID

A replicação GTID é frequentemente mais fácil de operar após a configuração porque o MySQL rastreia transações por IDs de transação global em vez de fazer você gerenciar um arquivo de log binário e posição manualmente. É especialmente útil durante failover, alterações de fonte e reconstruções de réplica.

Isso não significa que você deva ativá-lo casualmente no meio de uma migração. Ambos os servidores precisam de configurações GTID compatíveis, e seu processo de backup ou dump deve preservar o estado GTID correto. Um padrão comum é configurar:

[mysqld]
gtid_mode=ON
enforce_gtid_consistency=ON

Em seguida, após restaurar um dump ciente de GTID, configure a réplica com:

CHANGE REPLICATION SOURCE TO
  SOURCE_HOST='192.168.1.100',
  SOURCE_USER='repl_user',
  SOURCE_PASSWORD='use_a_real_secret_here',
  SOURCE_AUTO_POSITION=1;

Use isso apenas se o histórico GTID da fonte e da réplica estiver limpo e compreendido. Se você não tiver certeza, a replicação de arquivo e posição é mais fácil de raciocinar para uma primeira configuração. A pior escolha é misturar exemplos de ambas as abordagens até que a replicação comece, mas o histórico de transações não é o que você pensa que é.

Inicie a replicação:

START REPLICA;

Sintaxe antiga:

START SLAVE;

Verifique o status:

SHOW REPLICA STATUS\G

Sintaxe antiga:

SHOW SLAVE STATUS\G

Os campos principais são:

Campo	Valor saudável	O que indica
Replica_IO_Running	Yes	A réplica pode conectar e buscar eventos de log binário.
Replica_SQL_Running	Yes	A réplica pode aplicar eventos de log de retransmissão.
Last_IO_Error	vazio	Problemas de rede, credenciais ou log de fonte aparecem aqui.
Last_SQL_Error	vazio	Conflitos de dados e erros de aplicação aparecem aqui.
Seconds_Behind_Source	baixo ou caindo	Um indicador aproximado de latência.

A saída mais antiga usa Slave_IO_Running, Slave_SQL_Running e Seconds_Behind_Master.

Testar com uma Pequena Gravação

Não declare vitória depois que os threads disserem Yes. Crie uma pequena tabela de teste ou insira uma linha inofensiva em um esquema de teste existente na fonte e verifique se ela aparece na réplica.

Exemplo na fonte:

CREATE DATABASE IF NOT EXISTS repl_check;
CREATE TABLE IF NOT EXISTS repl_check.heartbeat (
  id INT PRIMARY KEY,
  checked_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP
);
REPLACE INTO repl_check.heartbeat (id) VALUES (1);

Na réplica:

SELECT * FROM repl_check.heartbeat;

Isso detecta erros simples, como apontar para a fonte errada, filtrar o banco de dados ou usar coordenadas desatualizadas.

Proteger o Canal de Replicação

Se o tráfego de replicação cruzar uma rede não confiável, exija TLS. Mesmo dentro de uma rede privada, muitas equipes agora preferem tráfego de banco de dados criptografado porque os limites de rede mudam com o tempo.

No mínimo, crie o usuário e o canal de replicação para que as credenciais não sejam compartilhadas com contas de aplicativos. Para canais baseados em TLS, configure certificados de acordo com sua versão do MySQL e inclua opções SSL na configuração da fonte de replicação. As opções exatas variam de acordo com a versão e a política de certificados, mas a intenção é a mesma: a réplica deve verificar se está se conectando à fonte esperada e proteger credenciais e alterações de linha em trânsito.

Além disso, mantenha o privilégio do usuário de replicação restrito. Ele não precisa de amplo acesso DDL ou DML. Se alguém obtiver essa senha, o raio de explosão deve ser limitado à leitura de logs de replicação, não à gravação de dados do aplicativo.

Problemas Comuns de Configuração

Se Replica_IO_Running for No, a réplica não pode buscar eventos. Verifique:

• SOURCE_HOST está correto.
• A fonte está ouvindo no endereço e porta esperados.
• Firewalls e grupos de segurança permitem tráfego.
• O host do usuário de replicação corresponde ao IP de origem da réplica.
• A senha e o plugin de autenticação funcionam com a versão do cliente/servidor da réplica.
• O arquivo de log binário solicitado ainda existe na fonte.

Se Replica_SQL_Running for No, a réplica buscou eventos, mas não conseguiu aplicá-los. Verifique Last_SQL_Error. Chaves duplicadas geralmente significam que a réplica não foi inicializada a partir do snapshot correspondente exato ou alguém escreveu diretamente na réplica. Linhas ausentes geralmente significam desvio de dados. Pular uma transação com SQL_SLAVE_SKIP_COUNTER pode fazer o thread se mover, mas também pode tornar a réplica incorreta. Use-o apenas quando você entender a transação com falha e aceitar o risco de divergência.

Se a latência for alta logo após a configuração, deixe a réplica alcançar e observe se Seconds_Behind_Source cai. Uma grande importação de dump seguida pela inicialização da replicação pode deixar um acúmulo. Se a latência crescer em vez de encolher, inspecione E/S de disco na réplica e volume de gravação na fonte.

Manter a Réplica Saudável Após a Configuração

Configure a retenção de log binário na fonte para que as réplicas possam sobreviver a manutenção e interrupções. O MySQL moderno usa binlog_expire_logs_seconds:

[mysqld]
binlog_expire_logs_seconds=604800

Esse exemplo mantém logs por cerca de 7 dias. Escolha um valor com base em suas necessidades de recuperação e capacidade de disco. Sistemas mais antigos podem usar expire_logs_days.

Monitore o estado da replicação e a latência. No mínimo, alerte quando qualquer thread de replicação parar, quando a latência exceder sua tolerância e quando o uso de disco da fonte crescer porque os logs binários não são limpos. Para verificações de consistência de dados, muitas equipes usam ferramentas do Percona Toolkit, como pt-table-checksum e pt-table-sync, mas teste-as cuidadosamente antes de executá-las em dados de tamanho de produção.

Finalmente, mantenha o tráfego do aplicativo longe da réplica até que você tenha certeza de que ela é somente leitura, atualizada e monitorada. Uma réplica que aceita gravações acidentais é pior do que nenhuma réplica, porque o dano pode permanecer oculto até o failover ou a recuperação.

A replicação assíncrona funciona bem quando o snapshot inicial, as coordenadas do log binário, os privilégios e o monitoramento estão todos alinhados. A maioria das configurações com falha vem de um desses ser assumido em vez de verificado.