MySQL 高可用性之MySQL-MMM

一、MMM简介

MMM即Multi-Master Replication Manager for MySQL:mysql多主复制管理器,基于perl实现,关于mysql主主复制配置的监控、故障转移和管理的一套可伸缩的脚本套件(在任何时候只有一个节点可以被写入)。

MMM也能对从服务器进行读负载均衡,所以可以用它来在一组用于复制的服务器启动虚拟ip。

除此之外,它还有实现数据备份、节点之间重新同步功能的脚本。

MySQL本身没有提供replication failover的解决方案,通过MMM方案能实现服务器的故障转移,从而实现mysql的高可用。MMM不仅能提供浮动IP的功能,如果当前的主服务器挂掉后,会将你后端的从服务器自动转向新的主服务器进行同步复制,不用手工更改同步配置。这个方案是目前比较成熟的解决方案。

优点:

高可用性,扩展性好,出现故障自动切换,对于主主同步,在同一时间只提供一台数据库写操作,保证的数据的一致性。当主服务器挂掉以后,另一个主立即接管,其他的从服务器能自动切换,不用人工干预。

缺点:

monitor节点是单点,不过这个你也可以结合keepalived或者haertbeat做成高可用;

至少三个节点,对主机的数量有要求,需要实现读写分离,还需要在前端编写读写分离程序;

在读写非常繁忙的业务系统下表现不是很稳定,可能会出现复制延时、切换失效等问题。

Mmm主要功能由下面三个脚本提供:

mmm_mond  负责所有的监控工作的监控守护进程,决定节点的移除(mmm_mond进程定时心跳检测,失败则将write ip浮动到另外一台master)等等

mmm_agentd  运行在mysql服务器上的代理守护进程,通过简单远程服务集提供给监控节点

mmm_control  通过命令行管理mmm_mond进程

在整个监管过程中,需要在mysql中添加相关授权用户,授权的用户包括一个mmm_monitor用户和一个mmm_agent用户,如果想使用mmm的备份工具则还要添加一个mmm_tools用户。

二、案例

1、环境介绍

OS:centos7.2(64位)数据库系统:mysql5.7.13

关闭selinux

配置ntp,同步时间


角色


IP


hostname


Server-id


Write vip


Read vip


Master1


192.168.31.83


master1


1


192.168.31.2


Master2(backup)


192.168.31.141


master2


2


192.168.31.3


Slave1


192.168.31.250


slave1


3


192.168.31.4


monitor


192.168.31.106


monitor1


注意:这里从服务器只设置了一台。

2、在所有主机上配置/etc/hosts文件,添加如下内容:

192.168.31.83 master1

192.168.31.141 master2

192.168.31.250 slave1

192.168.31.106 monitor1

3.安装支持包和相关库

在所有主机上安装perl perl-devel perl-CPAN libart_lgpl.x86_64 rrdtool.x86_64   rrdtool-perl.x86_64包

#yum -y install perl-*  libart_lgpl.x86_64  rrdtool.x86_64  rrdtool-perl.x86_64

注:使用centos7在线yum源安装

安装perl的相关库

#cpan -i Algorithm::Diff Class::Singleton DBI DBD::mysql Log::Dispatch Log::Log4perl Mail::Send Net::Ping Proc::Daemon Time::HiRes Params::Validate Net::ARP

#cpan Proc::Daemon

#cpan Log::Log4perl

4.配置master1和master2互为主从,slave1为master1的从。注意添加防火墙规则。(具体的配置方法这里不再叙述)

5.mysql-mmm配置:

mysql> grant super,replicationclient,process on *.* to ‘mmm_agent‘@‘192.168.31.%‘ identified by ‘123456‘;  //创建代理账号

mysql> grant replication client on *.* to ‘mmm_monitor‘@‘192.168.31.%‘ identified by ‘123456‘;  //创建监控账号

注意:因为之前的主从复制,所以可以只在master1服务器执行就ok了。

mmm_monitor用户:mmm监控用于对mysql服务器进程健康检查

mmm_agent用户:mmm代理用来更改只读模式,复制的主服务器等

检查master2和slave1上是否都存在监控和代理账号:

5、mysql-mmm安装及配置

监控程序和代理程序都集成在mysql-mmm-2.2.1.tar.gz源码包中,所以四台服务器都要利用该源码包安装。

下载地址:

http://pkgs.fedoraproject.org/repo/pkgs/mysql-mmm/mysql-mmm-2.2.1.tar.gz/f5f8b48bdf89251d3183328f0249461e/mysql-mmm-2.2.1.tar.gz

(1)编写配置文件(五台主机必须一致)

完成安装后,所有的配置文件都放到了/etc/mysql-mmm/下面。

