第十五课mysql8.0高可用架构之mha和mmm

MHA（Master

High

Availability）目前在MySQL高可用方面是一个相对成

解决方案，它由

DeNA公司youshimaton（现就职于MySQL高可用性环境下故障切换和主从提升的高可用公司）开发，是一套优秀的作为。在MySQL故障切换过程中，MHA能做到在0~30秒之内自动完成数据库的故障切换操作，并且在进行故障切换的过程中，MHA能在最大程度上保证数据的一致性，以达到真正意义上的高可用。MHA

还提供

主库切换的功能，能够安全地切换当前运行的主库到一个新的主库中(通过将从库提升为主库),大概0.5-2秒内即可完成。MHA介绍自动故障检测和自动故障转移MHA能够在一个已经存在的 环境中

MySQL，当检测到Master故障后能够实现

自动故障转移，通过鉴定出

”的Salve的relaylog，并将其应用到所有的Slave，这样MHA就能够保证各个slave之间的数据一致性，即使有些slave在主库 时还没有收到 的relay

log事件。一个slave节点能否成为候选的主节点可通过在配置文件中配

置它的优先级。由于master能够保证各个slave之间的数据一致性，所以所有的slave节 点都有希望成为主节点。在通常的replication环境中由于 中断而极容易产生的数据 一致性问题，在MHA中将不会发生。交互式（手动）故障转移MHA可以手动地实现故障转移，而不必去理会master的状态，即不

master状态，确认故障发生后可通过MHA

手动切换切换Master到不同的主机MHA能够在0.5-2秒内实现切换，0.5-2秒的写阻塞通常是可接受的，所以你甚至能在非期间就 切换master。诸如升级到高版本，升级到更快的服务器之类的工作，将会变得更容易。MHA介绍自动故障转移快主库

不存在数据一致性问题配置不需要对当前mysql环境做重大修改不需要添加额外的服务器(仅一台manager就可管理上百个replication)性能优秀，可工作在半同步

和异步，当mysql状态时，仅需要每隔N秒向master发送

包(默认3秒)，所以对性能无影响。你可以理解为MHA

的性能和简单的主从

框架性能一样。只要replication支持的 引擎，MHA都支持，不会局限于innodbMHA优势MHA由Manager节点和Node节点组成。MHA

Manager可以单独部署在一 立的机器上管理多个master-slave集群，也可以部署在一台slave节点上。MHANode运行在每台MySQL服务器上，MHAManager会

定时探测集群中的master节点，当master出现故障时，它可以自动将 数据的slave

提升为新的master，然后将所有其他的slave重新指向新的master。整个故障转移过程

对应用程序完全透明。MHA组成的master保存二进制日志事件（binlogevents）更新的slave；从宕机;识别含有应用差异的中继日志（relay

log）到其他的slave；应用从master保存的二进制日志事件（binlog

events）；提升一个slave为新的master；使其他的slave连接新的master进行

；MHA工作原理地址：

/yoshinorim/mha4mysql-manager/releases/tag/v0.58准备四个节点，其中一个是管理节点，三个是一主两从的环境在所有节点上安装node节点yum

install

-y

perl-DBD-MySQLrpm

-ivh mha4mysql-node-0.58-0.noarch.rpm在管理节点上安装manager节点#先安装依赖wget7.noarch.rpm[root@server1

data]#

rpm

-ivh

epel-release-latest-7.noarch.rpmyum

install

perl-DBD-MySQL

perl-Config-Tiny

perl-Log-Dispatch

perl-Parallel-ForkManager

-yrpm

-ivh mha4mysql-manager-0.58-0.el7.noarch.rpm在四个节点的/etc/hosts中添加主机内容：192.168.237.132

mycat192.168.237.128

master192.168.237.130

slave1192.168.237.131

slave2在管理节点创建配置文件manager_host$

cat

f[server

default]#

mysql

user

and

passworduser=rootpassword=mysqlssh_user=root#

working

directory

on

themanagermanager_workdir=/var/log/masterha/app1#

working

directory

on

MySQL

serversremote_workdir=/var/log/masterha/app1repl_user=replrepl_password=mysql[server1]hostname=masterport=3308master_binlog_dir=/usr/local/mysql/data[server2]hostname=slave1port=3308master_binlog_dir=/usr/local/mysql/data[server3]hostname=slave2port=3308master_binlog_dir=/usr/local/mysql/data两个节点的f文件：port

