首页 > > 网络编程 > Mysql >

MySQL-MMM方案

2018-06-18 00:20:38来源：未知阅读 ()

参考文档：

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

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

一．MySQL-MMM方案

1. MMM方案简介

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

注意：

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

2. MMM套件简介

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

mmm_mond：监控进程，运行在监控/管理节点上，主要对所有数据库的监控工作，同时决定和处理所有节点的角色切换。
mmm_agentd：代理进程，运行在每台db服务器上，主要完成监控的测试工作和执行简单的远端服务设置。
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. 拓扑图

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

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

双主复制：http://www.cnblogs.com/netonline/p/7606704.html
相关规划如下：

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	10.11.4.192 10.11.4.193	master2在master1无故障时只提供读服务，master1故障时接管写VIP
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. 注意事项

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

标签：

版权申明：本站文章部分自网络，如有侵权，请联系：west999com@outlook.com
特别注意：本站所有转载文章言论不代表本站观点，本站所提供的摄影照片，插画，设计作品，如需使用，请与原作者联系，版权归原作者所有