MHA无法自动补齐数据，仅支持故障时选主、补relay log差异、重配从库；真正数据修复需依赖提前配置的binlog保存机制及手动/脚本化恢复流程。
不能靠 MHA 自己“自动补齐”数据——它不提供实时增量同步或数据修复能力，只负责故障时选新主、补 relay log 差异、重配从库。真正要实现“数据补齐”，得靠你提前配好的 binlog 保存机制 + 手动/脚本化恢复流程。
mysqlbinlog -R 拉取宕机主库的二进制日志必须提前部署
MHA 在检测到 master 宕机后，会尝试通过 mysqlbinlog -R 远程拉取其未传给从库的 binlog 事件。但这要求：宕机主库的 mysqld 进程虽挂，但机器还活着、磁盘可读、MySQL 数据目录和 binlog 文件完好，且 MHA 能 SSH 连上该节点。
- 必须在所有节点（尤其是原 master）提前创建专用 binlog 存放目录，如
/data/mysql/mha/binlog，并确保mysql用户有读写权限 - 在 MHA 配置文件（如
/etc/mha/app1.cnf）中显式声明：master_binlog_dir=/data/mysql/mha/binlog，否则 MHA 不知道去哪找 - 如果原 master 磁盘损坏或彻底失联，
mysqlbinlog -R会失败，MHA 就只能基于已有 relay log 做差异应用，丢失部分数据
masterha_manager 启动时加 --remove_dead_master_conf 是双刃剑
这个参数会让 MHA 在 failover 成功后，自动从配置文件中删掉已宕机的旧 master 节点段（如 [server1]）。看起来干净，但会导致后续恢复原主库时：配置缺失、无法被识别为合法候选节点、VIP 和复制关系难重建。
- 生产环境建议去掉该参数，改用
--ignore_last_failover避免重复切换，同时保留旧节点配置 - 若已启用
--remove_dead_master_conf，故障恢复前必须手动把旧 master 的配置段（含hostname、port、candidate_master=1等）加回app1.cnf - 别忘了同步更新
master_ip_failover_script和master_ip_online_change_script中的 IP 判断逻辑，否则 VIP 可能不会切回去
原主库恢复后执行 CHANGE MASTER TO 的关键参数来源
恢复后的原主库要重新作为 slave 接入新集群，CHANGE MASTER TO 语句里的 MASTER_LOG_FILE 和 MASTER_LOG_POS 不能瞎猜。它们来自 MHA failover 日志，不是新主库的 SHOW MASTER STATUS。
- 查 MHA manager 日志：
grep 'All other slaves should start replication from here' /var/log/mha/app1/manager.log，里面明确给出推荐的CHANGE MASTER TO语句 - 该位置是新主库在提升瞬间的 binlog 坐标，也是所有从库应统一追的起点；用新主库当前的
File/Position可能跳过部分事件 - 密码字段（
MASTER_PASSWORD）需替换为实际复制账户密码，日志里默认是占位符或明文（取决于repl_password配置），切勿直接复制粘贴
binlog 保存目录权限与 SELinux 是静默失败高发区
即使你写了 master_binlog_dir=/data/mysql/mha/binlog，MHA 仍可能默默跳过 binlog 补全，原因常藏在系统层。
-
chown -R mysql:mysql /data/mysql/mha/binlog必须执行，MHA Node 是以mysql用户身份调用mysqlbinlog的 - SELinux 启用时，
mysqld进程默认无权通过网络读取远程 binlog，需运行：setsebool -P mysql_connect_any on - 防火墙若限制了 MySQL 端口（3306）或自定义 binlog 传输端口，
mysqlbinlog -R会超时失败，且错误不显眼，只在 manager.log 里记一句 “Could not get binary log”
最易被忽略的是：MHA 的 binlog 补全只作用于故障切换窗口期产生的差异，它不解决主从延迟积压、不修复误删表、也不替代定期物理备份。真要“补齐”，得靠你自己的 mysqldump 全量 + mysqlbinlog 增量回放组合拳，MHA 只是帮你把切换那几十秒的数据兜住而已。
