参考文档:

  1. 官方文档:http://mysql-mmm.org/mmm2:guide

本文对mmm方案做简单介绍,并做1个简单的验证。

一.MySQL-MMM方案

1. MMM方案简介

MMM(Multi-Master Replication Manager for MySQL)是一组集监控,故障切换,管理MySQL多主复制的脚本套件,同时具备对读请求进行负载均衡的能力,同时为MySQL提供了良好的读、写分离架构。

注意:

  1. 只有1个节点可响应写请求
  2. 读请求可被负载到多个节点,可减轻主节点的读写压力;
  3. MMM方案在读写非常繁忙的业务系统下可能会出现复制延时、切换失效等问题,并不太适合对数据安全性要求很高,并且读、写繁忙的环境中。

2. MMM套件简介

MMM套件主要功能是通过以下三个脚本实现的:

  1. mmm_mond:监控进程,运行在监控/管理节点上,主要对所有数据库的监控工作,同时决定和处理所有节点的角色切换。
  2. mmm_agentd:代理进程,运行在每台db服务器上,主要完成监控的测试工作和执行简单的远端服务设置。
  3. mmm_control:管理脚本,用来查看和管理集群运行状态,同时管理mmm_mond进程。

二.验证环境

1. 操作系统

CentOS-6.7-x86_64

2. MySQL版本

MySQL版本是5.6.36: https://cdn.mysql.com//Downloads/MySQL-5.6/mysql-5.6.36.tar.gz

3. 拓扑图

  1. 采用VMware ESXi虚拟出的4台服务器master/backup/slave/mmm,地址10.11.4.196/197/198/199;
  2. MySQL主从复制,双主复制等已提前配置完成,参考如下:

    主从复制:http://www.cnblogs.com/netonline/p/7603578.html

    双主复制:http://www.cnblogs.com/netonline/p/7606704.html

  3. 相关规划如下:

Role

Hosts

IP

Attributes

VIP

Description

master1

master

10.11.4.196

write

10.11.4.191

通过VIP进行写操作

master2

backup

10.11.4.197

write | read

10.11.4.192

10.11.4.193

master2在master1无故障时只提供读服务,master1故障时接管写VIP

slave

slave

10.11.4.198

read

monitor

mmm

10.11.4.199

monitor

   

三.配置

1. 操作系统配置hosts

#4台服务器配置相同
[root@master ~]# vim /etc/hosts
10.11.4.196 master
10.11.4.197 backup
10.11.4.198 slave
10.11.4.198 mmm 

2. 创建相关账户

User

Password

Privileges

Description

mmm_monitor

mmm_monitor

REPLICATION CLIENT

监控数据库状态,包括主从延时等

mmm_agent

mmm_agent

SUPER,REPLICATION CLIENT,PROCESS

修改write服务器的read_only状态,重新定向新主库等

repl

repl

REPLICATION SLAVE

主从/主主复制用户(已预配置)

#只需要在3台db服务器创建账户即可,监控服务器不需要
[root@master ~]# mysql -uroot -p
Enter password: mysql> GRANT REPLICATION CLIENT ON *.* TO 'mmm_monitor'@'10.11.4.%' IDENTIFIED BY 'mmm_monitor';
mysql> GRANT SUPER,REPLICATION CLIENT, PROCESS ON *.* TO 'mmm_agent'@'10.11.4.%' IDENTIFIED BY 'mmm_agent';
mysql> flush privileges;

3. 安装MMM

1)3台数据库服务器

#默认的yum源中没有mmm,需要先安装epel;
#数据库服务器只需要安装mysql-mmm-agnet
[root@master ~]# wget http://mirrors.ustc.edu.cn/fedora/epel/6/x86_64/epel-release-6-8.noarch.rpm
[root@master ~]# rpm -ivh epel-release-6-8.noarch.rpm
[root@master ~]# yum -y install mysql-mmm-agent

2)监控服务器

#监控服务器可以安装全部mmm方案组件,实际上只启动mysql-mmm-monitor组件
[root@mmm ~]# wget http://mirrors.ustc.edu.cn/fedora/epel/6/x86_64/epel-release-6-8.noarch.rpm
[root@mmm ~]# rpm -ivh epel-release-6-8.noarch.rpm
[root@mmm ~]# yum -y install mysql-mmm*

3)MMM文件路径说明

Path

Description

/usr/libexec/mysql-mmm/

脚本路径