=

3308server_id

=

2#

socket

=

.....innodb_data_file_path=ibdata1:76M;ibdata2:50M:autoextend#innodb-read-only=1innodb_buffer_pool_size=200Minnodb_log_file_size=30Minnodb_log_files_in_group=3innodb_undo_directory=/usr/local/mysql/innodb_locks_unsafe_for_binlog=on#

Remove

leading

#

to

set

options

mainly

useful

for

reporting

servers.#

The

server

defaults

are

faster

for

transactions

and

fast

SELECTs.#

Adjust

sizes

as

needed,

experiment

to

find

the

optimal

values.#

join_buffer_size

=

128M#

sort_buffer_size

=

2M#

read_rnd_buffer_size

=

2Msecure_file_priv=/tmp/#skip-grant-tablescharacter_set_server=utf8skip-slave-start=1sql_mode=NO_ENGINE_SUBSTITUTION,STRICT_TRANS_TABLESlog-bin=mysql-binrelay_log_purge=0log-slave-updates=trueMHA

manager通过SSH所有的node节点，各个node节点也同样需要通过SSH

来文件，所以有必要在每一个node和manager上配置SSH相互发送不同的relay

log无

登陆。ssh-keygen

-trsacat

id_rsa.pub

>>authorized_keys[root@mycat

.ssh]#

catauthorized_keys设置

和软连接mkdir

/var/log/masterha/app1

-pln

-s

/usr/local/mysql/bin/mysqlbinlog/usr/bin/mysqlbinlogln

-s

/usr/local/mysql/bin/mysql

/usr/bin/mysqlMHAmanager可通过masterha_check_sshmasterha_check_ssh--检测SSH连接是否配置正常#f[root@mycat

app1]#

masterha_check_ssh

--

fThu

Jun

22

21:08:55

2017

-

[warning]

Global

configuration

file

/etc/maf

notfound.Skip

.Thu

Jun

22

21:08:55

2017

-

[info]Reading

application

default

configurations

fromf.. Thu

Jun

22

21:08:55

2017

-

[info]

Reading

server

configurations

fromf..Thu

Jun

22

21:08:55

2017

-

[info]StartingSSH

connection

tests..Thu

Jun

22

21:08:56

2017

-

[debug]Thu

Jun 22

21:08:55

2017

-

[debug]toroot@slave1(192.168.237.130:22)..Connecting

via

SSH

from

root@master(192.168.237.128:22)Warning:

Permanently

added

'192.168.237.130'

(ECDSA)

to

the

list

of

knownhosts.

Thu

Jun 22

21:08:55

2017

-

[debug]

ok.Thu

Jun 22

21:08:55

2017

-

[debug]

Connecting

via

SSHfrom

root@master(192.168.237.128:22)toroot@slave2(192.168.237.131:22)..Warning:

Permanently

added

'192.168.237.131'

(ECDSA)

to

the

list

of

known

hosts.Thu

Jun 22

21:08:56

2017

-

[debug]

ok.Thu

Jun

22

21:08:56

2017

-

[debug]root@master(192.168.237.128:22)..Jun 22

21:08:56

2017

-

[debug]Thu

Jun 22

21:08:55

2017

-

[debug]toThuThuJun 22

21:08:56

2017

-

[debug]Connecting

via

SSHfrom

root@slave1(192.168.237.130:22)ok.Connecting

via

SSH

from

root@slave1(192.168.237.130:22)to

root@slave2(192.168.237.131:22)..Warning:

Permanently

added

'192.168.237.131'

(ECDSA)

to

the

list

of

known[debug]

ok.Connectingvia

SSH

from

root@slave2(192.168.237.131:22)hosts.

Thu

Jun 22

21:08:56

2017

-Thu

Jun

22

21:08:57

2017

-

[debug]Thu

Jun 22

21:08:56

2017

-

[debug]toroot@master(192.168.237.128:22)..Thu

Jun 22

21:08:56

2017

-

[debug]Thu

Jun 22

21:08:56

2017

[debug]ok.Connecting

via

SSH

from

