首页 / MYSQL / Spring - MySql实现高可用架构之MHA

Spring - MySql实现高可用架构之MHA

内容导读

互联网集市收集整理的这篇技术教程文章主要介绍了Spring - MySql实现高可用架构之MHA，小编现在分享给大家，供广大互联网技能从业者学习和参考。文章包含13518字，纯文字阅读大概需要20分钟。

内容图文

一、简介

　　MHA（Master HA）是一款开源的 MySQL 的高可用程序，它为 MySQL 主从复制架构提供了 automating master failover 功能。MHA 在监控到 master 节点故障时，会提升其中拥有最新数据的 slave 节点成为新的master 节点，在此期间，MHA 会通过于其它从节点获取额外信息来避免一致性方面的问题。MHA 还提供了 master 节点的在线切换功能，即按需切换 master/slave 节点。
　　MHA 是由日本人 yoshinorim（原就职于DeNA现就职于FaceBook）开发的比较成熟的 MySQL 高可用方案。MHA 能够在30秒内实现故障切换，并能在故障切换中，最大可能的保证数据一致性。目前淘宝也正在开发相似产品 TMHA，目前已支持一主一从。

二、MHA 服务

2.1 服务角色

　　MHA 服务有两种角色， MHA Manager(管理节点)和 MHA Node(数据节点)：
MHA Manager：
　　通常单独部署在一台独立机器上管理多个 master/slave 集群(组)，每个 master/slave 集群称作一个 application，用来管理统筹整个集群。
MHA node：
　　运行在每台 MySQL 服务器上(master/slave/manager)，它通过监控具备解析和清理 logs 功能的脚本来加快故障转移。
　　主要是接收管理节点所发出指令的代理，代理需要运行在每一个 mysql 节点上。简单讲 node 就是用来收集从节点服务器上所生成的 bin-log 。对比打算提升为新的主节点之上的从节点的是否拥有并完成操作，如果没有发给新主节点在本地应用后提升为主节点。
Spring - MySql实现高可用架构之MHA - 文章图片
　　由上图我们可以看出，每个复制组内部和 Manager 之间都需要ssh实现无密码互连，只有这样，在 Master 出故障时， Manager 才能顺利的连接进去，实现主从切换功能。

2.2提供的工具

　　MHA会提供诸多工具程序，其常见的如下所示：
Manager节点：
　　masterha_check_ssh：MHA 依赖的 ssh 环境监测工具；
　　masterha_check_repl：MYSQL 复制环境检测工具；
　　masterga_manager：MHA 服务主程序；
　　masterha_check_status：MHA 运行状态探测工具；
　　masterha_master_monitor：MYSQL master 节点可用性监测工具；
　　masterha_master_swith:master：节点切换工具；
　　masterha_conf_host：添加或删除配置的节点；
　　masterha_stop：关闭 MHA 服务的工具。
Node节点：（这些工具通常由MHA Manager的脚本触发，无需人为操作）
　　save_binary_logs：保存和复制 master 的二进制日志；
　　apply_diff_relay_logs：识别差异的中继日志事件并应用于其他 slave；
　　purge_relay_logs：清除中继日志（不会阻塞 SQL 线程）；
　　自定义扩展：
　　secondary_check_script：通过多条网络路由检测master的可用性；
　　master_ip_failover_script：更新application使用的masterip；
　　report_script：发送报告;
　　init_conf_load_script：加载初始配置参数；
　　master_ip_online_change_script;更新master节点ip地址。

2.3工作原理

Spring - MySql实现高可用架构之MHA - 文章图片
MHA工作原理总结为以下几条：
（1）从宕机崩溃的 master 保存二进制日志事件（binlog events）；
（2）识别含有最新更新的 slave ；
（3）应用差异的中继日志(relay log) 到其他 slave ；
（4）应用从 master 保存的二进制日志事件(binlog events)；
（5）提升一个 slave 为新 master ；
（6）使用其他的 slave 连接新的 master 进行复制。

三、实现过程

3.1 准备实验 Mysql 的 Replication 环境

3.1.1 相关配置