管理服务器和数据库服务器上都要包含一个共同的文件mmm_common.conf,内容如下:

<host default>

cluster_interfaceeno16777736  #群集的网络接口

pid_path       /var/run/mmm_agentd.pid    #pid路径

bin_path          /usr/lib/mysql-mmm/    #可执行文件路径

replication_user        rep    #复制用户

replication_password   123456  #复制用户密码

agent_usermmm_agent        #代理用户

agent_password    123456   #代理用户密码

</host>

<host master1>         #master1的host名

ip     192.168.31.83    #master1的ip

mode    master    #角色属性,master代表是主

peer    master2   #与master1对等的服务器的host名,也就是master2的服务器host名

</host>

<host master2#和master的概念一样

ip       192.168.31.141

mode     master

peer     master1

</host>

<host slave1>    #从库的host名,如果存在多个从库可以重复一样的配置

ip      192.168.31.250    #从的ip

mode    slave          #slave的角色属性代表当前host是从

</host>

<role writer>    #writer角色配置

hosts      master1,master2    #能进行写操作的服务器的host名,如果不想切换写操作这里可以只配置master,这样也可以避免因为网络延时而进行write的切换,但是一旦master出现故障那么当前的MMM就没有writer了只有对外的read操作。

ips    192.168.31.2    #对外提供的写操作的虚拟IP

mode   exclusive    #exclusive代表只允许存在一个主,也就是只能提供一个写的IP

</role>

<role reader>    #read角色配置

hosts   master2,slave1    #对外提供读操作的服务器的host名,当然这里也可以把master加进来

ips     192.168.31.3,192.168.31.4 #对外提供读操作的虚拟ip,这两个ip和host不是一一对应的,并且ips也hosts的数目也可以不相同。

mode     balanced    #balanced代表负载均衡

</role>

将这个文件拷贝到其它的服务器,配置不变。

for host in master1 master2 slave1 ; do scp /etc/mysql-mmm/mmm_common.conf $host:/etc/mysql-mmm/ ; done

mmm监控端的主要配置

(2)配置监控文件

编辑 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_ips192.168.31.83,192.168.31.141,192.168.31.250 #用于测试网络可用性 IP 地址列表,只要其中有一个地址 ping 通,就代表网络正常,这里不要写入本机地址。

auto_set_online  0 #设置自动online的时间,默认是超过60s就将它设置为online,默认是60s,这里将其设为0就是立即online

</monitor>

<check default>

check_period    5   #检查周期默认为5s

trap_period     10  #一个节点被检测不成功的时间持续trap_period秒,就慎重的认为这个节点失败了,默认为10秒。

timeout         2   #检查超时的时间默认为2秒

#restart_after     10000#在完成restart_after次检查后,重启checker进程。

max_backlog     86400  #记录检查rep_backlog日志的最大次数,默认为60。

</check>

<host default>

monitor_usermmm_monitor   #监控db服务器的用户

monitor_password  123456  #监控db服务器的密码

</host>

debug 0  #debug 0正常模式,1为debug模式

(3)启动监控进程

注:添加source /root/.bash_profile目的是:在mysql-mmm-monitor下次开机自启时,执行/root/.bash_profile,为其提供环境变量。

自动启动和手动启动的唯一区别,就是激活一个console 。那么说明在作为服务启动的时候,可能是由于缺少环境变量。

成功启动监控进程

mmm_mond监控服务监听的端口号为9988,注意在防火墙添加规则。

mysql服务器端的主要配置

(4)代理文件配置(三台mysql服务器以master1为例)

编辑 4台mysql节点机上的/etc/mysql-mmm/mmm_agent.conf

注意:这个配置只配置db服务器,监控服务器不需要配置,this后面的host名改成当前服务器的主机名。

(5)启动代理进程(三台mysql服务器以master1为例)

同样在 /etc/init.d/mysql-mmm-agent的脚本文件的#!/bin/sh下面,加入如下内容

source /root/.bash_profile

成功启动代理进程

mmm_agentd服务监听的是9989端口,注意添加防火墙规则。

注意:在这三台mysql服务器上都要配置代理文件并启动代理程序。

(6)检查集群状态

注意:无论是在db端还是在监控端如果有对配置文件进行修改操作都需要重启代理进程和监控进程。

MMM启动顺序:先启动monitor,再启动 agent。

在监控主机上执行”mmm_control show”,发现mysql服务器都处于ONLINE状态,能够写入的只有master1。

如果服务器状态不是ONLINE,可以用如下命令将服务器上线,例如:

#mmm_control  set_online 主机名

从上面的显示可以看到,写请求的VIP在master1上,所有从节点也都把master1当做主节点。

master2上启用了read vip地址。