root@slave2(192.168.237.131toroot@slave1(192.168.237.130:22)..Thu

Jun 22

21:08:57

2017

-

[debug]

ok.在管理节点检查

配置为了让MHA正常工作，所有的master和slave必须在配置文件中正确配置，MHA可通过masterha_check_repl

检测

是否正确配置[root@mycat

.ssh]#

masterha_check_repl

--

f……ThuJun2221:58:242017-

[info]

Alive

Servers:ThuJun2221:58:242017-

[info]

master(192.168.237.128:3308)ThuJun2221:58:242017-

[info]

slave1(192.168.237.130:3308)ThuJun2221:58:242017-

[info]

slave2(192.168.237.131:3308)ThuJun2221:58:242017-

[info]

Alive

Slaves:ThuJun2221:58:242017-

[info]

slave1(192.168.237.130:3308)Version=5.7.17-log

(oldest

major

version

between

slaves)

log-bin:enabled Thu

Jun22

21:58:24

2017 -

[info]

Replicatingfrom192.168.237.128(192.168.237.128:3308)Thu

Jun 22

21:58:24

2017-

[info]

slave2(192.168.237.131:3308)slaves)

log-bin:enabledVersion=5.7.17-log

(oldest

major

version

between……MySQL

Replication

Health

is

OK.开启Manager当你正确配置了mysql

，正确安装了manager和node节点，SSH配置也正确，那么

下一步就是开启manager，可通过masterha_manager命令开启manager_host$

nohup

masterha_manager

-->/var/log/masterha/app1/mha_manager.log

<

/dev/null

&f检查manager状态当MHA manager启动

以后，如果没有异常则不会打印任何信息。可通过masterha_check_status命令检查manager的状态，以下是范例manager_host$

masterha_check_status

--

fapp1

(pid:3287)

is

running(0: _OK),

master:master终止manager你

可

以

通

过 masterha_stop

命

令

来

停

止manager manager_host$

masterha_stop

--f Stopped

app1

successfully.测试master的自动故障转移现在master运行正常，manager

也正常，下一步就是停止master，测试自动故障转移，可以简单地停止master上的mysqld服务[root@master

bin]#

/etc/init.d/mysql.serverstop Shutting

down

MySQL............

SUCCESS!这时候检查manager的log日志，看看slave1是否成功成为新的master，并且slave2从slave1中

。查看MHA切换日志vi

/var/log/masterha/app1/mha_manager.log-----

Failover

Report

-----app1:

MySQL

Master

failover

master

to

slave1succeededCheck

MHAMaster

master

is

down!Manager

logs

at

mycat

fordetails.

Started automated(non-interactive)failover.The

latest

slave

slave1(192.168.237.130:3308)

has

all

relay

logs

forrecovery. Selected

slave1

as

a

new

master.slave1:

OK:

Applying

all

logs

succeeded.slave2:

This

host

has

the

latest

relay

log

events.Generating

relay

diff

files

from

the

latest

slavesucceeded.slave2:

OK:

Applying

all

logs

succeeded.

Slave

started,

replicating

fromslave1.

slave1:

Resetting

slave

info

succeeded.Master

failover

to

slave1(192.168.237.130:3308)

completed

successfully查看slave1上的slave进程状态：

mysql>

show

slavestatus\G Emptyset

(0.00sec)查看slave2上的slave进程状态：

mysql>

show

slavestatus\G***************************

1.

row***************************Slave_IO_State:Waiting

for

master

to

send

eventMaster_Host:

192.168.237.130Master_User:

repl

Master_Port:

3308Connect_Retry:

60Master_Log_File:

mysql-bin.000015Read_Master_Log_Pos:

520Relay_Log_File:

slave2-relay-bin.000002

Relay_Log_Pos:

320Relay_Master_Log_File:

mysql-bin.000015Slave

IO

Running:

Yes

Slave

SQL

Running:Yes[root@192.168.0.20

~]# cat

/etc[server

default]fmanager_workdir=/var/log/masterha/app1.log

//设置manager的工作manager_log=/var/log/masterha/app1/manager.log //设置manager的日志master_binlog_dir=/data/mysql//设置master保存binlog的位置，以便MHA可以找到master的日志，我这里的也就是mysql的数据master_ip_failover_script=/usr/local/bin/master_ip_failover//设置自动failover时候的切换master_ip_online_change_script=/usr/local/bin/master_ip_online_change//设置手动切换时候的切换脚//设置mysql中root用户的

，这个

是前文中创建

用户的那个本password=12user=root设置用户root_interval=1//设置

主库，发送

包的时间间隔，默认是3秒，尝试三次没有回应的时候自动进行failover remote_workdir=/tmp

//设置远端mysql在发生切换时binlog的保存位置repl_password=123456

//设置

用户的repl_user=repl

//设置

环境中的

用户名report_script=/usr/local/send_report//设置发生切换后发送的的脚本secondary_check_script=

/usr/local/bin/masterha_secondary_check

-s

server03

-s

server02（该

的主要作用是关闭主机放在发生脑裂,这里没有使用）shutdown_script=""//设置故障发生后关闭故障主机ssh_user=root//设置ssh的登录用户名[server1]hostname=

192.168.0.50port=3306[server2]hostname=

192.168.0.60port=3306candidate_master=1//设置为候选master，如果设置该参数以后，发生主从切换以后将会将此从库提升为主库，即使这个主库不是集群中事件

的slave

check_repl_delay=0

//默认情况下如果一个slave master

100M的relay

logs的话，MHA将不会选择该slave作为一个新的master，因为对于这个slave的恢复需要花费很长时间，通过设置check_repl_delay=0,MHA触发切换在选择一个延时，这个参数对于设置了candidate_master=1的主机非常有用，因为这个候选主在切换新的master的时候将会忽略的过程中一定是新的master[server3]hostname=192.168.0.70port=3306[root@192.168.0.20~]#设置relay

log的清除方式（在每个slave节点上）：

[root@192.168.0.60

~]# mysql-e

'set

globalrelay_log_purge=0'

[root@192.168.0.70

~]# mysql-e

'setglobal

relay_log_purge=0'

注意：MHA

在发生切换的过程中，从库的恢复过程中依赖于relaylog的相关信息，所以这里要将relay

log的自动清除设置为OFF，采用手动清除relaylog的方式。在默认情况下，从服务器上的中继日志会在SQL线程执行完毕后被自动删除。但是在MHA

环境中，这些中继日志在恢复其他从服务器时可能会被用到，因此需要禁用中继日志的自动删除功能。先关闭两个从库的slave进程mysql>

stop

slave;在主库上执行

操作，而从库没办法同步mysql>

insertinto

temp2

values(5000,'abc');Query

OK,

1

row

affected

(0.00

sec)主库MySQL直接关闭，两个从库开启

进程，依旧没有数据[root@master

~]#

/etc/init.d/mysql.serverstop Shutting

down

MySQL....

SUCCESS!mysql>

select

*

from

temp2

where

id=5000;Empty

set

(0.00

sec)开启mha进程，发现完成主从切换-----

Failover

Report

-----app1:MySQL

Master

failover

master

to

slave1succeeded Master

master

is

down!……Master

failover

to

slave1(192.168.237.130:3308)

completed

successfully.查看新的主从上是否有5000这条记录mysql>

select

*

from

temp2

where

id=5000;+------

+------

+|

id

|

name

|+------

+------

+|

5000

|

abc

|查看增量binlog日志[root@mycat

~]# /usr/local/mysql/bin/mysqlbinlog

-v/var/log/masterha/app1/saved_master_binlog_from_master_3308_20170628203943.binlog验证MHA先获取日志再切换手动failover，这种场景意味着在业务上没有启用MHA自动切换功能，当主服务器故障时，人工手动调用MHA来进行故障切换操作，具体命令如下：先关闭mha进程，确保不会自动执行切换[root@mycat

~]#

masterha_stop

--

f再关闭maser主库[root@master

~]#

/etc/init.d/mysql.server

stopShutting

down

MySQL............

SUCCESS!执行手动切换[root@mycat

~]#

masterha_master_switch

--master_state=dead

-- f

----new_master_ip=192.168.237.131

--dead_master_host=master

--dead_master_port=3308new_master_port=3308……-----

Failover

Report

-----app1:

MySQL

Master

failover

master

to

slave1succeededCheck

MHAMaster

master

is

down!Manager

logs

at

mycat

fordetails.

Started

manual(interactive)failover.The

latest

slave

slave1(192.168.237.130:3308)

has

all

relay

logs

for

recovery.Selected

slave1

as

a

new

master.slave1:

OK:Applying

all

logs

succeeded.slave2:

This

host

has

the

latest

relay

logevents.Generating

relay

diff

files

from

the

latest

slavesucceeded.slave2:

OK:

Applying

all

logs

succeeded.

Slave

started,

replicating

from

slave1.slave1:

Resetting

slave

info

succeeded.Master

failover

to

slave1(192.168.237.130:3308)

completed

successfully.MHA手动切换查看slave1的配置：mysql>

show slavestatus\GEmpty

set

(0.00

sec)查看slave2的配置：mysql>

show slave

status\G***************************

1.

row***************************

Slave_IO_State:Waiting

for

master

to

send

eventMaster_Host:

192.168.237.130Master_User:

repl Master_Port:

3308Connect_Retry:

60Master_Log_File:

mysql-bin.000022Read_Master_Log_Pos:

531Relay_Log_File:

slave2-relay-bin.000002

Relay_Log_Pos:

320Relay_Master_Log_File:

mysql-bin.000022Slave_IO_Running:

Yes

Slave_SQL_Running:YesMHA手动切换切换必须满足以下条件才会为了保证数据完全一致性，在最快的时间内完成切换，MHA的切换成功，否则会切换失败。所有slave的IO线程都在运行所有slave的SQL线程都在运行所有的show

slave

status的输出中Seconds_Behind_Master参数小于或者等于

running_updates_limit秒，如果在切换过程中不指定running_updates_limit,那么默认情况下running_updates_limit为1秒。在master端，通过show processlist输出，没有一个更新花费的时间大于running_updates_limit秒。切换步骤如下：首先，停掉MHA

：[root@mycat

~]#

masterha_stop

--其次，进行切换操作（模拟f切换主库操作，原主库192.168.237.128变为slave，192.168.237.131提升为新的主库）[root@mycat

~]#

masterha_master_switch

-- f

--master_state=alive--new_master_host=slave2

--new_master_port=3308

--orig_master_is_new_slave

--running_updates_limit=10000master变为slave节点，如果不加此-orig_master_is_new_slave切换时加上此参数是将原参数，原来的master将不启动--running_updates_limit=10000,故障切换时,候选master如果有延迟的话，mha切换不能成功，加上此参数表示延迟在此时间范围内都可切换（单位为s），但是切换的时间长短是由

recover时relay日志的大小决定MHA

切换检查原master的状态： mysql>

show

slavestatus\G***************************

1.

row***************************Slave_IO_State:Waiting

for

master

to

send

eventMaster_Host:

slave2Slave_IO_Running:

YesSlave_SQL_Running:

Yes检查slave1的状态：mysql>

show

slave

status\G;***************************

1.

row***************************Slave_IO_State:

Waiting

for

master

to

sendeventMaster_Host:

192.168.237.131Slave_IO_Running:

YesSlave_SQL_Running:

Yes检查slave2的状态：mysql>

show

slave

status\GEmpty

set

(0.00

sec)MHA

切换在master节点上执行ifconfig

eno16777736:2

192.168.237.120/24在

节点上配置/usr/local/bin/master_ip_failover

详见

中的对应文件在

节点的

f中添加此文件master_ip_failover_script=/usr/local/bin/master_ip_failover测试当把master关机之后，VIP漂移到了新的主节点上[root@master

bin]#/etc/init.d/mysql.server

stopShutting

downMySQL............SUCCESS!MHA

vip漂移MMM（Master-Master

replication

manager

for

MySQL）是一套支持双主故障切换和双

常管理的

程序。MMM

使用Perl语言开发，主要用来和管理MySQLMaster-Master（双主）

，虽然叫做双主，但是业务上同一时刻只允许对一个主进行写入，另一台备选主上提供部分读服务，以加速在主主切换时刻备选主的预热，可以说MMM这套

程序一方面实现了故障切换的功能，另一方面其附加的工具脚本也可以实现多个slave的read负载均衡。M

M

M提供了自动和手动两种方式移除一组服务器中延迟较高的服务器的虚拟ip，同时它还可以备份数据，实现两节点之间的数据同步等。由于MM

M无法完全的保证数据一致性，所以M

M

M适用于对数据的一致性要求不是很高，但是又想最大程度的保证业务可用性的场景。对于那些对数据的一致性要求很高的业务，非常不建议采用M

M

M这种高可用架构。MMM介绍MMM介绍配置两主一从的环境192.168.0.60和192.168.0.50互为主从，192.168.0.40为192.168.0.60的从库

db1（192.168.0.60）上：

server-id

=

1log_slave_updates

=

1auto-increment-increment=

2auto-increment-offset

=1

db2（192.168.0.50）上

：

server-id

=2log_slave_updates

=

1auto-increment-increment

=

2auto-increment-offset

=2

db3（192.168.0.40）log_slave_updates

=上

：

server-id

=

31通过change

master语句建立

关系：CHANGE

MASTER

TOMASTER_HOST='192.168.237.130',MASTER_PORT=3308,MASTER_USER='repl',MASTER_PASSWORD='mysql',MASTER_LOG_FILE='mysql-bin.000017',MASTER

LOG

POS=234;mysql-mmm

，在所有服务器上安装：[root@192.168.0.60

~]#wget[root@192.168.0.60

~]#mv

