共计 6828 个字符,预计需要花费 18 分钟才能阅读完成。
参考文档:
- 官方文档: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 |
||
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 将一直承担写服务。
本文永久更新链接地址:http://www.linuxidc.com/Linux/2017-10/147547.htm