MHA架构概述及实战

231312111

MySQL MHA架构介绍：
  MHA（Master High Availability）目前在MySQL高可用方面是一个相对成熟的解决方案，它由日本DeNA公司youshimaton（现就职于Facebook公司）开发，是一套优秀的作为MySQL高可用性环境下故障切换和主从提升的高可用软件。在MySQL故障切换过程中，MHA能做到在0~30秒之内自动完成数据库的故障切换操作，并且在进行故障切换的过程中，MHA能在最大程度上保证数据的一致性，以达到真正意义上的高可用。
  该软件由两部分组成：MHA Manager（管理节点）和MHA Node（数据节点）。MHA Manager可以单独部署在一台独立的机器上管理多个master-slave集群，也可以部署在一台slave节点上。MHA Node运行在每台MySQL服务器上，MHA Manager会定时探测集群中的master节点，当master出现故障时，它可以自动将最新数据的slave提升为新的master，然后将所有其他的slave重新指向新的master。整个故障转移过程对应用程序完全透明。
  在MHA自动故障切换过程中，MHA试图从宕机的主服务器上保存二进制日志，最大程度的保证数据的不丢失，但这并不总是可行的。例如，如果主服务器硬件故障或无法通过ssh访问，MHA没法保存二进制日志，只进行故障转移而丢失了最新的数据。使用MySQL 5.5的半同步复制，可以大大降低数据丢失的风险。MHA可以与半同步复制结合起来。如果只有一个slave已经收到了最新的二进制日志，MHA可以将最新的二进制日志应用于其他所有的slave服务器上，因此可以保证所有节点的数据一致性。
  目前MHA主要支持一主多从的架构，要搭建MHA,要求一个复制集群中必须最少有三台数据库服务器，一主二从，即一台充当master，一台充当备用master，另外一台充当从库，因为至少需要三台服务器，出于机器成本的考虑，淘宝也在该基础上进行了改造，目前淘宝TMHA已经支持一主一从。（出自：《深入浅出MySQL(第二版)》）
MHA工作原理总结为以下几条：
（1）从宕机崩溃的master保存二进制日志事件（binlog events）;
（2）识别含有最新更新的slave;
（3）应用差异的中继日志(relay log) 到其他slave;
（4）应用从master保存的二进制日志事件(binlog events);
（5）提升一个slave为新master;
（6）使用其他的slave连接新的master进行复制。
  目前高可用方案可以一定程度上实现数据库的高可用，在进行高可用方案选择时，主要是看业务还有对数据一致性方面的要求。最后出于对数据库的高可用和数据一致性的要求，推荐使用MHA架构。

MHA实践测试
一、环境准备
操作系统版本：centos 7
服务器架构：
Master    ip：192.168.2.11  主机名称：node01    server_id:1  职责：写
Candicate mastor  ip：192.168.2.12  主机名称：node02   server_id:2  职责：读
Slave     ip：192.168.2.13  主机名称：node3     server_id:3  职责：读
Monitor   ip：192.168.2.6   主机名称：moni      -       职责：管理/监控
VIP        ip: 192.168.2.5   
其他准备：
每台服务器配置以下hosts

1 2 3 4 5

# vim /etc/hosts 192.168.2.6  moni    192.168.2.11  node01    192.168.2.12  node02    192.168.2.13  node3

