漫漫长路，其修远兮！
分类： Mysql/postgreSQL
2013-01-17 11:15:15
在上一篇文章中已经介绍了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的阻塞写入是可以接受的。因此切换主服务器不需要计划分配维护时间窗口(呵呵，不需要你在夜黑风高时通宵达旦完成切换主服务器的任务)。
优点：相比mmm方案可以自动同步差异的日志，可以自己写故障转移的脚本，比较灵活
缺点：如果故障转移了需要重新修改配置文件，重新启动masterha_manager服务
1. 服务器环境
|
服务器IP |
角色 |
OS |
mysql |
说明 |
|
10.1.10.24 |
Monitor节点 |
Centos 5.5 64bit |
--- |
|
|
10.1.10.4 |
Master 节点 |
Centos 5.5 64bit |
Mysql5.5.18 |
|
|
10.1.10.16 |
Slave节点(master替补节点) |
Centos 5.5 64bit |
Mysql5.5.18 |
|
|
10.1.10.70 |
Slave 节点 |
Centos 5.5 64bit |
Mysql5.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_rsa和Identity.pub。
在10.1.10.27点上执行
ssh-copy-id -i /root/.ssh/id_rsa.pub
ssh-copy-id -i /root/.ssh/id_rsa.pub
ssh-copy-id -i /root/.ssh/id_rsa.pub
同理在其余的三台机器上面也把分别自己的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]
关闭master 10.1.10.4的mysql服务，slave 10.1.10.16升级为master ,slave 10.1.10.70的maseter
连接指向了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.
虽然这里完成了slave到master的升级切换，但是对于前段应用程序来说，还要更换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主服务器的ip和port信息持久化到配置文件里，这样应用就可以使用新的配置了。
有时候需要手动切换MySQL主服务器，可以使用masterha_master_switch命令，不过它调用的不是master_ip_failover_script脚本，而是master_ip_online_change_script脚本，但调用参数类似，脚本可以互用。
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)
| |
+ +
Sr2 Sr2
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
