DBAtlas · Atlas de operações de banco de dados

Fazer um backup lógico consistente com informações de GTID usando mysqldump

MySQLBackup e PITR

Comando

mysqldump -h db1 -u backup -p \
  --single-transaction --source-data=2 --set-gtid-purged=ON \
  --routines --events --triggers --hex-blob \
  --all-databases | gzip > /backup/full_$(date +%F_%H%M).sql.gz

# Restore: GTID sets must not overlap on the target
zcat /backup/full_2026-10-08_0200.sql.gz | mysql -h db2 -u root -p

O que faz

Faz o dump das tabelas InnoDB dentro de um único snapshot consistente e grava no topo o arquivo / posição do binlog (como comentário) e um comando SET @@GLOBAL.GTID_PURGED, para que o dump possa alimentar uma réplica ou servir de ponto de partida para um PITR baseado em binlog.

Quando usar

Para bancos de até algumas dezenas de GB, para mover schemas / tabelas e para migração lógica entre versões.

Atenção

--single-transaction só é consistente para InnoDB; tabelas MyISAM saem inconsistentes. DDL (ALTER / RENAME / TRUNCATE) em uma tabela durante o dump faz o dump falhar ou perder a tabela. --source-data / --set-gtid-purged obtêm um breve global read lock no início (exige o privilégio RELOAD); se uma consulta longa estiver rodando nesse momento, todas as gravações travam enquanto o lock espera. Um dump parcial (--databases) ainda grava todos os GTIDs; use --set-gtid-purged=OFF ao mover um subconjunto para outro servidor. O dump é single-threaded; para dados grandes prefira o dump do MySQL Shell ou o XtraBackup.

Abrir no DBAtlas →

Relacionados