不能直接用mysqldump做主从全量同步，因其默认不锁表且无法保证binlog位点一致性，易导致复制中断；可靠方案是XtraBackup物理备份，需配合--source-data=2或--dump-slave=2精准记录GTID或position。
为什么不能直接用 mysqldump 做主从全量同步
因为 mysqldump 默认不锁表（除非加 --single-transaction），而主从同步依赖一致的 binlog 位点。如果 dump 过程中主库持续写入，从库恢复后很可能因 GTID 或 position 错位导致复制中断；即使加了锁，长事务也会阻塞业务，线上几乎不可行。
真正可用的方案是基于物理备份：快照级一致性 + 位点/UUID 可追溯。XtraBackup 正是为此设计，但要注意它默认不记录 Executed_Gtid_Set，必须显式启用 --dump-slave=2 或 --source-data=2 才能生成可靠同步起点。
-
--dump-slave=2：在备份时执行SHOW SLAVE STATUS，适合已有的从库转为主库再备份的场景 -
--source-data=2：执行SHOW MASTER STATUS，适用于主库直备，输出CHANGE MASTER TO语句到xtrabackup_info - 二者都要求备份期间主库不能重启，否则
gtid_executed可能不完整
如何用 xtrabackup 做一次可复现的全量同步
核心是让从库恢复后能精准 START SLAVE，而不是靠猜位点。关键不是“备份快”，而是“元数据准”。
主库执行：
innobackupex --user=root --password=xxx --no-timestamp --slave-info --safe-slave-backup /data/backup/full
注意：--slave-info 会生成 xtrabackup_slave_info，但仅当主库本身是某集群的从库时才有效；对纯主库，必须用 --source-data=2 替代。
- 备份完成后，先
innobackupex --apply-log /data/backup/full回滚未提交事务 - 再清空从库
datadir，用innobackupex --copy-back /data/backup/full - 检查
/data/backup/full/xtrabackup_binlog_info（含 file + position）或xtrabackup_slave_info（含 GTID） - 启动从库 mysqld 后，执行
CHANGE MASTER TO ... MASTER_AUTO_POSITION=1（GTID 模式）或指定MASTER_LOG_FILE/MASTER_LOG_POS
xtrabackup 增量备份怎么接上全量做持续同步
增量不是独立存在，它必须依附于一个有效的全量备份基线。XtraBackup 的增量只记录 InnoDB 页面变更，不包含 binlog 位点——所以每次增量备份后，你仍要手动记录当前主库的 SHOW MASTER STATUS，否则无法保证后续从库追平。
典型流程：
# 第一次全量（记下此时的 binlog position） innobackupex --user=root --password=xxx --no-timestamp --source-data=2 /backup/full <h1>一天后增量（必须指定 --incremental-basedir 指向 full）</h1><p>innobackupex --user=root --password=xxx --no-timestamp --incremental-basedir=/backup/full --incremental /backup/inc1</p><h1>应用日志时也需按顺序：先全量 apply-log，再 inc1 apply-log，最后 copy-back</h1><p>innobackupex --apply-log --redo-only /backup/full innobackupex --apply-log --redo-only /backup/full --incremental-dir=/backup/inc1 innobackupex --apply-log /backup/full</p>
- 所有
--apply-log操作必须在从库离线时进行，且--redo-only不能用于最后一次增量 - 增量备份不自动更新
xtrabackup_binlog_info，你得自己在每次增量后跑mysql -e "SHOW MASTER STATUS"并存档 - 如果中间某次增量损坏，整个链就断了，没法跳过；建议每 3–5 天重做一次全量
GTID 模式下最容易被忽略的三个坑
开 GTID 后 xtrabackup 表面更简单，实际约束更强。很多团队同步失败，不是命令写错，而是忽略了 MySQL 内部状态和备份行为的耦合。
- 备份前必须确认主库
gtid_mode=ON且enforce_gtid_consistency=ON，否则--source-data=2输出的 GTID 集可能不完整 -
RESET MASTER会清空gtid_executed，若在备份前执行，会导致xtrabackup_binlog_info中的 GTID 集为空，从库START SLAVE时直接报Cannot replicate from server with empty GTID set - 从库恢复后首次
START SLAVE前，务必检查SELECT @@GLOBAL.gtid_executed是否与备份时一致；如果不一致，说明apply-log过程中误触发了 auto-increment 或其他隐式事务
真正麻烦的从来不是命令怎么敲，而是备份那一刻的 MySQL 状态是否干净、可重现。GTID 让位点管理变少，但也让错误更隐蔽——没报错，但从库就是不追，大概率是 gtid_executed 和 gtid_purged 对不上。