:mmm2:mysql-mmm-2.2.1.tar.gz[root@192.168.0.60

~]#tar

xf

mysql-mmm-2.2.1.tar.gz[root@192.168.0.60

~]#mysql-mmm-2.2.1.tar.gzcd

mysql-mmm-2.2.1[root@192.168.0.60 mysql-mmm-2.2.1]#make

install配置agent端的配置文件，需要在master1，master2，slave1上分别配置。在db1主机上配置agent配置文件：[root@192.168.0.60

~]#

cd

/etc/mysql-mmm/[root@192.168.0.60

mysql-mmm]#

cat

mon.confwritereth0/var/run/mmm_agentd.pid/usr/lib/mysql-mmm/replmysqlmmm_agentmmm_agent192.168.237.128masterdb2active_master_role<host

default>cluster_interface

pid_pathbin_pathreplication_user192.168.237.130masterdb1192.168.237.131slavedb1,

db2192.168.237.120exclusivedb2,

db3192.168.237.121,192.168.237.122balancedreplication_passwordagent_useragent_password</host><host

db1>ipmodepeer</host><host

db2>ipmodepeer</host><host

db3>ipmode</host><rolewriter>hostsipsmode</role><rolereader>hostsipsmode</role>其中replication_user用于检查

的用户，agent_user为agent的用户，mode标明是否为主或者备选主，或者从库。mode

