keepalived仅负责vip漂移，不执行备份；真备份须绑定当前vip所在节点的mysql实例，并校验复制状态、规避双主写入冲突、适配gtid、外存备份文件。
不能靠 Keepalived 漂移 VIP 来“执行备份”——它不负责备份逻辑，只管 IP 归属；真要实现备份高可用，必须把备份动作绑定到当前 VIP 所在节点的 MySQL 实例上，且需规避双主同时写入导致的备份一致性风险。
Keepalived 本身不触发、不管理备份任务
Keepalived 的 vrrp_script 和 notify 机制只能感知 VIP 切换事件（如 MASTER、BACKUP、FAULT），但它不会自动调用 mysqldump 或 xtrabackup。如果你在配置里写了 notify_master "/path/to/backup.sh"，那也只是“通知你 VIP 落在这台机器上了”，脚本是否执行备份、何时执行、是否加锁、是否校验复制位点，全得自己写清楚。
- 常见错误现象：
notify_master脚本没加超时或互斥锁，VIP 频繁抖动时触发多次并发备份，打满磁盘和 CPU - 使用场景：仅适用于“单活双主”模式（即只有一端接受写入），备份必须在当前
MASTER节点上运行，否则可能备份到延迟从库的数据 - 性能影响：备份过程若未限制 IO 和 CPU（如
ionice -c2 -n7、cpulimit），会拖慢线上查询
备份前必须确认 MySQL 复制状态是否可靠
双主架构下，任一节点都可能是 VIP 所在方，但它的 Slave_IO_Running 和 Slave_SQL_Running 状态未必为 Yes。如果备份脚本不检查，就直接 dump，很可能导出的是已中断复制、落后数分钟甚至数小时的数据。
- 实操建议：在
notify_master调用的备份脚本开头加入校验逻辑，例如：mysql -e "SHOW SLAVE STATUS\G" | grep -E "(Slave_IO_Running|Slave_SQL_Running): Yes" | wc -l
必须返回2才继续；否则退出并告警 - 参数差异：MySQL 5.7 与 8.0 的
SHOW SLAVE STATUS输出字段略有不同，脚本中避免硬依赖Seconds_Behind_Master，优先用Slave_SQL_Running_State是否含Slave has read all relay log - 容易踩的坑：误把
Master_Host当成本地写入源——双主中每个节点既是 master 也是 slave，Master_Host指的是它同步的上游，不是“谁在写”
备份脚本必须处理自增冲突与 GTID 模式适配
双主环境下，若启用 auto_increment_increment 和 auto_increment_offset，备份时若未显式指定 --set-gtid-purged=OFF（GTID 模式）或忽略 --skip-triggers --skip-routines，恢复后可能因主键重复或触发器错位引发数据异常。
- MySQL 5.7 常用组合：
mysqldump --single-transaction --routines --triggers --master-data=2 --databases mydb > backup.sql
- MySQL 8.0 + GTID 推荐写法：
mysqldump --single-transaction --routines --triggers --set-gtid-purged=OFF --databases mydb > backup.sql
- 关键点：备份命令中
--master-data=2会写入CHANGE MASTER TO语句，但在双主中该语句指向的是“本机作为 slave 时的 master”，不是当前 VIP 所代表的逻辑主库，恢复时需人工清理或重写
备份目标路径不能依赖本地磁盘，必须外挂或同步
Keepalived 切换后，新 MASTER 节点上的备份文件如果只存在本地 /backup/，老节点宕机期间产生的增量无法合并，历史备份链断裂。
- 可行方案：备份脚本末尾强制 rsync 到 NFS 或对象存储（如
aws s3 cp），并带上时间戳与节点标识，例如：backup_$(hostname)_$(date +%Y%m%d_%H%M%S).sql.gz - 容易被忽略的地方：rsync 过程中若网络中断，脚本未判断
$?就 exit 0，会导致“看似备份成功，实则文件为空” - 兼容性注意：CentOS 7 默认 rsync 不支持
--info=progress2，用--progress会干扰日志解析，建议统一用rsync -avz --delete+ 单独日志文件记录
真正落地时，最难的不是写脚本，而是让备份行为和 VIP 状态、复制延迟、应用写入路由三者严格对齐——少一个 check，就可能在故障切换后发现备份不可用。
