MHA

MySQL读写分离架构(KHPM) Keepalived HAProxy ProxySQL MySQL Keepalived+HAProxy 应用程序入口无单点故障 ProxySQL Cluster ProxySQL无单点故障 MHA MySQL无单点故障(MHA Manager后续用ORCH RAFT代替，实现无单点故障) 来源： 51CTO 作者： 易语随风去 链接： https://blog.51cto.com/aimax/2430628

MHA(Master High Availability)目前在 MySQL 高可用方面是一个相对成熟的解决方案, 是一套优秀的作为 MySQL 高可用性环境下故障切换和主从提升的高可用软件。在 MySQL 故障切换过程中,MHA 能做到在 0~30 秒之内自动完成数据库的故障切换操 作,并且在进行故障切换的过程中,MHA 能在最大程度上保证数据的一致性,以达 到真正意义上的高可用。 该软件由两部分组成:MHA Manager(管理节点)和 MHA Node(数据节点)。MHA Manager 可以单独部署在一台独立的机器上管理多个 master-slave 集群,也可以部署在一台 slave 节 点上。 MHA Node 运行在每台 MySQL 服务器上,MHA Manager 会定时探测集群中的 master 节点,当 master 出现故障时,它可以自动将最新数据的 slave 提升为新的 master,然后将 所有其他的 slave 重新指向新的 master。整个故障转移过程对应用程序完全透明。MHA 可 以 与半同步复制结合起来,目前 MHA 主要支持一主多从的架构,要搭建 MHA,要求一个复制集群 中必须最少有三台数据库服务器,一主二从,即一台充当 master,一台充当备用 master,另 外一台充当从库. MHA 切换步骤: 1.从宕机的 master

MHA：Master HA，对主节点进行监控，可实现自动故障转 移至其它从节点；通过提升某一从节点为新的主节点，基于主 从复制实现，还需要客户端配合实现，目前MHA主要支持一 主多从的架构，要搭建MHA,要求一个复制集群中必须最少有 三台数据库服务器，一主二从，即一台充当master，一台充 当备用master，另外一台充当从库，如果财大气粗，也可以用一台专门的服务器来当MHA监控管理服务器 MHA工作原理 1 从宕机崩溃的master保存二进制日志事件（binlog events） 2 识别含有最新更新的slave 3 应用差异的中继日志（relay log）到其他的slave 4 应用从master保存的二进制日志事件（binlog events） 5 提升一个slave为新的master 6 使其他的slave连接新的master进行复制 注意：MHA需要基于ssh，key验证登入方法 相关软件包 MHA监控服务器安装:mha4mysql-manager-0.55-1.el5.noarch，mha4mysql-node-0.54-1.el5.noarch 其他主从集群服务器安装:mha4mysql-node-0.54-1.el5.noarch 下面是实验环境 四台centos-7主机，一台搭建MHA管理服务器，另外三台，做一主二从架构

MHA 官方网址 Manager : https://github.com/yoshinorim/mha4mysql-manager Node : https://github.com/yoshinorim/mha4mysql-node MHA 工作原理 主库宕机处理过程 1. 监控节点 (通过配置文件获取所有节点信息) 系统,网络,SSH连接性 主从状态,重点是主库 2. 选主 (1) 如果判断从库(position或者GTID),数据有差异,最接近于 Master 的 slave,成为备选主 (2) 如果判断从库(position或者GTID),数据一致,按照配置文件顺序,选主. (3) 如果设定有权重(candidate_master=1),按照权重强制指定备选主. 1. 默认情况下如果一个 slave 落后 master 100M的 relay logs 的话，即使有权重,也会失效. 2. 如果 check_repl_delay=0 的话,即使落后很多日志,也强制选择其为备选主 3. 数据补偿 (1) 当SSH能连接,从库对比主库 GTID 或者 position 号,立即将二进制日志保存至各个从节点并且应用( save_binary_logs ) (2) 当SSH不能连接, 对比从库之间的relaylog的差异( apply_diff_relay_logs ) 4.