linux运维进阶-mysql高可用

.以下操作基于rhel6.5

Mysql的高可用MHA实现

Server3：172.25.50.3
 master

Server4：172.25.50.4  Candicate slave

Server5：172.25.50.5 slave

Server2: 172.25.50.2  monitor

Server3是master，Server4和server5是server3的slave,其中master对外提供写服务，备选master（实际的slave，主机名server4）

提供读服务，另一个slave也提供相关的读服务，一旦master宕机，将会把备选master提升为新的master，slave指向新的master。

一．基础知识

MHA（Master High Availability）是一套优秀的作为MySQL高可用性环境下故障切换和主从提升的高可用软件。

在MySQL故障切换过程中，MHA能做到在0~30秒之内自动完成数据库的故障切换操作，并且在进行故障切换的过程中，MHA能在最大程度上保证数据的一致性，以达到真正意义上的高可用。

由两部分组成：MHA Manager（管理节点）和MHA Node（数据节点）。

目前MHA主要支持一主多从的架构，要搭建MHA,要求一个复制集群中必须最少有三台数据库服务器，一主二从，即一台充当master，一台充当备用master，另外一台充当从库，因为至少需要三台服务器，出于机器成本的考虑，淘宝也在该基础上进行了改造，目前淘宝TMHA已经支持一主一从。

MHA构架组成：MHA Manager（管理节点）和MHA Node（数据节点）



mha支持多套主从切换，只要编写多个配置文件即可，例：app1.conf,app2.conf,...,appn.conf

二.工作机制

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 node所需的perl模块

四.配置ssh无密码连接：

ssh-keygen   ##每台机子都要生成自己的公秘钥对 【连续回车】

ssh-copy-id -i /root/.ssh/id_rsa.pub root@172.25.50.3

ssh-copy-id -i /root/.ssh/id_rsa.pub root@172.25.50.4

ssh-copy-id -i /root/.ssh/id_rsa.pub root@172.25.50.5

每台机子都要做上述操作(3给4，5；4给3，5；5给3，4 ；2给3，4，5)

配置完后测试： server3,4,5可以互相无密码登陆，server2可无密码登陆其他第三个主机

五.搭建主从复制环境

【前面博客实验中Server4的数据已经和server3（master)数据同步】

下面配置首先使server5与server3(master)数据相同，然后进行同步；

注意：在同步数据之前务必保证数据的一致，binlog-do-db 和 replicate-ignore-db 设置必须相同，MHA 在启动时候会检测过滤规则，如果过滤规则不同，MHA
不启动监控和故障转移。

1.在Master上备份一份完整的数据

[root@server3 ~]# mysqldump -uroot -pWrh.6666 -h 172.25.50.3 --master-data=2 --single-transaction -R --triggers -A > all.sql

##将server3上数据库的所有数据备份在文件all.sql中，其中--master-data=2代表备份时刻记录master的Binlog位置和

Position，--single-transaction意思是获取一致性快照，-R意思是备份存储过程和函数，--triggres的意思是备份触发器，-A代表

备份所有的库。

配置server5为从机，把数据备份复制到server5上

首先配置server5上的半同步复制

yum install -y mysql-community-client-5.7.17-1.el6.x86_64.rpm mysql-community-common-5.7.17-1.el6.x86_64.rpm mysql-community-libs-5.7.17-1.el6.x86_64.rpm mysql-community-libs-compat-5.7.17-1.el6.x86_64.rpm mysql-community-server-5.7.17-1.el6.x86_64.rpm

vim /etc/my.cnf
server-id=6              server-id每个节点均不相同，范围是1到2^32-1
log-bin=mysql-bin
binlog-do-db=test
binlog-ignore-db=mysql
gtid_mode=ON
enforce-gtid-consistency=true

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

所有节点上的配置文件除了server-id之外必须相同，因为当master节点down掉了，需要slave接管，因此配置要相同。

/etc/init.d/mysqld start
mysql -p

 

  

2.将从主机上导出的数据文件再导入备机的mysql中以实现数据同步。

