mysql主从架构下如何优雅地做全量同步_xtrabackup增量备份方案-mysql教程-PHP中文网

不能直接用mysqldump做主从全量同步，因其默认不锁表且无法保证binlog位点一致性，易导致复制中断；可靠方案是xtrabackup物理备份，需配合--source-data=2或--dump-slave=2精准记录gtid或position。

mysql主从架构下如何优雅地做全量同步_xtrabackup增量备份方案

为什么不能直接用 `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 替代。

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

备份完成后，先 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 或其他隐式事务