数据库MMM故障转移切换-阿里云开发者社区

MMM 高可用 MYSQL

工作原理

相较于其它HA软件，MHA的目的在于维持MySQL Replication中Master库的高可用性，其最大特点是可以修复多个Slave之间的差异日志，最终使所有Slave保持数据一致，然后从中选择一个充当新的Master，并将其它Slave指向它。

-从宕机崩溃的master保存二进制日志事件(binlogevents)。

-识别含有最新更新的slave。

-应用差异的中继日志(relay log)到其它slave。

-应用从master保存的二进制日志事件(binlogevents)。

-提升一个slave为新master。

-使其它的slave连接新的master进行复制。

目前MHA主要支持一主多从的架构，要搭建MHA,要求一个复制集群中必须最少有三台数据库服务器，一主二从，即一台充当master，一台充当备用master，另外一台充当从库，因为至少需要三台服务器。

其中master对外提供写服务，备选master（实际的slave，主机名centos3）提供读服务，slave也提供相关的读服务，一旦master宕机，将会把备选master提升为新的master，slave指向新的master，manager作为管理服务器。

一、基础环境准备

1、在配置好IP地址后检查selinux，iptables设置，关闭 selinux ，iptables 服务以便后期主从同步不出错

注：时间要同步

2、在四台机器都配置epel源

下载地址：http://dl.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm

截图00.png

3，建立交互式登录

截图01.png

截图02.png

截图03.png

查看每台hosts文件

截图04.png

二、配置mysql半同步复制

为了尽可能的减少主库硬件损坏宕机造成的数据丢失，因此在配置MHA的同时建议配置成MySQL的半同步复制。

注：mysql半同步插件是由谷歌提供，具体位置/usr/local/mysql/lib/plugin/下，一个是master用的semisync_master.so，一个是slave用的semisync_slave.so，下面我们就来具体配置一下。

如果不清楚Plugin的目录，用如下查找：

mysql> show variables like '%plugin_dir%';

截图05.png

1、分别在主从节点上安装相关的插件（master,Candicatemaster,slave）

在MySQL上安装插件需要数据库支持动态载入。检查是否支持，用如下检测：

 
        mysql> show 
        var
        iables like 
        '%have_dynamic_loading%'
        ;

截图06.png

所有mysql数据库服务器，安装半同步插件(semisync_master.so,semisync_slave.so)

 
        mysql> install plugin rpl_semi_sync_master soname 
        'semisync_master.so'
        ; 
       
        mysql> install plugin rpl_semi_sync_slave soname 
        'semisync_slave.so'
        ;

截图07.png

其他mysql主机采用同样的方法安装

检查Plugin是否已正确安装：
mysql> show plugins;
查看半同步相关信息

截图08.png

或

 
        mysql> select * from information_schema.plugins;

截图09.png

上图可以看到半同复制插件已经安装，只是还没有启用，所以是off

2、修改my.cnf文件，配置主从同步：

注：若主MYSQL服务器已经存在，只是后期才搭建从MYSQL服务器，在置配数据同步前应先将主MYSQL服务器的要同步的数据库拷贝到从MYSQL服务器上（如先在主MYSQL上备份数据库，再用备份在从MYSQL服务器上恢复）

master mysql主机：

截图10.png

rpl_semi_sync_master_enabled=1 1表是启用，0表示关闭

rpl_semi_sync_master_timeout=10000：毫秒单位，该参数主服务器等待确认消息10秒后，不再等待，变为异步方式。

Candicate master主机：

截图11.png

注：relay_log_purge=0，禁止 SQL 线程在执行完一个 relay log 后自动将其删除，对于MHA场景下，对于某些滞后从库的恢复依赖于其他从库的relay log，因此采取禁用自动删除功能

Slave主机：

截图12.png

查看半同步相关信息

mysql>show variables like ‘%rpl_semi_sync%’;

查看半同步状态：

mysql>show status like ‘%rpl_semi_sync%’;

有几个状态参数值得关注的：

rpl_semi_sync_master_status ：显示主服务是异步复制模式还是半同步复制模式

rpl_semi_sync_master_clients ：显示有多少个从服务器配置为半同步复制模式

rpl_semi_sync_master_yes_tx ：显示从服务器确认成功提交的数量 (即master成功接收到slave的回复的次数。)

