MySQL-MMM高可用集群搭建（可用）

原创作品，允许转载，转载时请务必以超链接形式标明文章原始出处、作者信息和本声明。否则将追究法律责任。http://lizhenliang.blog.51cto.com/7876557/1354576

一、环境简述

1、工作逻辑图

2、MySQL-MMM优缺点

优点：高可用性，扩展性好，出现故障自动切换，对于主主同步，在同一时间只提供一台数据库写操作，保证的数据的一致性。

缺点：Monitor节点是单点，可以结合Keepalived实现高可用。

3、MySQL-MMM工作原理

MMM(Master-Master replication managerfor Mysql，Mysql主主复制管理器)是一套灵活的脚本程序，基于perl实现，用来对mysql replication进行监控和故障迁移，并能管理mysql Master-Master复制的配置(同一时间只有一个节点是可写的)。

mmm_mond：监控进程，负责所有的监控工作，决定和处理所有节点角色活动。此脚本需要在监管机上运行。

mmm_agentd：运行在每个mysql服务器上的代理进程，完成监控的探针工作和执行简单的远端服务设置。此脚本需要在被监管机上运行。

mmm_control：一个简单的脚本，提供管理mmm_mond进程的命令。

mysql-mmm的监管端会提供多个虚拟IP（VIP），包括一个可写VIP，多个可读VIP，通过监管的管理，这些IP会绑定在可用mysql之上，当某一台mysql宕机时，监管会将VIP迁移至其他mysql。

在整个监管过程中，需要在mysql中添加相关授权用户，以便让mysql可以支持监理机的维护。授权的用户包括一个mmm_monitor用户和一个mmm_agent用户，如果想使用mmm的备份工具则还要添加一个mmm_tools用户。

4、需求描述

操作系统：CentOS 6.5_X64

数据库：MySQL 5.1

MMM：MySQL-MMM 2.2.1

数据库分配：

function	ip	hostname	server id
monitoring host	192.168.0.201	monitor	无
master 1	192.168.0.202	db1	1
master 2	192.168.0.203	db2	2
slave 1	192.168.0.204	db3	3
slave 2	192.168.0.205	db4	4

虚拟IP地址（VIP）：

ip	role
192.168.0.211	writer
192.168.0.212	reader
192.168.0.213	reader

数据库同步需要的用户：

function	description	privileges
monitor user	mmm监控用于对mysql服务器进程健康检查	REPLICATION CLIENT
agent user	mmm代理用来更改只读模式，复制的主服务器等	SUPER, REPLICATION CLIENT, PROCESS
replication user	用于复制	REPLICATION SLAVE

二、db1，db2，db3和db4安装数据库并配置

[root@db1 ~]# yum install mysql-server mysql

[root@db1 ~]# service mysqld start

[root@db1 ~]# mysqladmin -u root password 123.com

[root@db1 ~]# vi /etc/my.cnf   #添加如下

[mysqld]

binlog-do-db=test           #需要记录二进制日志的数据库，多个用逗号隔开

binlog-ignore-db=mysql，information_schema  #不需要记录二进制日志的数据库，多个用逗号隔开

auto_increment_increment=2  #字段一次递增多少

auto_increment_offset=1     #自增字段的起始值，值设置不同

replicate-do-db=test        #同步的数据库，多个写多行

replicate-ignore-db = information_schema #不同步的数据库，多个写多行

server_id = 1               #每台设置不同

log_bin = mysql-bin

log_slave_updates           #当一个主故障，另一个立即接管

sync-binlog=1               #每条自动更新，安全性高，默认是0

[root@db1 ~]# service mysqld restart

三、配置db1和db2主主同步

#先查看下log bin日志和pos值位置

db1配置如下：

[root@db1 ~]# mysql -u root -p123.com

mysql> GRANT REPLICATION SLAVE ON *.* TO 'replication'@'192.168.0.%' IDENTIFIED BY 'replication';

mysql> flush privileges;

mysql> change master to

    -> master_host='192.168.0.203',

    -> master_user='replication',

    -> master_password='replication',

    -> master_log_file='mysql-bin.000002',

-> master_log_pos=106;  #对端状态显示的值

