MHA架构概述及实战

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

# 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/modules/bwiki/index.phpplugin=attach&pcmd=open&file=mha4mysql-manager-0.56.tar.gz&refer=matsunobu)

mha4mysql-node-0.56.tar.gz (http://www.mysql.gr.jp/frame/modules/bwiki/index.phpplugin=attach&pcmd=open&file=mha4mysql-node-0.56.tar.gz&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):

[[email protected] ~]# ssh-keygen -t rsa
[[email protected] ~]# ssh-copy-id -i /root/.ssh/id_rsa.pub [email protected]
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
[email protected]‘s password: # 输入密码
Number of key(s) added: 1
Now try logging into the machine, with:   "ssh ‘[email protected]‘"
and check to make sure that only the key(s) you wanted were added.
[[email protected] ~]# ssh-copy-id -i /root/.ssh/id_rsa.pub [email protected]
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
[email protected]‘s password: 
Number of key(s) added: 1
Now try logging into the machine, with:   "ssh ‘[email protected]‘"
and check to make sure that only the key(s) you wanted were added.
[[email protected] ~]# ssh-copy-id -i /root/.ssh/id_rsa.pub [email protected]
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
[email protected]‘s password: 
Number of key(s) added: 1
Now try logging into the machine, with:   "ssh ‘[email protected]‘"
and check to make sure that only the key(s) you wanted were added.

在node01 192.168.2.11操作(Master):

[[email protected] ~]# ssh-keygen -t rsa
[[email protected] ~]# ssh-copy-id -i /root/.ssh/id_rsa.pub [email protected]
/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
[email protected]‘s password: 
Number of key(s) added: 1
Now try logging into the machine, with:   "ssh ‘[email protected]‘"
and check to make sure that only the key(s) you wanted were added.
[[email protected] ~]# ssh-copy-id -i /root/.ssh/id_rsa.pub [email protected]
/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
[email protected]‘s password: 
Number of key(s) added: 1
Now try logging into the machine, with:   "ssh ‘[email protected]‘"
and check to make sure that only the key(s) you wanted were added.

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

[[email protected] ~]# ssh-keygen -t rsa
[[email protected] ~]# ssh-copy-id -i /root/.ssh/id_rsa.pub [email protected]
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
[email protected]‘s password: 
Number of key(s) added: 1
Now try logging into the machine, with:   "ssh ‘[email protected]‘"
and check to make sure that only the key(s) you wanted were added.
[[email protected] ~]# ssh-copy-id -i /root/.ssh/id_rsa.pub [email protected]
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
[email protected]‘s password: 
Number of key(s) added: 1
Now try logging into the machine, with:   "ssh ‘[email protected]‘"
and check to make sure that only the key(s) you wanted were added.

3、在node3 192.168.2.13操作(slave):

[[email protected] ~]# ssh-keygen -t rsa
[[email protected] ~]# ssh-copy-id -i /root/.ssh/id_rsa.pub [email protected]
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
[email protected]‘s password: 
Number of key(s) added: 1
Now try logging into the machine, with:   "ssh ‘[email protected]‘"
and check to make sure that only the key(s) you wanted were added.
[[email protected] ~]# ssh-copy-id -i /root/.ssh/id_rsa.pub [email protected]
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
[email protected]‘s password: 
Number of key(s) added: 1
Now try logging into the machine, with:   "ssh ‘[email protected]‘"
and check to make sure that only the key(s) you wanted were added.

三、所有节点服务器安装mha4mysql-node-0.56

1、解决组件依赖关系

192.168.2.11 [[email protected] ~]# yum install perl-DBD-MySQL perl-CPAN -y
192.168.2.12 [[email protected] ~]# yum install perl-DBD-MySQL perl-CPAN -y
192.168.2.13 [[email protected] ~]# yum install perl-DBD-MySQL perl-CPAN -y
192.168.2.6  [[email protected] ~]# yum install perl-DBD-MySQL perl-CPAN -y

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

[[email protected] soft]# ls
mha4mysql-manager-0.56.tar.gz  mha4mysql-node-0.56.tar.gz
[[email protected] soft]# tar xf mha4mysql-node-0.56.tar.gz   #解压
[[email protected] soft]# cd mha4mysql-node-0.56 
[[email protected] mha4mysql-node-0.56]# perl Makefile.PL 
[[email protected] 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

[[email protected] soft]# yum install perl-DBD-MySQL perl-CPAN perl-Config-Tiny perl-Log-Dispatch perl-Parallel-ForkManager perl-Time-HiRes -y   #解决依赖关系
[[email protected] soft]# tar xf mha4mysql-manager-0.56.tar.gz    
[[email protected] soft]# cd mha4mysql-manager-0.56    
[[email protected] soft]# perl Makefile.PL    
[[email protected] soft]# make && make install
#注:安装的脚本程序默认存放在/usr/local/bin/目录下,有以下脚本
[[email protected] 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信息

[[email protected] scripts]# pwd
/soft/mha4mysql-manager-0.56/samples/scripts
[[email protected] 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)

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

2、默认安装mysql无密码,node01、node02、node3节点上数据库设置管理员密码(测试密码:12345678)

#授权root用户访问任意库,本地登录密码

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(修改前建议备份该文件)修改如下内容,修改配置后重启数据库:

[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一定要唯一;
[[email protected] ~]# systemctl restart mysqld.service #重启服务

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

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

binlog-do-db 和 replicate-ignore-db 必须相同

log_bin、relay_log,二进制日志和中继日志尽量不要跟数据存储放在同一磁盘同一目录,防止硬盘损坏时日志也丢失

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

mysql> CREATE DATABASE apps;
Query OK, 1 row affected (0.00 sec)
[[email protected] /]# mysql -uroot -p apps < /soft/apps.sql

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

[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配置文件多了下面这两条)
[[email protected] ~]# systemctl restart mysqld.service #重启服务
[[email protected] ~]#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节点同理):

[[email protected] ~]# 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线程。下面我们手动执行看看什么情况:

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

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

[[email protected] ~]# 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.
[[email protected] ~]# mysql -uroot -p12345678 -e "GRANT ALL PRIVILEGES ON *.* TO [email protected]‘127.0.0.1‘ IDENTIFIED BY ‘12345678‘"
Warning: Using a password on the command line interface can be insecure.
重新测试执行:
[[email protected] ~]# 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

[[email protected] ~]# cd /mydata/data/
[[email protected] 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修改如下内容,修改配置后重启数据库:

[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   #从库只读
[[email protected] ~]# systemctl restart mysqld.service #重启服务

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

[[email protected] /]# 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),并授权访问所有主机:

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:

[[email protected] /]# 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/目录下,并且导入到从库中

[[email protected] /]# scp /soft/all.sql [email protected]:/soft/
all.sql                                      100%  637KB 637.0KB/s   00:00    
[[email protected] /]# scp /soft/all.sql [email protected]:/soft/
all.sql                                      100%  637KB 637.0KB/s   00:00

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

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

node02和node3,连接mysql,执行以下命令:

[[email protected] /]# mysql -uroot -p12345678
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 #还原同步文件和日志

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)

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

[[email protected] /]# mysql -uroot -p12345678
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 #还原同步文件和日志

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号####################

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      |
+----+------------+-------------------------+---------+
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的工作目录,并且创建相关配置文件

[[email protected] /]# mkdir -p /etc/masterha
[[email protected] /]# mkdir -p /mydata/masterha
[[email protected] /]# cp -a /soft/mha4mysql-manager-0.56/samples/conf/app1.cnf /etc/masterha/  #示例配置文件拷贝至新建目录/etc/masterha/
#拷贝以下脚本至/usr/local/bin/目录下,先在配置文件app1.cnf注释该配置后引用keepalive开启配置项
[[email protected] /]#cp -a /soft/mha4mysql-manager-0.56/samples/scripts/master_ip_failover /usr/local/bin/
[[email protected] /]#cp -a /soft/mha4mysql-manager-0.56/samples/scripts/master_ip_online_change /usr/local/bin/
[[email protected] /]#cp -a /soft/mha4mysql-manager-0.56/samples/scripts/masterha_secondary_check /usr/local/bin/
##############修改app1.cnf配置文件,修改后的文件内容如下:
[[email protected] /]# 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连接测试

[[email protected] 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、测试整个复制环境

[[email protected] ~]# 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

注释后重新执行测试:

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状态

[[email protected] ~]#masterha_check_status --conf=/etc/masterha/app1.cnf
app1 is stopped(2:NOT_RUNNING).

注:开启为"PING_OK",暂停为"NOT_RUNNING"

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

启动:

[[email protected] ~]# 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。

查看状态:

[[email protected] ~]# 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服务:

[[email protected] ~]#systemctl stop mysql.service

2、查看MHA状态

[[email protected] ~]# 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

[[email protected] 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,开启只读模式,这时必须关闭只读模式

mysql> set global read_only=0;

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

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,设置数据库只读模式#######

[[email protected] data]# systemctl start mysqld.service
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号

#######

[[email protected] masterha]mysqlbinlog saved_master_binlog_from_192.168.2.11_3306_20161103185229.binlog #看最后一个at事件号

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

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)

[[email protected] 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服务

[[email protected] masterha]# masterha_check_repl --conf=/etc/masterha/app1.cnf 
[[email protected] 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检测时会报错

[[email protected] ~]# 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为读写模式

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)
时间: 2024-11-03 21:56:36

MHA架构概述及实战的相关文章

大型互联网架构概述

本文旨在简单介绍大型互联网的架构和核心组件实现原理. 理论上讲,从安装配置,最佳实践以及源码来剖析各个组件,这个自然是极好的.由于笔者时间以及知识有限,有很多知识没有在工作中亲自实践的机会.所以有些地方语焉不详,还请大家多多指教. 大型互联网架构 解决问题的通用思路是将分而治之(divide-and-conquer),将大问题分为若干个小问题,各个击破.在大型互联网的架构实践中,无一不体现这种思想. 架构目标 低成本:任何公司存在的价值都是为了获取商业利益.在可能的情况下,希望一切都是低成本的.

《数据安全架构设计与实战》新书推荐

<数据安全架构设计与实战>一书融入作者十余年安全架构实践经验,系统性地介绍数据安全架构设计与治理实践,主要包括:产品安全架构(从源头开始保障数据/隐私安全).安全技术体系架构(构建统一的安全能力中心).数据安全与隐私保护治理(建立全局视野并保障数据安全落地). 专家评论 数据安全问题其实一直存在,只是在大数据.基于大数据的人工智能时代变得更加重要,郑云文的这本<数据安全架构设计与实战>在覆盖信息安全.网络安全基础知识与最佳实践的基础上,对数据安全相关问题有更深入的探讨.如同书中的观

秒杀系统架构分析与实战

0 系列目录 秒杀系统架构 秒杀系统架构分析与实战 1 秒杀业务分析 正常电子商务流程 (1)查询商品:(2)创建订单:(3)扣减库存:(4)更新订单:(5)付款:(6)卖家发货 秒杀业务的特性 (1)低廉价格:(2)大幅推广:(3)瞬时售空:(4)一般是定时上架:(5)时间短.瞬时并发量高: 2 秒杀技术挑战 假设某网站秒杀活动只推出一件商品,预计会吸引1万人参加活动,也就说最大并发请求数是10000,秒杀系统需要面对的技术挑战有: 对现有网站业务造成冲击 秒杀活动只是网站营销的一个附加活动,

Scrapy架构概述

Scrapy架构概述 1, 从最初自己编写的spiders,获取到start_url,并且封装成Request对象. 2,通过engine(引擎)调度给SCHEDULER(Requests管理调度器). 3,SCHEDULER管理ENGINE传递过来的所有Requests,通过优先级,传递给ENGINE. 4,ENGINE 将传递过来的Request对象传递给Downloader(下载器),但是在传递之间会通过MiddleWare(中间件)对Requests进行包装,添加头部,代理IP之类的.

秒杀系统架构分析与实战(参考、转载)

目录[-] 0 系列目录 1 秒杀业务分析 2 秒杀技术挑战 3 秒杀架构原则 4 秒杀架构设计 4.1 前端层设计 4.2 站点层设计 4.3 服务层设计 4.4 数据库设计 4.4.1 基本概念 4.4.2 设计思路 5 大并发带来的挑战 5.1 请求接口的合理设计 5.2 高并发的挑战:一定要“快” 5.3 重启与过载保护 6 作弊的手段:进攻与防守 6.1 同一个账号,一次性发出多个请求 6.2 多个账号,一次性发送多个请求 6.3 多个账号,不同IP发送不同请求 7 高并发下的数据安全

大规模分布式系统架构与设计实战摘录

大规模分布式系统架构与设计实战摘录 一位网站资深架构师曾经说过:在互联网公司呆一年,相当于在传统软件公司呆三年. 他的意思大概是在互联网公司一年遇到的问题比传统软件公司三年遇到的问题还多.而且 随着网站业务的快速发展,问题也层出不穷,没年遇到的问题都不同. 遇到问题,解决问 题,经历了这个过程,技术才能升华,人和技术才能融为一体,才知道什么技术是真正有 用的,什么技术是花拳绣腿.大型网站的技术本质都很简单,掌握起来也不难.大型网站 的架构师最有价值的地发不在于他们掌握了多少技术,而在于他们经历多

Android软硬整合设计与框架揭秘: HAL&amp;Framework &amp;Native Service &amp;App&amp;HTML5架构设计与实战开发

掌握Android从底层开发到框架整合技术到上层App开发及HTML5的全部技术: 一次彻底的Android架构.思想和实战技术的洗礼: 彻底掌握Andorid HAL.Android Runtime.Android Framework.Android Native Service.Android Binder.Android App.Android Testing.HTML5技术的源泉和精髓等核心技术,不仅仅是技术和代码本身,更重要的是背后的设计思想和商业哲学. 一.课程特色 l  贯通And

JavaEE体系架构概述、MyBatis总结

JavaEE体系架构概述 java EE是sum公司发布的标准企业级应用规范集合,它提供了一个多层结构的分布式应程序模型,是开发基于网络的企业级应用首选平台.Java EE技术平台的核心思想是“容器”加组件 事务:有明确边界的一组序列,在应用程序中一个请求对应一个事务,当请求发送时,事务开始,当请求结束,事务也就结束.总的来说,事务有四个特性:1.原子性,一个请求要么成功,要么失败,不会再有其他情况:2.一致性,事务处理需要的和得到的时相同的:3.持久性,事务处理的结果时确认的.持久的,如果需要

【转载】秒杀系统架构分析与实战

本文转载自:http://my.oschina.net/xianggao/blog/524943 0 系列目录 秒杀系统架构 秒杀系统架构分析与实战 1 秒杀业务分析 正常电子商务流程 (1)查询商品:(2)创建订单:(3)扣减库存:(4)更新订单:(5)付款:(6)卖家发货 秒杀业务的特性 (1)低廉价格:(2)大幅推广:(3)瞬时售空:(4)一般是定时上架:(5)时间短.瞬时并发量高: 2 秒杀技术挑战 假设某网站秒杀活动只推出一件商品,预计会吸引1万人参加活动,也就说最大并发请求数是100