基于 MHA 的MySQL高可用-CentOS7(理论)

MHA 简介

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

MHA 由两部分组成:MHA Manager(管理节点)和 MHA Node(数据节点)。MHA Manager 可以单独部署在一台独立的机器上管理多个 master-slave 集群,也可以部署在一台 slave 节 点上。MHA Node 运行在每台 MySQL 服务器及 Manager 服务器上,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 快速搭建 我们自己使用其实也可以使用 1 主 1 从,但是 master 主机宕机后无法切换,以及无法补全 binlog。master 的 mysqld 进程 crash 后,还是可以切换成功,以及补全 binlog 的。

官方介绍:https://code.google.com/p/mysql-master-ha/

工作流程

(1)从宕机崩溃的 master 上尝试保存二进制日志事件(binlog events);

(2)识别含有最新更新的 slave 服务器;

(3)应用差异的中继日志(relay log)到其他的 slave;

(4)应用从 master 保存的二进制日志事件(binlog events);

(5)提升一个 slave 为新的 master 服务器;

(6)将其他的 slave 连接指向新的 master 进行主从复制;

MHA 工具介绍

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 的半同步复制。关于半同步复制原理各位自己进行查阅。(不是必须)

MHA 环境说明
所有操作系统均为 centos 7.x 64bit,涉及到主从复制环境搭建后面会简单演示步骤,但 是相关的安全复制不会详细说明,MySQL Replication 需要注意的问题:

角色 IP地址 主机名 ServerID 数据库类型
Primary Master 192.168.200.111 server01 1
Secondary Master 192.168.200.112 server02 2
Slave1 192.168.200.113 server03 3
Slave2 192.168.200.114 server04 4
Manager 192.168.200.115 server05 - 监控复制组

其中 Primary Master 对外提供写服务,备选 Secondary Master(实际的 slave 提供读服务, slave1和slave2也提供相关的读服务,一旦Primary Master宕机,将会把备选Secondary Master 提升为新的 Primary Master,slave1 和 slave2 指向新的 master。

原文地址:https://www.cnblogs.com/2567xl/p/11720114.html

时间: 2024-08-27 18:41:01

基于 MHA 的MySQL高可用-CentOS7(理论)的相关文章

基于 MHA 的MySQL高可用-CentOS7(实例)

环境部署 角色 IP地址 主机名 ServerID 数据库类型 Primary Master 192.168.200.111 server01 1 写 Secondary Master 192.168.200.112 server02 2 写 Slave1 192.168.200.113 server03 3 读 Slave2 192.168.200.114 server04 4 读 Manager 192.168.200.115 server05 - 监控复制组 配置所有主机名称 master

keepalived结合MHA实现mysql高可用

本例结合本博另一篇文章 MHA-大杀器实现MYSQL单主宕机时,VIP漂移实现高可用,环境请参考上一篇文章 本例使用keepalived-1.1.20.tar.gz版本 [[email protected] keepalived-1.1.20]# ./configure --sysconf=/etc/ #此项表示设置keepalived的根目录 如果编译报错"configure: error: Popt libraries is required" 则yum -y install po

基于Keepalived实现Mysql高可用

前言 由于最近要使用Mysql数据库,而目前公司服务器与业务有限,于是只使用了一台Mysql.所以,问题很明显,如果这台Mysql坏了,那么将会影响整个公司的业务,所以考虑做Mysql的高可用方案.目前,Mysql的高可用方案很多,这里选择Keepalived+Mysql实现高可用. 环境介绍 ID OS IP Role node1 CentOS6.5_X64 192.168.1.159 Master node2 CentOS6.5_X64 192.168.1.160 Slave  Mysql

基于heartbeat v2 crm实现基于nfs的mysql高可用集群

前言 因heartbeat v1内置的资源管理器haresource功能比较简单,且不支持图形化管理,所以heartbeat v2不再支持haresource,转而使用更加强大的资源管理器crm进行集群管理.本文将讲解如何基于heartbeat v2 crm实现基于nfs的mysql高可用集群. 高可用实现 实验拓扑 实验环境 node1:172.16.10.123 mariadb-5.5.36 CentOS6.6 node2:172.16.10.124 mariadb-5.5.36 CentO

【视频分享】基于MyCat的MySQL高可用读写分离集群

# [视频分享]基于MyCat的MySQL高可用读写分离集群 ## 获取方式 **方式一:****链接:**[百度网盘](https://pan.baidu.com/s/137KFcoCE-i75vA8FE_OYFQ)==关注公众号极客萧(xiaoyxyj),并且回复关键字:mycat 即可获取下载链接和提取码(注意大小写别错)====如果链接失效,请及时联系我== 原文地址:https://www.cnblogs.com/icefirebug/p/11784738.html

基于PXC的MySQL高可用环境简单部署

PXC简介 Percona XtraDB Cluster(简称PXC集群)提供了MySQL高可用的一种实现方法. 1.集群是有节点组成的,推荐配置至少3个节点,但是也可以运行在2个节点上. 2.每个节点都是普通的mysql/percona服务器,可以将现有的数据库服务器组成集群,反之,也可以将集群拆分成单独的服务器. 3.每个节点都包含完整的数据副本. PXC集群主要由两部分组成:Percona Server with XtraDB和Write Set Replication patches(使

构建MHA实现MySQL高可用集群架构

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

heartbeat v2配置高可用web集群和基于nfs搭建MySQL高可用集群

安装环境:Centos 6.4, httpd2.4,mysql5.5,heartbeat v2 提供两台机器node1和node2,在/etc/hosts文件中添加名称解析,并且主机名称要与节点名称要相同,即uname -n的名称要和hosts定义的名称必须一样. #   IP                         HOSTNAME             ALIAS 10.204.80.79     node1.mylinux.com     node1 10.204.80.80  

基于Keepalived的MySQL高可用

keepalived负责的是故障转移,至于故障转以后的节点之间数据的一致性问题依赖于具体的复制模式.不管是主从.一主多从还是双主.集群节点个数.主从具体的模式无关(常规复制,半同步复制,GTID复制,多线程复制,甚至可以是MGR)都没有直接的关系.个人认为,MySQL高可用方向,MGR+自动故障转移中间件(keepalived),应该是是个趋势.怎么感觉MHA的配置又臭又长. keepalive的安装 1,参考http://blog.51cto.com/afterdawn/1888682 1.官