consul mysql 检查_基于Consul的MySQL高可用服务，健康检查怎么做？

原标题：基于Consul的MySQL高可用服务，健康检查怎么做？

这是学习笔记的第 2128 篇文章

今天写了下Consul健康检查的脚本内容，之前更新过一版，可以参见：

完整的Consul健康检查策略设计

我是在上一个版本上面做的更新,对于健康检查来说，我们改进的思路是希望检查的过程是稳定可控的，换句话说，要判断一个数据库是主库还是从库，这个逻辑不是很难写，难就难在这个过程中出现一些异常的时候，检查的逻辑是否健壮，比如网络出现抖动，可能检查的结果就错误了，对于数据库服务来说，基于Consul的域名服务应该是稳定的，在出现故障的时候才应该做出改变，所以对此我们设计了基于ACL的检查和本地自检，两者可以做下互补。

基于Consul的健康检查我们预期实现两大类功能，第一类是业务数据读写，第二类是读写分离，按照这两个类别我们划分为三个子类，分别代表code: write,mixed_read,read_only

第一类是业务读写，即主库的正常数据写入和读取

第二类是读写分离，混合读，在主库和从库间做查询的负载均衡

第三类是读写分离，从库只读，在从库侧做查询的负载均衡

所以业务需求是持续变化的，而我们要做的就是根据数据库角色(主库，从库)，根据业务的选项(write,mixed_read,read_only)来进行域名服务的状态配置。

这个逻辑用如下的图形来标识：

返回为0代表成功，返回为2代表失败

红色的部分是异常的部分，比如主库不能设置为只读,从库不能设置为可写

如果仔细看这个流程，其实会发现实际的逻辑检查不是很复杂，略微复杂的是从库端的检查，判断是否开启读取的域名，一个关键的检查就是从库延迟，如果从库延迟过大，这个时候开启读写分离是有问题的，所以我们可以设定一个阈值，比如(1s-10s)的一个阈值来冗余一定的延时，超出阈值则读服务不可用，如果是多个从库就可以实现平滑的负载均衡。

而整个流程的检查中，核心的一个逻辑就是基于主库和从库。

要判断一个数据库是主库还是从库，看起来很简单，但是实际上要让整个流程足够稳定，经得起考验，我们就得设定一定的规范和流程检验。

整个检查逻辑中主从库的检查是按照如下的流程图来设计的：

很多条件都实现了多重条件检查和基于规范的检查。

整个逻辑的部分使用了如下的Shell脚本来完成，感兴趣的可以看一下，后续会做一些微调。返回搜狐，查看更多

责任编辑：