一.方案介绍

在上一篇文章中已经介绍了mmm方案,接下来介绍一下mha方案,mha方案在淘宝和58同城有在使用。MHA(mysql-master-ha)

MHA有以下一些特点

1.主服务器的自动监控和故障转移

MHA监控复制架构的主服务器,一旦检测到主服务器故障,就会自动进行故障转移。即使有些从服务器没有收到最新的relay log,MHA自动从最新的从服务器上识别差异的relay log并把这些日志应用到其他从服务器上,因此所有的从服务器保持一致性了。MHA通常在几秒内完成故障转移,9-12秒可以检测出主服务器故障,7-10秒内关闭故障的主服务器以避免脑裂,几秒中内应用差异的relay log到新的主服务器上,整个过程可以在10-30s内完成。还可以设置优先级指定其中的一台slave作为master的候选人。由于MHA在slaves之间修复一致性,因此可以将任何slave变成新的master,而不会发生一致性的问题,从而导致复制失败。

2.交互式主服务器故障转移

可以只使用MHA的故障转移,而不用于监控主服务器,当主服务器故障时,人工调用MHA来进行故障故障。

3. 非交互式的主故障转移

不监控主服务器,但自动实现故障转移。这种特征适用于已经使用其他软件来监控主服务器状态,比如heartbeat来检测主服务器故障和虚拟IP地址接管,可以使用MHA来实现故障转移和slave服务器晋级为master服务器。

4.在线切换主服务器

在许多情况下,需要将现有的主服务器迁移到另外一台服务器上。比如主服务器硬件故障,RAID控制卡需要重建,将主服务器移到性能更好的服务器上等等。维护主服务器引起性能下降,导致停机时间至少无法写入数据。另外,阻塞或杀掉当前运行的会话会导致主主之间数据不一致的问题发生。MHA提供快速切换和优雅的阻塞写入,这个切换过程只需要0.5-2s的时间,这段时间内数据是无法写入的。在很多情况下,0.5-2s的阻塞写入是可以接受的。因此切换主服务器不需要计划分配维护时间窗口(呵呵,不需要你在夜黑风高时通宵达旦完成切换主服务器的任务)

二.方案部署

1.MHA方案的优缺点

优点:相比mmm方案可以自动同步差异的日志,可以自己写故障转移的脚本,比较灵活

缺点:如果故障转移了需要重新修改配置文件,重新启动masterha_manager服务

2.安装部署

服务器IP

角色OS
mysql
说明
10.1.10.24
Monitor节点
Centos 5.5 64bit---

10.1.10.4
Master 节点
Centos 5.5 64bitMysql5.5.18

10.1.10.16

Slave节点(master替补节点)

Centos 5.5 64bitMysql5.5.18
10.1.10.70
Slave
Centos 5.5 64bitMysql5.5.18


2. 在数据库节点安装node

首先安装yum -y install perl-DBD-MySQL

tar -zxvpf mha4mysql-node-0.54.tar.gz

perl Makefile.PL

make && make install

3. 在管理节点安装mha manager

yum install perl-DBD-MySQL

yum install perl-Config-Tiny

yum install perl-Log-Dispatch

yum install perl-Parallel-ForkManager

yum install perl-Config-IniFiles

tar -zxvpf mha4mysql-manager-0.54.tar.gz

perl Makefile.PL

make && make install

4.编辑管理节点的配置文件

mkdir /etc/masterha

mkdir -p /masterha/app1

