DBAtlas · Atlas de operaciones de bases de datos

Tomar un backup lógico consistente con información de GTID usando mysqldump

MySQLBackup y 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

Qué hace

Vuelca las tablas InnoDB dentro de un único snapshot consistente y escribe al principio el archivo / posición del binlog (como comentario) y una sentencia SET @@GLOBAL.GTID_PURGED, de modo que el volcado pueda inicializar una réplica o servir como punto de partida de un PITR basado en binlog.

Cuándo usarlo

Para bases de datos de hasta unas pocas decenas de GB, para trasladar esquemas / tablas y para migraciones lógicas entre versiones.

Precaución

--single-transaction solo es consistente para InnoDB; las tablas MyISAM salen inconsistentes. Un DDL (ALTER / RENAME / TRUNCATE) sobre una tabla durante el volcado hace que este falle o que omita la tabla. --source-data / --set-gtid-purged toman un breve global read lock al inicio (requiere el privilegio RELOAD); si en ese momento hay una consulta larga en ejecución, todas las escrituras se detienen mientras el bloqueo espera. Un volcado parcial (--databases) sigue escribiendo todos los GTID; use --set-gtid-purged=OFF al trasladar un subconjunto a otro servidor. El volcado es de un solo thread; para datos grandes es preferible el dump de MySQL Shell o XtraBackup.

Abrir en DBAtlas →

Relacionado