　　MHA 对 MYSQL 复制环境有特殊要求，例如各节点都要开启二进制日志及中继日志，各从节点必须显示启用其read-only属性，并关闭relay_log_purge功能等，这里对配置做事先说明。
　　本实验环境共有四个节点，其角色分配如下（实验机器均为centos 7.3）：
Spring - MySql实现高可用架构之MHA - 文章图片

　　为了方便我们后期的操作，我们在各节点的/etc/hosts文件配置内容中添加如下内容：

192.168.37.111 node1.keer.com node1
192.168.37.122 node2.keer.com node2
192.168.37.133 node3.keer.com node3
192.168.37.144 node4.keer.com node4

Spring - MySql实现高可用架构之MHA - 文章图片

这样的话，我们就可以通过 host 解析节点来打通私钥访问，会方便很多。
　　本步骤完成。

3.1.2 初始主节点 master 的配置

　　我们需要修改 master 的数据库配置文件来对其进行初始化配置：

[root@master ~]# vim /etc/my.cnf
	[mysqld]
	server-id = 1				//复制集群中的各节点的id均必须唯一
	log-bin = master-log		//开启二进制日志
	relay-log = relay-log		//开启中继日志
	skip_name_resolve			//关闭名称解析（非必须）
[root@master ~]# systemctl restart mariadb

Spring - MySql实现高可用架构之MHA - 文章图片

本步骤完成。

3.1.3 所有 slave 节点依赖的配置

　　我们修改两个 slave 的数据库配置文件，两台机器都做如下操作：

[root@slave1 ~]# vim /etc/my.cnf
	[mysqld]
	server-id = 2 				//复制集群中的各节点的id均必须唯一；
	relay-log = relay-log		//开启中继日志
	log-bin = master-log		//开启二进制日志
	read_only = ON				//启用只读属性
	relay_log_purge = 0			//是否自动清空不再需要中继日志
	skip_name_resolve			//关闭名称解析（非必须）
	log_slave_updates = 1       //使得更新的数据写进二进制日志中
[root@slave1 ~]# systemctl restart mariadb

[root@slave2 ~]# vim /etc/my.cnf
	[mysqld]
	server-id = 3 				//复制集群中的各节点的id均必须唯一；
	relay-log = relay-log		//开启中继日志
	log-bin = master-log		//开启二进制日志
	read_only = ON				//启用只读属性
	relay_log_purge = 0			//是否自动清空不再需要中继日志
	skip_name_resolve			//关闭名称解析（非必须）
	log_slave_updates = 1       //使得更新的数据写进二进制日志中
[root@slave2 ~]# systemctl restart mariadb

本步骤完成。

3.1.4 配置一主多从复制架构

　　下面只会给出命令，具体的知识及过程详解见我的上一篇博客——实战项目——mysql主从架构的实现。
master 节点上：

MariaDB [(none)]>grant replication slave,replication client on *.* to 'slave'@'192.168.%.%' identified by 'keer';
MariaDB [(none)]> show master status;

slave 节点上：

MariaDB [(none)]> change master to master_host='192.168.37.122', 
    -> master_user='slave', 
    -> master_password='keer',
    -> master_log_file='mysql-bin.000001',
    -> master_log_pos=415;
MariaDB [(none)]> start slave;
MariaDB [(none)]> show slave status\G;

本步骤完成。

3.2 安装配置MHA

3.2.1 在 master 上进行授权

　　在所有 Mysql 节点授权拥有管理权限的用户可在本地网络中有其他节点上远程访问。当然，此时仅需要且只能在 master 节点运行类似如下 SQL 语句即可。

MariaDB [(none)]> grant all on *.* to 'mhaadmin'@'192.168.%.%' identified by 'mhapass';

3.2.2 准备 ssh 互通环境

　　MHA集群中的各节点彼此之间均需要基于ssh互信通信，以实现远程控制及数据管理功能。简单起见，可在Manager节点生成密钥对儿，并设置其可远程连接本地主机后，将私钥文件及authorized_keys文件复制给余下的所有节点即可。
　　下面操作在所有节点上操作：

[root@manager ~]# ssh-keygen -t rsa
[root@manager ~]# ssh-copy-id -i .ssh/id_rsa.pub root@node1

