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.rpmmysql5.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-manager:
[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_failoverMHA运行过程:
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进行复制