数据库高可用和身份切换的关键--如何解决数据库经常宕机问题
作者：互联网
切换，保业务还是保数据
- 如何进行身份切换
- 停止备库同步
- 配置主库复制从库
- 可靠性优先策略
- 检查B库的seconds_behind_master，不能过大
- A库只读readonly = true
- 检查B库的seconds_behind_master = 0
- B库关只读，readonly = false
- B库停止复制A库，A库开始复制B库
- 可靠性优先策略
- 数据无丢失
- 有几秒的时间两个数据库均不可写
- 若一开始未检查seconds_behind_master, 不可用时间无法控制
- 可用性优先策略
- 取消等待数据一致的过程
- A库只读，B库关只读
- B库停止复制A库，A库开始复制B库
- 可用性优先策略
- 系统没有不可写的时间
- 若切换时还有未重放的relay log
- 可能造成数据不一致错误
- 总结：
- 普通业务执行时，尽量用可靠性优先策略
- 日志、流水等不太需要数据可靠性的，用可用性优先策略
数据库切换了，业务怎么办
- 业务切换至新地址
- 业务预留接口，通知新的数据库地址
- 使用微服务框架，通知业务
- 使用内部DNS,通过域名连接
- 自己搭建coredns
- vip漂移
- 使用keepalived进行自动vip漂移
- 使用代理
- 使用haproxy等代理组件，将转发地址切换至新库
- 使用dble时的主备切换
- 使用dble等分库分表中间件，将数据分片地址切换至新库
- 总结
- 业务切换至新地址，不影响性能，业务可能不支持
- 使用内部DNS，方便，但是需要多于的硬件资源
- vip便宜：自动漂移，需要多余的ip资源
- 使用代理：自动更新，需要多余的资源
- dble: 客户端无感知，需要被动通知
如何实现自动主从切换
- keepalived
- 常见的高可用组件
- 可以检测节点状态
- 自动执行切换脚本
- 还有vip漂移功能
- 使用keepalived进行身份切换+vip自动漂移
- MHA (master high availability)
- 常用的mysql高可用组件
- 支持GTID
- binlog来不及传送时会尝试登录A库传送binlog
- 不能自动漂移vip
- MHA
- 从宕机崩溃的master抢救未传送的binlog
- 等待slave执行中继日志，追赶master
- 在slave执行从master抢救出来的binlog
- 提升一个slave为新的master
- 使用其它slave连接新的master进行复制
- 自研高可用组件
- 完全自主控制
- 研发代价高
- 总结
- keepalived也可以自动切换身份，但是并不完善
- MHA是较为完善的mysql自动身份切换工具
- 若有更高级的mysql管理需求，可以二次开发MHA或者自己开发高可用中间件
MHA实战
- MHA与dble联动
高可用了，集群为什么还会挂
总结
- dble的单点问题可能造成数据库系统无法使用
- dble变为多节点后，数据协调可以使用zookeeper
- 多节点dble可以使用keepalived提供统一vip，或者使用负载均衡
- 至此，我们的三高分分布式数据库系统已经初具规模
本章总结
- 切换策略
- 普通业务执行时，尽量用可靠性优先策略
- 日志、流水等不太需要数据可靠性的，可用可用性优先策略
- 如何切换业务
- 业务切换至新地址，不影响性能，业务可能不支持
- 使用内部DNS,方便，需要多余的硬件资源
- vip漂移：自动漂移，需要vip资源，像keepalived
- 使用代理组件：自动更新，需要多余资源
- dble：客户端无感知，需要被动通知
- 如何自动切换数据库身份
- keepalived也可以自动切换身份，但是不完善
- MHA是较为完善的mysql身份自动切换工具
- 二次开发MHA或者开发高可用中间件
- 最后一个单点问题
- dble单点问题可能造成数据库系统无法使用
- dble变为多节点后，数据协调可以使用zookeeper
- 对节点dble可以使用keepalived提供统一vip，或者使用负载均衡
标签：宕机,--,数据库,keepalived,MHA,vip,dble,master,切换 来源： https://www.cnblogs.com/mayanan/p/16103072.html