mysql> start slave;     #启动同步

db2配置如下：

[root@db2 ~]# mysql -u root -p123.com

mysql> GRANT REPLICATION SLAVE ON *.* TO 'replication'@'192.168.0.%' IDENTIFIED BY 'replication';

mysql> flush privileges;

mysql> change master to

    -> master_host='192.168.0.202',

    -> master_user='replication',

    -> master_password='replication',

    -> master_log_file='mysql-bin.000002',

    -> master_log_pos=106;

mysql> start slave;  #启动同步

#主主同步配置完毕，查看同步状态Slave_IO和Slave_SQL是YES说明主主同步成功。

在db2插入数据测试下：

在db2查看是否同步成功：

可以看到已经成功同步过去，同样在db2插入到user表数据，也能同步过去。我们的双主就成功了，开始做主从复制。

四、配置slave1和slave2做为master1的从库

#先看下master1状态值

在slave1和slave2分别执行：

mysql> change master to

    -> master_host='192.168.0.202',

    -> master_user='replication',

    -> master_password='replication',

    -> master_log_file='mysql-bin.000002',

    -> master_log_pos=434;

在slave1和slave2查看如下说明主从复制成功。但是数据没过来，这是因为主从复制原理只同步配置完后的增删改记录，以后的数据是不能同步的，我们可以把主的数据库备份了，然后在送数据库还原。

[root@db1 ~]# mysqldump -uroot -p123.com test > test.sql

[root@db1 ~]# scp test.sql root@192.168.0.204:/root/

[root@db1 ~]# scp test.sql root@192.168.0.205:/root/

[root@db3 ~]# mysql -u root -p123.com test < test.sql

[root@db4 ~]# mysql -u root -p123.com test < test.sql

五、MySQL-MMM安装配置

CentOS默认没有mysql-mmm软件包，官方推荐使用epel的网络源，五台都安装epel：

rpm -ivh http://mirrors.ustc.edu.cn/fedora/epel/6/x86_64/epel-release-6-8.noarch.rpm

1、monitor节点安装

[root@monitor ~]# yum -y install mysql-mmm-monitor

2、四台db节点安装

[root@db1 ~]# yum -y install mysql-mmm-agent

3、在四台db节点授权monitor访问

[root@db ~]# mysql -u root -p123.com

mysql> GRANT REPLICATIONCLIENT ON *.* TO 'mmm_monitor'@'192.168.0.%' IDENTIFIED BY 'monitor';                   

mysql> GRANT SUPER,REPLICATION CLIENT, PROCESS ON *.* TO 'mmm_agent'@'192.168.0.%' IDENTIFIED BY'agent';

4、修改mmm_common.conf文件（五台相同）

[root@monitor ~]# vi /etc/mysql-mmm/mmm_common.conf

active_master_role      writer

<host default>

    cluster_interface       eth0

    pid_path               /var/run/mysql-mmm/mmm_agentd.pid

    bin_path                /usr/libexec/mysql-mmm/

    replication_user        replication

    replication_password    replication

    agent_user              mmm_agent

    agent_password          agent

</host>

<host db1>

    ip     192.168.0.202

    mode   master

    peer   db2

</host>

<host db2>

    ip     192.168.0.203

    mode   master

    peer   db1

</host>

<host db3>

    ip     192.168.0.204

    mode   slave

</host>

<host db4>

    ip     192.168.0.205

    mode   slave

</host>

<role writer>

    hosts  db1, db2

    ips    192.168.0.211

    mode   exclusive    #只有一个host可以writer，一般写操作是这个模式

</role>

<role reader>

    hosts  db3, db4

    ips    192.168.0.212,192.168.0.213

    mode   balanced     #多个host可以reader，一般读操作是这个模式

</role>

#通过scp命令传送到其他四台：

scp /etc/mysql-mmm/mmm_common.conf root@192.168.0.202/203/204/205:/etc/mysql-mmm/

5、修改四台db代理端mmm_agent.conf文件

[root@db ~]# vi /etc/mysql-mmm/mmm_agent.conf

include mmm_common.conf

this db1   #分别修改为本机的主机名，即db1、db2、db3和db4

