切换，保业务还是保数据

1. 如何进行身份切换

• 停止备库同步
• 配置主库复制从库

2. 可靠性优先策略

• 检查B库的seconds_behind_master，不能过大
• A库只读readonly = true
• 检查B库的seconds_behind_master = 0
• B库关只读，readonly = false
• B库停止复制A库，A库开始复制B库

3. 可靠性优先策略

• 数据无丢失
• 有几秒的时间两个数据库均不可写
• 若一开始未检查seconds_behind_master, 不可用时间无法控制

4. 可用性优先策略

• 取消等待数据一致的过程
• A库只读，B库关只读
• B库停止复制A库，A库开始复制B库

5. 可用性优先策略

• 系统没有不可写的时间
• 若切换时还有未重放的relay log
• 可能造成数据不一致错误

6. 总结：

• 普通业务执行时，尽量用可靠性优先策略
• 日志、流水等不太需要数据可靠性的，用可用性优先策略

数据库切换了，业务怎么办

1. 业务切换至新地址

• 业务预留接口，通知新的数据库地址
• 使用微服务框架，通知业务

2. 使用内部DNS,通过域名连接

• 自己搭建coredns

3. vip漂移

• 使用keepalived进行自动vip漂移

4. 使用代理

• 使用haproxy等代理组件，将转发地址切换至新库

5. 使用dble时的主备切换

• 使用dble等分库分表中间件，将数据分片地址切换至新库

6. 总结

• 业务切换至新地址，不影响性能，业务可能不支持
• 使用内部DNS，方便，但是需要多于的硬件资源
• vip便宜：自动漂移，需要多余的ip资源
• 使用代理：自动更新，需要多余的资源
• dble: 客户端无感知，需要被动通知

如何实现自动主从切换

1. keepalived

• 常见的高可用组件
• 可以检测节点状态
• 自动执行切换脚本
• 还有vip漂移功能
• 使用keepalived进行身份切换+vip自动漂移

2. MHA (master high availability)

• 常用的mysql高可用组件
• 支持GTID
• binlog来不及传送时会尝试登录A库传送binlog
• 不能自动漂移vip

3. MHA
   

• 从宕机崩溃的master抢救未传送的binlog
• 等待slave执行中继日志，追赶master
• 在slave执行从master抢救出来的binlog
• 提升一个slave为新的master
• 使用其它slave连接新的master进行复制

4. 自研高可用组件

• 完全自主控制
• 研发代价高

5. 总结

• keepalived也可以自动切换身份，但是并不完善
• MHA是较为完善的mysql自动身份切换工具
• 若有更高级的mysql管理需求，可以二次开发MHA或者自己开发高可用中间件

MHA实战

1. MHA与dble联动
   

高可用了，集群为什么还会挂

总结

1. dble的单点问题可能造成数据库系统无法使用
2. dble变为多节点后，数据协调可以使用zookeeper
3. 多节点dble可以使用keepalived提供统一vip，或者使用负载均衡
4. 至此，我们的三高分分布式数据库系统已经初具规模

本章总结

1. 切换策略

• 普通业务执行时，尽量用可靠性优先策略
• 日志、流水等不太需要数据可靠性的，可用可用性优先策略

2. 如何切换业务

• 业务切换至新地址，不影响性能，业务可能不支持
• 使用内部DNS,方便，需要多余的硬件资源
• vip漂移：自动漂移，需要vip资源，像keepalived
• 使用代理组件：自动更新，需要多余资源
• dble：客户端无感知，需要被动通知

3. 如何自动切换数据库身份

• keepalived也可以自动切换身份，但是不完善
• MHA是较为完善的mysql身份自动切换工具
• 二次开发MHA或者开发高可用中间件

4. 最后一个单点问题

• dble单点问题可能造成数据库系统无法使用
• dble变为多节点后，数据协调可以使用zookeeper
• 对节点dble可以使用keepalived提供统一vip，或者使用负载均衡