mha不能保证innodb事务不丢失，是否丢事务取决于从库同步状态及innodb持久化配置（如sync_binlog=1、innodb_flush_log_at_trx_commit=1），而非mha本身。
MySQL主从切换时MHA能否保证InnoDB事务不丢失
MHA本身不提供强一致性保障，它只是在检测到主库故障后尽快完成主从角色切换。是否丢事务，取决于从库的同步状态和InnoDB的持久化配置，而非MHA本身。
关键看两个条件：relay_log_info_repository = TABLE（确保中继日志位置持久化）、sync_binlog = 1 和 innodb_flush_log_at_trx_commit = 1（主库写binlog和redo log都落盘）。若主库崩溃前有未刷盘的事务，MHA切过去也拿不到。
- 即使从库
Seconds_Behind_Master = 0，也不代表已执行完所有relay log——可能还在SQL线程缓存里 - MHA默认只检查
Seconds_Behind_Master，不会校验Relay_Log_Pos与Read_Master_Log_Pos是否完全一致 - 建议在
master_ip_failover脚本中加入SELECT MASTER_POS_WAIT(...)等待关键位点追平，再提升为新主
MHA切换过程中InnoDB的crash recovery如何影响一致性
从库被提升为主库后，MySQL启动时会自动触发InnoDB crash recovery：重放redo log、回滚未提交事务、提交已prepare但未commit的XA事务。这个过程是原子的，但前提是redo log本身完整。
如果原主库崩溃时innodb_flush_log_at_trx_commit = 0或2，部分事务可能只写入了OS cache而未落盘，这些事务在恢复中就不可见——不是MHA的问题，而是InnoDB持久化策略决定的。
-
innodb_flush_log_at_trx_commit = 1是强一致前提，但会带来约10%~30%的写性能下降 - MHA failover脚本里不应跳过
mysql_upgrade（尤其跨小版本升级时），否则InnoDB系统表元数据不一致可能引发后续recover失败 - 注意
innodb_fast_shutdown = 1（默认）会导致shutdown时不做full purge，下次启动recover时间变长，但不影响一致性
为什么MHA + 半同步复制仍可能丢事务
半同步（rpl_semi_sync_master_enabled = ON）只保证至少一个从库收到并写入relay log，不保证其已执行（apply）。MHA切换时若选中这个“已接收但未执行”的从库，就会丢掉那些已确认但未提交的事务。
MySQL 5.7+ 的rpl_semi_sync_master_wait_point = AFTER_SYNC（默认）比AFTER_COMMIT更安全，但它依然无法规避网络分区导致的“假确认”：主库以为从库收到了，其实包丢了或从库卡在IO线程。
- 启用半同步后务必监控
Rpl_semi_sync_master_yes_tx和Rpl_semi_sync_master_no_tx，持续出现no_tx说明半同步实际失效 - MHA的
secondary_check_script应同时检查SHOW SLAVE STATUS\G中的Exec_Master_Log_Pos和Relay_Master_Log_File，不能只信Seconds_Behind_Master - 不要依赖
MASTER_AUTO_POSITION = 1自动找位点——GTID mode下MHA对gtid_purged和gtid_executed的校验逻辑较弱，易选错候选主库
真正能缩小RPO的实操配置组合
把RPO压到秒级以内，靠的是InnoDB + 复制协议 + MHA协同调优，不是单点配置。核心是让“主库写完”和“从库可升主”之间的时间窗口尽可能短且可验证。
- 主库：
sync_binlog = 1、innodb_flush_log_at_trx_commit = 1、innodb_support_xa = ON（MySQL 5.7.7+已默认ON） - 从库：
relay_log_recovery = ON（崩溃重启后自动重建relay log）、slave_parallel_type = LOGICAL_CLOCK+slave_parallel_workers > 0（加速追平） - MHA配置：
master_pid_file指向mysqld真实pid；ping_interval = 1；failover前用pt-heartbeat或自定义SQL查SELECT UNIX_TIMESTAMP()-UNIX_TIMESTAMP(ts) FROM heartbeat验证延迟真实性
最常被忽略的一点：MHA manager节点自身必须和数据库同机房部署，否则网络抖动会误判主库宕机，触发不必要的failover——这种“脑裂式切换”比丢几条事务更难排查。
