原标题:基于Consul的MySQL高可用服务,健康检查怎么做?
这是学习笔记的第 2128 篇文章
今天写了下Consul健康检查的脚本内容,之前更新过一版,可以参见:
完整的Consul健康检查策略设计
我是在上一个版本上面做的更新,对于健康检查来说,我们改进的思路是希望检查的过程是稳定可控的,换句话说,要判断一个数据库是主库还是从库,这个逻辑不是很难写,难就难在这个过程中出现一些异常的时候,检查的逻辑是否健壮,比如网络出现抖动,可能检查的结果就错误了,对于数据库服务来说,基于Consul的域名服务应该是稳定的,在出现故障的时候才应该做出改变,所以对此我们设计了基于ACL的检查和本地自检,两者可以做下互补。
基于Consul的健康检查我们预期实现两大类功能,第一类是业务数据读写,第二类是读写分离,按照这两个类别我们划分为三个子类,分别代表code: write,mixed_read,read_only
第一类是业务读写,即主库的正常数据写入和读取
第二类是读写分离,混合读,在主库和从库间做查询的负载均衡
第三类是读写分离,从库只读,在从库侧做查询的负载均衡
所以业务需求是持续变化的,而我们要做的就是根据数据库角色(主库,从库),根据业务的选项(write,mixed_read,read_only)来进行域名服务的状态配置。
这个逻辑用如下的图形来标识:
返回为0代表成功,返回为2代表失败
红色的部分是异常的部分,比如主库不能设置为只读,从库不能设置为可写
如果仔细看这个流程,其实会发现实际的逻辑检查不是很复杂,略微复杂的是从库端的检查,判断是否开启读取的域名,一个关键的检查就是从库延迟,如果从库延迟过大,这个时候开启读写分离是有问题的,所以我们可以设定一个阈值,比如(1s-10s)的一个阈值来冗余一定的延时,超出阈值则读服务不可用,如果是多个从库就可以实现平滑的负载均衡。
而整个流程的检查中,核心的一个逻辑就是基于主库和从库。
要判断一个数据库是主库还是从库,看起来很简单,但是实际上要让整个流程足够稳定,经得起考验,我们就得设定一定的规范和流程检验。
整个检查逻辑中主从库的检查是按照如下的流程图来设计的:
很多条件都实现了多重条件检查和基于规范的检查。
整个逻辑的部分使用了如下的Shell脚本来完成,感兴趣的可以看一下,后续会做一些微调。返回搜狐,查看更多
责任编辑: