Passo a passo para criar replicação MySQL 8.4 ou MariaDB primária-réplica com GTID, com usuário dedicado, TLS e verificação de atraso.

Para que serve

A replicação MySQL mantém uma cópia do banco atualizada quase em tempo real em outro servidor ou VM. Ela serve para ter um banco de reserva pronto para assumir em caso de falha, para tirar relatórios e backups da réplica sem pesar no primário e para migrar de servidor com pouca parada. Com GTID (identificador global de transação), a réplica sabe sozinha de onde continuar, sem anotar arquivo e posição do binlog.

Replicação não é backup. Um DROP TABLE ou um DELETE errado é replicado em segundos. Continue fazendo backups (veja a categoria Backup e migração).

Pré-requisitos

  • Dois servidores ou VMs com a mesma versão principal (ex.: MySQL 8.4 nos dois, ou MariaDB 11.4 nos dois). A réplica nunca deve ser mais antiga que o primário.
  • Comunicação pela rede privada (VLAN, bridge interna do Proxmox ou VPN WireGuard). Nos exemplos: primário 10.0.0.11, réplica 10.0.0.12. Se os dois servidores dedicados estiverem no mesmo datacenter, a E-Consulters pode colocá-los na mesma VLAN (cada servidor tem a sua por padrão): peça por ticket. Em datacenters diferentes, use uma VPN WireGuard entre eles.
  • Porta 3306 liberada somente entre os dois IPs. Não exponha a porta na internet (veja segurança de banco de dados).
  • Todas as tabelas em InnoDB e com chave primária (recomendado para replicação por linha).

Parte A: replicação MySQL 8.4 com GTID

1. Configure o primário

Em /etc/mysql/mysql.conf.d/mysqld.cnf, seção [mysqld]:

server_id                = 11
bind-address             = 10.0.0.11
log_bin                  = mysql-bin
gtid_mode                = ON
enforce_gtid_consistency = ON
binlog_expire_logs_seconds = 604800

Reinicie (systemctl restart mysql) e crie o usuário de replicação, exigindo TLS:

CREATE USER 'repl'@'10.0.0.12' IDENTIFIED BY 'SenhaForteAqui' REQUIRE SSL;
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'10.0.0.12';

O binlog_expire_logs_seconds (7 dias no exemplo) define por quanto tempo a réplica pode ficar desconectada e ainda recuperar o atraso.

2. Configure a réplica

server_id                = 12
log_bin                  = mysql-bin
gtid_mode                = ON
enforce_gtid_consistency = ON
read_only                = ON
super_read_only          = ON
relay_log                = relay-bin

super_read_only impede gravações até de administradores, evitando que alguém altere dados direto na réplica e quebre a replicação. Reinicie o serviço.

3. Copie os dados iniciais

No primário, gere um dump consistente que já carrega as GTIDs:

mysqldump -u root -p --all-databases --single-transaction \
  --triggers --routines --events --set-gtid-purged=ON \
  | gzip > /root/inicial.sql.gz
scp /root/inicial.sql.gz root@10.0.0.12:/root/

Na réplica, limpe o histórico de GTID local e importe:

mysql -u root -p -e "SET GLOBAL super_read_only=OFF; RESET BINARY LOGS AND GTIDS;"
zcat /root/inicial.sql.gz | mysql -u root -p
mysql -u root -p -e "SET GLOBAL super_read_only=ON;"

No MySQL 8.0, o comando equivalente é RESET MASTER. Para bancos de centenas de GB, o dump lógico é lento; prefira o plugin Clone do MySQL ou o Percona XtraBackup, descritos nos artigos de backup.

4. Inicie a replicação

CHANGE REPLICATION SOURCE TO
  SOURCE_HOST = '10.0.0.11',
  SOURCE_PORT = 3306,
  SOURCE_USER = 'repl',
  SOURCE_PASSWORD = 'SenhaForteAqui',
  SOURCE_AUTO_POSITION = 1,
  SOURCE_SSL = 1;
START REPLICA;

Parte B: replicação MariaDB com GTID

No MariaDB, a GTID é sempre gerada (formato domínio-servidor-sequência); não existe gtid_mode. A sintaxe usa CHANGE MASTER.

  1. Primário (/etc/mysql/mariadb.conf.d/50-server.cnf): 
    server_id        = 11
