您的位置: 首页  >  文章  >  MHA高可用

MHA高可用

分类: 文章 • 2024-03-05 16:56:01

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已经支持一主一从。MHA 适合任何存储引擎, 只要能主从复制的存储引擎它都支持，不限于支持事物的 innodb 引擎。
官方介绍：https://code.google.com/p/mysql-master-ha/
下面展示了如何通过MHA Manager管理多组主从复制。可以将MHA工作原理总结为如下：
MHA高可用
（1）从宕机崩溃的master保存二进制日志事件（binlog events）;
（2）识别含有最新更新的slave；
（3）应用差异的中继日志（relay log）到其他的slave；
（4）应用从master保存的二进制日志事件（binlog events）；
（5）提升一个slave为新的master；
（6）使其他的slave连接新的master进行复制；
MHA软件由两部分组成，Manager工具包和Node工具包，具体的说明如下。
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线程）
注意：
为了尽可能的减少主库硬件损坏宕机造成的数据丢失，因此在配置MHA的同时建议配置成MySQL 5.5的半同步复制。关于半同步复制原理各位自己进行查阅。（不是必须）

IP地址 主机名 角色 软件
192.168.137.101 manager manager mha4mysql-manager、mha4mysql-node
192.168.137.102 master master mha4mysql-node
192.168.137.103 slave1 Slave1,
Candicate master mha4mysql-node
192.168.137.104 slave2 Slave2 mha4mysql-node
注意在这里：
192.168.137.102 是mysql主服务器
192.168.137.103、192.168.137.104是从服务器
但是192.168.137.103是备选服务器
配置如下：
注意：由于是测试机所以我在这里是全部关闭防火墙以及Linux内核
setenforce 0
systemctl stop firewalld
配置本地yum源 （所有的服务器上都一样）
vim /etc/yum.repos.d/CentOS-Media.repo
[c7-media]
name=CentOS-$releasever - Media
baseurl=file:///media/cdrom/
gpgcheck=0
enabled=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7
挂载光盘
mkdir /media/cdrom
mount /dev/cdrom /media/cdrom/

第一步：所有服务器互相配置ssh免**登入（所有服务器都要有的操作）
[[email protected] ~]# ssh-****** -t rsa //一路回车
[[email protected] ~]# ssh-copy-id 192.168.137.102
[[email protected] ~]# ssh-copy-id 192.168.137.103
[[email protected] ~]# ssh-copy-id 192.168.137.104
其他服务器一样的动作 注意修改IP

第二步：所有服务器都要安装epel源 （所有服务器都要有的操作）
[[email protected] ~]# wget http://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm
[[email protected] ~]# rpm -ivh epel-release-latest-7.noarch.rpm
[[email protected] ~]# yum clean all
[[email protected] ~]# yum makecache
[[email protected] ~]# yum -y install perl-DBD-MySQL perl-Config-Tiny perl-Log-Dispatch perl-Parallel-ForkManager --skip-broken
[[email protected] ~]# rpm -ivh mha4mysql-node-0.54-0.el6.noarch.rpm
[[email protected] ~]# cd /usr/bin/
[[email protected] bin]# ll app* filter* purge* save*
MHA高可用
接下来是 管理节点的步骤（ manager的 ）
[[email protected] ~]# yum install perl-DBD-MySQL perl-Config-Tiny perl-Log-Dispatch perl-Parallel-ForkManager perl-Time-HiRes perl-ExtUtils-CBuilder perl-ExtUtils-MakeMaker perl-CPAN -y
[[email protected] ~]# rpm -ivh mha4mysql-manager-0.55-0.el6.noarch.rpm
[[email protected] ~]# ll /usr/bin/mast*
MHA高可用
接下来是搭建主从复制：
主的服务器
[[email protected] ~]# yum -y install mariadb mariadb-server
[[email protected] ~]# systemctl start mariadb
[[email protected] ~]# mysqladmin -uroot password “123456”
[[email protected] ~]# mysql -uroot -p123456
MariaDB [(none)]> grant replication slave on . to r[email protected]‘192.168.137.%’ identified by ‘123456’;
MariaDB [(none)]> flush privileges;
MariaDB [(none)]> create database HA;
MariaDB [(none)]> use HA;
MariaDB [HA]> create table test(id int,name varchar(20));
MariaDB [(none)]> exit

[[email protected] ~]# vim /etc/my.cnf
在 [ mysqld ] 里面添加
server-id=11
log-bin=master-bin
log-slave-updates=true
[[email protected] ~]# systemctl restart mariadb

从1的服务器
[[email protected] ~]# systemctl start mariadb
[[email protected] ~]# mysqladmin -uroot password “123456”
[[email protected] ~]# mysql -uroot -p123456
MariaDB [(none)]> grant replication slave on . to [email protected]‘192.168.137.%’ identified by ‘123456’;
MariaDB [(none)]> flush privileges;
MariaDB [(none)]> create database HA;
MariaDB [(none)]> use HA;
MariaDB [HA]> create table test(id int,name varchar(20));
MariaDB [(none)]> exit