6、修改管理端mmm_mon.conf文件

[root@monitor ~]# vi /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

    status_path         /var/lib/mysql-mmm/mmm_mond.status

    ping_ips            192.168.0.202,192.168.0.203,192.168.0.204,192.168.0.205

#真实数据库IP，来检测网络是否正常

    auto_set_online     10  #恢复后自动设置在线的时间

</monitor>

<host default>

    monitor_user        mmm_monitor

    monitor_password    monitor

</host>

debug 0

六、启动MySQL-MMM

1、db代理端启动

[root@db1 ~]# /etc/init.d/mysql-mmm-agent start

[root@db1 ~]# chkconfigmysql-mmm-agent on

2、monitor管理端启动

[root@monitor ~]# /etc/init.d/mysql-mmm-monitor start

[root@monitor ~]# chkconfigmysql-mmm-monitor on

七、测试集群

1、查看集群状态

由此看来，主db1是对外一个写入的角色，但不真正提供只写，要想实现读写分离还需要结合amoeba。后面的虚拟IP是真正来访问Mysql数据库的。

2、故障转移切换

停掉主db1数据库，等待几秒后，可以看到数据库db1处于HARD_OFFLINE（离线状态），检测不到数据库的存在。

启动主db1数据库后，可以看到数据库db1处于AWAITING_RECOVER（恢复状态），几秒后将恢复在线状态。模拟Slave故障也是如此，DOWN掉一个，虚拟IP会全部在另一台正常数据库上。

MMM高可用性测试：

服务器读写采有VIP地址进行读写，出现故障时VIP会漂移到其它节点，由其它节点提供服务。

首先查看整个集群的状态，可以看到整个集群状态正常

[root@monitor1 ~]# mmm_control show

master1(192.168.31.83) master/ONLINE. Roles: writer(192.168.31.2)

master2(192.168.31.141) master/ONLINE. Roles: reader(192.168.31.5)

slave1(192.168.31.250) slave/ONLINE. Roles: reader(192.168.31.4)

slave2(192.168.31.225) slave/ONLINE. Roles: reader(192.168.31.3)

模拟master1宕机，手动停止mysql服务，观察monitor日志,master1的日志如下：

[root@monitor1 ~]# tail -f /var/log/mysql-mmm/mmm_mond.log

查看群集的最新状态

[root@monitor1 ~]# mmm_control show

master1(192.168.31.83) master/HARD_OFFLINE. Roles:

master2(192.168.31.141) master/ONLINE. Roles: reader(192.168.31.5), writer(192.168.31.2)

slave1(192.168.31.250) slave/ONLINE. Roles: reader(192.168.31.4)

slave2(192.168.31.225) slave/ONLINE. Roles: reader(192.168.31.3)

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

检查所有的db服务器群集状态

[root@monitor1 ~]# mmm_control checks all

master1 ping [last change: 2017/01/09 21:31:47] OK

master1 mysql [last change: 2017/01/09 22:03:07] ERROR: Connect error (host = 192.168.31.83:3306, user = mmm_monitor)! Can't connect to MySQL server on '192.168.31.83' (111)

master1 rep_threads [last change: 2017/01/09 21:31:47] OK

master1 rep_backlog [last change: 2017/01/09 21:31:47] OK: Backlog is null

slave1 ping [last change: 2017/01/09 21:31:47] OK

slave1mysql [last change: 2017/01/09 21:31:47] OK

slave1 rep_threads [last change: 2017/01/09 21:31:47] OK

slave1 rep_backlog [last change: 2017/01/09 21:31:47] OK: Backlog is null

master2 ping [last change: 2017/01/09 21:31:47] OK

master2 mysql [last change: 2017/01/09 21:57:32] OK

master2 rep_threads [last change: 2017/01/09 21:31:47] OK

master2 rep_backlog [last change: 2017/01/09 21:31:47] OK: Backlog is null

slave2 ping [last change: 2017/01/09 21:31:47] OK

slave2mysql [last change: 2017/01/09 21:31:47] OK

slave2 rep_threads [last change: 2017/01/09 21:31:47] OK

slave2 rep_backlog [last change: 2017/01/09 21:31:47] OK: Backlog is null