/usr/share/perl5/vendor_perl/MMM/

MMM的Perl路径

/usr/sbin/

可执行命令

/etc/init.d/

启动服务

/etc/mysql-mmm/

配置文件

/var/log/mysql-mmm/

日志文件

4. 配置文件

1)mmm_common.conf文件

#mmm_common.conf文件,在监控服务器与数据库服务器上都需要配置,且配置一致;
#以下为按规划做的配置
[root@mmm ~]# vim /etc/mysql-mmm/mmm_common.conf
# 积极的master角色的标示,全部db服务器都需要开启read_only参数,监控代理会自动将writer服务器的read_only属性关闭.
active_master_role writer <host default>
# cluster接口
cluster_interface br0
# pid路径
pid_path /var/run/mysql-mmm/mmm_agentd.pid
# 执行文件路径
bin_path /usr/libexec/mysql-mmm/
# 复制用户
replication_user repl
# 复制用户密码
replication_password repl
# 代理用户,用于更改read_only属性等操作
agent_user mmm_agent
# 代理用户密码
agent_password RepAgent
</host> # "host"参数后带角色服务器的host名
<host master>
# 角色服务器的IP地址
ip 10.11.4.196
# 服务器的角色属性
mode master
# 与角色对等属性的服务器的host名,这里指master2,即backup
peer backup
</host> # 双主中的另一台服务器,概念一致
<host backup>
ip 10.11.4.197
mode master
peer master
</host> # 从库的host名,如果有多个从库可重复配置
<host slave>
ip 10.11.4.198
# 服务器角色属性
mode slave
</host> # writer角色配置
<role writer>
# 可进行写操作的服务器的host名;
# 如果不想切换写操作此处可只配置1台服务器,可以避免因为网络延时而进行write的切换,但master出现故障时,MMM就没有writer了,只提供对外的read操作.
hosts master, backup
# 写操作vip
ips 10.11.4.191
# 同时只允许一个主存在,只提供一个写vip
mode exclusive
</role> # reader角色配置
<role reader>
# 可进行读操作的服务器的host名;
hosts backup, slave
# 读操作vip;
# vip与host没有一一对应关系;
# vip与host数目也没有对应关系,vip可以对于host数,此时部分host可分配到多个vip
ips 10.11.4.192, 10.11.4.193
# 负载均衡模式
mode balanced
</role> #同时可以将此配置文件拷贝到其余3台服务器:
[root@mmm ~]# scp /etc/mysql-mmm/mmm_common.conf master:/etc/mysql-mmm/
[root@mmm ~]# scp /etc/mysql-mmm/mmm_common.conf backup:/etc/mysql-mmm/
[root@mmm ~]# scp /etc/mysql-mmm/mmm_common.conf slave:/etc/mysql-mmm/ 

2)mmm_mon.conf文件

#mmm_mon.conf文件,监控服务器文件配置
[root@mmm ~]# vim /etc/mysql-mmm/mmm_mon.conf
include mmm_common.conf <monitor>
ip 127.0.0.1
pid_path /var/run/mysql-mmm/mmm_mond.pid
bin_path /usr/libexec/mysql-mmm
# cluster状态文件,mmm_control show操作的原始数据
status_path /var/lib/mysql-mmm/mmm_mond.status
# 被监控的db服务器IP地址
ping_ips 10.11.4.196,10.11.4.197,10.11.4.198
# 不设置时,默认值是60s;
# 故障恢复后,offline超过60s的节点会一直处于AWAITING_RECOVERY的状态,需要手动set_online;
# offline低于60s的节点,且非flapping状态,会自动online
auto_set_online 20 # The kill_host_bin does not exist by default, though the monitor will
# throw a warning about it missing. See the section 5.10 "Kill Host
# Functionality" in the PDF documentation.
#
# kill_host_bin /usr/libexec/mysql-mmm/monitor/kill_host
#
</monitor> <host default>
# 监控db服务器的用户
monitor_user mmm_monitor
# 监控db服务器的用户密码
monitor_password mmm_monitor
</host> # 0是正常模式,1是debug模式
debug 0

3)mmm_agent.conf文件

#mmm_agent.conf文件,3台db服务器上的代理文件配置
[root@master ~]# vim /etc/mysql-mmm/mmm_agent.conf
include mmm_common.conf # this后面的参数是当前服务器的host名;
# 在3台db服务器根据host名修改即可,监控服务器不需要
this master

5. 启动进程