Spring - MySql实现高可用架构之MHA - 文章图片

当四台机器都进行了上述操作以后，我们可以在 manager 机器上看到如下文件：

[root@manager ~]# cd .ssh/
[root@manager .ssh]# ls
authorized_keys  id_rsa  id_rsa.pub  known_hosts
[root@manager .ssh]# cat authorized_keys

Spring - MySql实现高可用架构之MHA - 文章图片

　四台机器的公钥都已经在authorized_keys这个文件中了，接着，我们只需要把这个文件发送至另外三台机器，这四台机器就可以实现 ssh 无密码互通了：

[root@manager .ssh]# scp authorized_keys root@node2:~/.ssh/
[root@manager .ssh]# scp authorized_keys root@node3:~/.ssh/
[root@manager .ssh]# scp authorized_keys root@node4:~/.ssh/

　当然，我们也可以在机器上实验一下，看看 ssh 是否还需要输入密码。

3.2.3 安装 MHA 包

　　在本步骤中， Manager节点需要另外多安装一个包。具体需要安装的内容如下：

四个节点都需安装：mha4mysql-node-0.56-0.el6.norch.rpm
Manager 节点另需要安装：mha4mysql-manager-0.56-0.el6.noarch.rpm

需要安装的包我已经上传至百度云盘，密码：mkcr，大家需要的自行下载使用~
　　我们使用rz命令分别上传，然后使用yum安装即可。

[root@manager ~]# rz
[root@manager ~]# ls
anaconda-ks.cfg  initial-setup-ks.cfg                     Pictures
Desktop          mha4mysql-manager-0.56-0.el6.noarch.rpm  Public
Documents        mha4mysql-node-0.56-0.el6.noarch.rpm     Templates
Downloads        Music                                    Videos
[root@manager ~]# yum install -y mha4mysql-node-0.56-0.el6.noarch.rpm 
[root@manager ~]# yum install -y mha4mysql-manager-0.56-0.el6.noarch.rpm

3.2.4 初始化 MHA ，进行配置

Manager 节点需要为每个监控的 master/slave 集群提供一个专用的配置文件，而所有的 master/slave 集群也可共享全局配置。全局配置文件默认为/etc/masterha_default.cnf，其为可选配置。如果仅监控一组 master/slave 集群，也可直接通过 application 的配置来提供各服务器的默认配置信息。而每个 application 的配置文件路径为自定义。具体操作见下一步骤。

3.2.5 定义 MHA 管理配置文件

　　为MHA专门创建一个管理用户，方便以后使用，在mysql的主节点上，三个节点自动同步：

mkdir /etc/mha_master
vim /etc/mha_master/mha.cnf

配置文件内容如下；

[server default] 			//适用于server1,2,3个server的配置
user=mhaadmin 				//mha管理用户
password=mhapass 			//mha管理密码
manager_workdir=/etc/mha_master/app1 		//mha_master自己的工作路径
manager_log=/etc/mha_master/manager.log 	// mha_master自己的日志文件
remote_workdir=/mydata/mha_master/app1		//每个远程主机的工作目录在何处
ssh_user=root 				// 基于ssh的密钥认证
repl_user=slave				//数据库用户名
repl_password=magedu		//数据库密码
ping_interval=1 			//ping间隔时长
[server1] 					//节点2
hostname=192.168.37.133 	//节点2主机地址
ssh_port=22 				//节点2的ssh端口
candidate_master=1 			//将来可不可以成为master候选节点/主节点
[server2]
hostname=192.168.37.133
ssh_port=22
candidate_master=1
[server3]
hostname=192.168.37.144
ssh_port=22
candidate_master=1

3.2.6 对四个节点进行检测

1）检测各节点间 ssh 互信通信配置是否 ok
　　我们在 Manager 机器上输入下述命令来检测：

[root@manager ~]# masterha_check_ssh -conf=/etc/mha_master/mha.cnf

如果最后一行显示为[info]All SSH connection tests passed successfully.则表示成功。

Spring - MySql实现高可用架构之MHA - 文章图片

2）检查管理的MySQL复制集群的连接配置参数是否OK

[root@manager ~]# masterha_check_repl -conf=/etc/mha_master/mha.cnf

