Centro de Conhecimento DevOps
Centro de Conhecimento DevOps

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

Domine a configuração da replicação assíncrona do MySQL com este guia definitivo passo a passo. Aprenda a configurar corretamente os servidores Master e Slave, ajustando as configurações de `my.cnf`, estabelecendo contas de usuário de replicação seguras e realizando snapshots de dados iniciais críticos usando `mysqldump`. Este artigo fornece comandos práticos e dicas essenciais de solução de problemas para garantir uma sincronização de dados eficiente e minimizar a latência de replicação para uma arquitetura de banco de dados escalável.

46 visualizações

Configurando a Replicação Assíncrona do MySQL: Um Guia Passo a Passo

A replicação do MySQL é um recurso fundamental para alcançar alta disponibilidade, escalabilidade e estratégias robustas de backup. A replicação assíncrona, o tipo mais comum, garante que os dados gravados no servidor primário (Master) sejam eventualmente copiados para um ou mais servidores secundários (Slaves), sem que o Master espere o Slave confirmar a transação.

Este guia abrangente fornece um tutorial detalhado, passo a passo, para configurar uma configuração padrão de replicação assíncrona Master-Slave usando MySQL. Abordaremos os ajustes necessários na configuração do servidor, a configuração do usuário e os passos críticos para inicializar a sincronização de dados.

Pré-requisitos e Visão Geral

Antes de iniciar a configuração, certifique-se de ter:

  1. Dois servidores MySQL em execução (Servidor A: Master, Servidor B: Slave).
  2. Conectividade de rede entre os dois servidores (geralmente a porta TCP 3306 deve estar aberta).
  3. Acesso root ou administrativo para configurar ambas as instâncias do MySQL e modificar os arquivos de configuração my.cnf ou my.ini.

Para o propósito deste guia, assumimos que o IP do Servidor Master é 192.168.1.100 e o IP do Servidor Slave é 192.168.1.101.

Fase 1: Configurando o Servidor Master

O servidor Master deve ser configurado para registrar todos os eventos de modificação de dados em um arquivo de log binário, do qual o Slave fará a leitura.

Passo 1: Edite o Arquivo de Configuração do Master (my.cnf)

Localize o arquivo de configuração do MySQL (geralmente /etc/mysql/my.cnf ou /etc/my.cnf) e adicione ou modifique as seguintes diretivas dentro da seção [mysqld].

[mysqld]
# 1. ID único para este servidor (deve ser maior que 0)
server-id=1

# 2. Habilitar log binário
log-bin=mysql-bin

# 3. Lista de bancos de dados para replicar (opcional, mas recomendado)
# binlog-do-db=mydatabase

# 4. Opcional: Garantir que a conexão use TCP/IP, útil para testes
# bind-address=0.0.0.0

Nota: O server-id deve ser único em todos os servidores que participam da topologia de replicação.

Passo 2: Reinicie o MySQL e Verifique o Log Binário

Após salvar o arquivo de configuração, reinicie o serviço MySQL no servidor Master.

# Debian/Ubuntu
sudo systemctl restart mysql
# RHEL/CentOS
sudo systemctl restart mysqld

Faça login na interface de linha de comando do MySQL e verifique se o log binário está ativo:

SHOW VARIABLES LIKE 'log_bin';
-- O valor deve ser ON

Passo 3: Crie o Usuário de Replicação

A replicação requer uma conta de usuário dedicada no servidor Master com privilégios específicos que o Slave usará para se conectar e recuperar os logs binários. Certifique-se de que este usuário possa se conectar remotamente do endereço IP do Slave (192.168.1.101).

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

Passo 4: Registre o Status Atual do Master

Antes de prosseguir, devemos estabelecer a posição exata (Arquivo e Posição) no log binário onde o Slave deve começar a ler. Este passo é crítico para a sincronização.

FLUSH TABLES WITH READ LOCK; -- Interrompe temporariamente as gravações
SHOW MASTER STATUS;

-- IMPORTANTE: Anote estes dois valores:
-- File: mysql-bin.000001
-- Position: 1234

-- NÃO DESBLOQUEIE AS TABELAS AINDA SE ESTIVER TIRANDO UM SNAPSHOT INICIAL (Passo 6)

