分布式数据存储 - MySQL主从复制高可用方案

   前面几篇文章说道MySQL数据库的高可用方案主从复制、主从复制的延迟产生缘由、延迟检测及延迟解决方案(并未从根本上解决)，这种主从复制方案保证数据的冗余的同时能够作读写分离来分担系统压力可是并不是是高可用方案，由于主从节点中主节点仍然是单点的，一旦主节点宕机会致使应用中写失败。双主复制虽然很好的避免主节点的单点故障，可是未提供统一访问入口来实现负载均衡，若是其中master宕掉的话须要手动切换到另一个master，而不能自动进行切换。本篇文章就来剖析主从复制的高可用。

1、基础概念介绍                                                                                            

• Keepalived/heartbeat

       是一个基于VRRP（虚拟路由冗余协议）可用来实现服务高可用性的软件方案，避免出现单点故障。Keepalived通常用来实现轻量级高可用性，且不须要共享存储，通常用于两个节点之间，常见有LVS+Keepalived、Nginx+Keepalived组合。

• MHA/MMM

       MHA是一套MySQL故障切换方案，来保证数据库系统的高可用。在宕机的时间内（一般10—30秒内），完成故障切换，部署MHA，可避免主从一致性问题，易安装，不改变现有部署。 还支持在线切换，从当前运行master切换到一个新的master上面，只须要很短的时间（0.5-2秒内），此时仅仅阻塞写操做，并不影响读操做，便于主机硬件维护。 在有高可用，数据一致性要求的系统上，MHA 提供了有用的功能，几乎无间断的知足维护须要。

