MySQL架构之MHA架构实战

一、MHA原理

1、简介：

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已经支持一主一从。

我们自己使用其实也可以使用1主1从，但是master主机宕机后无法切换，以及无法补全binlog。master的mysqld进程crash后，还是可以切换成功，以及补全binlog的。

（1）从宕机崩溃的master保存二进制日志事件（binlog events）;

（2）识别含有最新更新的slave；

（3）应用差异的中继日志（relay log）到其他的slave；

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

（5）提升一个slave为新的master；

（6）使其他的slave连接新的master进行复制；

2、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线程）

二、环境准备

主机 ip 描述 系统
linux-node1 192.168.56.11 master以及MHA管理节点 centos 7.4
linux-node2 192.168.56.12 slave节点 centos 7.4
linux-node3 192.168.56.13 slave节点 centos 7.4

三、MHA部署实战

1、安装依赖

[[email protected] ~]# yum install -y perl-DBD-MySQL
[[email protected] ~]#  yum install -y perl-Config-Tiny perl-Log-Dispatch perl-Parallel-ForkManager
[[email protected] ~]# yum install -y perl-DBD-MySQL
[[email protected] ~]# yum install -y perl-DBD-MySQL
#如果无法安装，需要安装epel源：yum install -y epel-release

2、安装软件

[[email protected] ~]# rpm -ivh mha4mysql-node-0.56-0.el6.noarch.rpm
准备中...                          ################################# [100%]
正在升级/安装...
   1:mha4mysql-node-0.56-0.el6        ################################# [100%]
[[email protected] ~]# rpm -ivh mha4mysql-node-0.56-0.el6.noarch.rpm
准备中...                          ################################# [100%]
正在升级/安装...
   1:mha4mysql-node-0.56-0.el6        ################################# [100%]

[[email protected] ~]# rpm -ivh mha4mysql-node-0.56-0.el6.noarch.rpm
Preparing...                          ################################# [100%]
Updating / installing...
   1:mha4mysql-node-0.56-0.el6        ################################# [100%]

3、修改/etc/my.cnf

修改服务节点my.cnf，这里做临时配置，最终生效要配置到my.cnf
MySQL [(none)]> set global relay_log_purge=0;
Query OK, 0 rows affected (0.04 sec)

MySQL [(none)]> grant all privileges on *.* to [email protected]‘192.168.56.%‘ identified by ‘123456‘;
Query OK, 0 rows affected, 1 warning (0.04 sec)

MySQL [(none)]> flush privileges;
Query OK, 0 rows affected (0.03 sec)

配置如下：
[client]
port        = 3306
socket      = /data/mysql/mysql.sock

[mysql]
no-auto-rehash

[mysqld]
user = mysql
port        = 3306
socket      = /data/mysql/mysql.sock
datadir     = /data/mysql/data
log-bin = /data/mysql/mysql-bin
server-id = 6
#skip-grant-tables
relay_log_purge=0

4、管理节点配置MHA

[[email protected] ~]# mkdir /etc/mha
[[email protected] ~]# mkdir /var/log/mha/app1 -p
[[email protected] ~]# vim /etc/mha/app1.cnf
[server default]
manager_log=/var/log/mha/app1/manager.log   #设置manager的日志
manager_workdir=/var/log/mha/app1.log       #设置manager的工作目录
master_binlog_dir=/data/mysql/data          #设置master 保存binlog的位置，以便MHA可以找到master的日志
user=mha                                    #设置监控用户mha
password=123456     #设置mysql中root用户的密码，这个密码是前文中创建监控用户的那个密码
ping_interval=2         #设置监控主库，发送ping包的时间间隔，默认是3秒，尝试三次没有回应的时候自动进行railover
repl_password=123456    #设置复制用户的密码
repl_user=rep                   #设置复制环境中的复制用户名
ssh_user=root                  #设置ssh的登录用户名

[server1]
hostname=192.168.56.11
port=3306

[server2]
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
hostname=192.168.56.12
port=3306

[server3]
hostname=192.168.56.13
port=3306

5、配置SSH登录

[[email protected] ~]# ssh-keygen -t rsa

ssh-copy-id -i .ssh/id_rsa.pub [email protected]
ssh-copy-id -i .ssh/id_rsa.pub [email protected]
ssh-copy-id -i .ssh/id_rsa.pub [email protected]

[[email protected] ~]# ssh 192.168.56.12
Last login: Tue Jan  9 17:03:24 2018 from 192.168.56.1
[[email protected] ~]# logout
Connection to 192.168.56.12 closed.
[[email protected] ~]# ssh 192.168.56.13
Last login: Tue Jan  9 21:25:59 2018 from 192.168.56.1
[[email protected] ~]# logout
Connection to 192.168.56.13 closed.
[[email protected] ~]# ssh 192.168.56.11
Last failed login: Wed Jan 10 17:08:07 CST 2018 from linux-node2 on ssh:notty
There were 3 failed login attempts since the last successful login.
Last login: Sat Jan  6 08:52:06 2018 from 192.168.56.1
[[email protected] ~]# logout
Connection to 192.168.56.11 closed.