1)监控/管理

#监控服务器默认开机启动没有设置;
#配置文件如有改动,监控端或db服务器都需要重启进程
[root@mmm ~]# chkconfig --level 35 mysql-mmm-monitor on
[root@mmm ~]# service mysql-mmm-monitor start

2)代理

#3台db服务器操作类似
[root@master ~]# chkconfig --level 35 mysql-mmm-agent on
[root@master ~]# service mysql-mmm-agent start

6. iptables

#mmm_agent服务打开本地tcp9989端口,供监控/管理端访问,需要防火墙放行;
#3台db服务器操作类似
[root@master ~]# vim /etc/sysconfig/iptables
-A INPUT -m state --state NEW -m tcp -p tcp --dport 9989 -j ACCEPT [root@master ~]# service iptables restart

四.验证

1. 集群节点状态

#查看ping,mysql,复制线程是否正常
[root@mmm ~]# mmm_control checks all

2. 集群角色状态

#各角色已经拿到vip
[root@mmm ~]# mmm_control show 

3. 对节点执行offline/online操作

1)offline

#backup节点的状态是”ADMIN_OFFLINE”;
#slave节点同时获得2个读vip
[root@mmm ~]# mmm_control set_offline backup
[root@mmm ~]# mmm_control show

2)online

#backup节点的状态在恢复到"ONLINE"前,有一个短暂的"REPLICATION_FAIL"状态
[root@mmm ~]# mmm_control set_online backup
[root@mmm ~]# mmm_control show

4. 执行write切换操作

1)查看slave当前对应的master

#当前对应的master是master节点
[root@slave ~]# mysql -uroot -pxxxxxx -e 'show slave status\G;'

2)write切换

#write角色已经切换到backup节点
[root@mmm ~]# mmm_control move_role writer backup
[root@mmm ~]# mmm_control show

3)查看slave对应的master是否切换

#当前对应的master是backup节点
[root@slave ~]# mysql -uroot -pxxxxxx -e 'show slave status\G;'

五.一些总结

1. 日志

监控端:/var/log/mysql-mmm/mmm_mond.log

代理端:/var/log/mysql-mmm/mmm_agentd.log

2. 命令

除常用的mmm_control命令外,mmm方案还提供如下命令:

mmm_backup :备份文件

mmm_restore :还原文件

mmm_clone :克隆文件

3. 注意事项

  1. 对外提供读写服务的vip由monitor程序控制。
  2. 如果monitor没有启动,则db服务器不会被分配vip;
  3. 如果已经为db服务器分配了vip,但monitor程序故障/关闭,已分配的vip不会被立即关闭,外部程序可以继续访问(只要不重启网络)。这样的好处是降低了对monitor的可靠性要求;但如果此时其中的某台db服务器故障,因为无法处理切换,已分配的vip依然在已故障的db服务上,此vip会变的不可访问。
  4. agent程序受monitor程序的控制处理write切换,从库切换等操作,如果monitor进程关闭,那么agent进程本身是不能处理任何故障的。
  5. monitor程序负责监控db服务器的状态,包括db、服务器是否运行、复制线程是否正常、主从延时等;同时用于控制agent程序处理故障。
  6. monitor会每隔几秒钟监控db服务器的状态,如果db服务器已经从故障变成了正常,那么monitor会自动在60s之后将其设置为online状态(默认是60s,可以设为其它的值),由监控端的配置文件参数"auto_set_online"决定,集群节点的三种状态分别是:HARD_OFFLINE,AWAITING_RECOVERY,ONLINE。
  7. 默认monitor会控制mmm_agent将writer db服务器read_only修改为OFF,其它db服务器read_only修改为ON。可以在所有db服务器的my.cnf文件中加入read_only=1,由monitor来控制writer和read,但root用户与复制用户不受read_only参数的影响。
  8. monitor会控制slave指向master,如果当前master故障,monitor会控制slave指向新的master,由于MMM方案采用非抢占机制,所以新的master将一直承担写服务。