• LVS

      (Linux Virtual Server)是一个高可用性虚拟的服务器集群系统。其主要用于多服务器的负载均衡，做用于网络层。LVS构建的服务器集群系统中，前端的负载均衡层被称为Director Server；后端提供服务的服务器组层被称为Real Server。

      LVS有三种工做模式，分别是DR（Direct Routing 直接路由）、TUN(Tunneling IP隧道）、NAT（Network Address Translation 网络地址转换）。其中TUN模式可以支持更多的Real Server，但须要全部服务器支持IP隧道协议；DR也能够支持至关的Real Server，但须要保证Director Server虚拟网卡与物理网卡在同一网段；NAT扩展性有限，没法支持更多的Real Server，由于全部的请求包和应答包都须要Director Server进行解析再生，影响效率。 同时，LVS负载均衡有10中调度算法，分别是rr、wrr、lc、wlc、lblc、lblcr、dh、sh、sed、nq。

2、基于主从复制的高可用方案                                                                           

一、双节点主从 + keepalived/heartbeat

    两个节点能够采用简单的一主一从模式，或者双主模式，而且放置于同一个VLAN中，在master节点发生故障后，利用keepalived/heartbeat的高可用机制实现快速切换到slave节点。

 

注意事项：

• 采用keepalived做为高可用方案时，两个节点最好都设置成BACKUP模式，避免由于意外状况下（好比脑裂）相互抢占致使往两个节点写入相同数据而引起冲突；
• 把两个节点的auto_increment_increment（自增起始值）和auto_increment_offset（自增步长）设成不一样值。其目的是为了不master节点意外宕机时，可能会有部分binlog未能及时复制到slave上被应用，从而会致使slave新写入数据的自增值和原先master上冲突了，所以一开始就使其错开；固然了，若是有合适的容错机制能解决主从自增ID冲突的话，也能够不这么作；
• slave节点服务器配置不要太差，不然更容易致使复制延迟。做为热备节点的slave服务器，硬件配置不能低于master节点；
• 若是对延迟问题很敏感的话，可考虑使用MariaDB分支版本，或者直接上线MySQL 5.7最新版本，利用多线程复制的方式能够很大程度下降复制延迟；
• 对复制延迟特别敏感的另外一个备选方案，是采用semi sync replication（就是所谓的半同步复制）或者后面会提到的PXC方案，基本上无延迟，不过事务并发性能会有不小程度的损失，须要综合评估再决定；
• keepalived的检测机制须要适当完善，不能仅仅只是检查mysqld进程是否存活，或者MySQL服务端口是否可通，还应该进一步作数据写入或者运算的探测，判断响应时间，若是超过设定的阈值，就能够启动切换机制；
• keepalived最终肯定进行切换时，还须要判断slave的延迟程度。须要事先定好规则，以便决定在延迟状况下，采起直接切换或等待何种策略。直接切换可能由于复制延迟有些数据没法查询到而重复写入；
• keepalived或heartbeat自身都没法解决脑裂的问题，所以在进行服务异常判断时，能够调整判断脚本，经过对第三方节点补充检测来决定是否进行切换，可下降脑裂问题产生的风险。

二、多节点主从+MHA/MMM

    多节点主从，能够采用一主多从，或者双主多从的模式。这种模式下，能够采用MHA或MMM来管理整个集群，目前MHA应用的最多，优先推荐MHA，最新的MHA也已支持MySQL 5.6的GTID模式了。

MHA架构：

1）Node

   MHA是基于MySQL Replication环境的，在该环境中，无论是Master角色，仍是Slave角色，都称为Node，是被监控管理的对象节点。Node服务器上须要安装MHA Node包。

2）Manager

   Manager为MHA架构中的管理者，建议部署在一台独立的服务器上，固然也可部署在某个Slave上，但该Slave永远不要被选择成为新的Master，不然故障切换后的MHA架构就失去了高可用性。Manager服务器须要安装MHA Manager包，并完善一个主配置文件。一个Manager可管理多套MySQL Replication环境。

MHA工做原理：

    MHA的目的在于维持MySQL Replication中Master库的高可用性，其最大特色是能够修复多个Slave之间的差别日志，最终使全部Slave保持数据一致，而后从中选择一个充当新的Master，并将其它Slave指向它。

基本工做流程大体以下：

1） Manager按期监控Master，监控时间间隔由参数ping_interval决定，缺省为3秒钟一次；可利用其自身的监控功能，也可调用第三方软件来监控；MHA自身提供了两种监控方式：SELECT（执行SELECT 1）和CONNECT（建立链接/断开链接），因为参数ping_type决定，缺省为SELECT方式。

2） 当监测到Master故障时，调用SSH脚本对全部Node执行一次检查，包括以下几个方面：

• MySQL实例是否能够链接；
• Master服务器是否能够SSH连通；
• 检查SQL Thread的状态；
• 检查哪些Server死掉了，哪些Server是活动的，以及活动的Slave实例；
• 检查Slave实例的配置及复制过滤规则；
• 最后退出监控脚本并返回表明特殊意义代码。

3） 开始Master故障切换，包括以下几个子阶段：

• 1: Configuration Check Phase

        在这个阶段，若某个Slave实例的SQL Thread中止了，则会自动启动它；并再次确认活动的Servers及Slaves。

• 2: Dead Master Shutdown Phase

        在这个阶段，首先调用master_ip_failover_script，若HA是基于VIP实现的，则关闭VIP，如果基于目录数据库实现的，则修改映射记录。而后调用shutdown_script脚本强制关闭主机，以免服务重启时，发生脑裂。

• 3: Master Recovery Phase

        又包括以下3个子阶段：

  3.1: Getting Latest Slaves Phase

             检查各个Slave，获取最近的和最旧的binary log file和position，并检查各个Slave成为Master的优先级，依赖于candidate_master、no_master、[server_xxx]顺序、binary log差别量等因素。

  3.2: Saving Dead Master's Binlog Phase

            若dead master所在服务器依然能够经过SSH连通，则提取dead master的binary log，提取日志的起点就是上一步获取的最新的binary log file和position，直到最后一条事件日志，并在dead master本地的工做目录（由参数remote_workdir决定）中建立文件保存这些提取到的日志，而后将该文件拷贝到Manager服务器的工做目录下（由参数manager_workdir决定）。固然，若dead master系统就没法链接，也就不存在差别的binary log了。另外，MHA还要对各个Slave节点进行健康检查，主要是SSH连通性。

  3.3: Determining New Master Phase

            接下来调用apply_diff_relay_logs命令恢复Slave的差别日志，这个差别日志指的是各个Slave之间的relay log。恢复完成后，全部的Slave数据是一致的，此时就能够根据优先级选择New Master了。

  3.4: New Master Diff Log Generation Phase

            这里是生成dead master和new master之间的差别日志，即将Phase 3.2保存的binary log拷贝到New Master的工做目录中（remote_workdir）。

  3.5: Master Log Apply Phase

           将上一步拷贝的差别日志恢复到New Master上，若发生错误，也可手动恢复。而后获取New Master的binlog name和position，以便其它Slave从这个新的binlog name和position开始复制。最后会开启New Master的写权限，即将read_only参数设置为0。

• 4: Slaves Recovery Phase

 4.1: Starting Parallel Slave Diff Log Generation Phase

      生成Slave与New Slave之间的差别日志，并将该日志拷贝到各Slave的工做目录下，这部分日志dead master和new master之间差别的那部分日志，由于各个Slave在 3.3阶段已经同步了。

 4.2: Starting Parallel Slave Log Apply Phase

      在各个Slave上应用这部分差别日志，而后经过CHANGE MASTER TO命令将这些Slave指向新的New Master，最后开始复制(start slave)。

• 5: New master cleanup phase

        清理New Master其实就是重置slave info，即取消原来的Slave信息。

至此整个Master故障切换过程完成。

简单的说，工做原理：

从宕机崩溃的master保存二进制日志事件（binlog events）；

识别含有最新更新的slave；

应用差别的中继日志（relay log）到其余的slave；

应用从master保存的二进制日志事件（binlog events）；

提高一个slave为新的master；

使其余的slave链接新的master进行复制；

MHA的优点：

1）master自动监控和故障转移
    在当前已存在的主从复制环境中，MHA能够监控master主机故障，而且故障自动转移。即便有一些slave没有接受新的relay log events，MHA也会从最新的slave自动识别差别的relay log events，并apply差别的event到其余slaves。所以全部的slave都是一致的。MHA秒级别故障转移（9-12秒监测到主机故障，任选7秒钟关闭电源主机避免脑裂，接下来apply差别relay logs， 注册到新的master，一般须要时间10-30秒即total downtime）。另外，在配置文件里能够配置一个slave优先成为master。由于MHA修复了slave之间的一致性，dba就不用去处理一致性问题。当迁移新的master以后，并行恢复其余slave。即便有成千上万的slave,也不会影响恢复master时间，slave也很快完成。当其中一个master崩溃，MHA4秒完成故障转移，这是主动/被动集群解决方案没法完成的。
2）互动(手动)master故障转移
    MHA能够用来只作故障转移，而不监测master，MHA只做为故障转移的交互。
3）非交互式故障转移
    非交互式的故障转移也提供（不监控master，自动故障转移）。这个特性颇有用，特别是你已经安装了其余软件监控master。好比，用Pacemaker(Heartbeat)监测master故障和vip接管，用 MHA故障转移和slave提高。
4）在线切换master到不一样主机
    在不少状况下，有必要将master转移到其余主机上（如替换raid控制器，提高master机器硬件等等）。这并非master崩溃，可是计划维护必须去作。计划维护致使downtime，必须尽量快的恢复。快速的master切换和优雅的阻塞写操做是必需的，MHA提供了这种方式。优雅的master切换， 0.5-2秒内阻塞写操做。在不少状况下0.5-2秒的downtime是能够接受的，而且即便不在计划维护窗口。这意味着当须要更换更快机器，升级高版本时，dba能够很容易采起动做。
5）master crash不会致使主从数据不一致性
    当master crash后，MHA自动识别slave间relay logevents的不一样，而后应用与不一样的slave，最终全部slave都同步。结合经过半同步一块儿使用，几乎没有任何数据丢失。
6）MHA部署不影响当前环境设置
    MHA最重要的一个设计理念就是尽量使用简单。使用与5.0+以上主从环境，其余HA方案须要改变mysql部署设置，MHA不会让dba作这些部署配置，同步和半同步环境均可以用。启动/中止/升级/降级/安装/卸载 MHA都不用改变mysql主从（如启动/中止）。 当你须要升级MHA到新版本时，不须要中止mysql，仅仅更新MHA版本，而后从新启动MHAmanger便可。MHA 支持包含5.0/5/1/5.5/5.6。有些HA方案要求特定的mysql版本（如mysqlcluster，mysql withglobal transaction id 等）,并且你可能不想仅仅为了MasterHA而迁移应用。
7）不额外增长服务器
    MHA 包含MHA Manager和MHA node。MHA node运行在每台mysql服务器上，Manager能够单独部署一台机器，监控100+以上master，总服务器数量不会有太大增长。须要注意的是Manager也能够运行在slaves中的一台机器上。
8）性能无影响
    当监控master，MHA只是几秒钟（默认3秒）发送ping包，不发送大的查询。主从复制性能不受影响
9）适用任何mysql在主从中适用的存储引擎
    Mysql不只仅适用于事务安全的innodb引擎，在主从中适用的引擎，MHA均可以适用。即便用遗留环境的mysiam引擎，不进行迁移，也能够用MHA。

MHA的限制：

• 须要在各个节点间打通ssh信任，这对某些公司安全制度来讲是个挑战，由于若是某个节点被黑客攻破的话，其余节点也会跟着遭殃；
• 自带提供的脚本还须要进一步补充完善，固然了，通常的使用仍是够用的。

MHA链接切换：

     一般有两种解决方案：一是引入VIP，当数据库切换时，VIP随之切换；经常使用的HA软件中，大可能是采用VIP实现的，好比Oracle RAC，SQL Server群集、Heartbeat等。二是采用全局目录数据库，即将应用和数据库之间的链接映射为一个列表，当数据库切换时，更改这个映射列表。MHA并不限制用户使用那种方式，只是经过master_ip_failover_script配置参数提供了一个接口。 若采用VIP的方式来实现，可引入第三方软件，好比Keplived等，也可自行编写一个VIP切换脚本。 

三、多节点主从+zookeeper

    在大规模节点环境下，采用keepalived或者MHA做为MySQL的高可用管理仍是有些复杂或麻烦。首先，这么多节点若是没有采用配置服务来管理，必然杂乱无章，线上切换时很容易误操做。在较大规模环境下，建议采用zookeeper管理集群，可实现快速检测切换，以及便捷的节点管理。

 

 

 参考

传送门LVS+Keepalived和MHA安装配置：

http://bestvivi.com/2015/09/09/MySQL%E4%B8%BB%E4%B8%BB%E5%A4%8D%E5%88%B6+LVS+Keepalived%E5%AE%9E%E7%8E%B0MySQL%E9%AB%98%E5%8F%AF%E7%94%A8%E6%80%A7/

http://joelhy.github.io/2015/02/06/mysql-mha/