rpl_semi_sync_master_no_tx ：显示从服务器确认不成功提交的数量 (即master 等待超时的次数)

rpl_semi_sync_master_tx_avg_wait_time ：事务因开启 semi_sync ，平均需要额外等待的时间（即master 花在每个事务上的平均等待时间）

Rpl_semi_sync_master_tx_wait_time ：master 花在所有事物上的等待时间

rpl_semi_sync_master_net_avg_wait_time ：事务进入等待队列后，到网络平均等待时间（即master 等待slave 回复的平均等待时间。单位毫秒.）

Rpl_semi_sync_master_net_wait_time ：master 总的等待时间

Rpl_semi_sync_master_net_waits ：master 等待slave 回复的的总的等待次数。

Rpl_semi_sync_master_no_times：master 关闭半同步复制的次数。

Rpl_semi_sync_master_timefunc_failures ：记录master调用类似 gettimeofday()等函数的失败次数

Rpl_semi_sync_master_tx_waits ：master总的等待次数

Rpl_semi_sync_master_wait_sessions ：当前有多少个session 因为slave 的回复而造成等待

master主机：

截图13.png

第一条grant命令是创建一个用于主从复制的帐号，在master和candicate master的主机上创建即可。

第二条grant命令是创建MHA管理账号，所有mysql服务器上都需要执行。MHA会在配置文件里要求能远程登录到数据库，所以要进行必要的赋权。

Candicate master主机：

 
        mysql> grant replication slave on *.* to mharep@
        '192.168.2.%' 
        identified by 
        '123456'
        ; 
       
        mysql> grant all privileges on *.* to manager@
        '192.168.2.%' 
        identified by 
        '123456'
        ;

查看从的状态，以下两个值必须为yes,代表从服务器能正常连接主服务器

Slave_IO_Running:Yes

Slave_SQL_Running:Yes

截图14.png

Slave主机：

 
        mysql> grant all privileges on *.* to manager@
        '192.168.2.%' 
        identified by 
        '123456'
        ; 
       
        mysql> change master to master_host=
        '192.168.2.105'
        ,master_port=
        3306
        ,master_user=
        'mharep'
        ,master_password=
        '123456'
        ,master_log_file=
        'mysql-bin.000001'
        ,master_log_pos=
        742
        ;

查看从的状态，以下两个值必须为yes,代表从服务器能正常连接主服务器

Slave_IO_Running:Yes

Slave_SQL_Running:Yes

截图15.png

查看master服务器的半同步状态：

 
        mysql>show  status  like ‘%rpl_semi_sync%’;

截图16.png

三、配置mysql-mha

mha包括manager节点和data节点，data节点包括原有的MySQL复制结构中的主机，至少3台，即1主2从，当masterfailover后，还能保证主从结构；只需安装node包。manager server：运行监控脚本，负责monitoring 和 auto-failover；需要安装node包和manager包。

1、在所有主机上安装mha所依赖的软件包

 
        [root@centos2 src]# yum -y install perl-DBD-MySQL perl-Config-Tiny perl-Log-Dispatch perl-Parallel-ForkManager perl-Config-IniFiles ncftp perl-Params-Validate perl-CPAN perl-Test-Mock-LWP.noarch perl-LWP-Authen-Negotiate.noarch perl-devel perl-ExtUtils-CBuilder perl-ExtUtils-MakeMaker

1、以下操作管理节点需要两个都安装，在3台数据库节点只要安装MHA的node节点：

在所有数据库节点上安装mha4mysql-node-0.56.tar.gz

截图17.png

其他两个数据节点也安装mha4mysql-node-0.56.tar.gz（过程略）

在管理节点需要两个都安装：mha4mysql-node-0.56.tar.gz和mha4mysql-manager-0.56.tar.gz

安装mha4mysql-node-0.56.tar.gz

截图18.png

安装mha4mysql-manager-0.56.tar.gz(确保manager主机正常连接internet)

截图19.png

