MHA初探

一、基本描述
   MHA（mysql-master-ha）,MHA的一个主要的目标就是实现主从的自动快速切换（10-30s），并且切换过程
不会导致数据不一致问题，同时部署MHA不会导致新增加机器，不需要改变原来的部署结构，不会有性能损失
并且易于安装.
   它同时提供了在线切换功能（计划内): 从旧master节点安全的切换到新的master节点，只需要很短的时间
（0.5-2s），并且这个过程中只是阻塞写，不会影响读操作
 具体功能点：
 1、自动主库监控和failover
    MHA具有监控复制环境的中master状态的功能，可以发现master是否不可用，并且完成自动故障切换。在多个
 slave情况下，MHA会自动的找到跟最接近主库（the latest）的slave的不同的relay log事件，然后把这些events
应用到其他的slave上，最终所有的slave达到数据一致。 正常情况MHA在数秒内能够完成failover（9-12s确认master
不可用，7-10s（可选择）关闭原master所在机器来防止脑裂, 几秒钟来应用不同的relay log，总时间需要10-30s）
另外，可以通过配置文件指定一个候选master。因为MHA会完成slave之间的一致，所以你可以提升任何一个slave
为新的master，并且不会导致不一致问题
 2、交互式master failover
   可以用MHA只做failover，而不监控master。 MHA提供交换式的master failover
 3、非交互式master failover
   非交互的master failover在你已经有监控mysql master软件的情况还是有用的，
   比如你可以用（Pacemaker）来监控 master状态和vip接管， 然后使用MHA做failover和slave提升
 4、online switchover
   数据库升级，服务器硬件升级等场景

有点总结：
 1、master failover和 slave promotion操作会非常迅速。
   9-12s发现故障，可选择的7-10s的主机power off，数秒的应用差异relay log。从新选举新的master
   后，MHA并行恢复剩余的slave，不管你有1台或者10台，对恢复时间几乎没影响，都能很快完成
 2、master crash掉不会导致数据不一致
   MHA处理slave间差异的中继日志，达到最终一致，结合半同步复制，几乎
  可以认为数据不会丢失
 3、无需修改当前的mysql配置（MHA支持mysql5.0+）
    MHA的启停、升级降级、安装卸载都不需要停数据库，只是replace就ok了
 4、不需要增加大量服务器
    MHA由MHA Manager和MHA Node组成，MHA Node在mysql服务器上部署运行，
    不需要额外的服务；MHA Manager正常情况运行在专用服务器上，但是一个
    MHA Manager 可以监控大量（100+）的master。 并且MHA Manager 也可以
    运行在slave 上，这样根本不需要增加额外的机器
 5、无性能损失
    MHA可以在常规的异步复制或半同步复制下工作，它默认3s会向master发送
    ping包，没有复杂查询。几乎对性能无影响
 6、支持任何存储引擎

二、原理分析和架构

原理分析：
图片1

slave的中继日志里，master的二进制日志的位置被标记“end_log_pos”,通过对比
slave之间的end_log_pos值来确定哪些中继日志没有被全员应用。MHA内部通过这个
原理来修复slaves之间的一致性，在这个基本原理上，MHA做了一些优化和发展， 比如
快速生成差异中继日志，使用 row格式的恢复方式等。

架构
图片2

MHA结构包括两个部分：
1、MHA Manager：监控master，控制master failover，扩展的script等
2、MHA Node：解析二进制日志和中继日志，确认差异中继日志，应用差异中继日志等

当MHA Manager执行failover，MHA manger 通过ssh连接MHA Node，调用需要的MHA Node
命令做操作

扩展定制
MHA有很多的扩展点：比如使用MHA更新master的IP（更新全局目录库信息，更新vip等）
如何处理IP有用户自己决定，MHA没有明确强制使用什么方式：

目前提供的扩展script接口:
secondary_check_script: For checking master availability from multiple network routes
master_ip_failover_script: For updating master's ip address used from applications
shutdown_script: For forcing shutdown the master
report_script: For sending reports
init_conf_load_script: For loading initial configuration parameters
master_ip_online_change_script: For updating master ip address. This is not used for master failover, but used for online master switch

三、支持的复制架构：

【1】管理节点的部署：

 1、专用管理节点服务器，管理多组服务器:MHA Manager只消耗很少的CPU和内存，可以单个MHA
    Manager管理上百组服务器
 2、部署到一个slave节点上,节省服务器

【2】复制环境情况：

场景一：一主多从
      M(RW)                            M(RW), promoted from S1
         |                                             |
  +------+------+        --(master crash)--&gt     +-----+-----+
 S1(R) S2(R)   S3(R)                           S2(R)        S3(R)
最常见的架构，MHA能够很好在这个场景下工作

场景二： 一主多从（一个slave在远端数据中心）
        M(RW)                                M(RW), promoted from S1
         |                                                 |
  +------+---------+         --(master crash)--&gt     +-----+------+
 S1(R) S2(R)     Sr(R,no_master=1)                   S2(R)         Sr(R,no_master=1)
很多情况下，需要一个远端备份的slave，但是并不想切换的时候被切成主库， MHA支持
这样的场景在配置文件设置no_master=1这个slave就永远不会成为master。