Spring - MySql实现高可用架构之MHA - 文章图片

我们发现检测失败，这可能是因为从节点上没有账号，因为这个架构，任何一个从节点，将有可能成为主节点，所以也需要创建账号。
　　因此，我们需要在master节点上再次执行以下操作：

MariaDB [(none)]> grant replication slave,replication client on *.* to 'slave'@'192.168.%.%' identified by 'keer';
MariaDB [(none)]> flush privileges;

执行完这段操作之后，我们再次运行检测命令：

[root@manager ~]# masterha_check_repl -conf=/etc/mha_master/mha.cnf
Thu Nov 23 09:07:08 2017 - [warning] Global configuration file /etc/masterha_default.cnf not found. Skipping.
Thu Nov 23 09:07:08 2017 - [info] Reading application default configuration from /etc/mha_master/mha.cnf..
Thu Nov 23 09:07:08 2017 - [info] Reading server configuration from /etc/mha_master/mha.cnf..
……
MySQL Replication Health is OK.

3.3 启动 MHA

　　我们在 manager 节点上执行以下命令来启动 MHA：

[root@manager ~]# nohup masterha_manager -conf=/etc/mha_master/mha.cnf &> /etc/mha_master/manager.log &
[1] 7598

　启动成功以后，我们来查看一下 master 节点的状态：

[root@manager ~]# masterha_check_status -conf=/etc/mha_master/mha.cnf
mha (pid:7598) is running(0:PING_OK), master:192.168.37.122

上面的信息中“mha (pid:7598) is running(0:PING_OK)”表示MHA服务运行OK，否则，则会显示为类似“mha is stopped(1:NOT_RUNNING).”
　　如果，我们想要停止 MHA ，则需要使用 stop 命令：

[root@manager ~]# masterha_stop -conf=/etc/mha_master/mha.cnf

3.4 测试 MHA 故障转移

3.4.1 在 master 节点关闭 mariadb 服务,模拟主节点数据崩溃

[root@master ~]# killall -9 mysqld mysqld_safe
[root@master ~]# rm -rf /var/lib/mysql/*

3.4.2 在 manger 节点查看日志

　　我们来查看日志：

[root@manager ~]# tail -200 /etc/mha_master/manager.log 
……
Thu Nov 23 09:17:19 2017 - [info] Master failover to 192.168.37.133(192.168.37.133:3306) completed successfully.

表示 manager 检测到192.168.37.122节点故障，而后自动执行故障转移，将192.168.37.133提升为主节点。
　　注意，故障转移完成后， manager将会自动停止，此时使用 masterha_check_status 命令检测将会遇到错误提示，如下所示：

[root@manager ~]# masterha_check_status -conf=/etc/mha_master/mha.cnf
mha is stopped(2:NOT_RUNNING).

3.5 提供新的从节点以修复复制集群

　　原有 master 节点故障后，需要重新准备好一个新的 MySQL 节点。基于来自于master 节点的备份恢复数据后，将其配置为新的 master 的从节点即可。注意，新加入的节点如果为新增节点，其 IP 地址要配置为原来 master 节点的 IP，否则，还需要修改 mha.cnf 中相应的 ip 地址。随后再次启动 manager ，并再次检测其状态。
　　我们就以刚刚关闭的那台主作为新添加的机器，来进行数据库的恢复：
　　原本的 slave1 已经成为了新的主机器，所以，我们对其进行完全备份，而后把备份的数据发送到我们新添加的机器上：

[root@slave1 ~]# mkdir /backup
[root@slave1 ~]# mysqldump --all-database > /backup/mysql-backup-`date +%F-%T`-all.sql
[root@slave1 ~]# scp /backup/mysql-backup-2017-11-23-09\:57\:09-all.sql root@node2:~

然后在 node2 节点上进行数据恢复：

[root@master ~]# mysql < mysql-backup-2017-11-23-09\:57\:09-all.sql

接下来就是配置主从。照例查看一下现在的主的二进制日志和位置，然后就进行如下设置：

