双主架构中物理备份必须独立于复制链且物理隔离，严禁依赖双向复制；全量备份须固定源库（如server-id=1的A节点），锁表瞬间手动获取并固化binlog位点，禁用--master-data=2和--slave-info，binlog需配置独立路径并rsync时排除index文件。
备份不能依赖双向复制本身
双向复制不是备份，它只同步变更、不保留历史、不防误删。你执行 DROP TABLE 或 UPDATE ... WHERE id=123 后，另一台机器也会立刻执行——备份必须独立于复制链存在，且物理隔离。
常见错误是轮着在 A/B 节点跑 mysqldump --all-databases --master-data=2：该命令会把本机当前 SHOW MASTER STATUS 的位点写进 dump 文件，而这个位点大概率属于对端 binlog；恢复时执行其中的 CHANGE REPLICATION SOURCE TO，就会指向不存在的日志文件，报错 Could not find first log file name in binary log index file 或卡死 SQL 线程。
- 双主中任意节点执行
--master-data=2都不可靠，哪怕开了 GTID —— 它只写传统 position，不写 GTID 信息 - server-id 不同，但
mysqldump不感知拓扑，无法自动选“安全源” - 若某节点刚
RESET MASTER（如测试环境），位点从mysql-bin.000001开始，另一节点 binlog 可能已是000047，恢复必断链
全量备份必须固定源库 + 手动固化位点
生产环境只允许从一台指定主库（例如 server-id=1 的 A 节点）发起全量备份，且位点必须在锁表瞬间获取，不能依赖 dump 自带逻辑。
正确流程是：
- 执行
FLUSH TABLES WITH READ LOCK锁表 - 立即执行
SHOW MASTER STATUS，记下File和Position - 执行
UNLOCK TABLES解锁 - 用
mysqldump -u user -p --single-transaction --routines --triggers --databases db1 db2 > backup.sql（去掉--master-data） - 把刚才记下的位点单独存为
backup.pos，和backup.sql一起归档 - 恢复时手工执行
CHANGE REPLICATION SOURCE TO MASTER_LOG_FILE='mysql-bin.000012', MASTER_LOG_POS=198765
严禁在 B 节点（server-id=2）上同时跑另一份带 --master-data=2 的备份——两份位点冲突，备份集不可互换。
binlog 日志同步要避开回环路径
仅靠 dump 或数据文件不够，binlog 是闪回、审计、故障回滚的唯一依据。但双主各自生成 binlog，若目录结构一致（如都叫 /var/lib/mysql/mysql-bin.*），直接 rsync 会覆盖或混杂。
必须做两件事：
- 每台机器配置独立
binlog路径：log-bin = /data/binlog_A/mysql-bin（A 机）、log-bin = /data/binlog_B/mysql-bin（B 机） -
rsync推送时加--delete-after和--exclude='mysql-bin.index'，避免 index 文件被覆盖导致日志索引错乱
物理备份优先用 xtrabackup，但需禁用 --slave-info
xtrabackup 支持热备、增量、压缩，但在双主环境下不能用 --slave-info —— 它会记录当前节点的复制坐标，而双主中该坐标来自对端，恢复后可能误导后续同步。
推荐做法：
- 在 A 节点执行：
xtrabackup --user=backup --password=xxx --no-timestamp --stream=xbstream /backup/ | ssh backup-server "xbstream -x -C /remote/backup/" - 备份完成后，手动在 A 节点执行
SHOW MASTER STATUS，将结果写入backup.pos - 恢复时先解压，再用
xtrabackup --prepare，最后用CHANGE REPLICATION SOURCE TO指向 A 节点的位点
真正麻烦的不是怎么备份，而是怎么确保恢复后复制还能继续跑通——位点来源、binlog 路径、GTID 模式是否启用，三者必须严格对齐，漏掉任一环节，同步就停在那儿不动了。
