mysql主从集群高可用架构-----MHA

原理:

MHA(Master High Availability)是现在解决mysql高可用的一个相对成熟的方案

它是由两部分组成,管理端(master manager)和节点端(node manager),管理端可以单独布置在一台机器上,整个mysql主从集群就是它的各个节点,

管理端对所有节点进行监控,当master宕机之后,管理端会根据自己配置文件里的设定,将某一个从节点升为主节点,(如果没有设置,它会自己比对,将最新数据的节点升为主节点),然后将其他节点自动指向提升上来的新的主节点,在提升的过程中,所有结点之间必须可以无密码ssh连接,管理端可以对所有的节点ssh无密码连接.

在MHA自动故障切换的过程中,如果宕掉的 master 无法ssh连接上,则无法同步最新的二进制日志,也就无法获得最新的数据,造成数据丢失,因此,为了避免这中情况发生,MHA一般配合半同步复制.可以最大程度的保存数据.

为了避免在更换主节点时同步日志出错(pos模式下更换节点,日志同步会出错),我们开启GTID模式

目前MHA支持一主多从,整个MHA架构最少有三个节点,一台master 一台slave做备用master 一台slave只做同步,当然,为了充分利用资源,集群可以做读写分离(master做写操作,slave做读操作)

本次实验我们准备了四台机器,一台做master manager 剩下三台node做一主2从配置,

实验准备

操作系统:

redhat 6.5

节点:

server1: 172.25.12.1 master master-node

server2: 172.25.12.2 slave master-node

server3: 172.25.12.3 slave master-node

server4: 172.25.12.4 master-manager

数据库版本:

mysql 5.7

防火墙及selinux:

关闭

配置master-manager

在server4 上(172.25.12.4)

安装包:

yum install -y
mha4mysql-manager-0.56-0.el6.noarch.rpm
mha4mysql-node-0.56-0.el6.noarch.rpm
perl-Config-Tiny-2.12-7.1.el6.noarch.rpm
perl-Email-Date-Format-1.002-5.el6.noarch.rpm
perl-Log-Dispatch-2.27-1.el6.noarch.rpm
perl-Mail-Sender-0.8.16-3.el6.noarch.rpm
perl-Mail-Sendmail-0.79-12.el6.noarch.rpm
perl-MIME-Lite-3.027-2.el6.noarch.rpm
perl-MIME-Types-1.28-2.el6.noarch.rpm
perl-Parallel-ForkManager-0.7.9-1.el6.noarch.rpm

创建配置文件及其目录:

mkdir /etc/mha
vim /etc/mha/mha.conf

配置文件如下:

[server default]
manager_workdir=/usr/local/mha
#设置manager的工作目录

manager_log=/usr/local/mha/mha.log
#设置manager的日志

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

user=root
#设置监控用户root,这个用户在mysql里存在

password=Yang@123
#设置mysql中监控用户的那个密码

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

remote_workdir=/tmp
#设置远端mysql在发生切换时binlog的保存位置

repl_user=mha
#设置同步用户mha

repl_password=Yang@123
#设置mha的密码

ssh_user=root
#设置ssh的登录用户名

[server1]
hostname=172.25.12.1
port=3306

[server2]
hostname=172.25.12.2
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=172.25.12.3
port=3306
#no_master=1             #一定不会是master

检测配置:

masterha_check_repl --conf=/etc/mha/mha.conf

配置ssh:

ssh-keygen
ssh-copy-id  172.25.12.1
ssh-copy-id  172.25.12.2
ssh-copy-id  172.25.12.3

scp -rp ~/.ssh/ root@172.25.12.1:/root
scp -rp ~/.ssh/ root@172.25.12.2:/root
scp -rp ~/.ssh/ root@172.25.12.3:/root

检测ssh状态:

masterha_check_ssh --conf=/etc/mha/mha.conf

[root@server4 MHA]#  masterha_check_ssh --conf=/etc/mha/mha.conf
.
.
Mon Jun 26 20:19:12 2017 - [debug]  Connecting via SSH from root@172.25.12.1(172.25.12.1:22) to root@172.25.12.2(172.25.12.2:22)..
Mon Jun 26 20:19:12 2017 - [debug]   ok.
Mon Jun 26 20:19:12 2017 - [debug]  Connecting via SSH from root@172.25.12.1(172.25.12.1:22) to root@172.25.12.3(172.25.12.3:22)..
Mon Jun 26 20:19:13 2017 - [debug]   ok.
Mon Jun 26 20:19:13 2017 - [debug]
Mon Jun 26 20:19:13 2017 - [debug]  Connecting via SSH from root@172.25.12.2(172.25.12.2:22) to root@172.25.12.1(172.25.12.1:22)..
Mon Jun 26 20:19:13 2017 - [debug]   ok.
Mon Jun 26 20:19:13 2017 - [debug]  Connecting via SSH from root@172.25.12.2(172.25.12.2:22) to root@172.25.12.3(172.25.12.3:22)..
Mon Jun 26 20:19:13 2017 - [debug]   ok.
Mon Jun 26 20:19:14 2017 - [debug]
Mon Jun 26 20:19:13 2017 - [debug]  Connecting via SSH from root@172.25.12.3(172.25.12.3:22) to root@172.25.12.1(172.25.12.1:22)..
Mon Jun 26 20:19:13 2017 - [debug]   ok.
Mon Jun 26 20:19:13 2017 - [debug]  Connecting via SSH from root@172.25.12.3(172.25.12.3:22) to root@172.25.12.2(172.25.12.2:22)..
Mon Jun 26 20:19:14 2017 - [debug]   ok.
Mon Jun 26 20:19:14 2017 - [info] All SSH connection tests passed successfully.

