Effectuer une sauvegarde logique cohérente avec les informations GTID via mysqldump

Commande

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

Ce que fait la commande

Exporte les tables InnoDB dans un snapshot cohérent unique et écrit en tête le fichier / la position binlog (en commentaire) et une instruction SET @@GLOBAL.GTID_PURGED, afin que le dump puisse initialiser une réplique ou servir de point de départ à un PITR basé sur les binlogs.

Quand l'utiliser

Pour les bases jusqu'à quelques dizaines de GB, pour déplacer des schémas / tables, et pour une migration logique entre versions.

Attention

--single-transaction n'est cohérent que pour InnoDB ; les tables MyISAM sortent incohérentes. Un DDL (ALTER / RENAME / TRUNCATE) sur une table pendant le dump fait échouer le dump ou omettre la table. --source-data / --set-gtid-purged prennent un bref verrou global en lecture au début (privilège RELOAD requis) ; si une requête longue s'exécute à ce moment, toutes les écritures sont bloquées pendant l'attente du verrou. Un dump partiel (--databases) écrit quand même tous les GTID ; utilisez --set-gtid-purged=OFF pour déplacer un sous-ensemble vers un autre serveur. Le dump est mono-thread ; pour de gros volumes, préférez le dump de MySQL Shell ou XtraBackup.