stop slave;
change master to master_host='172.25.50.3', master_user='wrh',master_auto_position=1;
start slave;
show slave status \G;

做到这里我们的server5已经和master（server3）数据同步

在检查一下server4的数据同步：





说明server4的数据与master数据相同

3.两台slave服务器设置read_only（从库对外提供读服务，之所以没有写进配置文件，是因为随时slave会提升为master）

设置relay log的清除方式（在每个slave节点上）





4.创建监控用户，给监控权限（在master上执行，也就是server3)

六.配置MHA

Manager工具包：

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信息

Node工具包 （这些工具通常由MHA Manager的脚本触发，无需人为操作）主要包括以下几个工具：

save_binary_logs                保存和复制master的二进制日志
apply_diff_relay_logs           识别差异的中继日志事件并将其差异的事件应用于其他的slave
filter_mysqlbinlog              去除不必要的ROLLBACK事件（MHA已不再使用这个工具）
purge_relay_logs                清除中继日志（不会阻塞SQL线程）

1.创建MHA的工作目录，并且创建相关配置文件

[root@server5 ~]# mkdir -p /etc/masterha
[root@server5 ~]# vim /etc/masterha/app.cnf

2.检查：在监控结点上操作



 可以看见各个节点ssh验证都是ok的。

3.检查整个复制环境状况(server2 Monitor 监控节点上操作)，如下：

[root@server2 ~]# masterha_check_repl --conf=/etc/masterha/app.cnf

这里的报错信息原因是Failover两种方式：一种是虚拟IP地址，一种是全局配置文件。

MHA并没有限定使用哪一种方式，而是让用户自己选择，虚拟IP地址的方式会牵扯到其它的软件,比如keepalive软件，而且还要修改脚本master_ip_failover。

所以先暂时注释master_ip_failover_script= /usr/local/bin/master_ip_failover这个选项。

[root@server2 ~]# vim /etc/masterha/app.cnf

检测成功





3.检查MHA Manager的状态

通过master_check_status脚本查看Manager的状态：

注意：如果正常，会显示"PING_OK"，否则会显示"NOT_RUNNING"

4.开启MHA Manager监控(server2 操作)如下:

[root@server2 ~]# mkdir -p /var/log/masterha/app/
[root@server2~]# nohup masterha_manager --conf=/etc/masterha/app.cnf --remove_dead_master_conf --ignore_last_failover < /dev/null > /var/log/masterha/app/manager.log 2>&1 &
[1] 1344
[root@server2 ~]# masterha_check_status --conf=/etc/masterha/app.cnf
app (pid:1344) is running(0:PING_OK), master:172.25.50.3
#可以看见已经在监控了，而且master的主机为172.25.50.3

八.测试

1.当master down掉
在server4上授权复制：

mysql> GRANT REPLICATION SLAVE ON *.* TO 'wrh'@'172.25.50.%' IDENTIFIED BY 'Wrh.6666';

将master即server3服务停掉，这时备用的master即server4会切换为真正的master，在slave可以查看此时的master：

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

在server5上：

mysql>change master to master_host='172.25.50.4', master_user='wrh',master_password='Wrh.6666',MASTER_AUTO_POSITION = 1;
Query OK, 0 rows affected, 2 warnings (0.55 sec)

start slave;
show slave status \G;
#可以看见此时的主机已经转移到server4上。

2.在线切换master到不同主机

在很多情况下，有必要将master转移到其他主机上（如替换raid控制器，提升master机器硬件等等）。

这并不是master崩溃，但是计划维护必须去做。

在server2上

[root@server2 ~]# masterha_master_switch --conf=/etc/masterha/app.cnf --master_state=alive --new_master_host=172.25.50.5 --new_master_port=3306 --orig_master_is_new_slave --running_updates_limit=10000

##手动切换master

3.故障转移

server2：  nohup masterha_manager --conf=/etc/masterha/app.cnf & #后台监控
server5： /etc/init.d/msyqld stop    #模拟master故障

#操作之前修改app.cnf配置文件指定server4为备用master，当master挂掉时，server4会变成master

server5：start slave;
server5：show slave status\G;
#此时可以看见master为server4

END