从上面可以看到master1能ping通，说明只是服务死掉了。

启动master1主机的mysql服务，观察monitor日志,master1的日志如下：

[root@monitor1 ~]# tail -f /var/log/mysql-mmm/mmm_mond.log

2017/01/09 22:16:56 INFO Check 'mysql' on 'master1' is ok!

2017/01/09 22:16:56 INFO Check 'rep_backlog' on 'master1' is ok!

2017/01/09 22:16:56 INFO Check 'rep_threads' on 'master1' is ok!

2017/01/09 22:16:59 FATAL State of host 'master1' changed from HARD_OFFLINE to AWAITING_RECOVERY

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

用如下命令将服务器上线：

[root@monitor1 ~]#mmm_controlset_onlinemaster1

查看群集最新状态

[root@monitor1 ~]# mmm_control show

master1(192.168.31.83) master/ONLINE. Roles:

master2(192.168.31.141) master/ONLINE. Roles: reader(192.168.31.5), writer(192.168.31.2)

slave1(192.168.31.250) slave/ONLINE. Roles: reader(192.168.31.4)

slave2(192.168.31.225) slave/ONLINE. Roles: reader(192.168.31.3)

可以看到主库启动不会接管主，只到现有的主再次宕机。

总结

(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端：/var/log/mysql-mmm/mmm_agentd.log

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

2、命令文件：

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

mmm_mond：监控进程的启动文件

mmm_backup：备份文件

mmm_restore：还原文件

mmm_control：监控操作命令文件

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

3、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]] - show checks status#执行监控检查操作

set_online<host> - set host <host> online #将host设置为online

set_offline<host> - set host <host> offline #将host设置为offline

mode - print current 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> #移除writer服务器为指定的host服务器(Only use --force if you know what you are doing!)

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

检查所有的db服务器群集状态：

[root@monitor1 ~]# mmm_control checks all

检查项包括：ping、mysql是否正常运行、复制线程是否正常等

检查群集环境在线状况：

[root@monitor1 ~]# mmm_control show

对指定的host执行offline操作：

[root@monitor1 ~]# mmm_controlset_offline slave2

对指定的host执行onine操作：

[root@monitor1 ~]# mmm_controlset_online slave2

执行write切换(手动切换):

查看当前的slave对应的master

[root@slave2 ~]# mysql -uroot -p123456 -e 'show slave status\G;'

mysql: [Warning] Using a password on the command line interface can be insecure.

*************************** 1. row ***************************

Slave_IO_State: Waiting for master to send event

Master_Host: 192.168.31.141

writer切换，要确保mmm_common.conf文件中的writer属性有配置对应的host,否则无法切换

[root@monitor1 ~]# mmm_controlmove_role writer master1

OK: Role 'writer' has been moved from 'master2' to 'master1'. Now you can wait some time and check new roles info!

[root@monitor1 ~]# mmm_control show

master1(192.168.31.83) master/ONLINE. Roles: writer(192.168.31.2)

master2(192.168.31.141) master/ONLINE. Roles: reader(192.168.31.5)

slave1(192.168.31.250) slave/ONLINE. Roles: reader(192.168.31.4)

slave2(192.168.31.225) slave/ONLINE. Roles: reader(192.168.31.3)

save从库自动切换到了新的master

[root@slave2 ~]# mysql -uroot -p123456 -e 'show slave status\G;'

mysql: [Warning] Using a password on the command line interface can be insecure.

*************************** 1. row ***************************

Slave_IO_State: Waiting for master to send event

Master_Host: 192.168.31.83

4、其它处理问题

如果不想让writer从master切换到backup（包括主从的延时也会导致写VIP的切换），那么可以在配置/etc/mysql-mmm/mmm_common.conf时，去掉<role write>中的backup

<role writer>#writer角色配置

hosts master1 #这里只配置一个Hosts

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

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

</role>

这样的话当master1出现故障了writer写操作不会切换到master2服务器，并且slave也不会指向新的master，此时当前的MMM之前对外提供写服务。

5、总结

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参数的影响。

至此，MySQL-MMM架构配置完毕。后续会写在此基础上实现读写分离、负载均衡机制。如图：