MariaDB [(none)]> change master to master_host='192.168.37.133',  master_user='slave',  master_password='keer', master_log_file='mysql-bin.000006', master_log_pos=925;
MariaDB [(none)]> start slave;
MariaDB [(none)]> show slave status\G;
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 192.168.37.133
                  Master_User: slave
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mysql-bin.000006
          Read_Master_Log_Pos: 925
               Relay_Log_File: mysql-relay-bin.000002
                Relay_Log_Pos: 529
        Relay_Master_Log_File: mysql-bin.000006
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes

3.6 新节点提供后再次执行检查操作

　　我们来再次检测状态：

[root@manager ~]# masterha_check_repl -conf=/etc/mha_master/mha.cnf

如果报错，则再次授权（详见上文）。若没有问题，则启动 manager，注意，这次启动要记录日志：

[root@manager ~]# masterha_manager -conf=/etc/mha_master/mha.cnf > /etc/mha_master/manager.log 2>&1 &
[1] 10012

启动成功以后，我们来查看一下 master 节点的状态：

[root@manager ~]# masterha_check_status -conf=/etc/mha_master/mha.cnf
mha (pid:9561) is running(0:PING_OK), master:192.168.37.133

3.7新节点上线，故障转换恢复注意事项

　　1）在生产环境中，当你的主节点挂了后，一定要在从节点上做一个备份，拿着备份文件把主节点手动提升为从节点，并指明从哪一个日志文件的位置开始复制
　　2）每一次自动完成转换后，每一次的(replication health )检测不ok始终都是启动不了必须手动修复主节点，除非你改配置文件
　　3）手动修复主节点提升为从节点后，再次运行检测命令

[root@manager ~]# masterha_check_status -conf=/etc/mha_master/mha.cnf
mha (pid:9561) is running(0:PING_OK), master:192.168.37.133

4）再次运行起来就恢复成功了

[root@manager ~]# masterha_manager --conf=/etc/mha_master/mha.cnf

作者：珂儿吖

出处：http://www.cnblogs.com/keerya/

本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。

内容总结

以上是互联网集市为您收集整理的Spring - MySql实现高可用架构之MHA全部内容，希望文章能够帮你解决Spring - MySql实现高可用架构之MHA所遇到的程序开发问题。如果觉得互联网集市技术教程内容还不错，欢迎将互联网集市网站推荐给程序员好友。

内容备注

版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容，请发送邮件至 gblab@vip.qq.com 举报，一经查实，本站将立刻删除。

内容手机端

扫描二维码推送至手机访问。

本文链接：https://qyyshop.com/info/861784.html

来源：【匿名】

【上一篇】玩转MySQL（一）【下一篇】用IE远程创建Mysql数据库的简易程序

更多 ►

【Spring - MySql实现高可用架构之MHA】教程文章相关的互联网学习教程文章

实现MHA，MySQL高可用集群架构【代码】

MHA：Master HA，对主节点进行监控，可实现自动故障转移至其它从节点；通过提升某一从节点为新的主节点，基于主从复制实现，还需要客户端配合实现，目前MHA主要支持一主多从的架构，要搭建MHA,要求一个复制集群中必须最少有三台数据库服务器，一主二从，即一台充当master，一台充当备用master，另外一台充当从库，如果财大气粗，也可以用一台专门的服务器来当MHA监控管理服务器 MHA工作原理1 从宕机崩溃的master保存二进制日志...

MySQL 部署 MHA 高可用架构 (一)【代码】

MHA 官方网址Manager : https://github.com/yoshinorim/mha4mysql-manager Node : https://github.com/yoshinorim/mha4mysql-nodeMHA 工作原理主库宕机处理过程 1. 监控节点 (通过配置文件获取所有节点信息)系统,网络,SSH连接性主从状态,重点是主库2. 选主 (1) 如果判断从库(position或者GTID),数据有差异,最接近于 Master 的 slave,成为备选主 (2) 如果判断从库(position或者GTID),数据一致,按照配置文件顺序,选主. (3) 如果设定有...

在CentOS7上部署MySQL-MMM高可用群集【代码】【图】

