标签：mysql5.7.13 mmm 高可用性
博主QQ：819594300
博客地址：http://zpf666.blog.51cto.com/
有什么疑问的朋友可以联系博主，博主会帮你们解答，谢谢支持！
一、MMM简介：
MMM即Multi-MasterReplication Manager for MySQL:mysql多主复制管理器。MMM是perl语言编写的。
MMM的特点：
①基于perl实现,关于mysql主主复制配置的监控、故障转移和管理的一套可伸缩的脚本套件（在任何时候只有一个节点可以被写入）；
②MMM也能对从服务器进行读负载均衡，所以可以用它来在一组用于复制的服务器启动虚拟ip；
③除此之外，它还有实现数据备份、节点之间重新同步功能的脚本。
④MySQL本身没有提供replication failover的解决方案，通过MMM方案能实现服务器的故障转移，从而实现mysql的高可用。
⑤MMM不仅能提供浮动IP的功能，如果当前的主服务器挂掉后，会将你后端的从服务器自动转向新的主服务器进行同步复制，不用手工更改同步配置。
这个方案是目前比较成熟的解决方案，想了解详情请看官网：http://mysql-mmm.org
优点：
①高可用性（不但能做主主的高可用还能做从从的高可用）；
②扩展性好；
③出现故障自动切换，对于主主同步，在同一时间只提供一台数据库写操作，保证的数据的一致性。当主服务器挂掉以后，另一个主立即接管，其他的从服务器能自动切换，不用人工干预。
缺点：
monitor节点是单点，不过这个你也可以结合keepalived或者haertbeat做成高可用;至少三个节点，对主机的数量有要求，需要实现读写分离,还需要在前端编写读写分离程序。在读写非常繁忙的业务系统下表现不是很稳定，可能会出现复制延时、切换失效等问题。
不适用场景：
MMM方案并不太适应于对数据安全性要求很高，并且读、写繁忙的环境中。
适用场景：
MMM的适用场景为数据库访问量大，并且能实现读写分离的场景。
Mmm主要功能由下面三个脚本提供：
mmm_mond 负责所有的监控工作的监控守护进程，决定节点的移除(mmm_mond进程定时心跳检测，失败则将write ip浮动到另外一台master)等等
mmm_agentd 运行在mysql服务器上的代理守护进程，通过简单远程服务集提供给监控节点
mmm_control 通过命令行管理mmm_mond进程
授权用户：
在整个监管过程中，需要在mysql中添加相关授权用户，授权的用户包括一个mmm_monitor用户和一个mmm_agent用户，如果想使用mmm的备份工具则还要添加一个mmm_tools用户。
二、环境介绍:
OS:centos7.2（64位）数据库系统：mysql5.7.13
角色 | IP | hostname | Server-id | Write vip | Read vip |
Master1 | 192.168.1.5 | master1 | 1 | 192.168.1.10 | |
Master2(backup) | 192.168.1.6 | master2 | 2 | 192.168.1.20 | |
Slave1 | 192.168.1.7 | slave1 | 3 | 192.168.1.30 | |
Slave2 | 192.168.1.8 | slave2 | 4 | 192.168.1.40 | |
monitor | 192.168.1.9 | monitor | 无 |
三、实验步骤
1、在monitor上配置ntp，让全部主机时间同步，并且全部主机都关闭selinux
现在在其他四台主机上都进行如下操作：
至此，现在五台主机时间都同步了。
下面的关闭selinux在五台主机都要操作：
2、在所有主机上配置/etc/hosts文件，添加如下内容：
（在master1上添加，其他四台全部用scp命令拷贝一份即可）
先修改五台主机的主机名：分别为master1、master2、slave1、slave2、monitor
下面正式开始修改各自的hosts文件（五台全部一样）：
3、在所有主机上安装perl perl-devel perl-CPANlibart_lgpl.x86_64 rrdtool.x86_64 rrdtool-perl.x86_64包（注：必须使用centos7在线yum源安装）
4、在所有主机上安装perl的相关库
截图看不清的可以看下面的粘贴的内容：
#cpan-i Algorithm::Diff Class::Singleton DBIDBD::mysql Log::Dispatch Log::Log4perl Mail::Send Net::Ping Proc::Daemon Time::HiRes Params::Validate Net::ARP
注意：DBD::mysql和Net::Ping这两个库非常的难装，大家一定要看清楚！
注1：DBD::mysql安装不上，我们可以首先尝试单独安装DBD::mysql（命令是：cpan DBD::mysql），如果不行，则可能是因为你的mysql服务器上libmysqlclient.so.18和libmysqlclient.so.20两个共享对象文件共存了，系统默认使用老版本，所以我们要把libmysqlclient.so.18删除掉，而libmysqlclient.so.18的是因为我们系统安装了mariadb-libs.x86_64 这个包，我们卸载这个包就可以把libmysqlclient.so.18删除（命令是：rpm -e mariadb-libs.x86_64 --nodeps），然后我们就可以单独安装DBD::mysql（命令是：cpan -f DBD::mysql）了。
注2：Net::Ping安装不上，我们也可以先尝试单独安装Net::Ping（命令是：cpan -f Net::Ping），如果不行，则可能是因为Net::Ping编译后要测试，在测试那没通过，所以后面也不让Net::Ping安装，Net::Ping模块是由Net-Ping-2.58.tar.gz这个包提供的，它下载后存放的路径是：
/root/.local/share/.cpan/sources/authors/id/R/RU/RURBAN/Net-Ping-2.58.tar.gz
然后我们去手动tar解压缩Net-Ping-2.58.tar.gz这个包，按照下面的顺序来手动安装：
perlMakefile.PL && make && make install
两个模块安装完毕后，重启mysqld服务即可。
5、在master1、master2、slave1、slave2主机上安装mysql5.7和配置复制
注1：在实际生产环境中，两台master也要加read_only=1这个配置项，本次实验我只在slave上加，master就不加了。
注2：mysql5.7我已安装完毕，因此安装过程略。
在每个mysql的配置文件/etc/my.cnf中加入以下内容，注意server-id不能重复：
四台mysql的my.cnf配置文件修改完毕后，都需要重启mysqld服务：
6、四台mysql主机要开启防火墙，要么关闭防火墙或者创建访问规则
7、主从配置（master1和master2配置成主主，slave1和slave2配置成master1的从）
在master1上授权：
在master2上授权：
8、把master2、slave1和slave2配置成master1的从库
在master1上执行show masterstatus; 获取binlog文件和Position点：
分别在master2、slave1和slave2执行如下命令：
验证主从复制：（保证master2、slave1、slave2三台主机都是双yes即为成功）
9、把master1配置成master2的从库（因为要互为主从）
在master2上执行show masterstatus ;获取binlog文件和Position点：
在master1上执行如下命令：
验证主从复制：
10、mysql-mmm配置
分别在四台mysql节点上创建如下的用户
创建代理账号：
创建监控账号：
注1：因为之前的主从复制，以及主从已经是ok的，所以上面的创建用户的命令我只在master1服务器执行就ok了（即只在master1上创建这两个用户，其他三台都可以自动同步）
检查master2和slave1、slave2三台db上是否都存在监控和代理账号：
或者
注2：
mmm_monitor用户：mmm监控用于对mysql服务器进程健康检查
mmm_agent用户：mmm代理用来更改只读模式，复制的主服务器等
11、mysql-mmm安装
在monitor主机(192.168.1.9)上安装监控程序：
图片中的下载地址是：
12、在数据库服务器(master1、master2、slave1、slave2)上安装代理（即mysql-mmm）（同11步操作）
先在monitor上把mysql-mmm软件推送给四台mysql服务器：
然后再每台mysql服务器上分别安装各自的mysql-mmm软件：
13、配置mmm
注意{编写配置文件，五台主机必须一致：}
完成安装后，所有的配置文件都放到了/etc/mysql-mmm/下面了。
管理服务器（即monitor）和数据库服务器（即四台mysql）上都要包含一个共同的文件mmm_common.conf，五台的mmm_common.conf文件都修改成如下内容：（下面我只以master1为例）
配置项解释如下：
active_master_role writer #积极的master角色的标示，所有的db服务器要开启read_only参数，对于writer服务器监控代理会自动将read_only属性关闭。
<hostdefault>
cluster_interface eno16777736 #群集的网络接口
pid_path /var/run/mmm_agentd.pid #pid路径
bin_path /usr/lib/mysql-mmm/ #可执行文件路径
replication_user zpf #复制用户(即授权用户)
replication_password 123456 #复制用户密码
agent_user mmm_agent #代理用户
agent_password 123456 #代理用户密码
配置项解释如下：
<hostmaster1> #master1的host名
ip 192.168.1.5 #master1的ip
mode master #角色属性，master代表是主
peer master2 #与master1对等的服务器的host名，也就是master2的服务器host名
</host>
<hostmaster2> #和master的概念一样
ip 192.168.1.6
mode master
peer master1
</host>
配置项解释如下：
<hostslave1> #从库的host名,如果存在多个从库可以重复一样的配置
ip 192.168.1.7 #从的ip
mode slave #slave的角色属性代表当前host是从
</host>
<hostslave2> #和slave的概念一样
ip 192.168.1.8
mode slave
</host>
配置项解释如下：
<rolewriter> #writer角色配置
hosts master1,master2 #能进行写操作的服务器的host名，如果不想切换写操作这里可以只配置master,这样也可以避免因为网络延时而进行write的切换，但是一旦master出现故障那么当前的MMM就没有writer了只有对外的read操作。
ips 192.168.1.10 #对外提供的写操作的虚拟IP
mode exclusive #exclusive代表只允许存在一个主，也就是只能提供一个写的IP
</role>
<rolereader> #read角色配置
hosts master2,slave1,slave2 #对外提供读操作的服务器的host名,当然这里也可以把master加进来
ips 192.168.1.20, 192.168.1.30, 192.168.1.40 #对外提供读操作的虚拟ip，这三个ip和host不是一一对应的,并且ips也hosts的数目也可以不相同，如果这样配置的话其中一个hosts会分配两个ip
mode balanced #balanced代表负载均衡
</role>
一台配置完毕，然后把这个文件拷贝到其他的四台主机，配置都不变：
代理文件配置：
编辑四台mysql节点机上的/etc/mysql-mmm/mmm_agent.conf
注意：这个配置只配置mysql服务器，监控服务器(即monitor)不需要配置，this后面的host名改成当前服务器的主机名。
启动代理进程：（如下步骤也都是在四台mysql主机上操作，这里我就以master1为例来操作了）
在 /etc/init.d/mysql-mmm-agent的脚本文件的#!/bin/sh下面，加入如下内容：
添加成系统服务并设置为自启动：
失败说明：添加source /root/.bash_profile目的是为了mysql-mmm-agent服务能启机自启。
自动启动和手动启动的唯一区别，就是激活一个console 。那么说明在作为服务启动的时候，可能是由于缺少环境变量。
解决办法：
再次试着开启服务：
这次成功了。
查看一下服务是否在运行：
配置防火墙：
注：以上操作都必须在四台mysql主机上都操作完成了，然后方可下面的操作。
编辑 monitor主机上的/etc/mysql-mmm/mmm_mon.conf：
各个配置项解释如下：
includemmm_common.conf
<monitor>
ip 127.0.0.1 #为了安全性，设置只在本机监听，mmm_mond默认监听9988
pid_path /var/run/mmm_mond.pid
bin_path /usr/lib/mysql-mmm/
status_path/var/lib/misc/mmm_mond.status
ping_ips 192.168.1.5,192.168.1.6,192.168.1.7,192.168.1.8 #用于测试网络可用性 IP 地址列表，只要其中有一个地址 ping 通，就代表网络正常，这里不要写入本机地址
auto_set_online 0 #设置自动online的时间，默认是超过60s就将它设置为online，默认是60s，这里将其设为0就是立即online
</monitor>
<checkdefault>
check_period 5 #描述：检查周期默认为5s，默认值：5s
trap_period 10 #描述：一个节点被检测不成功的时间持续trap_period秒，就慎重的认为这个
点失败了，默认值：10s
timeout 2 #描述：检查超时的时间，默认值：2s
#restart_after 10000 #描述：在完成restart_after次检查后，重启checker进程，默认值：10000
max_backlog 86400 #描述：记录检查rep_backlog日志的最大次数，默认值：60
</check>
<hostdefault>
monitor_usermmm_monitor #监控db服务器的用户
monitor_password 123456 #监控db服务器的密码
</host>
debug0 #debug 0正常模式，1为debug模式
启动监控进程：
在 /etc/init.d/mysql-mmm-moniter的脚本文件的#!/bin/sh下面，加入如下内容：
添加成系统服务并设置为自启动：
解决方法：安装下列perl的库
再次试着启动服务：
这次成功了。
查看一下服务是否在运行：
注1：无论是在mysql端还是在监控端(monitor)如果有对配置文件进行修改操作都需要重启代理进程和监控进程。
注2：MMM启动顺序：先启动monitor，再启动agent
配置防火墙：
14、检查集群状态
从上图可以看出四台主机都是离线状态（这也是它们的原始状态）
如果服务器状态不是ONLINE，可以用如下命令将服务器上线：
格式：#mmm_controlset_online主机名
我们现在把四台主机都处于复苏状态：
再次查看群集状态：
从上图显示可以看到，写请求的VIP在master1上，所有从节点也都把master1当做主节点。
15、查看是否启用vip
16、在master2，slave1，slave2主机上分别查看主mysql的指向：
17、MMM高可用性测试：
说明：服务器读写采有VIP地址进行读写，出现故障时VIP会漂移到其它节点，由其它节点提供服务。
首先查看整个集群的状态，可以看到整个集群状态正常：
模拟master1宕机，手动停止mysql服务，观察monitor日志,master1的日志如下：
查看群集的最新状态：
从显示结果可以看出master1的状态有ONLINE转换为HARD_OFFLINE，写VIP转移到了master2主机上。
检查所有的mysql服务器群集状态：
从上面截图可以看到master1能ping通，说明只是服务死掉了。
18、查看master2、slave1、slave2
查看master2主机：
查看slave1主机：
查看slave2主机：
19、现在再把master1主机的mysql服务启动，再次观察monitor日志：
从上面截图可以看到master1的状态由hard_offline改变为awaiting_recovery状态。
20、用下面的命令将服务器master上线
21、再次查看群集的最新状态
从上图可以看到原主master1重新启动后不会接管主，只有现有的主（即master2）宕机了，master1才会接管。
总结：
(1)master2备选主节点宕机不影响集群的状态，就是移除了master2备选节点的读状态。
(2)master1主节点宕机，由master2备选主节点接管写角色，slave1,slave2指向新master2主库进行复制，slave1,slave2会自动change master到master2.
(3)如果master1主库宕机，master2复制应用又落后于master1时就变成了主可写状态，这时的数据主无法保证一致性。
如果master2,slave1,slave2延迟于master1主，这个时master1宕机，slave1,slave2将会等待数据追上db1后，再重新指向新的主node2进行复制操作，这时的数据也无法保证同步的一致性。
(4)如果采用MMM高可用架构，主，主备选节点机器配置一样，而且开启半同步进一步提高安全性或采用MariaDB/mysql5.7进行多线程从复制，提高复制的性能。
附：
1、日志文件：
说明：日志文件往往是分析错误的关键，所以要善于利用日志文件进行问题分析。
db端（即mysql服务器端）：
监控端（即monitor端）：
2、命令文件：
说明：db服务器端（即mysql服务器端）只有mmm_agentd程序，其它的都是在monitor服务器端。
3、mmm_control用法
作用：mmm_control程序可以用于监控群集状态、切换writer、设置online\offline操作等。
检查所有的db服务器群集状态：
该命令检查项包括：ping、mysql是否正常运行、复制线程是否正常等。
检查群集环境在线状况：
对指定的host执行offline操作：
对指定的host执行onine操作：
执行write切换(手动切换):
首先查看当前的slave对应的master：
然后进行writer切换，要确保mmm_common.conf文件中的writer属性有配置对应的host,否则无法切换：
查看一下writer是否转到master1:
再次查看一下slave是否自动切换了新master：（下图中可以确定slave切换了新master）
4、其它处理问题
原因：如果不想让writer从master切换到backup（包括主从的延时也会导致写VIP的切换），那么可以在配置/etc/mysql-mmm/mmm_common.conf时，去掉<role write>中的backup
5、总结
①对外提供读写的虚拟IP是由monitor程序控制。如果monitor没有启动那么db服务器不会被分配虚拟ip,但是如果已经分配好了虚拟ip，当monitor程序关闭了原先分配的虚拟ip不会立即关闭外部程序还可以连接访问（只要不重启网络），这样的好处就是对于monitor的可靠性要求就会低一些，但是如果这个时候其中的某一个db服务器故障了就无法处理切换，也就是原先的虚拟ip还是维持不变，挂掉的那台DB的虚拟ip会变的不可访问。
②agent程序受monitor程序的控制处理write切换，从库切换等操作。如果monitor进程关闭了那么agent进程就起不到什么作用，它本身不能处理故障。
③monitor程序负责监控db服务器的状态，包括Mysql数据库、服务器是否运行、复制线程是否正常、主从延时等；它还用于控制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,所以为了严谨可以在所有的服务器的my.cnf文件中加入read_only=1由monitor控制来控制writer和read,root用户和复制用户不受read_only参数的影响。
本文出自 “IT技术助手” 博客，请务必保留此出处http://zpf666.blog.51cto.com/11248677/1916289
标签：mysql5.7.13 mmm 高可用性
原文地址：http://zpf666.blog.51cto.com/11248677/1916289
