MySQL高可用架构设计方案
4. MySQL数据一致性
4.1.背景
??MySQL主库异常Down掉，会导致主备库之间的数据不一致 ??MySQL主备切换后，备库成为主库，数据存在不一致
??MySQL的逻辑复制理论上是有风险的，极端情况下可能存在主备数据不一致
4.2.解决方案
4.2.1.常规
??设置innodb_flush_log_at_trx_commit = 1 ??设置sync_binlog = 1 ??设置innodb_support_xa = true ??半同步复制（Semi-Sync）
??主备库尽量采用row模式复制，不要采用statement模式复制 ??主备库定期数据一致性校验
??数据生命周期内的binlog尽量保存下来
4.2.2.主备切换
Master宕机后，有三个选择
??Slave立即提供服务，存在数据不一致风险
??Slave不提供服务，等待Master恢复，保证数据一致
??Slave提供部分服务（比如只能新建，不允许修改），等待Master恢复后，保持数据一致
MySQL高可用架构设计方案
对于我们的MySQL高可用环境，我们采用的处理策略 1、Slave立即提供服务
2、Slave（旧） Master（新） 3、Master（旧）Rollback 4、Master（旧） Slave（新） 5、Master（新）Replay
Rollback & Replay
MasterSlaveRollbackReplay
??Rollback
—Master回滚，保持与Slave一致 —重新恢复主备复制关系 ??Replay
—Slave重放，减少数据丢失 —冲突检测机制
MySQL高可用架构设计方案
5. MySQL容灾
5.1.背景
??互联网应用以普通的PC服务器为主
??通过业务功能的写入主库通常只有一个，造成单点 ??意外操作导致数据丢失
??会遇到不可抗力因素或异常导致宕机
5.2.解决方案
MySQL高可用架构设计方案
??应用写入数据时，记录应用日志，日志可以用来恢复丢失的数据 ??MySQL复制模式是M-M-S，切换时只需修改read-only ??MySQL主从采用半同步复制（Remi-Sync） ??Slave作为备库，Slave2也是备库，作为容灾库
MySQL高可用架构设计方案
6. MySQL自动切换
6.1.背景
??互联网应用以普通的PC服务器为主
??MySQL的主库Down掉后，需要保持提供高可用的服务 ??人工调整切换时间太长
??多个MySQL的主库Down掉后，需要及时切换
6.2.解决方案
6.2.1.架构方式
1、整体架构
说明：
??Switch Manager是页面化操作管理切换，目前暂时不实现，采用App+动态数据源直接与Zookeeper进行通信。