6、检查SSH登录

[[email protected] ~]# masterha_check_ssh --conf=/etc/mha/app1.cnf
Wed Jan 10 17:11:00 2018 - [warning] Global configuration file /etc/masterha_default.cnf not found. Skipping.
Wed Jan 10 17:11:00 2018 - [info] Reading application default configuration from /etc/mha/app1.cnf..
Wed Jan 10 17:11:00 2018 - [info] Reading server configuration from /etc/mha/app1.cnf..
Wed Jan 10 17:11:00 2018 - [info] Starting SSH connection tests..
Wed Jan 10 17:11:03 2018 - [debug]
Wed Jan 10 17:11:00 2018 - [debug]  Connecting via SSH from [email protected](192.168.56.11:22) to [email protected](192.168.56.12:22)..
Wed Jan 10 17:11:01 2018 - [debug]   ok.
Wed Jan 10 17:11:01 2018 - [debug]  Connecting via SSH from [email protected](192.168.56.11:22) to [email protected](192.168.56.13:22)..
Wed Jan 10 17:11:02 2018 - [debug]   ok.
Wed Jan 10 17:11:03 2018 - [debug]
Wed Jan 10 17:11:01 2018 - [debug]  Connecting via SSH from [email protected](192.168.56.12:22) to [email protected](192.168.56.11:22)..
Wed Jan 10 17:11:02 2018 - [debug]   ok.
Wed Jan 10 17:11:02 2018 - [debug]  Connecting via SSH from [email protected](192.168.56.12:22) to [email protected](192.168.56.13:22)..
Wed Jan 10 17:11:02 2018 - [debug]   ok.
Wed Jan 10 17:11:03 2018 - [debug]
Wed Jan 10 17:11:02 2018 - [debug]  Connecting via SSH from [email protected](192.168.56.13:22) to [email protected](192.168.56.11:22)..
Wed Jan 10 17:11:02 2018 - [debug]   ok.
Wed Jan 10 17:11:02 2018 - [debug]  Connecting via SSH from [email protected](192.168.56.13:22) to [email protected](192.168.56.12:22)..
Wed Jan 10 17:11:03 2018 - [debug]   ok.
Wed Jan 10 17:11:03 2018 - [info] All SSH connection tests passed successfully.

7、检查mysql replication是否配置成功

[[email protected] ~]# ln -s /usr/local/mysql/bin/mysql /usr/bin/mysql
[[email protected] ~]# ln -s /usr/local/mysql/bin/mysqlbinlog /usr/bin/mysqlbinlog
#必须要做软连接，或者添加到PATH环境变量，否则会报错
[email protected] ~]# masterha_check_repl --conf=/etc/mha/app1.cnf
MySQL Replication Health is OK.

8、启动监控

[[email protected] ~]# nohup masterha_manager --conf=/etc/mha/app1.cnf --remove_dead_master < /dev/null > /var/log/mha/app1/manager.log 2>&1 &
[1] 20640
[[email protected] ~]# masterha_check_status --conf=/etc/mha/app1.cnf
app1 monitoring program is now on initialization phase(10:INITIALIZING_MONITOR). Wait for a while and try checking again.

9、测试

（1）停止主库
[[email protected] ~]# /etc/init.d/mysqld stop
Shutting down MySQL............ SUCCESS! 

（2）登录从库查看，node2变成了主库，node3的主库ip变成了192.168.56.12
[[email protected] ~]# mysql -uroot -p123456
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MySQL connection id is 24
Server version: 5.7.18-log MySQL Community Server (GPL)

Copyright (c) 2000, 2017, Oracle, MariaDB Corporation Ab and others.

Type ‘help;‘ or ‘\h‘ for help. Type ‘\c‘ to clear the current input statement.

MySQL [(none)]> show master status;
+------------------+----------+--------------+------------------+-------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+----------+--------------+------------------+-------------------+
| mysql-bin.000005 |      154 |              |                  |                   |
+------------------+----------+--------------+------------------+-------------------+
1 row in set (0.00 sec)

[[email protected] ~]# mysql -uroot -p123456
mysql> show slave status\G
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 192.168.56.12
                  Master_User: rep
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mysql-bin.000005
          Read_Master_Log_Pos: 154
               Relay_Log_File: linux-node3-relay-bin.000002
                Relay_Log_Pos: 320
        Relay_Master_Log_File: mysql-bin.000005
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes

原文地址：http://blog.51cto.com/jinlong/2059608

时间： 2024-08-30 04:23:16

MySQL架构之MHA架构实战的相关文章

mysql高可用MHA架构搭建

前言:首先介绍一下mha,引用自网络. MHA(Master High Availability)目前在MySQL高可用方面是一个相对成熟的解决方案. 该软件由两部分组成:MHA Manager(管理节点)和MHA Node(数据节点).MHA Manager可以单独部署在一台独立的机器上管理多个master-slave集群,也可以部署在一台slave节点上.MHA Node运行在每台MySQL服务器上,MHA Manager会定时探测集群中的master节点,当master出现故障时,它可以自