场景三：一主多从（一个候选master）
      M(RW)-----S0(R,candidate_master=1)   M(RW), promoted from S0
       |                                          |
  +----+----+          --(master crash)--&gt   +----+----+
 S1(R)     S2(R)                             S1(R)      S2(R)

MHA支持candidate_master=1参数来指定候选master

场景四：多主多从
      M(RW)        |                                          |
  +----+----+          --(master crash)--&gt   +----+----+
 S(R)     S2(R)                             S1(R)      S2(R)

MHA支持多主（一个读写，一个只读）配置，当master不可用，切换到另一个主库上

场景五： 三层复制
        M(RW)                                   M(RW), promoted from S1
         |                                                 |
  +------+---------+         --(master crash)--&gt     +-----+------+
 S1(R) S2(R)     Sr(R)                              S2(R)       Sr(R)
                   |                                              |
                   +                                              +
                  Sr2                                            Sr2

该场景下当Sr2的上层是Sr，MHA不能恢复Sr2。Sr正常情况下，MHA能够处理此
场景跟之前的类似

场景六： 三层复制，多主
   M1(host1,RW)         |                                |
  +-----+--------+                       +
 S1(host3,R)    S2(host4,R)             S3(host5,R)
 
=> After failover
 
          M2(host2,RW)
                 |
  +--------------+--------------------------+
 S1(host3,R)    S2(host4,R)             S3(host5,R)

MHA支持该场景，host5是有一个三层的slave，MHA不会管理host5，但是当host1不可用的时候，
切换到host2上，host5还是可以正常复制。

[server default]
multi_tier_slave=1

[server1]
hostname=host1
candidate_master=1

[server2]
hostname=host2
candidate_master=1

[server3]
hostname=host3

[server4]
hostname=host4

[server5]
hostname=host5

【3】 master IP的管理:
 方法一：使用vip管理软件，当数据库挂掉，vip自动切换到从库
 方法二：使用一个全局目录数据库，当主库切换的时候，对保存的
         信息做更新

【4】结合半同步复制:
    虽然MHA可以从挂掉的master节点获取二进制日志，但是当master节点
无法连通的时候，MHA无法获取这些可能只存在于master上events，这时候
的failover就会造成数据丢失
    半同步复制可以大大降低这种风险，半同步复制能够确保至少有一个
slave获得到了最新的二进制日志，这样MHA即使无法登陆master节点也能
获得到几乎所有的events日志，保证数据的不会丢失
 

四、安装配置(host1(M), host2(S), host3(S), host4(管理节点))：
1、搭建复制环境，MHA不处理这些，需要自己搭建
2、建立节点互信，SSH免输入密码
3、MHA Node节点安装：
yum install perl-DBD-MySQL

# rpm -ivh mha4mysql-node-X.Y-0.noarch.rpm
或者：
$ tar -zxf mha4mysql-node-X.Y.tar.gz
$ perl Makefile.PL
$ make
$ make install

MHA Node需要安装在所有的mysql服务器上（master，slaves），并且在管理
节点服务器上也要安装，MHA Manager 模块内部调用会用到 MHA Node模块
安装完成后/usr/bin会生成三个命令：
 save_binary_logs: Saving and copying dead master's binary logs
 apply_diff_relay_logs: Identifying differential relay log events and applying all necessary log events
 purge_relay_logs: Purging relay log files

4、MHA Manager节点安装:

yum install perl-DBD-MySQL perl-Config-Tiny perl-Log-Dispatch perl-Parallel-ForkManager perl-Time-HiRes -y
如果没有安装的话：
rpm -ivh mha4mysql-node-X.Y-0.noarch.rpm

rpm -ivh mha4mysql-manager-X.Y-0.noarch.rpm
or
$ tar -zxf mha4mysql-manager-X.Y.tar.gz
$ perl Makefile.PL
$ make
$ sudo make install

安装完成后/usr/bin下生成9个命令：
masterha_check_repl
masterha_check_ssh
masterha_check_status
masterha_conf_host
masterha_manager
masterha_master_monitor
masterha_master_switch
masterha_secondary_check
masterha_stop

5、配置文件：
manager_host$ cat /etc/app1.cnf
 
[server default]
# mysql user and password
user=root
password=mysqlpass
ssh_user=root
# working directory on the manager
manager_workdir=/var/log/masterha/app1
# working directory on MySQL servers
remote_workdir=/var/log/masterha/app1
 
[server1]
hostname=host1
[server2]
hostname=host2
[server3]
hostname=host3
验证SSH联通性：
 masterha_check_ssh --conf=/etc/app1.cnf
输出下面信息说明SSH配置没有问题
Sat May 14 14:42:22 2011 - [info] All SSH connection tests passed successfully.
验证复制环境：
manager_host$ masterha_check_repl --conf=/etc/app1.cnf
  ...
  MySQL Replication Health is OK.

5、启动Manager：
manager_host$ nohup masterha_manager --conf=/etc/app1.cnf   --ignore_fail_on_start  --ignore_last_failover >> /var/log/manager.log 2>&1 &
 

五、扩展
文档只是简单的概述了MHA的原理和优势，以及应用场景，详细参考：
https://code.google.com/p/mysql-master-ha/

 

 

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/20625855/viewspace-1649629/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/20625855/viewspace-1649629/