exclusive主为独占模式，同一时刻只能有一个主，<rolewrite>中hosts表示目前的主库和备选主的真实主机ip或者主机名，ips为对外提 供的虚拟ip地址，<role

readr>中hosts代表从库真实的ip和主机名，ips代表从库的虚拟ip地址。由于master2和slave1两台主机也要配置agent配置文件，

直接把mon.conf从master1拷贝到master2和slave1两台主机的/etc/mysql-mmm下。分别在db1，db2，db3三台主机的/etc/mysql-

mmm_agent.conf文件，分别用不同的字符标识，注意这三台机器的this

db1这块要想，比如本环境

中，db1要配置this

db1，db2要配置为this

db2，而db3要配置为this

db3。在db1（192.168.237.128）上：[root@master

mysql-mmm]#

cat

mmm_agent.confinclude

mon.confthis

db1在db2（192.168.237.130）上：[root@slave1

mysql-mmm]#

cat

mmm_agent.confinclude

mon.confthis

db2在db3（192.168.237.131）上：[root@slave2

mysql-mmm]#

cat

mmm_agent.confinclude

mon.confthis

db3在mycat（192.168.237.132）配置monitor的配置文件：[root@mycat

mysql-mmm]#

cat

mmm_mon.conf

includemon.conf127.0.0.1/var/run/mmm_mond.pid/usr/lib/mysql-mmm//var/lib/misc/mmm_mond.status192.168.237.128,