cp samples/conf/* /etc/masterha/

cat /etc/masterha/app1.cnf


[server default]

manager_workdir=/masterha/app1

manager_log=/masterha/app1/manager.log

user=mha_mon

password=123456

ssh_user=root

repl_user=repl

repl_password=replPAS

ping_interval=1

shutdown_script=""

master_ip_online_change_script=""

report_script=""

#master_ip_failover_script="/usr/local/bin/master_ip_failover"

[server1]

hostname=10.1.10.4

master_binlog_dir=/data/dbdata/mysqllog/binlog

candidate_master=1

[server2]

hostname=10.1.10.16

master_binlog_dir=/data/dbdata/mysqllog/binlog

candidate_master=1

[server3]

hostname=10.1.10.70

master_binlog_dir=/data/dbdata/mysqllog/binlog

5.配置机器之间相互ssh的访问

在每台机器上面执行ssh-keygen -t rsa,会生成两个文件id_rsaIdentity.pub

10.1.10.27点上执行

ssh-copy-id -i /root/.ssh/id_rsa.pub root@10.1.10.4

ssh-copy-id -i /root/.ssh/id_rsa.pub root@10.1.10.16

ssh-copy-id -i /root/.ssh/id_rsa.pub root@10.1.10.70

同理在其余的三台机器上面也把分别自己的rsa传到剩余的机器上面,这样这四台机器之间就可以相互ssh登陆了。

6.测试ssh连接

masterha_check_ssh --conf=/etc/masterha/app1.cnf

如果正常,会显示MySQL Replication Health is OK.

7.建立mha监控访问账号

GRANT ALL PRIVILEGES ON *.* TO 'mha_mon'@'10.1.10.%' IDENTIFIED BY ‘123456’

8.测试机器之间的复制连接

masterha_check_repl --conf=/etc/masterha/app1.cnf

如果正常,会显示MySQL Replication Health is OK

9.启动管理几点的进程

nohup masterha_manager --conf=/etc/masterha/app1.cnf > /tmp/mha_manager.log< /dev/null 2>&1 &

10.检查MHA的状态

masterha_check_status --conf=/etc/masterha/app1.cnf

如果正常,会显示[PING_OK],否则会显示[NOT_RUNNING]

3.故障转移测试

关闭master 10.1.10.4mysql服务,slave 10.1.10.16升级为master ,slave 10.1.10.70maseter

连接指向了10.1.10.16,自动完成了切换。Master 10.1.10.4节点从集群中排除。

切换的日志如下:

----- Failover Report -----

app1: MySQL Master failover 10.1.10.4 to 10.1.10.16 succeeded

Master 10.1.10.4 is down!

Check MHA Manager logs at localhost:/masterha/app1/manager.log for details.

Started automated(non-interactive) failover.

The latest slave 10.1.10.16(10.1.10.16:3306) has all relay logs for recovery.

Selected 10.1.10.16 as a new master.

10.1.10.16: OK: Applying all logs succeeded.

10.1.10.70: This host has the latest relay log events.

Generating relay diff files from the latest slave succeeded.

10.1.10.70: OK: Applying all logs succeeded. Slave started, replicating from 10.1.10.16.

10.1.10.16: Resetting slave info succeeded.

Master failover to 10.1.10.16(10.1.10.16:3306) completed successfully.

虽然这里完成了slavemaster的升级切换,但是对于前段应用程序来说,还要更换IP地址,这是比较麻烦的。那么如何通知前端应用程序呢?这里需要在配置文件中设置如下两个参数。

u master_ip_failover_script

u master_ip_online_change_script

说到Failover,通常有两种方式:一种是虚拟IP地址,一种是全局配置文件。MHA并没有限定使用哪一种方式,而是让用户自己选择,虚拟IP地址的方式会牵扯到其它的软件(vrrpd).

如果要测试效果的话,可以kill掉当前的MySQL主服务器,稍等片刻,MHA就会把某台MySQL从服务器提升为新的MySQL主服务器,并调用master_ip_failover_script脚本,我们在master_ip_failover_script脚本里可以把新的MySQL主服务器的ipport信息持久化到配置文件里,这样应用就可以使用新的配置了。

有时候需要手动切换MySQL主服务器,可以使用masterha_master_switch命令,不过它调用的不是master_ip_failover_script脚本,而是master_ip_online_change_script脚本,但调用参数类似,脚本可以互用。

三.MHA适用于的复制

1.单个master,多个 slaves

M(RW)M(RW), promoted from S1

||

+------+------+--(master crash)-->+-----+-----+

S1(R) S2(R)S3(R)S2(R)S3(R)

M服务器down掉,s1升级为M. 这是一种最常见的结构。

2.单个master,多个slave(其中一个slave是远程的数据中心,不作为升级master的目标)

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)

需在配置文件sr机器设置no_master=1

3.单个master,多个slave,一个候选master

M(RW)-----S0(R,candidate_master=1)M(RW), promoted from S0

||

+----+----+--(master crash)-->+----+----+

S1(R)S2(R)S1(R)S2(R)

需在配置文件s0机器设置candidate_master=1

4.多台master,多个slave

M(RW)<--->M2(R,candidate_master=1)M(RW), promoted from M2

||

+----+----+--(master crash)-->+----+----+

S(R)S2(R)S1(R)S2(R)

需在配置文件M2机器设置candidate_master=1

5.三层复制结构

M(RW)M(RW), promoted from S1

||

+------+---------+--(master crash)-->+-----+------+

S1(R) S2(R)Sr(R)S2(R)Sr(R)

||

++

Sr2Sr2

Sr2不要在配置文件中配置

6.三层复制结构,多个master

M1(host1,RW) <-----------------> M2(host2,read-only)

||

+-----+--------++

S1(host3,R)S2(host4,R)S3(host5,R)

=> After failover

M2(host2,RW)

|

+--------------+--------------------------+

S1(host3,R)S2(host4,R)S3(host5,R)

[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