根据提示输入。

 
        [root@centos1 mha4mysql-manager-
        0.56
        ]# mkdir /etc/masterha 
       
        [root@centos1 mha4mysql-manager-
        0.56
        ]# mkdir -p /masterha/app1 
       
        [root@centos1 mha4mysql-manager-
        0.56
        ]# mkdir /scripts 
       
        [root@centos1 mha4mysql-manager-
        0.56
        ]# cp samples/conf/* /etc/masterha/ 
       
        [root@centos1 mha4mysql-manager-
        0.56
        ]# cp samples/scripts/* /scripts/

1、配置mha

与绝大多数Linux应用程序类似，MHA的正确使用依赖于合理的配置文件。MHA的配置文件与mysql的my.cnf文件配置相似，采取的是param=value的方式来配置，配置文件位于管理节点，通常包括每一个mysql server的主机名，mysql用户名，密码，工作目录等等。

编辑/etc/masterha/app1.conf，内容如下：

截图19.png

保存退出

截图20.png

配关配置项的解释：

manager_workdir=/masterha/app1 //设置manager的工作目录

manager_log=/masterha/app1/manager.log //设置manager的日志

user=manager//设置监控用户manager

password=123456 //监控用户manager的密码

ssh_user=root //ssh连接用户

repl_user=mharep //主从复制用户

repl_password=123.abc //主从复制用户密码

ping_interval=1 //设置监控主库，发送ping包的时间间隔，默认是3秒，尝试三次没有回应的时候自动进行railover

master_binlog_dir=/usr/local/mysql/data //设置master 保存binlog的位置，以便MHA可以找到master的日志，我这里的也就是mysql的数据目录

candidate_master=1//设置为候选master，如果设置该参数以后，发生主从切换以后将会将此从库提升为主库。

 
        SSH 有效性验证：
       
        [root@centos1 ~]# masterha_check_ssh --global_conf=/etc/masterha/masterha_default.cnf --conf=/etc/masterha/app1.cnf

 
        集群复制的有效性验证：
       
        mysql必须都启动
       
        [root@centos1 ~]# masterha_check_repl --global_conf=/etc/masterha/masterha_default.cnf --conf=/etc/masterha/app1.cnf

验证成功的话会自动识别出所有服务器和主从状况

注：验证成功的话会自动识别出所有服务器和主从状况

在验证时，若遇到这个错误：Can't exec "mysqlbinlog" ......

解决方法是在所有服务器上执行：

 
        ln -s /usr/local/mysql/bin/* /usr/local/bin/

启动 manager：

截图21.png

注：在应用Unix/Linux时，我们一般想让某个程序在后台运行，于是我们将常会用&在程序结尾来让程序自动运行。比如我们要运行mysql在后台： /usr/local/mysql/bin/mysqld_safe –user=mysql&。可是有很多程序并不想mysqld一样，这样我们就需要nohup命令，

状态检查：

 
        [root@centos1 ~]# masterha_check_status --conf=/etc/masterha/app1.cnf

故障转移验证：(自动failover)

master dead后，MHA当时已经开启，候选Master库（Slave）会自动failover为Master.

验证的方式是先停掉 master（centos2），因为之前的配置文件中，把Candicatemaster(centos3)作为了候选人，那么就到 slave(centos4) 上查看 master 的 IP 是否变为了 centos3 的 IP

1)停掉 master

在 master（192.168.1.102）上把mysql停掉

2)查看 MHA 日志

[root@centos1 ~]# cat /masterha/app1/manager.log

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

app1: MySQL Master failover 192.168.1.102(192.168.1.105:3306) to 192.168.1.105(192.168.1.103:3306) succeeded

Master 192.168.1.105(192.168.1.102:3306) is down!

Check MHA Manager logs at centos1.benet.com:/masterha/app1/manager.log for details.

Started automated(non-interactive) failover.

从日志信息中可以看到 master failover 已经成功了，并可以看出故障转移的大体流程

3)检查 slave2 的复制

mysql> show slave status\G;

可以看到 master 的 IP 现在为 192.168.1.105,已经切换到和192.168.1.105同步了，本来是和192.168.1.106同步的，说明 MHA 已经把Candicatemaster(centos3)提升为了新的 master，IO线程和SQL线程也正确运行，MHA 搭建成功

本文转自柴鑫旺 51CTO博客，原文链接：http://blog.51cto.com/chaixinwang/2072202A ，如需转载请自行联系原作者

数据库MMM故障转移切换

热门文章

最新文章

相关课程

相关电子书

相关实验场景