必须校验复制状态再备份：先确认Slave_IO_Running和Slave_SQL_Running均为Yes，GTID模式下还需Retrieved_Gtid_Set与Executed_Gtid_Set相等，再执行mysqldump并加--set-gtid-purged=OFF等安全参数。
备份不能绑定 VIP，必须绑定当前实际承担写入角色的 MySQL 实例，并校验复制状态是否实时可靠。
backup.sh 必须在 notify_master 触发后立即检查 Slave_IO_Running 和 Slave_SQL_Running
Keepalived 的 notify_master 只表示 VIP 已漂移到本机，不代表这台 MySQL 正在同步、没延迟、没中断。常见错误是脚本直接开跑 mysqldump 或 xtrabackup，结果备份到的是落后 10 分钟甚至已断连的从库数据。
- 校验逻辑必须放在备份命令之前，例如：
mysql -e "SHOW SLAVE STATUS\G" | grep -E "(Slave_IO_Running|Slave_SQL_Running): Yes" | wc -l返回值不等于 2 就exit 1 - MySQL 5.7 和 8.0 的
SHOW SLAVE STATUS字段略有差异，避免硬依赖Seconds_Behind_Master；更稳妥的是检查Slave_SQL_Running_State是否包含Slave has read all relay log - 若使用 GTID 模式，还需额外确认
Retrieved_Gtid_Set和Executed_Gtid_Set是否相等，否则说明中继日志未完全执行
双主下备份必须规避 auto_increment 和 GTID 冲突风险
双主架构默认启用 auto_increment_increment=2 和 auto_increment_offset，且多数生产环境已开启 GTID。若备份时未控制参数，恢复后可能因主键重复或 GTID 集不一致导致复制断裂。
- 用
mysqldump时，必须加--set-gtid-purged=OFF（GTID 模式下），否则导入会清空目标实例的 GTID_EXECUTED - 禁用触发器和存储过程导出：加上
--skip-triggers --skip-routines，防止恢复时意外执行业务逻辑 - 物理备份（如
xtrabackup）无需处理 GTID 参数，但备份前需确保innodb_fast_shutdown=1，避免恢复时报log sequence number不匹配
备份脚本必须自带资源限制与互斥锁
VIP 频繁抖动时，vrrp_script 可能多次触发 notify_master，若无防护，同一节点上会并发运行多个备份进程，打满磁盘 IO 和 CPU，拖垮线上查询。
- 用
flock加文件锁，例如：flock -n /tmp/backup.lock -c "mysqldump ..."，抢不到锁直接退出 - 限制 IO：用
ionice -c2 -n7降低磁盘优先级 - 限制 CPU：用
cpulimit -l 30控制最多占用 30% CPU 时间 - 超时保护：用
timeout 7200（2 小时）包裹整个备份命令，防卡死
最易被忽略的一点：备份脚本里写的 Master_Host 值，不是“谁在写”，而是“我从哪同步”。双主中每个节点的 Master_Host 都指向对方，所以不能靠它判断写入源——必须结合 VIP 所在节点 + 复制状态校验 + 应用层写入路由规则，三者交叉验证才算真正安全。
