MHA之高可用平台化接入思路
MySQL之高可用部署
分析上面的工单处理步骤，可以发现，第一步资源申请受到的限制相对来讲比较大，第二步MHA环境的搭建，我们只需要把脚本接入平台即可实现半自动化处理，也就是说，第二步应该是我们需要聚焦的地方。
高可用的搭建步骤大概分为以下几步：
- 准备三台服务器，在其中的两台服务器上部署MySQL服务；
- 搭建两台MySQL服务器的主从关系；
- 建立主节点、从节点、MHA manager节点的ssh信任关系，完成后通过ssh命令进行验证；
- 开通主节点、从节点、MHA manager节点的防火墙，完成之后通过telnet命令进行验证；
- 初始化MHA环境，这一步包含MHA目录的创建，启动前的一些脚本准备等；
- 启动MHA，
- 检查MHA主从节点之间的工作状态，包含MHA状态、SSH状态以及repl复制状态；
- 给MHA的主节点绑定vip，并通过ip addr show命令进行验证
- 最后通过vip对服务进行访问，保证服务的可用性。
以上步骤，均可以通过平台化的过程进行实现，通过节点去调用每个过程中对应的脚本，再通过前端的部署页面进行过程状态显示，就可以完整的构建一套自动化MHA部署环境。
02
MHA之高可用管理
在MHA部署好之后，需要对MHA做一些检测，这些检测包含故障切换和计划内切换，确保MHA可以正常切换，当故障主机重新恢复的时候，需要对故障主机的状态进行重置，这块儿的逻辑大概如下：
1.MHA故障切换之后，需要将MHA的状态进行更新，更新成故障状态，此时ssh信任关系还在，而复制关系repl可能也随之挂掉了;
2.更新了MHA的状态之后，MySQL实例的角色发生了变换，因此需要对CMDB的源信息进行相应的更新，之前的主节点变成从节点，从节点转化成主节点；
3.此时无法判断故障节点的状态，因此需要将故障节点的运行状态设置为待处理的状态，从而提醒服务管理者去检查这个故障节点的状态；
4.更新完源信息之后，就需要对MHA主从节点的复制关系进行修复，这个修复目前来讲是通过人工干预的，平台化的操作目前还没办法实现；
5.主从关系修复好之后，需要重新启动MHA，在启动之前，需要删除failover.complete文件，这一步也可以在平台上进行操作，这个文件不删除的话是无法重新启动MHA的;
6.当MHA环境重新启动的时候，我们需要把刚才重置为待处理状态的故障节点重置为上线或者可用状态。
当MHA管理的工作做完之后，还需要一个MHA状态查看页面，可以实时的观察MHA当前的运行状态和主从信息，从而及时对MHA环境中的故障作出响应。
这些东西写出来可能看着枯燥无味，但是在实际做的过程中，还是有很多的前后端逻辑上的细节值得推敲的，因为代码实在太多了，这里就不贴代码了，等整个过程都实现完成了，再整理一篇以供参考学习。