系统时间同步(crontab -e):0-59/5 * * * * /usr/sbin/ntpdate us.pool.ntp.org | logger -t NTP
关闭selinux
关闭firewalld防火墙
配置安装epel源、mysql-community.repo、mysql-community-source.repo(安装mysql)
新建目录/soft，存放下载组件或安装包(以上所有服务器在本地保留)：
安装包mha4mysql-manager-0.56.tar.gz(http://www.mysql.gr.jp/frame/mod ... amp;refer=matsunobu)
mha4mysql-node-0.56.tar.gz (http://www.mysql.gr.jp/frame/mod ... amp;refer=matsunobu)
注：MHA官网https://code.google.com/p/mysql-master-ha/wiki/Downloads?tm=2
新建目录/mydata/data(建议使用lvm2镜像，实现物理备份)，存放数据库数据
准备测试数据库apps.sql(见附件，默认也存放节点服务器/soft/目录下)
二、SSH密钥登录方式设置
MHA Manager内部使用SSH连接到各个MySQL服务器，最新从库节点上的MHA Node也需要使用SSH (scp)把relay log文件发给各个从库节点，故需要各台服务器见需要配置SSH密钥登录方式。
（使用key登录，工作中常用，最好不要禁掉密码登录，如果禁了，可能会有问题）
1、在localhost  192.168.2.6操作（Monitor）：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

[iyunv@localhost ~]# ssh-keygen -t rsa [iyunv@localhost ~]# ssh-copy-id -i /root/.ssh/id_rsa.pub root@192.168.2.11 The authenticity of host '192.168.2.11 (192.168.2.11)' can't be established. ECDSA key fingerprint is 25:4d:ed:25:5f:cf:96:6d:13:23:7f:d4:46:98:87:3d. Are you sure you want to continue connecting (yes/no)? yes /usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed /usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys root@192.168.2.11's password: # 输入密码 Number of key(s) added: 1 Now try logging into the machine, with:   "ssh 'root@192.168.2.11'" and check to make sure that only the key(s) you wanted were added. [iyunv@localhost ~]# ssh-copy-id -i /root/.ssh/id_rsa.pub root@192.168.2.12 The authenticity of host '192.168.2.12 (192.168.2.12)' can't be established. ECDSA key fingerprint is 25:4d:ed:25:5f:cf:96:6d:13:23:7f:d4:46:98:87:3d. Are you sure you want to continue connecting (yes/no)? yes /usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed /usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys root@192.168.2.12's password: Number of key(s) added: 1 Now try logging into the machine, with:   "ssh 'root@192.168.2.12'" and check to make sure that only the key(s) you wanted were added. [iyunv@localhost ~]# ssh-copy-id -i /root/.ssh/id_rsa.pub root@192.168.2.13 The authenticity of host '192.168.2.13 (192.168.2.13)' can't be established. ECDSA key fingerprint is fd:4a:40:f4:ac:30:c9:63:0e:78:fa:fd:db:7c:f2:0f. Are you sure you want to continue connecting (yes/no)? yes /usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed /usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys root@192.168.2.13's password: Number of key(s) added: 1 Now try logging into the machine, with:   "ssh 'root@192.168.2.13'" and check to make sure that only the key(s) you wanted were added.

在node01 192.168.2.11操作（Master）：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

[iyunv@node01 ~]# ssh-keygen -t rsa [iyunv@node01 ~]# ssh-copy-id -i /root/.ssh/id_rsa.pub root@192.168.2.12 /usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed /usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys root@192.168.2.12's password: Number of key(s) added: 1 Now try logging into the machine, with:   "ssh 'root@192.168.2.12'" and check to make sure that only the key(s) you wanted were added. [iyunv@node01 ~]# ssh-copy-id -i /root/.ssh/id_rsa.pub root@192.168.2.13 /usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed /usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys root@192.168.2.13's password: Number of key(s) added: 1 Now try logging into the machine, with:   "ssh 'root@192.168.2.13'" and check to make sure that only the key(s) you wanted were added.

2、在node02 192.168.2.12操作(Candicate mastor)：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

[iyunv@node02 ~]# ssh-keygen -t rsa [iyunv@node02 ~]# ssh-copy-id -i /root/.ssh/id_rsa.pub root@192.168.2.11 The authenticity of host '192.168.2.11 (192.168.2.11)' can't be established. ECDSA key fingerprint is 25:4d:ed:25:5f:cf:96:6d:13:23:7f:d4:46:98:87:3d. Are you sure you want to continue connecting (yes/no)? yes /usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed /usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys root@192.168.2.11's password: Number of key(s) added: 1 Now try logging into the machine, with:   "ssh 'root@192.168.2.11'" and check to make sure that only the key(s) you wanted were added. [iyunv@node02 ~]# ssh-copy-id -i /root/.ssh/id_rsa.pub root@192.168.2.13 The authenticity of host '192.168.2.13 (192.168.2.13)' can't be established. ECDSA key fingerprint is fd:4a:40:f4:ac:30:c9:63:0e:78:fa:fd:db:7c:f2:0f. Are you sure you want to continue connecting (yes/no)? yes /usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed /usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys root@192.168.2.13's password: Number of key(s) added: 1 Now try logging into the machine, with:   "ssh 'root@192.168.2.13'" and check to make sure that only the key(s) you wanted were added.

3、在node3 192.168.2.13操作(slave)：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

[iyunv@node3 ~]# ssh-keygen -t rsa [iyunv@node3 ~]# ssh-copy-id -i /root/.ssh/id_rsa.pub root@192.168.2.11 The authenticity of host '192.168.2.11 (192.168.2.11)' can't be established. ECDSA key fingerprint is 25:4d:ed:25:5f:cf:96:6d:13:23:7f:d4:46:98:87:3d. Are you sure you want to continue connecting (yes/no)? yes /usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed /usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys root@192.168.2.11's password: Number of key(s) added: 1 Now try logging into the machine, with:   "ssh 'root@192.168.2.11'" and check to make sure that only the key(s) you wanted were added. [iyunv@node3 ~]# ssh-copy-id -i /root/.ssh/id_rsa.pub root@192.168.2.12 The authenticity of host '192.168.2.12 (192.168.2.12)' can't be established. ECDSA key fingerprint is 25:4d:ed:25:5f:cf:96:6d:13:23:7f:d4:46:98:87:3d. Are you sure you want to continue connecting (yes/no)? yes /usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed /usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys root@192.168.2.12's password: Number of key(s) added: 1 Now try logging into the machine, with:   "ssh 'root@192.168.2.12'" and check to make sure that only the key(s) you wanted were added.

三、所有节点服务器安装mha4mysql-node-0.56
1、解决组件依赖关系

1 2 3 4

192.168.2.11 [iyunv@node01 ~]# yum install perl-DBD-MySQL perl-CPAN -y 192.168.2.12 [iyunv@node02 ~]# yum install perl-DBD-MySQL perl-CPAN -y 192.168.2.13 [iyunv@node3 ~]# yum install perl-DBD-MySQL perl-CPAN -y 192.168.2.6  [iyunv@localhost ~]# yum install perl-DBD-MySQL perl-CPAN -y

2、解压、安装mha4mysql-node-0.56(其他节点服务器都类似以下操作)

1 2 3 4 5 6 7 8 9 10 11 12 13 14

[iyunv@node01 soft]# ls mha4mysql-manager-0.56.tar.gz  mha4mysql-node-0.56.tar.gz [iyunv@node01 soft]# tar xf mha4mysql-node-0.56.tar.gz   #解压 [iyunv@node01 soft]# cd mha4mysql-node-0.56 [iyunv@node01 mha4mysql-node-0.56]# perl Makefile.PL [iyunv@node01 mha4mysql-node-0.56]# make && make install #注：安装的脚本程序默认在/usr/local/bin/目录下 [root mha4mysql-node-0.56]# cd /usr/local/bin/ [root bin]# ll total 44 -r-xr-xr-x 1 root root 16367 Nov  1 17:46 apply_diff_relay_logs -r-xr-xr-x 1 root root  4807 Nov  1 17:46 filter_mysqlbinlog -r-xr-xr-x 1 root root  8261 Nov  1 17:46 purge_relay_logs -r-xr-xr-x 1 root root  7525 Nov  1 17:46 save_binary_logs

Node脚本说明：(这些工具通常由MHA Manager的脚本触发，无需人为操作)
save_binary_logs               //保存和复制master的二进制日志
apply_diff_relay_logs          //识别差异的中继日志事件并将其差异的事件应用于其他的slave
filter_mysqlbinlog             //去除不必要的ROLLBACK事件（MHA已不再使用这个工具）
purge_relay_logs               //清除中继日志（不会阻塞SQL线程）

2、监控管理节点moni(192.168.2.6)，解压、安装mha4mysql-manager-0.56

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

[iyunv@localhost soft]# yum install perl-DBD-MySQL perl-CPAN perl-Config-Tiny perl-Log-Dispatch perl-Parallel-ForkManager perl-Time-HiRes -y   #解决依赖关系 [iyunv@localhost soft]# tar xf mha4mysql-manager-0.56.tar.gz    [iyunv@localhost soft]# cd mha4mysql-manager-0.56    [iyunv@localhost soft]# perl Makefile.PL    [iyunv@localhost soft]# make && make install #注：安装的脚本程序默认存放在/usr/local/bin/目录下，有以下脚本 [iyunv@localhost bin]# ll total 84 -r-xr-xr-x 1 root root 16367 Nov  1 17:46 apply_diff_relay_logs -r-xr-xr-x 1 root root  4807 Nov  1 17:46 filter_mysqlbinlog -r-xr-xr-x 1 root root  1995 Nov  1 17:53 masterha_check_repl -r-xr-xr-x 1 root root  1779 Nov  1 17:53 masterha_check_ssh -r-xr-xr-x 1 root root  1865 Nov  1 17:53 masterha_check_status -r-xr-xr-x 1 root root  3201 Nov  1 17:53 masterha_conf_host -r-xr-xr-x 1 root root  2517 Nov  1 17:53 masterha_manager -r-xr-xr-x 1 root root  2165 Nov  1 17:53 masterha_master_monitor -r-xr-xr-x 1 root root  2373 Nov  1 17:53 masterha_master_switch -r-xr-xr-x 1 root root  5171 Nov  1 17:53 masterha_secondary_check -r-xr-xr-x 1 root root  1739 Nov  1 17:53 masterha_stop -r-xr-xr-x 1 root root  8261 Nov  1 17:46 purge_relay_logs -r-xr-xr-x 1 root root  7525 Nov  1 17:46 save_binary_logs

说明:安装完成之后在/usr/local/bin/目录下的这些脚本有些参数有可能存在问题，为保险起见可在mha4mysql-manager-0.56/samples/scripts目录下复制相关脚本到/usr/local/bin目录覆盖当前的某些脚本如：master_ip_failover，master_ip_online_change ，power_manager，send_repor等
masterha_check_ssh              #检查MHA的SSH配置状况
masterha_check_repl             #检查MySQL复制状况
masterha_manger                 #启动MHA
masterha_check_status           #检测当前MHA运行状态
masterha_master_monitor         #检测master是否宕机
masterha_master_switch          #控制故障转移（自动或者手动）
masterha_conf_host              #添加或删除配置的server信息

1 2 3 4 5 6 7 8

[iyunv@localhost scripts]# pwd /soft/mha4mysql-manager-0.56/samples/scripts [iyunv@localhost scripts]# ll total 32 -rwxr-xr-x 1 4984 users  3648 Apr  1  2014 master_ip_failover  #自动切换时vip管理的脚本，不是必须，如果我们使用keepalived的，我们可以自己编写脚本完成对vip的管理，比如监控mysql，如果mysql异常,我们停止keepalived就行，这样vip就会自动漂移 -rwxr-xr-x 1 4984 users  9870 Apr  1  2014 master_ip_online_change  #在线切换时vip的管理，不是必须，同样可以可以自行编写简单的shell完成 -rwxr-xr-x 1 4984 users 11867 Apr  1  2014 power_manager  #故障发生后关闭主机的脚本，不是必须 -rwxr-xr-x 1 4984 users  1360 Apr  1  2014 send_report   #因故障切换后发送报警的脚本，不是必须，可自行编写简单的shell完成

四、搭建主从复制架构
注意：node01(主)，node02(主备从）,node3(从)
1、node01、node02、node3安装数据库(由于前期有准备centos7 mysql源，可以直接安装，默认是community社区版mysql 5.6)

1 2 3

#yum install mysql-community-server -y #systemctl start mysqld.service #启动服务 #ss -ltnp |grep 3306  #查看是否服务正常

2、默认安装mysql无密码，node01、node02、node3节点上数据库设置管理员密码(测试密码：12345678)
#授权root用户访问任意库，本地登录密码

1 2 3 4

mysql> SET PASSWORD FOR 'root'@'localhost' =password('12345678'); mysql> SET PASSWORD FOR 'root'@'127.0.0.1' =password('12345678'); mysql> GRANT ALL PRIVILEGES ON *.* TO  'root'@'%' IDENTIFIED BY '12345678'; mysql> FLUSH PRIVILEGES;

3、node01(192.168.2.11)master配置mysql文件my.cnf(修改前建议备份该文件)修改如下内容,修改配置后重启数据库：

1 2 3 4 5 6 7 8 9 10 11

[mysqld] datadir = /mydata/data  #数据存放目录 socket = /var/lib/mysql/mysql.sock #socket innodb_file_per_table = ON  #开启独立的表空间 skip_name_resolve = ON   #禁用dns解析 log_bin = mysql-bin  #开启日志(日志存储位置尽量不要同数据存储同一磁盘同一目录，这里测试方便不重新指向) relay_log = relay-bin #开启中继日志 (日志存储位置尽量不要同数据存储同一磁盘同一目录，这里测试方便不重新指向) binlog-format = row  #日志格式 log-slave-updates = true   # 配置从服务器的更新写入二进制日志 sever_id = 1              #server_id一定要唯一； [iyunv@node01 ~]# systemctl restart mysqld.service #重启服务

注意：日志格式，binlog的格式也有三种：STATEMENT，ROW，MIXED。

1	mysql> show variables like 'log_%';   #查看日志是否开启

binlog-do-db 和 replicate-ignore-db 必须相同
log_bin、relay_log，二进制日志和中继日志尽量不要跟数据存储放在同一磁盘同一目录，防止硬盘损坏时日志也丢失

4、node01(192.168.2.11)master导入测试数据库apps.sql

1 2	mysql> CREATE DATABASE apps; Query OK, 1 row affected (0.00 sec)

1	[iyunv@node01 /]# mysql -uroot -p apps < /soft/apps.sql

5、node02(192.168.2.12)slave配置mysql文件my.cnf修改如下内容,修改配置后重启数据库：

1 2 3 4 5 6 7 8 9 10 11 12 13

[mysqld] datadir = /mydata/data   socket = /var/lib/mysql/mysql.sock #socket innodb_file_per_table = ON   skip_name_resolve = ON    log_bin = mysql-bin   relay_log = relay-bin binlog-format = row   log-slave-updates = true    sever_id = 2               relay_log_purge=0           #禁止自动删除中继日志(slave配置文件多了下面这两条） [iyunv@node02 ~]# systemctl restart mysqld.service #重启服务 [iyunv@node02 ~]#mysql -uroot -p12345678 -e "set global read_only=1"  #从库只读，不建议写在配置文件中

**************************
注意：
MHA在发生切换的过程中，从库的恢复过程中依赖于relay log的相关信息，所以这里要将relay log的自动清除设置为OFF，采用手动清除relay log的方式。在默认情况下，从服务器上的中继日志会在SQL线程执行完毕后被自动删除。但是在MHA环境中，这些中继日志在恢复其他从服务器时可能会被用到，因此需要禁用中继日志的自动删除功能。定期清除中继日志需要考虑到复制延时的问题。在ext3的文件系统下，删除大的文件需要一定的时间，会导致严重的复制延时。为了避免复制延时，需要暂时为中继日志创建硬链接，因为在linux系统中通过硬链接删除大文件速度会很快。（在mysql数据库中，删除大表时，通常也采用建立硬链接的方式）

设置定期清理relay脚本（两台slave服务器node02/node3）：

在slave node02 192.168.2.12操作(node3节点同理)：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

[iyunv@node02 ~]# cat /root/purge_relay_log.sh   #注该脚本要拥有执行权限 #!/bin/bash user=root passwd=12345678 port=3306 log_dir='/data/masterha/log' work_dir='/data' purge='/usr/local/bin/purge_relay_logs' if [ ! -d $log_dir ] then    mkdir $log_dir -p fi $purge --user=$user --password=$passwd --disable_relay_log_purge --port=$port --workdir=$work_dir >> $log_dir/purge_relay_logs.log 2>&1 [root ~]$ crontab -l 0 1 * * * /bin/bash /root/purge_relay_log.sh 注：在slave node3 192.168.2.13操作跟上面是一样的，这里不演示了。     #chmod +x purge_relay_log.sh

参数说明：

复制代码
--user mysql                      //用户名
--password mysql                  //密码
--port                            //端口号
--workdir                         //指定创建relay log的硬链接的位置，默认是/var/tmp，由于系统不同分区创建硬链接文件会失败，故需要执行硬链接具体位置，成功执行脚本后，硬链接的中继日志文件被删除
--disable_relay_log_purge         //默认情况下，如果relay_log_purge=1，脚本会什么都不清理，自动退出，通过设定这个参数，当relay_log_purge=1的情况下会将relay_log_purge设置为0。清理relay log之后，最后将参数设置为OFF。
purge_relay_logs脚本删除中继日志不会阻塞SQL线程。下面我们手动执行看看什么情况:

1	[root node02~]$ purge_relay_logs --user=root --password=12345678 --port=3306 -disable_relay_log_purge --workdir=/data

注：要授权root本地127.0.0.1登录执行，不然报以下错误

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

[iyunv@node02 ~]# purge_relay_logs --user=root --password=12345678 --port=3306 -disable_relay_log_purge --workdir=/data 2016-11-26 16:26:59: purge_relay_logs script started. DBI connect(';host=127.0.0.1;port=3306','root',...) failed: Access denied for user 'root'@'127.0.0.1' (using password: YES) at /usr/local/bin/purge_relay_logs line 185. [iyunv@node02 ~]# mysql -uroot -p12345678 -e "GRANT ALL PRIVILEGES ON *.* TO root@'127.0.0.1' IDENTIFIED BY '12345678'" Warning: Using a password on the command line interface can be insecure. 重新测试执行： [iyunv@node02 ~]# purge_relay_logs --user=root --password=12345678 --port=3306 -disable_relay_log_purge --workdir=/data 2016-11-26 16:40:21: purge_relay_logs script started. Found relay_log.info: /mydata/data/relay-log.info Opening /mydata/data/relay-bin.000001 .. Opening /mydata/data/relay-bin.000002 .. Opening /mydata/data/relay-bin.000003 .. Opening /mydata/data/relay-bin.000004 .. Executing SET GLOBAL relay_log_purge=1; FLUSH LOGS; sleeping a few seconds so that SQL thread can delete older relay log files (if it keeps up); SET GLOBAL relay_log_purge=0; .. ok. 2016-11-26 16:40:24: All relay log purging operations succeeded.

注：以上提示说明清除成功，同时会产生一个新的中继日志文件，如下的relay-bin.000005

1 2 3 4 5

[iyunv@node02 ~]# cd /mydata/data/ [iyunv@node02 data]# ls apps      ib_logfile0  mysql             mysql-bin.000003  mysql-bin.000006  mysql-bin.index     relay-bin.000005  test1 auto.cnf  ib_logfile1  mysql-bin.000001  mysql-bin.000004  mysql-bin.000007  performance_schema  relay-bin.index ibdata1   master.info  mysql-bin.000002  mysql-bin.000005  mysql-bin.000008  relay-bin.000004    relay-log.info

6、node3(192.168.2.13)slave配置mysql文件my.cnf修改如下内容,修改配置后重启数据库：

1 2 3 4 5 6 7 8 9 10 11 12 13

[mysqld] datadir = /mydata/data   socket = /var/lib/mysql/mysql.sock #socket innodb_file_per_table = ON   skip_name_resolve = ON    log_bin = mysql-bin   relay_log = relay-bin binlog-format = row   log-slave-updates = true    sever_id = 3               relay_log_purge=0           #禁止自动删除中继日志(slave配置文件多了下面这两条） read_only=1   #从库只读 [iyunv@node3 ~]# systemctl restart mysqld.service #重启服务

7、在node01(192.168.2.11)Master上备份一份完整的数据：

1	[iyunv@node01 /]# mysqldump -uroot -p12345678 --master-data=2 --single-transaction -R --triggers -A > /soft/all.sql

说明：
--master-data=2代表备份时刻记录master的Binlog位置和Position
--single-transaction意思是获取一致性快照
-R意思是备份存储过程和函数
--triggres的意思是备份触发器
-A代表备份所有的库
查看更多信息mysqldump --help

8、在node01(192.168.2.11)Master上创建复制用户repl（密码12345678），并授权访问所有主机:

1 2	mysql> grant replication slave on *.* to 'repl'@'%' identified by '12345678'; mysql> flush privileges; #刷新缓存

9、查看node01(192.168.2.11)Master主库备份时的binlog名称和位置，MASTER_LOG_FILE和MASTER_LOG_POS：

1 2	[iyunv@node01 /]# head -n 30 all.sql | grep 'CHANGE MASTER TO' -- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000003', MASTER_LOG_POS=1721;

10、把node01 Master主库备份all.sql复制到从库node01(192.168.2.12)和node3(192.168.2.13)/soft/目录下，并且导入到从库中

1 2 3 4

[iyunv@node01 /]# scp /soft/all.sql root@192.168.2.12:/soft/ all.sql                                      100%  637KB 637.0KB/s   00:00    [iyunv@node01 /]# scp /soft/all.sql root@192.168.2.13:/soft/ all.sql                                      100%  637KB 637.0KB/s   00:00

11、从库node02，node3导入all.sql，并设置复制参数

1 2 3 4

[iyunv@node02 /]# mysql -uroot -p12345678 < /soft/all.sql Warning: Using a password on the command line interface can be insecure. [iyunv@node3 /]# mysql -uroot -p12345678 < /soft/all.sql Warning: Using a password on the command line interface can be insecure.

node02和node3，连接mysql，执行以下命令：

1	[iyunv@node02 /]# mysql -uroot -p12345678

1 2	mysql> stop slave;  #暂停从库 Query OK, 0 rows affected, 1 warning (0.00 sec)

1 2	mysql> CHANGE MASTER TO MASTER_HOST='192.168.2.11',MASTER_USER='repl', MASTER_PASSWORD='12345678',MASTER_LOG_FILE='mysql-bin.000003',MASTER_LOG_POS=1721; Query OK, 0 rows affected, 2 warnings (0.04 sec)

说明：MASTER_HOST #主库 ，MASTER_USER和MASTER_PASSWORD #复制账号密码  ，CHANGE MASTER TO #还原同步文件和日志

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59

mysql> start slave; #启动复制 Query OK, 0 rows affected (0.00 sec) mysql> show slave status\G   #查看复制状态 *************************** 1. row ***************************                Slave_IO_State: Waiting for master to send event                   Master_Host: 192.168.2.11                   Master_User: repl                   Master_Port: 3306                 Connect_Retry: 60               Master_Log_File: mysql-bin.000003           Read_Master_Log_Pos: 1721                Relay_Log_File: relay-bin.000002                 Relay_Log_Pos: 283         Relay_Master_Log_File: mysql-bin.000003              Slave_IO_Running: Yes             Slave_SQL_Running: Yes               Replicate_Do_DB:           Replicate_Ignore_DB:            Replicate_Do_Table:        Replicate_Ignore_Table:       Replicate_Wild_Do_Table:   Replicate_Wild_Ignore_Table:                    Last_Errno: 0                    Last_Error:                  Skip_Counter: 0           Exec_Master_Log_Pos: 1721               Relay_Log_Space: 450               Until_Condition: None                Until_Log_File:                 Until_Log_Pos: 0            Master_SSL_Allowed: No            Master_SSL_CA_File:            Master_SSL_CA_Path:               Master_SSL_Cert:             Master_SSL_Cipher:                Master_SSL_Key:         Seconds_Behind_Master: 0 Master_SSL_Verify_Server_Cert: No                 Last_IO_Errno: 0                 Last_IO_Error:                Last_SQL_Errno: 0                Last_SQL_Error:   Replicate_Ignore_Server_Ids:              Master_Server_Id: 1                   Master_UUID: ea266108-a0c8-11e6-ab4f-000c29e4d45b              Master_Info_File: /mydata/data/master.info                     SQL_Delay: 0           SQL_Remaining_Delay: NULL       Slave_SQL_Running_State: Slave has read all relay log; waiting for the slave I/O thread to update it            Master_Retry_Count: 86400                   Master_Bind:       Last_IO_Error_Timestamp:      Last_SQL_Error_Timestamp:                Master_SSL_Crl:            Master_SSL_Crlpath:            Retrieved_Gtid_Set:             Executed_Gtid_Set:                 Auto_Position: 0 1 row in set (0.00 sec)

=================================================================================

1	[iyunv@node02 /]# mysql -uroot -p12345678

1 2 3 4

mysql> stop slave;  #暂停从库 Query OK, 0 rows affected, 1 warning (0.00 sec) mysql> CHANGE MASTER TO MASTER_HOST='192.168.2.11',MASTER_USER='repl', MASTER_PASSWORD='12345678',MASTER_LOG_FILE='mysql-bin.000003',MASTER_LOG_POS=1721; Query OK, 0 rows affected, 2 warnings (0.04 sec)

说明：MASTER_HOST #主库 ，MASTER_USER和MASTER_PASSWORD #复制账号密码  ，CHANGE MASTER TO #还原同步文件和日志

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59

mysql> start slave; #启动复制 Query OK, 0 rows affected (0.00 sec) mysql> show slave status\G   #查看复制状态 *************************** 1. row ***************************                Slave_IO_State: Waiting for master to send event                   Master_Host: 192.168.2.11                   Master_User: repl                   Master_Port: 3306                 Connect_Retry: 60               Master_Log_File: mysql-bin.000003           Read_Master_Log_Pos: 1721                Relay_Log_File: relay-bin.000002                 Relay_Log_Pos: 283         Relay_Master_Log_File: mysql-bin.000003              Slave_IO_Running: Yes             Slave_SQL_Running: Yes               Replicate_Do_DB:           Replicate_Ignore_DB:            Replicate_Do_Table:        Replicate_Ignore_Table:       Replicate_Wild_Do_Table:   Replicate_Wild_Ignore_Table:                    Last_Errno: 0                    Last_Error:                  Skip_Counter: 0           Exec_Master_Log_Pos: 1721               Relay_Log_Space: 450               Until_Condition: None                Until_Log_File:                 Until_Log_Pos: 0            Master_SSL_Allowed: No            Master_SSL_CA_File:            Master_SSL_CA_Path:               Master_SSL_Cert:             Master_SSL_Cipher:                Master_SSL_Key:         Seconds_Behind_Master: 0 Master_SSL_Verify_Server_Cert: No                 Last_IO_Errno: 0                 Last_IO_Error:                Last_SQL_Errno: 0                Last_SQL_Error:   Replicate_Ignore_Server_Ids:              Master_Server_Id: 1                   Master_UUID: ea266108-a0c8-11e6-ab4f-000c29e4d45b              Master_Info_File: /mydata/data/master.info                     SQL_Delay: 0           SQL_Remaining_Delay: NULL       Slave_SQL_Running_State: Slave has read all relay log; waiting for the slave I/O thread to update it            Master_Retry_Count: 86400                   Master_Bind:       Last_IO_Error_Timestamp:      Last_SQL_Error_Timestamp:                Master_SSL_Crl:            Master_SSL_Crlpath:            Retrieved_Gtid_Set:             Executed_Gtid_Set:                 Auto_Position: 0 1 row in set (0.00 sec)

12、验证复制是否正常！
############主库node01 Master插入一行数据，并查看Position号####################

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

mysql> INSERT INTO apps (app_name,url,country) VALUES ('BAIDU','http://www.baidu.com','CN'); Query OK, 1 row affected (0.00 sec) mysql> show slave status\G Empty set (0.00 sec) mysql> show master status\G *************************** 1. row ***************************              File: mysql-bin.000003          Position: 1951      Binlog_Do_DB: Binlog_Ignore_DB: Executed_Gtid_Set: 1 row in set (0.00 sec) ############从库node01 slave查看是否已经同步存在，Position号是否与主库master一致 mysql> SELECT * from apps; +----+------------+-------------------------+---------+ | id | app_name   | url                     | country | +----+------------+-------------------------+---------+ |  1 | QQ APP     | http://im.qq.com/       | CN      | |  2 | 微博 APP   | http://weibo.com/       | CN      | |  3 | 淘宝 APP   | https://www.taobao.com/ | CN      | |  4 | BAIDU      | http://www.baidu.com    | CN      | +----+------------+-------------------------+---------+

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57

mysql> show slave status\G *************************** 1. row ***************************                Slave_IO_State: Waiting for master to send event                   Master_Host: 192.168.2.11                   Master_User: repl                   Master_Port: 3306                 Connect_Retry: 60               Master_Log_File: mysql-bin.000003           Read_Master_Log_Pos: 1951             ###与主库一致                Relay_Log_File: relay-bin.000002                 Relay_Log_Pos: 513         Relay_Master_Log_File: mysql-bin.000003              Slave_IO_Running: Yes             Slave_SQL_Running: Yes               Replicate_Do_DB:           Replicate_Ignore_DB:            Replicate_Do_Table:        Replicate_Ignore_Table:       Replicate_Wild_Do_Table:   Replicate_Wild_Ignore_Table:                    Last_Errno: 0                    Last_Error:                  Skip_Counter: 0           Exec_Master_Log_Pos: 1951               Relay_Log_Space: 680               Until_Condition: None                Until_Log_File:                 Until_Log_Pos: 0            Master_SSL_Allowed: No            Master_SSL_CA_File:            Master_SSL_CA_Path:               Master_SSL_Cert:             Master_SSL_Cipher:                Master_SSL_Key:         Seconds_Behind_Master: 0 Master_SSL_Verify_Server_Cert: No                 Last_IO_Errno: 0                 Last_IO_Error:                Last_SQL_Errno: 0                Last_SQL_Error:   Replicate_Ignore_Server_Ids:              Master_Server_Id: 1                   Master_UUID: ea266108-a0c8-11e6-ab4f-000c29e4d45b              Master_Info_File: /mydata/data/master.info                     SQL_Delay: 0           SQL_Remaining_Delay: NULL       Slave_SQL_Running_State: Slave has read all relay log; waiting for the slave I/O thread to update it            Master_Retry_Count: 86400                   Master_Bind:       Last_IO_Error_Timestamp:      Last_SQL_Error_Timestamp:                Master_SSL_Crl:            Master_SSL_Crlpath:            Retrieved_Gtid_Set:             Executed_Gtid_Set:                 Auto_Position: 0 1 row in set (0.00 sec)

################################################################################
                     ***********以上复制架构已配置完成***********
################################################################################

五、配置MHA
1、MHA管理配置文件在moni节点manager上配置，配置文件分为两种：
全局配置文件：默认/etc/masterha_default.cnf，适用于所有的master/slave组
单独的配置文件：可自定义配置文件路径可以，适用于单个的master/slave组
即管理多组master/slave，可以把所有master/slave组合使用同一个配置文件，也可以每个master/slave使用不同的配置文件；
本实例只有一组master/slave组合，使用单独的配置文件：/etc/masterha/app1.cnf（在软件包解压后的目录里面有样例配置文件）
2、moni(192.168.2.6)节点创建MHA的工作目录，并且创建相关配置文件

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34

[iyunv@localhost /]# mkdir -p /etc/masterha [iyunv@localhost /]# mkdir -p /mydata/masterha [iyunv@localhost /]# cp -a /soft/mha4mysql-manager-0.56/samples/conf/app1.cnf /etc/masterha/  #示例配置文件拷贝至新建目录/etc/masterha/ #拷贝以下脚本至/usr/local/bin/目录下，先在配置文件app1.cnf注释该配置后引用keepalive开启配置项 [iyunv@localhost /]#cp -a /soft/mha4mysql-manager-0.56/samples/scripts/master_ip_failover /usr/local/bin/ [iyunv@localhost /]#cp -a /soft/mha4mysql-manager-0.56/samples/scripts/master_ip_online_change /usr/local/bin/ [iyunv@localhost /]#cp -a /soft/mha4mysql-manager-0.56/samples/scripts/masterha_secondary_check /usr/local/bin/ ##############修改app1.cnf配置文件，修改后的文件内容如下： [iyunv@localhost /]# cat /etc/masterha/app1.cnf [server default] manager_workdir=/var/log/masterha/app1.log                           #工作目录 manager_log=/var/log/masterha/app1/manager.log                       #日志 master_binlog_dir=/mydata/data                                       #指定node01节点Master保存binlog的位置 #master_ip_failover_script= /usr/local/bin/master_ip_failover         #自动failover时候的切换脚本 #master_ip_online_change_script= /usr/local/bin/master_ip_online_change  #设置手动切换时候的切换脚本 ping_interval=1                                    #心跳间隔发送ping包，默认是3秒，尝试三次没有回应自动进行failover remote_workdir=/mydata/masterha                  #设置远端mysql在发生切换时binlog的保存位置 repl_password=12345678                                           #复制用户的密码 repl_user=repl                                                  #复制用户名 report_script=/usr/local/bin/send_report                        #发生切换后发送的报警的脚本 #secondary_check_script= /usr/local/bin/masterha_secondary_check -s node02 -s node3 --user=root --master_host=node02 --master_ip=192.168.2.12 --master_port=3306                                                                          #一旦MHA到node02的监控之间出现问题，MHA Manager将会尝试从node3登录到node02,这里暂不使用 #shutdown_script=""         #设置故障发生后关闭故障主机脚本（该脚本的主要作用是关闭主机放在发生脑裂,这里没有使用） ssh_user=root                                                  #ssh的登录用户名 [server1] hostname=192.168.2.11  #Master节点 port=3306 [server2] hostname=192.168.2.12  #备用master节点，半复制集群，可指定此节点可以备用为master节点； port=3306 candidate_master=1      #设置候选master，如果设置该参数以后，发生主从切换以后将会将此从库提升为主库，即使这个主库不是集群中事件最新的slave check_repl_delay=0      #默认情况下如果一个slave落后master 100M的relay logs的话，MHA将不会选择该slave作为一个新的master，因为对于这个slave的恢复需要花费很长时间，通过设置check_repl_delay=0,MHA触发切换在选择一个新的master的时候将会忽略复制延时，这个参数对于设置了candidate_master=1的主机非常有用，因为这个候选主在切换的过程中一定是新的master [server3] hostname=192.168.2.13 port=3306

2、SSH连接测试

1 2 3

[iyunv@localhost mydata]# masterha_check_ssh --conf=/etc/masterha/app1.cnf Wed Nov  2 18:35:28 2016 - [debug]   ok. Wed Nov  2 18:35:28 2016 - [info] All SSH connection tests passed successfully.

3、测试整个复制环境

1 2 3 4 5 6 7 8 9 10 11 12 13 14

[iyunv@localhost ~]# masterha_check_repl --conf=/etc/masterha/app1.cnf Thu Nov  3 18:17:54 2016 - [info] Checking replication health on 192.168.2.12.. Thu Nov  3 18:17:54 2016 - [info]  ok. Thu Nov  3 18:17:54 2016 - [info] Checking replication health on 192.168.2.13.. Thu Nov  3 18:17:54 2016 - [info]  ok. Thu Nov  3 18:17:54 2016 - [info] Checking master_ip_failover_script status: Thu Nov  3 18:17:54 2016 - [info]   /usr/local/bin/master_ip_failover --command=status --ssh_user=root --orig_master_host=192.168.2.11 --orig_master_ip=192.168.2.11 --orig_master_port=3306 Bareword "FIXME_xxx" not allowed while "strict subs" in use at /usr/local/bin/master_ip_failover line 93. Execution of /usr/local/bin/master_ip_failover aborted due to compilation errors. Thu Nov  3 18:17:54 2016 - [error][/usr/local/share/perl5/MHA/MasterMonitor.pm, ln226]  Failed to get master_ip_failover_script status with return code 255:0. Thu Nov  3 18:17:54 2016 - [error][/usr/local/share/perl5/MHA/MasterMonitor.pm, ln424] Error happened on checking configurations.  at /usr/local/bin/masterha_check_repl line 48. Thu Nov  3 18:17:54 2016 - [error][/usr/local/share/perl5/MHA/MasterMonitor.pm, ln523] Error happened on monitoring servers. Thu Nov  3 18:17:54 2016 - [info] Got exit code 1 (Not master dead). MySQL Replication Health is NOT OK!

以上报错，原因是：原来Failover两种方式：一种是虚拟IP地址，一种是全局配置文件。MHA并没有限定使用哪一种方式，而是让用户自己选择，虚拟IP地址的方式会牵扯到其它的软件,比如keepalive软件，而且还要修改脚本master_ip_failover。
所以先暂时注释master_ip_failover_script= /usr/local/bin/master_ip_failover这个选项。后面引入keepalived后和修改该脚本以后再开启该选项
#master_ip_failover_script= /usr/local/bin/master_ip_failover

注释后重新执行测试：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

Testing mysql connection and privileges..Warning: Using a password on the command line interface can be insecure. done.     Testing mysqlbinlog output.. done.     Cleaning up test file(s).. done. Thu Nov  3 18:27:05 2016 - [info] Slaves settings check done. Thu Nov  3 18:27:05 2016 - [info] 192.168.2.11(192.168.2.11:3306) (current master) +--192.168.2.12(192.168.2.12:3306) +--192.168.2.13(192.168.2.13:3306) Thu Nov  3 18:27:05 2016 - [info] Checking replication health on 192.168.2.12.. Thu Nov  3 18:27:05 2016 - [info]  ok. Thu Nov  3 18:27:05 2016 - [info] Checking replication health on 192.168.2.13.. Thu Nov  3 18:27:05 2016 - [info]  ok. Thu Nov  3 18:27:05 2016 - [warning] master_ip_failover_script is not defined. Thu Nov  3 18:27:05 2016 - [warning] shutdown_script is not defined. Thu Nov  3 18:27:05 2016 - [info] Got exit code 0 (Not master dead). MySQL Replication Health is OK.

以上提示表示正常！！！

4、查看masterha状态

1 2	[iyunv@localhost ~]#masterha_check_status --conf=/etc/masterha/app1.cnf app1 is stopped(2:NOT_RUNNING).

注：开启为"PING_OK"，暂停为"NOT_RUNNING"

5、MHA启动、输出日志、状态查看及停止
启动：

1	[iyunv@localhost ~]# nohup masterha_manager --conf=/etc/masterha/app1.cnf --remove_dead_master_conf --ignore_last_failover < /dev/null > /var/log/manager.log 2>&1 &

参数说明：
--remove_dead_master_conf      #表示生主从切换后，老的主库的ip将会从配置文件中移除。
--manger_log                   #日志存放位置
--ignore_last_failover         #在缺省情况下，如果MHA检测到连续发生宕机，且两次宕机间隔不足8小时的话，则不会进行Failover，之所以这样限制是为了避免ping-pong效应。该参数代表忽略上次MHA触发切换产生的文件，默认情况下，MHA发生切换后会在日志目录，也就是上面产生app1.failover.complete文件，下次再次切换的时候如果发现该目录下存在该文件将不允许触发切换，除非在第一次切换后收到删除该文件，为了方便，这里设置为--ignore_last_failover。

查看状态：

1 2	[iyunv@localhost ~]# masterha_check_status --conf=/etc/masterha/app1.cnf app1 (pid:20454) is running(0:PING_OK), master:192.168.2.11  #当前master为192.168.2.11

停止：#masterha_stop --conf=/etc/masterha/app1.cnf

六、以下再没有引入keepalive下,MHA本身已经可以做主从切换了，七章节将介绍keepalive+MHA
1、在node01 master节点（192.168.2.11）上停止mysql服务：

1	[iyunv@node01 ~]#systemctl stop mysql.service

2、查看MHA状态

1 2 3

[iyunv@localhost ~]# masterha_check_status --conf=/etc/masterha/app1.cnf app1 is stopped(2:NOT_RUNNING).  #master暂停mysql服务后发现masterha暂停了，这是mha的bug吧 [1]+  Exit 10                 nohup masterha_manager --conf=/etc/masterha/app1.cnf --remove_dead_master_conf --ignore_last_failover < /dev/null > /var/log/manager.log 2>&

3、查看192.168.2.6mha_master日志/var/log/masterha/app1/manager.log

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34

[iyunv@localhost masterha]#more /var/log/masterha/app1/manager.log Wed Nov  9 14:36:47 2016 - [info] MHA::MasterMonitor version 0.56. Wed Nov  9 14:36:47 2016 - [info] Multi-master configuration is detected. Current primary(writable) master is 192.168.2.12(192 .168.2.12:3306) Wed Nov  9 14:36:47 2016 - [info] Master configurations are as below: Master 192.168.2.11(192.168.2.11:3306), replicating from 192.168.2.12(192.168.2.12:3306), read-only Master 192.168.2.12(192.168.2.12:3306), replicating from 192.168.2.11(192.168.2.11:3306) Wed Nov  9 14:36:47 2016 - [info] GTID failover mode = 0 Wed Nov  9 14:36:47 2016 - [info] Dead Servers: Wed Nov  9 14:36:47 2016 - [info] Alive Servers: Wed Nov  9 14:36:47 2016 - [info]   192.168.2.12(192.168.2.12:3306) Wed Nov  9 14:36:47 2016 - [info]   192.168.2.11(192.168.2.11:3306) Wed Nov  9 14:36:47 2016 - [info]   192.168.2.13(192.168.2.13:3306) Wed Nov  9 14:36:47 2016 - [info] Alive Slaves: Wed Nov  9 14:36:47 2016 - [info]   192.168.2.11(192.168.2.11:3306)  Version=5.6.34-log (oldest major version between slaves) log-bin:enabled Wed Nov  9 14:36:47 2016 - [info]     Replicating from 192.168.2.12(192.168.2.12:3306) Wed Nov  9 14:36:47 2016 - [info]     Primary candidate for the new Master (candidate_master is set) Wed Nov  9 14:36:47 2016 - [info]   192.168.2.13(192.168.2.13:3306)  Version=5.6.34-log (oldest major version between slaves) log-bin:enabled Wed Nov  9 14:36:47 2016 - [info]     Replicating from 192.168.2.12(192.168.2.12:3306) Wed Nov  9 14:36:47 2016 - [info] Current Alive Master: 192.168.2.12(192.168.2.12:3306) Wed Nov  9 14:36:47 2016 - [info] Checking slave configurations.. Wed Nov  9 14:36:47 2016 - [warning]  relay_log_purge=0 is not set on slave 192.168.2.11(192.168.2.11:3306). Wed Nov  9 14:36:47 2016 - [info] Checking replication filtering settings.. Wed Nov  9 14:36:47 2016 - [info]  binlog_do_db= , binlog_ignore_db= Wed Nov  9 14:36:47 2016 - [info]  Replication filtering check ok. Wed Nov  9 14:36:47 2016 - [info] GTID (with auto-pos) is not supported Wed Nov  9 14:36:47 2016 - [info] Starting SSH connection tests.. Wed Nov  9 14:36:48 2016 - [info] All SSH connection tests passed successfully. Wed Nov  9 14:36:48 2016 - [info] Checking MHA Node version.. Wed Nov  9 14:36:49 2016 - [info]  Version check ok. Wed Nov  9 14:36:49 2016 - [info] Checking SSH publickey authentication settings on the current master.. Wed Nov  9 14:36:49 2016 - [info] HealthCheck: SSH to 192.168.2.12 is reachable.

注:以上信息说明切换master至192.168.2.12成功，但由于之前192.168.2.12是作为slave，开启只读模式，这时必须关闭只读模式

1	mysql> set global read_only=0;

4、查看node3从节点，是否正常连接到新的master

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57

mysql> show slave status\G *************************** 1. row ***************************                Slave_IO_State: Waiting for master to send event                   Master_Host: 192.168.2.12      #master连接至node02                   Master_User: repl                   Master_Port: 3306                 Connect_Retry: 60               Master_Log_File: mysql-bin.000005           Read_Master_Log_Pos: 120                Relay_Log_File: relay-bin.000002                 Relay_Log_Pos: 283         Relay_Master_Log_File: mysql-bin.000005              Slave_IO_Running: Yes     #I/O线程正常             Slave_SQL_Running: Yes     #mysql线程正常               Replicate_Do_DB:           Replicate_Ignore_DB:            Replicate_Do_Table:        Replicate_Ignore_Table:       Replicate_Wild_Do_Table:   Replicate_Wild_Ignore_Table:                    Last_Errno: 0                    Last_Error:                  Skip_Counter: 0           Exec_Master_Log_Pos: 120               Relay_Log_Space: 450               Until_Condition: None                Until_Log_File:                 Until_Log_Pos: 0            Master_SSL_Allowed: No            Master_SSL_CA_File:            Master_SSL_CA_Path:               Master_SSL_Cert:             Master_SSL_Cipher:                Master_SSL_Key:         Seconds_Behind_Master: 0 Master_SSL_Verify_Server_Cert: No                 Last_IO_Errno: 0                 Last_IO_Error:                Last_SQL_Errno: 0                Last_SQL_Error:   Replicate_Ignore_Server_Ids:              Master_Server_Id: 2                   Master_UUID: 78ada284-a0c9-11e6-ab52-000c2939bb02              Master_Info_File: /mydata/data/master.info                     SQL_Delay: 0           SQL_Remaining_Delay: NULL       Slave_SQL_Running_State: Slave has read all relay log; waiting for the slave I/O thread to update it            Master_Retry_Count: 86400                   Master_Bind:       Last_IO_Error_Timestamp:      Last_SQL_Error_Timestamp:                Master_SSL_Crl:            Master_SSL_Crlpath:            Retrieved_Gtid_Set:             Executed_Gtid_Set:                 Auto_Position: 0 1 row in set (0.00 sec)

5、原master node01修复后，如出现硬件故障并且更换后正常，原数据库完全没损坏情况，可以把node01节点作为SLAVE库
#########启动mysql，暂停原slave，设置数据库只读模式#######

1	[iyunv@node01 data]# systemctl start mysqld.service

1 2	mysql> stop slave; mysql> set global read_only=1;

########查看记录切换后node02(正常情况切换后会新生成一个binlog文件，如：mysql-bin.000005) binlog和Position号与node01当前，注MHA node01节点上/mydata/masterha有生成一个mysqlbinlog saved_master_binlog_from_192.168.2.11_3306_20161103185229.binlog，查看异常时的Position号
#######

1	[iyunv@node02 masterha]mysqlbinlog saved_master_binlog_from_192.168.2.11_3306_20161103185229.binlog #看最后一个at事件号

#########node01(192.168.2.11)上设置同步的日志和事务号，开启从库####

1 2 3

mysql> CHANGE MASTER TO MASTER_HOST='192.168.2.12',MASTER_USER='repl', MASTER_PASSWORD='12345678',MASTER_LOG_FILE='mysql-bin.000005',MASTER_LOG_POS=120; mysql> start slave； mysql> show slave status\G  #查看同步

6、修改/etc/masterha/app1.cnf文件，当现有master故障出现自动切换回192.168.2.11(node01)

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25

[iyunv@localhost masterha]# cat /etc/masterha/app1.cnf [server default] manager_log=/var/log/masterha/app1/manager.log manager_workdir=/var/log/masterha/app1 master_binlog_dir=/mydata/data master_ip_online_change_script=/usr/local/bin/master_ip_online_change password=12345678 ping_interval=1 remote_workdir=/mydata/masterha repl_password=12345678 repl_user=repl report_script=/usr/local/bin/send_report ssh_user=root [server1] check_repl_delay=0 hostname=192.168.2.12 port=3306 [server2] candidate_master=1 check_repl_delay=0 hostname=192.168.2.11 port=3306 [server3] hostname=192.168.2.13 port=3306

#####同样也检查配置文件，并且开启masterha服务

1 2	[iyunv@localhost masterha]# masterha_check_repl --conf=/etc/masterha/app1.cnf [iyunv@localhost masterha]# nohup masterha_manager --conf=/etc/masterha/app1.cnf --remove_dead_master_conf --ignore_last_failover < /dev/null > /var/log/manager.log 2>&1 &

##############*  错误记录总结  *##################
1、如192.168.2.11(master)出现故障做了切换192.168.2.12（slave），由于之前192.168.2.12是从库并且只读，所以切换之后mysql还是只读情况，masterha检测时会报错

1 2 3 4 5 6 7 8 9 10 11 12 13 14

[iyunv@localhost ~]# masterha_check_repl --conf=/etc/masterha/app1.cnf Wed Nov  9 11:49:02 2016 - [warning] Global configuration file /etc/masterha_default.cnf not found. Skipping. Wed Nov  9 11:49:02 2016 - [info] Reading application default configuration from /etc/masterha/app1.cnf.. Wed Nov  9 11:49:02 2016 - [info] Reading server configuration from /etc/masterha/app1.cnf.. Wed Nov  9 11:49:02 2016 - [info] MHA::MasterMonitor version 0.56. Wed Nov  9 11:49:02 2016 - [info] Multi-master configuration is detected. Current primary(writable) master is 192.168.2.11(192.168.2.11:3306) Wed Nov  9 11:49:02 2016 - [info] Master configurations are as below: Master 192.168.2.11(192.168.2.11:3306), replicating from 192.168.2.12(192.168.2.12:3306) Master 192.168.2.12(192.168.2.12:3306), replicating from 192.168.2.11(192.168.2.11:3306), read-only Wed Nov  9 11:49:02 2016 - [error][/usr/local/share/perl5/MHA/ServerManager.pm, ln726] Slave 192.168.2.13(192.168.2.13:3306) replicates from 192.168.2.12:3306, but real master is 192.168.2.11(192.168.2.11:3306)! Wed Nov  9 11:49:02 2016 - [error][/usr/local/share/perl5/MHA/MasterMonitor.pm, ln424] Error happened on checking configurations.  at /usr/local/share/perl5/MHA/MasterMonitor.pm line 326. Wed Nov  9 11:49:02 2016 - [error][/usr/local/share/perl5/MHA/MasterMonitor.pm, ln523] Error happened on monitoring servers. Wed Nov  9 11:49:02 2016 - [info] Got exit code 1 (Not master dead). MySQL Replication Health is NOT OK!

解决方法：设置192.168.2.11为只读模式，192.168.2.12为读写模式

1 2 3 4

mysql> set global read_only=1; #开启只读模式 Query OK, 0 rows affected (0.00 sec) mysql> set global read_only=0;  #可读可写 Query OK, 0 rows affected (0.00 sec)