MYSQL之高可用架构
一、概述
MYSQL的高可用方案有多种，如MMM、MHA、MGR，目前主流的是MHA方案。这几个高可用方案均不是MYSQL本身自带的，而是通过下载相关的程序，在基于mysql主从原理的基础上，在外部开发一款程序，对MYSQL主从进行一些维护和操作而形成的自研产品。
1、MMM架构方案
如下为MMM方案架构图。它最大的特点是有两个主节点。一个主节点对外提供服务，另一个主节点作为备份节点。构建一个双主的架构。同时在每一个主节点下面有多个从节点。有一个监控服务器节点，它会监控主节点和从节点的情况。当主节点出现问题的时候，它会把写入的VIP漂移到备份节点上。停止从节点的复制过程，同时它会发送一条指令，让从节点连接新的主节点。这样避免了当主节点宕机后，新的主节点还需要重新人工写入VIP的情况。它容易产生的问题是如果用户正在向主节点写入数据的时候，数据还没有提交完成，或者说刚刚提交完成。因为主从复制的延迟，它并没有立即刷新到相应的磁盘中。或因网络等原因也没有立即同步到从节点。那么这个事务可能就会存在丢失的问题。另外MMM社区缺少维护。所以该方案也慢慢的退出了主流的架构。
2、MGR架构方案
这个方案用的比较少。它有三个主节点，服务之间也会同步相应的数据。相对MMM会复杂一些。它的缺点是该方案仅支持innodb,支持的存储类型太少。对一些公司来讲，这是一个致命的问题。
3、MHA架构方案
如下为MHA方案架构图，首先它会先安装一个管理节点来监控主节点。当发现主节点出现问题的时候，它会根据相应的策略把一个从节点提升为主节点，同时会把VIP移到新的主节点上。它仅仅会监控主节点。好处在于它的处理会非常迅速，在30s到50s之内完成故障处理。它会把主节点的binlog日志放到新的从节点中。新节点的relay-log 会放到其他的从节点中。这样能最大限度的保证数据不丢失。当主节点宕机了，即便他复制延迟了也没有关系。因为它把binlog日志移动到其他节点中去了。通过binlog日志sql的写入，来达到未完成的数据成功的写入。它的缺点是不会看从节点是否在运行，假如从节点挂了它不知道。另一个缺点是当主节点宕机后重启，不能够立即加入到复制里面。这个过程需要手动重启假如到集群。
二、构建
这里我们以MHA方案为例进行构建。
1、配置mysql主从
以132为主节点，131、133为从节点进行配置，如下所示：
2、构建MHA高可用架构
在上面主从的基础上，每一个节点安装一个mha节点工具包。在132主节点上安装一个mha管理节点manager。假如在生成环境中，管理节点最好单独部署一台机器。这个管理节点携带一个工具包，同时还自带一个shell脚本。这个主节点一直保持运行状态进行监控。当主节点出现故障时，它从宕机的master保存binlog日志文件。在从节点中根据复制量选举一个节点为主节点。应用新节点的中继日志迁移到其他的从节点中。把宕机master的binlog日志迁移到新的主节点中。提升新的主节点为master且发生VIP的漂移。通过shell让其他的slave连接新的master。
建立节点互信
安装mha node节点
安装mha manager
这里manager 配置在179.132上的，生成环境根据自己的情况，做出对应的修改。
配置主要是一个mysql主从的名单,如下：