mysql复制(高可用架构方案的基础)

mysql复制:把一个数据库实例上所有改变复制到另外一个数据库库服务器实例的过程特点:1.没有改变就无所谓复制 ;改变是复制的根本与数据源2.所有的改变:是指可以复制全部改变,也可以复制部分改变 可以在全部改变中根据业务需求选择部分库和部分表的复制复制的场景: 1.数据库容灾 2.需求:创建一个从数据服务器,做数据的测试和分析 3.负载均衡 4.复制时高可用架构方案的基础 mysql高可用架构特点1.数据库故障的检测与排除2.主从数据库的切换3.数据的备份和保护 mysql高可用架构常用方案1.

企业中MySQL主流高可用架构实战三部曲之MHA

老张最近两天有些忙,一些老铁一直问,啥时更新博文,我可能做不到天天更新啊,但保证以后一有空就写一些干货知识分享给大家. 我们如果想要做好技术这项工作,一定要做到理论与实践先结合.我一个曾经被数据库虐得体无完肤的过来人给大家一些建议:就是只看书,背理论真的行不通,到时遇到棘手的问题,你还是一样抓瞎.一定要在理论理清的基础上多做实验. 给自己定个目标,3个月做够100-500个实验.然后整理在做实验过程中的各种报错,认真解读分析报错原理,做好笔记.最后再拿起书,重新阅读之前有些可能理解不了的理论知识

MHA架构概述及实战

MySQL MHA架构介绍: MHA(Master High Availability)目前在MySQL高可用方面是一个相对成熟的解决方案,它由日本DeNA公司youshimaton(现就职于Facebook公司)开发,是一套优秀的作为MySQL高可用性环境下故障切换和主从提升的高可用软件.在MySQL故障切换过程中,MHA能做到在0~30秒之内自动完成数据库的故障切换操作,并且在进行故障切换的过程中,MHA能在最大程度上保证数据的一致性,以达到真正意义上的高可用. 该软件由两部分组成:MHA

mysql高可用研究之主从+MHA架构

最近在研究mysql的高可用架构,自己想总结下常用的高可用方案都有哪些.有哪些优缺点以及应用的场景?搞得是头昏脑涨,天昏地暗,看了诸多资料,每次都觉得公说公有理婆说婆有理.其实嘛,大家都没有说错,只不过适合自己的才是最正确的选择.今天就从比较常用的主从+MHA说起. 学习一种新的架构还是软件,最好还是先从了解它的原理开始,这样才能在做实验时测试出它的优势和弱势. ###################################################################

MySQL之高可用架构—MHA

MySQL高可用目前有heartbeat+drbd.MHA.MySQL复制等几种较成熟的方案,heartbeat+drbd的方案可扩展性较差,而且读写都由主服务器负责,从库并不提供读功能,适合于数据增长量不大.一致性要求很高的环境,如银行.金融业等.今天重点讲下MHA的高可用架构. MHA是一款优秀的高可用环境下故障切换和主从提升的高可用软件.在MySQL故障切换过程中,MHA能做到0-30秒之内自动完成数据库的故障切换,并且在切换的过程中,最大限度的保证数据的一致性,以达到真正意义上的高可用.

mysql高可用集群——MHA架构

目录 1.下载 2.搭建mha 2.1 系统配置 2.2 架构 2.3 添加ssh公钥信任 2.4 安装mha节点 2.5 manager配置文件 2.6 检查 2.7 启动manager进程 2.8 碰到的问题 3.测试切换 3.1 正常切换测试 3.2 回切测试 3.3 雪崩测试 3.4 主从不一致切换测试 下载 mha链接地址:http://pan.baidu.com/s/1pJkDGX9#dir/path=%2Fmysql%2FHA%2Fmha 或者:https://code.googl

CENTOS6.6 下mysql MHA架构搭建

本文来自我的github pages博客http://galengao.github.io/ 即www.gaohuirong.cn 摘要: 本篇是自己搭建的一篇mysql MHA文章 前面的安装步骤基本不变,后面的比如keepalived的配置文件有几种方法 其实想完成keepalived+lvs+atlas(mycat)+mha+mysql主从复制 这样的架构,只是MYCAT单独文章了 每个节点都关闭防火墙,SELINUX. 1.安装epel yum源 wget http://mirrors.

MySQL高可用架构之MHA （未完，待续）

MySQL高可用架构之MHA 简介: MHA(Master High Availability)目前在MySQL高可用方面是一个相对成熟的解决方案,它由日本DeNA公司youshimaton(现就职于Facebook公司)开发,是一套优秀的作为MySQL高可用性环境下故障切换和主从提升的高可用软件.在MySQL故障切换过程中,MHA能做到在0~30秒之内自动完成数据库的故障切换操作,并且在进行故障切换的过程中,MHA能在最大程度上保证数据的一致性,以达到真正意义上的高可用. 该软件由两部分组成: