金融级高可用需配置group_replication_consistency='after'（session级）、sync_binlog=1、innodb_flush_log_at_trx_commit=1，禁用多主，严格校验member_state=online后路由读请求。
必须启用的强一致性参数
单主模式下，group_replication_consistency = 'AFTER' 是金融场景的硬性开关，它确保事务在所有在线节点完成回放后才向客户端返回成功。这个值必须设为 SESSION 级（在应用连接建立后执行 SET SESSION group_replication_consistency = 'AFTER'），不能设 GLOBAL，否则只读查询也会被阻塞等待回放，拖垮报表类业务。
配合以下两项持久化配置，防止主节点宕机丢事务：
- sync_binlog = 1：每次事务提交都强制刷 binlog 到磁盘
- innodb_flush_log_at_trx_commit = 1：每次事务提交都强制刷 redo log 到磁盘
严格限制多主模式的使用
金融系统应禁用多主模式。MGR 不会合并冲突，而是直接回滚后到达的事务并报错 ER_GROUP_REPLICATION_CONFLICTING_TRANSACTION。实测冲突率约 3%，但金融要求的是 0% 可观测冲突。
即使业务层做了幂等或重试，也无法规避“两次扣款一次失败”的中间态——因为冲突发生在事务提交前，应用无法感知真实执行顺序。若架构上必须多写入口，应通过分库分表+路由规则，将同一账户的所有操作固定到单一节点，这本质上仍是逻辑单主。
节点健康判断与驱逐策略
group_replication_member_expel_timeout 不是越小越好。默认 5 秒，若设为 2 秒，在公网或跨机房环境下极易因瞬时抖动误判节点失联，引发脑裂或频繁主从切换。
建议设为 10–15 秒，并配合监控 performance_schema.replication_group_member_stats 表中的 MEMBER_STATE 和 MEMBER_ROLE 字段变化频率。真正影响 RTO 的是 group_replication_autorejoin_tries（自动重连次数）和选举耗时，不是驱逐阈值。
读请求路由必须校验节点状态
不能把读请求发给任意节点。必须先查 performance_schema.replication_group_members，确认目标节点的 MEMBER_STATE = 'ONLINE' 且 MEMBER_ROLE = 'SECONDARY'（单主模式下）才可路由读流量。
若跳过该检查，可能读到尚未回放完成的中继日志，出现“转账后查不到余额”的问题。建议在中间件（如 MySQL Router 或自研 proxy）中内置该校验逻辑，而不是依赖应用层判断。