bind-address     = 10.0.0.11
log_bin          = mariadb-bin
binlog_format    = ROW
gtid_strict_mode = ON
expire_logs_days = 7
    Crie o usuário: CREATE USER 'repl'@'10.0.0.12' IDENTIFIED BY '...' REQUIRE SSL; GRANT REPLICATION SLAVE ON *.* TO 'repl'@'10.0.0.12';
  2. Réplica: server_id = 12, log_bin = mariadb-bin, gtid_strict_mode = ON, read_only = ON.
  3. Dump no primário, gravando a posição GTID: 
    mariadb-dump -u root -p --all-databases --single-transaction \
  --routines --events --master-data=2 --gtid | gzip > /root/inicial.sql.gz
  4. Importe na réplica e pegue a GTID registrada no início do arquivo: 
    zcat /root/inicial.sql.gz | mariadb -u root -p
zcat /root/inicial.sql.gz | head -60 | grep -i gtid_slave_pos
  5. Inicie, usando o valor encontrado: 
    SET GLOBAL gtid_slave_pos = '0-11-123456';
CHANGE MASTER TO
  MASTER_HOST = '10.0.0.11',
  MASTER_USER = 'repl',
  MASTER_PASSWORD = '...',
  MASTER_USE_GTID = slave_pos,
  MASTER_SSL = 1;
START SLAVE;
    Use slave_pos em réplicas comuns. current_pos é para quando um antigo primário volta como réplica.

Como saber se a replicação MySQL funcionou

Na réplica:

SHOW REPLICA STATUS\G   -- MySQL 8.4 e MariaDB 10.5+
  • Replica_IO_Running: Yes e Replica_SQL_Running: Yes (no MariaDB os campos podem aparecer como Slave_IO_Running/Slave_SQL_Running).
  • Seconds_Behind_Source (ou Seconds_Behind_Master) próximo de 0.
  • Last_IO_Error e Last_SQL_Error vazios.

Teste prático: crie uma tabela em um banco de teste no primário e veja se ela aparece na réplica.

Problemas comuns

Erro de autenticação "requires secure connection"

No MySQL 8, o plugin caching_sha2_password exige TLS ou troca de chave. Use SOURCE_SSL = 1 (recomendado) ou GET_SOURCE_PUBLIC_KEY = 1.

Erro 1236: binlog necessário já foi apagado

A réplica ficou parada mais tempo que a retenção de binlogs. Será preciso refazer a cópia inicial. Aumente a retenção se as paradas forem frequentes.

Erro 1062 (chave duplicada) na réplica

Alguém gravou direto na réplica. Confirme super_read_only/read_only. Pular transações esconde divergências; o mais seguro é recriar a réplica a partir de um dump novo.

Réplica atrasando cada vez mais

Verifique disco e CPU da réplica e ative a aplicação paralela: no MySQL 8.4, replica_parallel_workers já vem com 4; no MariaDB, ajuste slave_parallel_threads. Transações enormes (um UPDATE de milhões de linhas) sempre atrasam; divida em lotes.

Perguntas frequentes

A réplica assume sozinha se o primário cair?

Não. A troca (failover) é manual: pare a replicação na réplica, desligue o read_only e aponte a aplicação para ela. Para automação, existem ferramentas como MySQL InnoDB Cluster, Orchestrator ou MaxScale, que exigem planejamento à parte.

Posso replicar de MySQL para MariaDB?

Os formatos de GTID são incompatíveis. Para migrar entre os dois, use dump e importação, e não replicação com GTID.

Posso usar a réplica para leitura?

Sim, aceitando um pequeno atraso. Para dividir leitura e escrita automaticamente, veja o artigo sobre ProxySQL.

Leitura complementar

Precisa de ajuda?

Se a réplica não conseguir se conectar ao primário e você suspeitar de problema de rede entre os servidores, abra um ticket com a saída de SHOW REPLICA STATUS\G e de nc -vz 10.0.0.11 3306 executado na réplica.

Esta resposta lhe foi útil? 0 Usuários acharam útil (0 Votos)

Leia também