192.168.237.130,192.168.237.131<monitor>ippid_pathbin_pathstatus_path_ips</monitor><host

default>mmm_monitormmm_monitormonitor_usermonitor_password</host>debug

0这里只在原有配置文件中的default>中配置了用于_ips添加了整个架构被的用户。主机的ip地址，而在<host创建

用户，这里需要创建3个用户，具体描述如下：在3台服务器(db1,db2,db3）进行

，因为我之前的主主，以及主从已经是ok的，的账号之前已经有了，所以这里就所以我在其中一台服务器执行就ok了。用于两个账号。mysql>

GRANT

SUPER,

REPLICATION

CLIENT,

PROCESS

ON

*.*

TO'mmm_agent'@'192.168.237.%'

IDENTIFIED

BY

'mmm_agent';Query

OK,

0

rows

affected

(0.08

sec)mysql>

GRANT

REPLICATION

CLIENT

ON*.*

TO'mmm_monitor'@'192.168.237.%'

IDENTIFIED

BY

'mmm_monitor';Query

OK,

0

rows

affected

(0.00

sec)mysql>

flush

privileges;Query

OK,

0

rows

affected

(0.03sec)

mysql>Yum

install

–y

cpanYum

install

–y

gcccpan

-i

Algorithm::Diff

Class::Singleton

DBI

DBD::mysql

Log::DispatchLog::Log4perl

Mail::Send

Net:: Proc::Daemon

Time::HiResParams::ValidateNet::ARPcpan

-i

Thread:Queue启动agent服务。最后分别在db1，db2，db3上启动agent，并在mycat（192.168.237.132）上启动monitor程序：[root@master

mysql-mmm]#

/etc/init.d/mysql-mmm-agent

startDaemon

bin:

'/usr/sbin/mmm_agentd'Daemon

pid:

'/var/run/mmm_agentd.pid'Starting

MMM

Agent

daemon...

Ok启动monitor：startmysql-mmm]#