MMM简介 MMM(MySQL主主复制管理器）是一套支持双主故障切换和双主日常管理的脚本程序。主要用来监控和管理MySQL Master-Master（双主）复制，虽然叫双主复制，但是业务上同一时刻只允许对一个主进行写入，另一台备选主上提供部分读服务，以加速在主切换时备选主的预热，可以说MMM这套脚本程序一方面实现了故障切换的功能，另一方面其内部附加的工具脚本也可以实现多个Slave的read负载均衡。MMM时一套灵活的脚本程序，基于perl实现，...

keepalived+amoeba+mysql-mmm+mysql实现mysql读写分离及高可用【代码】【图】

最近尝试了一下mysql的读写分离和高可用的搭建。搭好之后体验了一下，效果还不错。这里跟大家分享一下。1、首先介绍一下mysql-mmm这个工具是干嘛使的？众所周知，mysql自身提供了AB复制。我们也可以很轻松的实现master-master双向复制，同时再为其中的一个master节点搭建一个slave库。这样就实现了master1与master2之间的双向复制，同时master1与slave1之间主从复制这样的架构。这样整个体系中就存在两个master，正常情况下只有...

mysql高可用方案MHA介绍

mysql高可用方案MHA介绍概述 MHA是一位日本MySQL大牛用Perl写的一套MySQL故障切换方案，来保证数据库系统的高可用.在宕机的时间内（通常10—30秒内），完成故障切换，部署MHA，可避免主从一致性问题，节约购买新服务器的费用，不影响服务器性能，易安装，不改变现有部署。还支持在线切换，从当前运行master切换到一个新的master上面，只需要很短的时间（0.5-2秒内），此时仅仅阻塞写操作，并不影响读操作，便于主机硬件维护。...

[ZZ]MySQL高可用解决方案

MySQL高可用解决方案(MySQL HA Solution) 什么是高可用性？很多公司的服务都是24小时*365天不间断的。比如Call Center。这就要求高可用性。再比如购物网站，必须随时都可以交易。那么当购物网的server挂了一个的时候，不能对业务产生任何影响。这就是高可用性。高可用性2个问题：如何共享数据或同步数据？如何处理failover？解释failover，意思就是当服务器down掉，或者出现错误的时候，可以自动的切换到其他待命的服务器，不影...

通过KeepAlived搭建MySQL双主模式的高可用集群系统【图】

企业级MySQL集群具备高可用、可扩展、易管理、低成本的特点。下面将介绍企业环境中经常应用的一个解决方案，即MySQL的双主互备架构，主要设计思路是通过MySQL Replication技术将两台MySQL Server互相将对方作为自己的Master，自己又同时作为对方的Slave来进行复制。这样就实现了高可用构架中的数据同步功能，同时，将采用KeepAlived来实现Mysql的自动failover。在这个构架中，虽然两台MySQL Server互为主从，但同一时刻只有一个MyS...

Mysql 高可用集群 ------ MHA【代码】【图】

文章目录一、MHA 简介二、部署 MHA第一步：三台主从服务器安装 mysql第二步：修改 mysql 的主配置文件：/etc/my.cnf ，注意三个服务器的 server-id 不能一样第三步：三个服务器启动 mysql 服务第四步：配置 Mysql 主从同步（一主两从）第五步：安装 MHA第六步：启动 MHA一、MHA 简介：MHA（Master High Availability）（1）目前在MySQL高可用方面是一个相对成熟的解决方案，它由日本DeNA公司youshimaton（现就职于Facebook公司）开...

MySQL高可用配置【代码】

openstack高可用配置文档介绍利用两台物理主机实现高可用的openstack云平台，这里主要说明mysql和rabbitmq的高可用配置。 l 安装openstack云平台（两台主机上都部署openstack I版）安装centos操作系统，由于以active-passive模式配置mysql等服务的高可用时，需要单独的硬盘分区来装载和同步mysql等服务的数据，所以安装系统时，在系统镜像配置文件里预留出2-3块20G左右单独的硬盘分区作为备用;Yum –y update && reboot系统安装完...

mysql+mha高可用搭建

主库：172.25.254.125备库：172.25.254.225管理节点：172.25.254.126在开始之前，请先配置好服务器间的时间同步和名称解析一:在数据库节点安装mha node[root@dg53 ~]# rpm -ivh epel-release-5-4.noarch.rpm Retrieving epel-release-5-4.noarch.rpm warning: /var/tmp/rpm-xfer.yqwfYT: Header V3 DSA signature: NOKEY, key ID 217521f6 Preparing... ########################################### [100%] ...

mysql实现高可用架构之MHA

mysql实现高可用架构之MHA 一、简介MHA（Master HA）是一款开源的 MySQL 的高可用程序，它为 MySQL 主从复制架构提供了 automatingmaster failover （自动化主故障转移）功能。MHA 在监控到 master 节点故障时，会提升其中拥有最新数据的slave 节点成为新的master 节点，在此期间，MHA 会通过于其它从节点获取额外信息来避免一致性方面的问题。MHA 还提供了 master 节点的在线切换功能，即按需切换 master/slave 节点。 MHA 是由...

MySQL 5.6通过MMM实现读写分离的高可用架构【代码】【图】

上一篇博文我们使用keepalived+主从同步搭建了一个简单的MySQL高可用架构（详见http://blog.51cto.com/jiangjianlong/1981994），今天再分享下通过MMM搭建的实现MySQL读写分离的高可用群集。MMM (Master-Master Replication Manager for MySQL)是使用perl开发的MySQL主主复制管理器，可实现读写分离的高可用架构，对主库实现写请求的高可用，对从库实现读请求的负载均衡。本文的架构示意图如下：一、部署环境二、环境准备1、配置好...

mysql mha高可用架构的安装

MMM无法全然地保证数据的一致性，所以MMM适用于对数据的一致性要求不是非常高。可是又想最大程度的保证业务可用性的场景对于那些对数据一致性要求非常高的业务，非常不建议採用MMM的这样的高可用性架构。那么可以考虑使用MHA。在mysql故障切换的过程中。MHA可以在0-30s内自己主动完毕数据库的故障切换操作，而且MHA可以最大程度上保证数据的一致性，以达到真正意义上的高可用。MHA软件由两部分组成，Manager工具包和Node工具包。详...

docker swarm使用keepalived+haproxy搭建基于percona-xtradb-cluster方案的高可用mysql集群【代码】【图】

一、部署环境序号hostnameip备注1manager10710.0.3.107centos7;3.10.0-957.1.3.el7.x86_642worker6810.0.3.68centos7;3.10.0-957.1.3.el7.x86_643worker8010.0.3.80centos7;3.10.0-957.1.3.el7.x86_64docker版本docker version Client:Version: 18.09.0API version: 1.39Go version: go1.10.4Git commit: 4d60db4Built: Wed Nov 700:48:222018OS/Arch: linux/amd64Experimen...

keepalived + mysqlroute +mysql实现mysql高可用【代码】【图】

一、环境介绍： 1.1服务器角色配置：mysql-master 10.0.0.101(外) 172.168.1.101(内) mysql-slave 10.0.0.103 (外) 172.168.1.103(内) mysql-router01 10.0.0.102 (外) 172.168.1.102(内) mysql-router02 10.0.0.104 (外) 172.168.1.104(内) jumpserver 10.0.0.128 (外) 172.168.1.128(内)1.2配置数据库的一主两从库Slave01 和master都是允许读写的，slave02提供只读同时MySQL的主从复制都是事先配置成功的(此环境是开...

首页 / MYSQL / Spring - MySql实现高可用架构之MHA

Spring - MySql实现高可用架构之MHA

内容导读

内容图文

一、简介

二、MHA 服务

2.1 服务角色

2.2提供的工具

2.3工作原理

三、实现过程

3.1 准备实验 Mysql 的 Replication 环境

3.2 安装配置MHA

3.3 启动 MHA

3.4 测试 MHA 故障转移

3.5 提供新的从节点以修复复制集群

3.6 新节点提供后再次执行检查操作

3.7新节点上线， 故障转换恢复注意事项

内容总结

内容备注

内容手机端

【Spring - MySql实现高可用架构之MHA】教程文章相关的互联网学习教程文章

SPRING - 相关标签

MYSQL - 相关标签

架构 - 相关标签

MYSQL - 技术教程分类

MYSQL - 最新教程

MYSQL - 最热教程

3.7新节点上线，故障转换恢复注意事项