master-node配置:

先安装node:

yum install -y mha4mysql-node-0.56-0.el6.noarch.rpm

mysql5.7安装请看下面链接:

redhat6.5下的mysql5.7安装教程

主从集群配置(因为所有的节点都有可能升至master,所以几乎所有节点的配置都一样):

主从复制详细原理请参考下面链接:

mysql5.7主从复制原理及基本配置

先在各个节点上安装半同步插件(server1,server2,server3都执行)

登陆数据库,在数据库里执行下面命令:

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

所有节点配置文件都一样,除了里面的参数 server-id 其他的都必须一致,因为所有节点都有可能升至master

[root@server2 ~]# cat /etc/my.cnf | grep -v "#"

[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock

symbolic-links=0

log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid

server-id=2           #各个节点的sever-id不能一样
log-bin=mysql-bin
binlog-do-db=test
binlog-ignore-db=mysql

gtid-mode=ON         #开启gtid
enforce-gtid-consistency

rpl_semi_sync_master_enabled=ON     #开启半同步复制
rpl_semi_sync_slave_enabled=ON

slave-parallel-type=LOGICAL_CLOCK
slave-parallel-workers=16
master-info_repository=TABLE
relay_log_info_repository=TABLE
relay_log_recovery=ON

在所有节点上都设置监控用户以及同步用户(server1,server3,server3都执行):

先登陆mysql:

mysql> grant replication slave on *.* to mha@'172.25.12.%' identified by 'Yang@123';
mysql> grant all on *.* to root@'172.25.12.%' identified by 'Yang@123';

现在先设置server1为master:

在server2,server3上执行下面命令,让他们去同步server1

mysql> stop slave;
mysql> change master to master_host='172.25.12.1',master_user='mha',master_password='Yang@123',master_auto_position=1;
mysql> start slave;

查看各个节点的状态:

server1:

mysql> show master status;

server2,server3:

mysql> show slave status\G;

看下面这两个线程是否开启
Slave_IO_Running: Yes
Slave_SQL_Running: Yes

自此,高可用集群配置完毕,下面我们来检测下:

高可用检测:

先在server4上开启master-manag
d299
er:

[root@server4 mha]# nohup masterha_manager --conf=/etc/mha/mha.conf   --ignore_last_failover 2>&1 &

将server1 停掉:

[root@server1 ~]# /etc/init.d/mysqld stop
Stopping mysqld:                                           [  OK  ]

在server2上观察:

一开始是这样:

mysql> show slave status\G;
*************************** 1. row ***************************
Slave_IO_State:
Master_Host: 172.25.12.1
Master_User: mha
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000008
Read_Master_Log_Pos: 194
Relay_Log_File: server2-relay-bin.000002
Relay_Log_Pos: 367
Relay_Master_Log_File: mysql-bin.000008
Slave_IO_Running: Connecting
Slave_SQL_Running: Yes

几秒后:

mysql> show slave status\G;
*************************** 1. row ***************************
Slave_IO_State:
Master_Host: 172.25.12.1
Master_User: mha
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000008
Read_Master_Log_Pos: 194
Relay_Log_File: server2-relay-bin.000002
Relay_Log_Pos: 367
Relay_Master_Log_File: mysql-bin.000008
Slave_IO_Running: No
Slave_SQL_Running: No

再过几秒:

mysql> show slave status\G;
Empty set (1.11 sec)

ERROR:
No query specified

因为它切换成了master

在server3上观察:

mysql> show slave status\G;
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 172.25.12.2
Master_User: mha
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000004
Read_Master_Log_Pos: 194
Relay_Log_File: server3-relay-bin.000002
Relay_Log_Pos: 367
Relay_Master_Log_File: mysql-bin.000004
Slave_IO_Running: Yes
Slave_SQL_Running: Yes

自动切换成功

将server1上的mysql重启后,它不能自动加入到集群里,而且,他的状态默认还是master

这时,就要手动更改他的状态,将他加入到集群:

mysql> change master to master_host='172.25.12.2',master_user='mha',master_password='Yang@123',master_auto_position=1;
Query OK, 0 rows affected, 2 warnings (1.10 sec)

mysql> start slave;

查看:

mysql> show slave status\G;
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 172.25.12.2
Master_User: mha
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000004
Read_Master_Log_Pos: 194
Relay_Log_File: server1-relay-bin.000002
Relay_Log_Pos: 367
Relay_Master_Log_File: mysql-bin.000004
Slave_IO_Running: Yes
Slave_SQL_Running: Yes

手动切换:

使用手动切换时,不用开启master-manager

#热切换
masterha_master_switch --conf=/etc/mha/mha.conf --master_state=alive --new_master_host=172.25.12.1 --new_master_port=3306 --orig_master_is_new_slave --running_updates_limit=1000

#冷切换
masterha_master_switch --conf=/etc/mha/mha.conf --master_state=dead --dead_master_host=172.25.12.1 --dead_master_port=3306 --new_master_host=172.25.12.2 --new_master_port=3306 --ignore_last_failover

MHA运行过程:

1.配置文件检查阶段，这个阶段会检查整个集群配置文件配置

masterha_check_repl –conf=/etc/mha/mha.conf

masterha_check_ssh –conf=/etc/mha/mha.conf

2.宕机的master处理

3.复制dead maste和最新slave相差的relay log，并保存到MHA Manger具体的目录下

4.识别含有最新更新的slave

5.应用从master保存的二进制日志事件（binlog events）

6.提升一个slave为新的master进行复制

7.使其他的slave连接新的master进行复制