一、环境简述
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安装数据库并配置
123 | [root@db1 ~] # yum install mysql-server mysql [root@db1 ~] # service mysqld start [root@db1 ~] # mysqladmin -u root password 123.com |
12345678910111213 | [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配置如下:
12345678910 | [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配置如下:
12345678910 | [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分别执行:
123456 | 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查看如下说明主从复制成功。但是数据没过来,这是因为主从复制原理只同步配置完后的增删改记录,以后的数据是不能同步的,我们可以把主的数据库备份了,然后在送数据库还原。
12345 | [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访问
123 | [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文件(五台相同)
123456789101112131415161718192021222324252627282930313233343536373839 | [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文件
123 | [root@db ~] # vi /etc/mysql-mmm/mmm_agent.conf include mmm_common.conf this db1 #分别修改为本机的主机名,即db1、db2、db3和db4 |
6、修改管理端mmm_mon.conf文件
12345678910111213141516 | [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架构配置完毕。后续会写在此基础上实现读写分离、负载均衡机制。如图: