Backup e replicação no MySQL: um guia prático de sobrevivência

Um backup que você nunca restaurou é uma esperança, não um backup — e uma réplica que você não monitora é um ponto único de falha silencioso. Este guia cobre o essencial de MySQL que todo operador precisa: backups lógicos vs físicos, recuperação point-in-time e replicação baseada em GTID feita do jeito certo.

Dois tipos de backup, dois trabalhos diferentes

Backups lógicos exportam comandos SQL; backups físicos copiam os arquivos de dados. Você precisa saber qual atende seu objetivo de recuperação.

# Lógico — portátil, restore lento, ótimo para bancos pequenos/médios
mysqldump --single-transaction --routines --triggers \
  --all-databases > full.sql

# Físico — restore rápido de bancos grandes, lock quase zero com XtraBackup
xtrabackup --backup --target-dir=/backups/full

O --single-transaction é crítico: ele dá um snapshot consistente das tabelas InnoDB sem travar escritas. Sem ele, o mysqldump num servidor movimentado produz um dump inconsistente.

Recuperação point-in-time precisa de binary logs

Só um backup full noturno significa até 24 horas de perda de dados. O binary log é o equivalente ao WAL do MySQL — habilite-o e você pode reaplicar transações até o segundo antes do desastre:

# my.cnf
log_bin = mysql-bin
binlog_format = ROW
server_id = 1

# Restore: carregue o backup full e reaplique os binlogs até um instante
mysqlbinlog --stop-datetime="2026-05-10 14:29:59" \
  mysql-bin.000042 | mysql

Replicação com GTIDs

Os Global Transaction Identifiers tornam a replicação muito mais simples de raciocinar que a antiga abordagem de arquivo-e-posição — cada transação tem um ID único, então failover e reapontar réplicas "simplesmente funcionam".

# Nos dois servidores, my.cnf
gtid_mode = ON
enforce_gtid_consistency = ON
log_bin = mysql-bin

# Na réplica
CHANGE REPLICATION SOURCE TO
  SOURCE_HOST='primary.internal',
  SOURCE_USER='repl', SOURCE_PASSWORD='secret',
  SOURCE_AUTO_POSITION=1;
START REPLICA;

Sempre verifique a réplica

SHOW REPLICA STATUS\G
-- Procure por:
--   Replica_IO_Running: Yes
--   Replica_SQL_Running: Yes
--   Seconds_Behind_Source: 0

O Seconds_Behind_Source é sua métrica de lag — mas, como o número único de lag do PostgreSQL, ele esconde se o atraso é rede, disco ou uma consulta lenta na réplica. E um backup que você nunca restaurou não é um backup: teste a recuperação com regularidade.

Um painel para um parque poliglota

A maioria das empresas roda mais de um engine. O PG Monitoring concentra sua inteligência mais profunda no PostgreSQL, mas a disciplina é idêntica em todo lugar: acompanhar o lag de replicação continuamente, alertar sobre paradas e verificar que os backups realmente restauram — para que uma falha silenciosa de réplica nunca vire um evento silencioso de perda de dados.