数据库高可用设计分析
基本概念
集群: 一组多个同时对外提供相同服务的实体机组成一个集群。这里的集群为主从结构,可写节点为主节点,其他只读节点为从节点。
高可用: 在发生局部故障时对整体业务影响很低。即不可用的时间要尽量的短。
对外部应用的访问来说,无需关注如何实现,如同只访问一个节点。并能得到持续的服务能力。
组织结构
高可用基石
- 冗余
- 切换机制
- 同步策略
冗余
避免单点故障的本质是冗余,不同级别的冗余带来的是不同级别的高可用。
单机冗余
- 存储
多块硬盘做raid,网络存储,外部存储,共享存储,快照等
- 网络
多网卡bond
- 电源
多电源,UPS等
由于每个单机上都用一份完整的数据。当单机发生故障时可保障仍然能够提供服务。
多机冗余
不要把鸡蛋放在同一个篮子里。
- 节点间网络,交换机
- 分布在不同机柜
- 分布在不同数据中心
同步策略
- 异步
- 半同步
- 全同步
性能: 异步 > 半同步 > 全不同步
数据可靠性: 全同步 > 半同步 > 异步
性能和数据可靠性综合考量
切换机制组成
在发生异常情况,应该有以下三个部分配合同时完成切换
- 统一对外提供服务
通过服务发现,集群对外体统访问入口,负载均衡。
对应用访问数据库集群进行接耦。当后端数据库节点发生变化时,对应用无感。
可选取 DNS 或 consul
- 数据库管理 MDB
对集群多实体机进行统一管理,自定故障切换机制。并完成故障转移。
MDB与DB在同一个节点。可在DB发生意外时对DB进行重新启动。
可选用 patroni
- 管理配置中心
接收集群中实体机心跳信息,实时掌握集群中实体机状态。可对集群进行选主。
可选用 DCS ,etcd 、zookeeper、 consul、 raft
另外这些组件本身就有完善的高可用方案
统一对外提供服务高可用
由于该组件属于无状态应用。冗余和服务可用性状态判断即可满足高可用。服务可用性判断通用的app基本都只身支持。
- 二层 keepalived
- 四层 haproxy
- 七层 dns
其他: consul ,zookeeper 等 服务注册,服务发现管理中心。
数据库管理 MDB 高可用
由于一台节点上,只有一个MDB。MDB 发生以外,与MDB同属于一台节点上的DB将处于托管状态。
MDB 高可用的实现方式不是冗余,因为DMB 只对本节点上的DB负责。冗余意义不明显。
具体的实现方式是 MDB 进程实时与本节点的操作系统通信,发送心跳给操作系统。当操作系统超出一定时间后没有收到心跳信息,将发生重启系统。
DB 忠诚与 MDB ,一荣俱荣,一损俱损。同生共亡。
切换机制设置
切换机制的配置管理都是在MDB上来完成。
集群节点具体的管理者,如何将这些冗余节点统一作为一个整体对外提供服务。
在各种异常情况发生时作出相应的决策,即对应的调整。
故障异常类型主要分两类:
- 组件模块异常
- 组件模块间通信异常
组件模块异常
根据组件结构图, 对外统一访问和节点状态信息组件本身支持高可用。这里不在考虑。
接下来分别对如下组件异常故障发生时进行分析
- DB
- MDB
- OS
DB异常
DB 的可用性有MDB进行监控。实时收集DB信息并回报给节点状态信息组件。 收集信息主要包括: 当前可用性状态,主从类型,主从拓扑,主从延长,当前LSN,TimeLine等
当MDB 发现DB异常时首先尝试对DB进行重启处理,家丑先不外扬,内部矛盾内部先处理。如果重启不能解决,把异常信息上报个中心。DB节点在集群中剔除。若当前节点为主节点,集群重新选主。
MDB 异常
通信异常
- 通信断开
- 通信恢复