Fase 2: Configurando o Servidor Slave

Passo 5: Edite o Arquivo de Configuração do Slave (my.cnf)

Configure o servidor Slave com um ID único e configurações opcionais.

[mysqld]
# ID único para este servidor (deve ser diferente do Master)
server-id=2

# Opcional: Recomendado para segurança
read_only=1

# Opcional: Habilitar log de retransmissão
relay_log=mysql-relay-bin

Reinicie o serviço MySQL no servidor Slave após salvar as alterações.

Passo 6: Transferência Inicial de Dados (Snapshot)

Se o servidor Slave estiver vazio, você deve preenchê-lo com a estrutura e o conteúdo atuais dos dados do Master. Este snapshot inicial deve ser feito enquanto as tabelas do Master estão bloqueadas (do Passo 4).

No servidor Master, execute o comando mysqldump. Usamos a flag --master-data=2 para incluir automaticamente a declaração CHANGE MASTER TO necessária no arquivo de dump, o que simplifica o Passo 7.

# Executar no console/shell do servidor Master
mysqldump -u root -p --all-databases --master-data=2 --single-transaction > master_dump.sql

# Agora, retorne ao MySQL CLI do Master e libere o bloqueio
UNLOCK TABLES;

Transfira master_dump.sql para o servidor Slave e importe-o:

# Executar no console/shell do servidor Slave
mysql -u root -p < master_dump.sql

Melhor Prática: O uso de master-data=2 é altamente recomendado, pois automatiza a captura da posição correta do log binário logo no início do dump.

Fase 3: Iniciando a Replicação

Passo 7: Defina a Conexão Master

Na linha de comando do MySQL do servidor Slave, execute o comando CHANGE MASTER TO, substituindo os valores anotados no Passo 4 e o usuário criado no Passo 3.

CHANGE MASTER TO
    MASTER_HOST='192.168.1.100',
    MASTER_USER='repl_user',
    MASTER_PASSWORD='secure_password',
    MASTER_LOG_FILE='mysql-bin.000001', -- O Arquivo registrado no Passo 4
    MASTER_LOG_POS=1234;              -- A Posição registrada no Passo 4

Passo 8: Inicie a Replicação e Verificação

Após definir os parâmetros de conexão, inicie os threads de replicação do Slave.

START SLAVE;

Verifique se os threads de replicação estão em execução e comunicando corretamente usando o comando SHOW SLAVE STATUS:

SHOW SLAVE STATUS\G

Examine a saída para os seguintes campos críticos:

Campo Valor Esperado Descrição
Slave_IO_Running Yes O Slave está se conectando com sucesso ao Master.
Slave_SQL_Running Yes O Slave está aplicando transações ao seu banco de dados.
Seconds_Behind_Master 0 ou número baixo Indica a latência da replicação. Deve cair rapidamente para 0.

Se Slave_IO_Running ou Slave_SQL_Running mostrar No, examine os campos Last_IO_Error ou Last_SQL_Error para dicas de solução de problemas (por exemplo, problemas de firewall, credenciais incorretas, chaves duplicadas).

Dicas de Solução de Problemas e Manutenção

Lidando com Erros de Replicação

Se o Slave encontrar um erro (por exemplo, tentativa de inserir uma chave primária duplicada), o thread Slave_SQL_Running será interrompido. Geralmente, você pode ignorar erros menores e não críticos usando:

STOP SLAVE;
SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1;
START SLAVE;

Aviso: Use SQL_SLAVE_SKIP_COUNTER com cautela. Ignorar transações pode levar à divergência de dados (inconsistência) entre o Master e o Slave.

Verificando a Consistência

Embora a replicação assíncrona seja eficiente, ela não garante consistência imediata. Para ambientes de alto risco, utilize ferramentas como pt-table-checksum do Percona Toolkit para verificar periodicamente a deriva de dados entre o Master e o Slave.

Gerenciando Logs Binários

Os logs binários consomem espaço em disco ao longo do tempo. Configure a expiração de logs no Master para evitar o uso excessivo do disco:

[mysqld]
# Remove logs binários mais antigos que 7 dias (604800 segundos)
expire_logs_days=7