前言
接关于MHA_Consul_MySQL高可用方案的简单总结和思考
中所讲，该方案无法严格保证主从数据一致或者不丢数据，那么对数据准确性非常严格的业务，则需要在业务层面进行相应的对账和修正。对账的前提当然是要有流水，可以是业务流水(跟余额表事务绑定)或者是binlog的变更流水。
既然是对准确性要求严格的业务，一般都应该会有业务流水。
方案描述
- 方案以数据库切换事件为线索，描述切库前的事先准备、切库中的止损、切库后的监控和修正。
一、切库前
- 余额写redis缓存（如果有多机房，需要异步多写对应机房的redis，或nsq通知）
二、切库中
- 发生切库事件
- （切库之后的一段时间内）若有用户余额变动操作，比对redis和DB余额是否一致，不一致则阻断一段时间。
- 缺点：不一致有可能是误伤（redis刚好写失败导致切库前就不一致）
- 折中：针对一些大额变更才阻断，增加一些更细致的策略
三、切库后
- 指定主库和从库，对比流水日志
- 修复数据（若有不一致），并关闭冻结开关
- 无法修复的订单如何处理（用户余额不足）？
- 考虑当坏账处理；通过余额调整（邮件审批方式同步团队成员）；再按流水订单重新扣除
对比流水和修复大致思路
- 读旧主库和新主库的余额变更流水日志
- 对比得到旧主库存在而新主库不存在的余额变更流水日志
- 获取受影响的用户的余额，重放流水日志模拟分析，得到受影响人数，受影响金额，不可修复订单（比如余额不足）等情况
- 按照流水日志中的业务类型重新执行相应的业务sql（充值，消费，提现等）
- 修复完成之后，重建旧主库，并挂为主库