MySQL在Consul服务中的健康检查逻辑

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

MySQL的Consul方向开始要大规模推广的时候，一直感觉健康检查的部分还是不够严谨，虽然感觉是，但是总体逻辑上看也没什么硬伤，就暂时搁置了下来，最近业务的推广和普及，一旦逻辑出现漏洞或者不严谨，则是一种很被动的局面，所以我们开始梳理清晰完整的检查逻辑，我对这个部分的要求是能够输出一个清晰可见的逻辑关系图，经得起推敲，一目了然，这样才算是心里踏实。

在Consul服务中，健康检查的逻辑应该是DBA侧集成最重要的一个环节了，总体来说，有两类需求，一类是数据写入，一类是读写分离，对于这两个类别，读写分离的部分有点特别，可以拆分成两个场景，第一个场景是只在从库可读，主库只为可写，第二个场景是主从负载均衡，均可读，所以按照这种设定，我把整个类型拆分成了三类，Write(主库可写），Read_only（从库只读），Mixed_Read(主库可读可写),其中Mixed_Read是属于读写分离范畴的，对于单点实例（无从库）可以设置为Write或者Mixed_Read均可(当然严谨来说建议为Write），而主从架构的主库只能为Write.

要实现这个功能，我们需要首先理清楚第一个概念，数据库的角色怎么判断，数据库的角色在这里我取舍了Relay的状况(Relay目前不适合Consul服务注册)，把角色分为了Master,Slave和Error三类。

有了第一层的保证，第二层的域名服务注册就会容易一些，这里我分为了选项Check_option,如果数据库角色为Master并且Check_Option为Write则提示写域名注册成功，否则为失败。如果为Slave,逻辑会稍微复杂，需要考虑延迟。

个人新书 《MySQL DBA工作笔记》