slave1上启用了read vip地址。

master2和slave1的主都是master1

6.MMM高可用性测试

停止master1的mysqld服务,模拟master1宕机,手动停止mysql服务,观察monitor日志:

查看群集的最新状态,从显示结果可以看出master1的状态有ONLINE转换为HARD_OFFLINE,写VIP转移到了master2主机上。

检查所有的db服务器群集状态,执行”mmm_control checks all”,从上面可以看到master1能ping通,说明只是服务死掉了。

write vip地址到了master2上了

从服务器的主自动切换为了master2

启动master1的mysqld服务

从上面可以看到master1的状态由hard_offline改变为awaiting_recovery状态。

将其上线后,可以看到master1并不会接管主,除非现有的主再次宕机。

7.总结

(1)对外提供读写的虚拟IP是由monitor程序控制。如果monitor没有启动那么db服务器不会被分配虚拟ip,但是如果已经分配好了虚拟ip,当monitor程序关闭了原先分配的虚拟ip不会立即关闭外部程序还可以连接访问(只要不重启网络),这样的好处就是对于monitor的可靠性要求就会低一些,但是如果这个时候其中的某一个db服务器故障了就无法处理切换,也就是原先的虚拟ip还是维持不变,挂掉的那台DB的虚拟ip会变的不可访问。

(2)agent程序受monitor程序的控制处理write切换,从库切换等操作。如果monitor进程关闭了那么agent进程就起不到什么作用,它本身不能处理故障。

3.monitor程序负责监控db服务器的状态,包括Mysql数据库、服务器是否运行、复制线程是否正常、主从延时等;它还用于控制agent程序处理故障。

(4)monitor会每隔几秒钟监控db服务器的状态,如果db服务器已经从故障变成了正常,那么monitor会自动在60s之后将其设置为online状态(默认是60s可以设为其它的值),有监控端的配置文件参数“auto_set_online”决定,群集服务器的状态有三种分别是:HARD_OFFLINE→AWAITING_RECOVERY→online

(5)默认monitor会控制mmm_agent会将writer db服务器read_only修改为OFF,其它的db服务器read_only修改为ON,所以为了严谨可以在所有的服务器的my.cnf文件中加入read_only=1由monitor控制来控制writer和read,root用户和复制用户不受read_only参数的影响。

附:

1、mysql-mmm日志文件:

日志文件往往是分析错误的关键,所以要善于利用日志文件进行问题分析。

db端:/var/log/mysql-mmm/mmm_agentd.log

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

2、mysql-mmm命令文件:

mmm_agentd:db代理进程的启动文件

mmm_mond:监控进程的启动文件

mmm_backup:备份文件

mmm_restore:还原文件

mmm_control:监控操作命令文件

db服务器端只有mmm_agentd程序,其它的都是在monitor服务器端。

3、mysql-mmm的六种状态

online:正常的状态,可以充当各种角色

admin_offline:手动下线的状态

hard_offline:ping不通并且(或者)mysql连接中断,会导致这种状态。

awaiting_recovery:等待恢复状态,能ping通,mysql连接接恢复正常。

replication_delay:复制延迟

replication_fail:复制中断,sql线程或io线程出现问题。

4.mmm_control用法

mmm_control程序可以用于监控群集状态、切换writer、设置online\offline操作等。

Valid commands are:

help        - show this message #帮助信息

ping        - ping monitor #ping当前的群集是否正常

show        - show status #群集在线状态检查

checks [<host>|all [<check>|all]] #执行监控检查操作

set_online <host>         #将host设置为online

set_offline <host>    #将host设置为offline

mode       #打印输出当前的mode

set_active      - switch into active mode.

set_manual      - switch into manual mode.

set_passive      - switch into passive mode.

move_role [--force] <role> <host> - move exclusive role <role> to host <host>

set_ip <ip> host>   - set role with ip<ip> to host <host>

时间: 2024-12-26 16:14:21

MySQL 高可用性之MySQL-MMM的相关文章

MySQL 高可用性keepalived+mysql

生产环境中一台mysql 主机存在单点故障,所以我们要确保 mysql 的高可用性,即两台 MySQL 服务器如果其中有一台 MySQL 服务器挂掉后,另外一台能立马接替其进行工作. MySQL 的高可用方案一般有如下几种: keepalived+双主,MHA,PXC,MMM,Heartbeat+DRBD 等,比较常用的是 keepalived+双主, MHA 和 PXC. 本节主要介绍了利用 keepalived 实现 MySQL数据库的高可用. Keepalived+mysql 双主来实现M

MySQL 高可用性——keepalived+mysql双主(有详细步骤和全部配置项解释)