/etc/init.d/mysql-mmm-monitor'/usr/sbin/mmm_mond'[root@mycatDaemon

bin:Daemon

pid:'/var/run/mmm_mond.pid'Starting

MMM Monitor

daemon:

Ok其中agent的日志存放在/var/log/mysql-mmm/mmm_agentd.log，monitor日志放

在/var/log/mysql-mmm/mmm_mond.log，启动过程中有什么问题，通常日志都会 有详细的记录。在monitor主机上检查集群主机的状态：[root@mycat

mysql-mmm]#

mmm_control

checks

all

db2db2

mysql[last[lastchange:

2017/06/29change:

2017/06/29OK

db2

rep_threadschange:

2017/06/2923:31:47]23:31:47]

OK23:31:47][lastOKchange:

2017/06/29

23:31:47]

OK:

Backlog

isdb2

rep_backlog

[lastnull

db3change:2017/06/2923:31:47][lastchange:

2017/06/29[lastOK23:31:47]

OKdb3

mysqldb3[last

change:

2017/06/29

23:31:47][last change:2017/06/2923:31:47]

OK:

Backlog

isrep_threadsOKdb3

rep_backlognull

db12017/06/29[last

change:OK23:31:47]

OK23:31:47][last change:

2017/06/29db1

mysqldb1[last

change:

2017/06/29

23:31:47]rep_threadsOK[last change:

2017/06/2923:31:47]

OK:

Backlog

isdb1

rep_backlognullY在

monitor

主

机

上 检查

集

群

环

境

状

况

：[root@192.168.0.30

~]# mmm

control

showdb1(192.168.237.128)

master/AWAITING_RECOVERY老.男R孩oIlT教es育:，只培养技术db2(192.168.237.130)

master/AWAITING_RECOVE .

Roles:online（上线）所有主机：使用下面

令将相关主机online[root@mycat

mysql-mmm]#

mmm_control

set_online

db1OK:

State

of

'db1'

changed

to

ONLINE.

Now

you

can

wait some

time

and

checkits

new

roles![root@mycat

mysql-mmm]#

mmm_control

set_online

db2OK:

State

of

'db2'

changed

to

ONLINE.

Now

you

can

wait some

time

and

checkits

new

roles![root@mycat

mysql-mmm]#

mmm_control

set_online

db3OK:

State

of

'db3'

changed

to

ONLINE.

Now

you

can

wait some

time

and

checkits

new

roles![root@mycat

mysql-mmm]#

mmm_control

show

db1(192.168.237.128)master/ONLINE.

Roles:

writer(192.168.237.120)db2(192.168.237.130)

master/ONLINE.

Roles:reader(192.168.237.121)db3(192.168.237.131)

slave/ONLINE.

Roles:reader(192.168.237.122)

。模拟db2（192.168.237.130[root@192.168.237.132

~]#）宕机，手动停止mysql服务，观察monitor日志：tail

-f

/var/log/mysql-mmm/mmm_mond.log2017/06/26

22:52:29

FATAL

State

of

hos