一、基本描述
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)--> +-----+-----+
S1(R) S2(R) S3(R) S2(R) S3(R)
最常见的架构,MHA能够很好在这个场景下工作
场景二: 一主多从(一个slave在远端数据中心)
M(RW) M(RW), promoted from S1
| |
+------+---------+ --(master crash)--> +-----+------+
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)--> +----+----+
S1(R) S2(R) S1(R) S2(R)
MHA支持candidate_master=1参数来指定候选master
场景四:多主多从
M(RW) | |
+----+----+ --(master crash)--> +----+----+
S(R) S2(R) S1(R) S2(R)
MHA支持多主(一个读写,一个只读)配置,当master不可用,切换到另一个主库上
场景五: 三层复制
M(RW) M(RW), promoted from S1
| |
+------+---------+ --(master crash)--> +-----+------+
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/