博主QQ:819594300 博客地址:http://zpf666.blog.51cto.com/ 有什么疑问的朋友可以联系博主,博主会帮你们解答,谢谢支持! 前言:生产环境中一台mysql主机存在单点故障,所以我们要确保mysql的高可用性,即两台MySQL服务器如果其中有一台MySQL服务器挂掉后,另外一台能立马接替其进行工作. MySQL的高可用方案一般有如下几种: keepalived+双主,MHA,PXC,MMM,Heartbeat+DRBD等,比较常用的是keepalived+双主,

MySQL高可用性之MHA

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

MySQL高可用解决方案MMM

一.MMM简介: MMM即Multi-Master Replication Manager for MySQL:mysql多主复制管理器,基于perl实现,关于mysql主主复制配置的监控.故障转移和管理的一套可伸缩的脚本套件(在任何时候只有一个节点可以被写入),MMM也能对从服务器进行读负载均衡,所以可以用它来在一组用于复制的服务器启动虚拟ip,除此之外,它还有实现数据备份.节点之间重新同步功能的脚本.MySQL本身没有提供replication failover的解决方案,通过MMM方案能实

MySQL 高可用性之keepalived+mysql双主

生产环境中一台mysql主机存在单点故障,所以我们要确保mysql的高可用性,即两台MySQL服务器如果其中有一台MySQL服务器挂掉后,另外一台能立马接替其进行工作. MySQL的高可用方案一般有如下几种: keepalived+双主,MHA,PXC,MMM,Heartbeat+DRBD等,比较常用的是keepalived+双主,MHA和PXC. 这里将主要介绍了利用 keepalived 实现 MySQL数据库的高可用. Keepalived+mysql双主来实现MySQL-HA,我们必须保

MySQL高可用群集--MMM高可用架构

为什么要使用MySQL高可用群集 在实际生产环境中,当普通的MySQL主从复制和读写分离不能满足实际需求时,就需要考虑MySQL的高可用群集,出于安全角度考虑,当数据访问量过大带来主服务器负载增大,当出现主服务器宕机一个时,保证数据服务不会中断的情况下,从服务器会自动寻找另一主服务器,而从服务器也会像主服务器一样,当其中一个宕机时,依旧可以保证服务不会中断. MMM高可用架构 什么是MMM? MMM(Master-Master replication manager for MySQL)是一套支

MySQL主主复制+LVS+Keepalived实现MySQL高可用性

MySQL主主复制+LVS+Keepalived实现MySQL高可用性 MySQL复制能够保证数据的冗余的同时可以做读写分离来分担系统压力,如果是主主复制还可以很好的避免主节点的单点故障.但是MySQL主主复制存在一些问题无法满足我们的实际需要:未提供统一访问入口来实现负载均衡,如果其中master宕掉的话需要手动切换到另外一个master,而不能自动进行切换. 这篇文章下面要介绍如何通过LVS+Keepalived的方式来是实现MySQL的高可用性,同时解决以上问题. Keepalived和L

MySQL 5.6通过MMM实现读写分离的高可用架构

上一篇博文我们使用keepalived+主从同步搭建了一个简单的MySQL高可用架构(详见http://blog.51cto.com/jiangjianlong/1981994),今天再分享下通过MMM搭建的实现MySQL读写分离的高可用群集.MMM (Master-Master Replication Manager for MySQL)是使用perl开发的MySQL主主复制管理器,可实现读写分离的高可用架构,对主库实现写请求的高可用,对从库实现读请求的负载均衡.本文的架构示意图如下: 一.部

MySQL Study之--MySQL主从复制类型

MySQL Study之--MySQL主从复制类型 一.复制原理 Mysql内建的复制功能是构建大型,高性能应用程序的基础.将Mysql的数据分布到多个系统上去,这种分布的机制,是通过将Mysql的某一台主机的数据复制到其它主机(slaves)上,并重新执行一遍来实现的.复制过程中一个服务器充当主服务器,而一个或多个其它服务器充当从服务器.主服务器将更新写入二进制日志文件,并维护文件的一个索引以跟踪日志循环.这些日志可以记录发送到从服务器的更新.当一个从服务器连接主服务器时,它通知主服务器从服务

涂抹mysql笔记-搭建mysql高可用体系

mysql的高可用体系<>追求更高稳定性的服务体系 可扩展性:横向扩展(增加节点).纵向扩展(增加节点的硬件配置) 高可用性<>Slave+LVS+Keepalived实现高可用:在从库部署负载均衡器.<>安装配置LVS:相当于负载均衡器.我们选择在192.168.1.9主机名为linux04的服务器上安装LVS1.modprobe -l |grep ipvs查看当前操作系统是否存在lpvs模块.2.lsmod |grep ip_vs查看是否ip_vs内个模块是否被加载