MySQL-MMM方案的更多相关文章

  1. MySQL MMM高可用方案

    200 ? "200px" : this.width)!important;} --> 介绍 本篇文章主要介绍搭建MMM方案以及MMM架构的原理.这里不介绍主从.主主的搭建方 ...

  2. MySQL HA方案之MySQL半复制+MHA+Keepalived+Atlas+LVS[转]

    MySQL HA方案之MySQL半复制+MHA+Keepalived+Atlas+LVS 简介 目前Mysql高可用的方案有好多,比如MMM,heartbeat+drbd,Cluster等,还有per ...

  3. 从 MySQL+MMM 到 MariaDB+Galera Cluster : 一个高可用性系统改造

    很少有事情比推出高可用性(HA)系统之后便经常看到的系统崩溃更糟糕.对于我们这个Rails运行机的团队来说,这个失效的HA系统是MySQL多主复制管理器(MMM). 我们已经找寻MMM的替代品有一段时 ...

  4. MySql优化方案

    mysql优化方案总结 u       Mysql数据库的优化技术 对mysql优化时一个综合性的技术,主要包括 a: 表的设计合理化(符合3NF) b: 添加适当索引(index) [四种: 普通索 ...

  5. MySQL备份方案-->(利用mysqldump以及binlog二进制日志)

                                                         MySQL备份方案-->(利用mysqldump以及binlog二进制日志) 随着数据不 ...

  6. Mysql主从方案的实现

    Mysql主从方案介绍 mysql主从方案主要作用: 读写分离,使数据库能支撑更大的并发.在报表中尤其重要.由于部分报表sql语句非常的慢,导致锁表,影响前台服务.如果前台使用master,报表使用s ...

  7. MySQL中间件方案盘点_搜狐科技_搜狐网

    MySQL中间件方案盘点_搜狐科技_搜狐网

  8. 实战体验几种MySQL Cluster方案(转)

    1.背景 MySQL的cluster方案有很多官方和第三方的选择,选择多就是一种烦恼,因此,我们考虑MySQL数据库满足下三点需求,考察市面上可行的解决方案: 高可用性:主服务器故障后可自动切换到后备 ...

  9. Mysql MMM 高可用

    一.Mysql MMM 高可用概况: mmm_mond  负责所有的监控工作的监控守护进程,决定节点的移除等: mmm_agentd  运行在mysql服务器上的代理守护进程,通过简单远程服务集提供给 ...

  10. Docker容器内Mysql大小写敏感方案解决

    Docker容器内Mysql大小写敏感方案解决 一.(lower_case_table_names)参数说明 二.Docker 部署 MySql 并修改为大小写不敏感 2.1直接在Docker启动的时 ...

随机推荐

  1. 在 S5PV210 的 开发板上 使用 串口 收发信息

    参考学习教程:周立功嵌入式Linux开发教程-(上册) 材料:首先 准备一个 安装好 Linux 的 开发板 使用  xshell 工具 连接 开发板  ,winscp 工具 连接 开发板  ,  准 ...

  2. java alibaba fastJson 遍历数组json

    import java.util.*; import com.alibaba.fastjson.*; public class Test { public static void main(Strin ...

  3. Notes 20180311 : String第三讲_深入了解String

    很多前辈我可能对于我的这节文章很困惑,觉得String这个东西还有什么需要特别了解的吗?其实不然,String是一个使用十分频繁的工具类,不可避免地我们也会遇到一些陷阱,深入了解String对于我们避 ...

  4. Android解析json数据

    Json数据 [{"code":"110000","sheng":"11","di":"0 ...

  5. jdk 下载地址 服务器

    https://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.html

  6. iOS 第三方库、插件、知名博客总结

    iOS 第三方库.插件.知名博客总结 用到的组件 1.通过CocoaPods安装 项目名称 项目信息 AFNetworking 网络请求组件 FMDB 本地数据库组件 SDWebImage 多个缩略图 ...

  7. 宏观看restframework序列化

    序列化 序列化意义 web有两种应用模式,一种是前后端不分离,一种是前后端分离,当前后端分离的时候,后端只需要向前端传输数据即可,不需要进行其他的操作,一般如果是中大型公司,都是前后端分离,这也是目前 ...

  8. linux环境mysql的安装主从关系的配置

  9. Home Assistant系列 -- 基于树莓派安装并设置自启动

    Home Assistant 是当前智能家居最火热的开源DIY 软件,之前的文章  智能家居系统 Home Assistant 系列 --介绍篇  已经详细介绍过了,这里就不详细介绍了,今天介绍 如何 ...

  10. Oracle笔记之——常用的函数及脚本

    一.oracle 常用的函数及关键字 1.集合操作 1)minus 差集 2)intersect 交集 3)UNION 并集,会去重 4)UNION ALL 并集,不去重2.事物 1)COMMIT ( ...