[[email protected] ~]# vim /etc/my.cnf
在 [ mysqld ] 里面添加
server-id = 22
log-bin=slave1-bin
relay-log=relay-log-bin
relay-log-index=slave-relay-bin.index
[[email protected] ~]# systemctl restart mariadb
[[email protected] ~]# mysql -uroot -p123456
MariaDB [(none)]> stop slave;
MariaDB [(none)]>change master to master_host=‘192.168.137.102’,master_user=‘repl’,master_password=‘123456’;
MariaDB [(none)]> start slave;
MariaDB [(none)]> show slave status \G

从2服务器
从1的服务器
[[email protected] ~]# systemctl start mariadb
[[email protected] ~]# mysqladmin -uroot password “123456”
[[email protected] ~]# mysql -uroot -p123456
MariaDB [(none)]> grant replication slave on . to [email protected]‘192.168.10.%’ identified by ‘123456’;
MariaDB [(none)]> flush privileges;
MariaDB [(none)]> create database HA;
MariaDB [(none)]> use HA;
MariaDB [HA]> create table test(id int,name varchar(20));
MariaDB [(none)]> exit

[[email protected] ~]# vim /etc/my.cnf
在 [ mysqld ] 里面添加
server-id = 33
log-bin=slave2-bin
relay-log=relay-log-bin
relay-log-index=slave-relay-bin.index
[[email protected] ~]# systemctl restart mariadb
[[email protected] ~]# mysql -uroot -p123456
MariaDB [(none)]> stop slave;
MariaDB [(none)]>change master to master_host=‘192.168.137.102’,master_user=‘repl’,master_password=‘123456’;
MariaDB [(none)]> start slave;
MariaDB [(none)]> show slave status \G \两个上面都执行一边
MHA高可用
两台slave服务器设置read_only（从库对外提供读服务，只所以没有写进配置文件，是因为slave随时会提升为master）
[[email protected] ~]# mysql -uroot -p123456 -e ‘set global read_only=1’
[[email protected] ~]# mysql -uroot -p123456 -e ‘set global read_only=1’

创建监控用户（在主从上都执行）
MariaDB [(none)]> grant all privileges on . to ‘root’@‘192.168.137.%’ identified by ‘123456’;
MariaDB [(none)]> flush privileges;

配置MHA
[[email protected] ~]# mkdir -p /etc/masterha
[[email protected] ~]# mkdir -p /var/log/masterha/app1
[[email protected] ~]# mkdir -p /data/mysql
[[email protected] ~]# vim /etc/masterha/app1.cnf
[server default]
manager_workdir=/var/log/masterha/app1 //设置manager的工作目录
manager_log=/var/log/masterha/app1/manager.log //设置manager的日志
user=root // 设置监控用户root
password=123456 // 设置监控用户root密码
ping_interval=1 //设置监控主库，发送ping包的时间间隔，默认是3秒，尝试三次没有回应的时候自动进行railover
repl_user= repl //设置复制环境中的复制用户名
repl_password=123456 //设置复制环境中的复制用户名密码
ssh_user=root //设置ssh的登录用户名

#下面的是后端主从服务器的节点
[server1]
hostname=192.168.137.102
port=3306

[server2]
hostname=192.168.137.103
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.137.104
port=3306

设置relay log的清除方式（在每个slave节点上）：
[[email protected] ~]# mysql -uroot -p123456 -e ‘set global relay_log_purge=0’
[[email protected] ~]# mysql -uroot -p123456 -e ‘set global relay_log_purge=0’
注意：

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

检查SSH配置
MHA高可用
[[email protected] ~]# masterha_check_ssh --conf=/etc/masterha/app1.cnf

都是OK代表正确

检查整个复制环境状况。

[[email protected] ~]# masterha_check_repl --conf=/etc/masterha/app1.cnf
MHA高可用
开启MHA Manager监控

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

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

查看MHA Manager监控是否正常：

[[email protected] ~]# masterha_check_status --conf=/etc/masterha/app1.cnf
app1 (pid:57512) is running(0:PING_OK), master:192.168.137.102
注意：如果正常，会显示"PING_OK"，否则会显示"NOT_RUNNING"，这代表MHA监控没有开启。 Master：后面IP是主的服务器

接下来是检查是否成功
第一步关掉主的mysql
[[email protected] ~]# systemctl stop mariadb
等待三十秒再去看看主的变成了谁
在slave2 上面查看
[[email protected] ~]# mysql -uroot -p123456
MariaDB [(none)]> show slave status \G

MHA高可用
实验完成

相关推荐