binlog、Xtrabackup 、Mysql主从不同步解决方法、auto_increment、mysql环形主从配置、MHA...

最新推荐文章于 2023-01-12 11:23:46 发布

chuangai7820

最新推荐文章于 2023-01-12 11:23:46 发布

阅读量551

点赞数

文章标签：数据库运维 shell

原文链接：https://my.oschina.net/u/3992081/blog/2995284

版权

binlog模式分三种（row，statement，mixed）

1.Row

日志中会记录成每一行数据被修改的形式，然后在slave端再对相同的数据进行修改，只记录要修改的数据，只有value，不会有sql多表关联的情况。
优点：在row模式下，bin-log中可以不记录执行的sql语句的上下文相关的信息，仅仅只需要记录那一条记录被修改了，修改成什么样了，所以row的日志内容会非常清楚的记录下每一行数据修改的细节，非常容易理解。而且不会出现某些特定情况下的存储过程和function，以及trigger的调用和出发无法被正确复制问题。
缺点：在row模式下，所有的执行的语句当记录到日志中的时候，都将以每行记录的修改来记录，这样可能会产生大量的日志内容。

mysql> insert into username(username) select * from aa;
ERROR 1146 (42S02): Table 'test.username' doesn't exist
mysql> insert into user(username) select * from aa;
Query OK, 1 row affected (0.01 sec)
Records: 1 Duplicates: 0 Warnings: 0

查看binlog

root@xuebinbin:/vobiledata/mysqllog# mysqlbinlog mysql-bin.000017

BINLOG '
63EfUBNQAAAALgAAAA8CAAAAAA8AAAAAAAEABHRlc3QABHVzZXIAAgIPAi0AAA==
63EfUBdQAAAAJgAAADUCAAAAAA8AAAAAAAEAAv/8BAAFYmFveXU=
'/*!*/;
### INSERT INTO test.user
### SET
###   @1=4 /* SHORTINT meta=0 nullable=0 is_null=0 */
###   @2='baoyu' /* VARSTRING(45) meta=45 nullable=0 is_null=0 */
# at 565
#120806 0:27:39 server id 80 end_log_pos 592    Xid = 20
COMMIT/*!*/;
DELIMITER ;
# End of log file
ROLLBACK /* added by mysqlbinlog */;
/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;

由此可见，row模式是针对每一行的数据，而于关联表无关，它把关联中的相应数据记录在log中。这样一来会产生大量的数据。

2.statement

每一条会修改数据的sql都会记录到master的binlog中，slave在复制的时候sql进程会解析成和原来master端执行多相同的sql再执行。
优点：在statement模式下首先就是解决了row模式的缺点，不需要记录每一行数据的变化减少了binlog日志量，节省了I/O以及存储资源，提高性能。因为他只需要记录在master上所执行的语句的细节以及执行语句的上下文信息。
缺点：在statement模式下，由于他是记录的执行语句，所以，为了让这些语句在slave端也能正确执行，那么他还必须记录每条语句在执行的时候的一些相关信息，也就是上下文信息，以保证所有语句在slave端被执行的时候能够得到和在master端执行时候相同的结果。另外就是，由于mysql现在发展比较快，很多的新功能不断的加入，使mysql的复制遇到了不小的挑战，自然复制的时候涉及到越复杂的内容，bug也就越容易出现。在statement中，目前已经发现不少情况会造成Mysql的复制出现问题，主要是修改数据的时候使用了某些特定的函数或者功能的时候会出现，比如：sleep()函数在有些版本中就不能被正确复制，在存储过程中使用了last_insert_id()函数，可能会使slave和master上得到不一致的id等等。由于row是基于每一行来记录的变化，所以不会出现，类似的问题。

mysql> insert into user(username) values('xuebinbin');
ERROR 1598 (HY000): Binary logging not possible. Message: Transaction level 'READ-COMMITTED' in InnoDB is not safe for binlog mode 'STATEMENT'
mysql> SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ
    -> ;
Query OK, 0 rows affected (0.00 sec)

mysql> insert into user(username) values('xuebinbin');
Query OK, 1 row affected (0.00 sec)

查看binlog
root@xuebinbin:/vobiledata/mysqllog# mysqlbinlog mysql-bin.000008

BEGIN
/*!*/;
# at 174
#120806 14:47:35 server id 80 end_log_pos 202    Intvar
SET INSERT_ID=2/*!*/;
# at 202
#120806 14:47:35 server id 80 end_log_pos 311    Query   thread_id=5   exec_time=0   error_code=0
use test/*!*/;
SET TIMESTAMP=1344235655/*!*/;
insert into user(username) values('xuebinbin')
/*!*/;
# at 311
#120806 14:47:35 server id 80 end_log_pos 338    Xid = 20
COMMIT/*!*/;
# at 338
#120806 14:53:18 server id 80 end_log_pos 357    Stop
DELIMITER ;
# End of log file
ROLLBACK /* added by mysqlbinlog */;
/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;

结果发现statement是以sql记录形式记录的。这样的话一个sql就只记录一条，减少了大量的数据存储。

3.Mixed

从官方文档中看到，之前的 MySQL 一直都只有基于 statement 的复制模式，直到 5.1.5 版本的 MySQL 才开始支持 row 复制。从 5.0 开始，MySQL 的复制已经解决了大量老版本中出现的无法正确复制的问题。但是由于存储过程的出现，给 MySQL Replication 又带来了更大的新挑战。另外，看到官方文档说，从 5.1.8 版本开始，MySQL 提供了除 Statement 和 Row 之外的第三种复制模式：Mixed，实际上就是前两种模式的结合。在 Mixed 模式下，MySQL 会根据执行的每一条具体的 SQL 语句来区分对待记录的日志形式，也就是在 statement 和 row 之间选择一种。新版本中的 statment 还是和以前一样，仅仅记录执行的语句。而新版本的 MySQL 中对 row 模式也被做了优化，并不是所有的修改都会以 row 模式来记录，比如遇到表结构变更的时候就会以 statement 模式来记录，如果 SQL 语句确实就是 update 或者 delete 等修改数据的语句，那么还是会记录所有行的变更。

Mysql Binlog日志分析

通过MysqlBinlog指令查看具体的mysql日志，如下:

///

SET TIMESTAMP=1350355892/*!*/;

BEGIN

/*!*/;

# at 1643330

#121016 10:51:32 server id 1 end_log_pos 1643885 Query thread_id=272571 exec_time=0 error_code=0

SET TIMESTAMP=1350355892/*!*/;

Insert into T_test….)

/*!*/;

# at 1643885

#121016 10:51:32 server id 1 end_log_pos 1643912 Xid = 0

COMMIT/*!*/;

///

1.开始事物的时间:

SET TIMESTAMP=1350355892/*!*/;

BEGIN

2.sqlevent起点

#at 1643330 :为事件的起点，是以1643330字节开始。

3.sqlevent 发生的时间点

#121016 10:51:32:是事件发生的时间，

4.serverId

server id 1 :为master 的serverId

5.sqlevent终点及花费时间，错误码

end_log_pos 1643885:为事件的终点，是以1643885 字节结束。

execTime 0: 花费的时间

error_code=0:错误码

Xid:事件指示提交的XA事务

使用 Xtrabackup 在线对MySQL做主从复制

发表于 2015-12-14 | 更新于: 2015-12-14 | 分类于 MySQL | | 阅读次数: 1581

1. 说明

1.1 xtrabackup

mysqldump对于导出10G以下的数据库或几个表，还是适用的，而且更快捷。一旦数据量达到100-500G，无论是对原库的压力还是导出的性能，mysqldump就力不从心了。Percona-Xtrabackup备份工具，是实现MySQL在线热备工作的不二选择，可进行全量、增量、单表备份和还原。（但当数据量更大时，可能需要考虑分库分表，或使用 LVM 快照来加快备份速度了）

2.2版本 xtrabackup 能对InnoDB和XtraDB存储引擎的数据库非阻塞地备份，innobackupex通过perl封装了一层xtrabackup，对MyISAM的备份通过加表读锁的方式实现。2.3版本 xtrabackup 命令直接支持MyISAM引擎。

XtraBackup优势：

无需停止数据库进行InnoDB热备
增量备份MySQL
流压缩到传输到其它服务器
能比较容易地创建主从同步
备份MySQL时不会增大服务器负载

1.2 replication

为什么要做主从复制？
我想这是要在实施以前要想清楚的问题。是为了实现读写分离，减轻主库负载或数据分析？为了数据安全，做备份恢复？主从切换做高可用？
大部分场景下，以上三个问号一主一从都能够解决，而且任何生产环境都建议你至少要有一个从库，假如你的读操作压力特别大，甚至要做一主多从，还可以不同的slave扮演不同的角色，例如使用不同的索引，或者不同的存储引擎，或使用一个小内存server做slave只用于备份。（当然slave太多也会对master的负载和网络带宽造成压力，此时可以考虑级联复制，即 A->B->C ）

还有需要考虑的是，一主一从，一旦做了主从切换，不通过其它HA手段干预的话，业务访问的还是原IP，而且原主库很容易就作废了。于是主-主复制就产生了，凭借各自不同的 server-id ，可以避免 “A的变化同步到B，B应用变化又同步到A” 这样循环复制的问题。但建议是，主主复制，其中一个主库强制设置为只读，主从切换后架构依然是可用的。

复制过程是slave主动向master拉取，而不是master去推的，所以理想情况下做搭建主从时不需要master做出任何改变甚至停服，slave失败也不影响主库。

复制类型
- 基于语句的复制：STATEMENT，在主服务器上执行的SQL语句，在从服务器上执行同样的语句，有可能会由于SQL执行上下文环境不同而是数据不一致，例如调用NOW()函数。MySQL在5.7.7以前默认采用基于语句的复制，在 5.7.7 及以后版本默认改用 row-based。
- 基于行的复制：ROW，把改变的内容复制过去，而不是把命令在从服务器上执行一遍。从mysql5.0开始支持，能够严格保证数据完全一致，但此时用mysqlbinlog去分析日志就没啥意义。因为任何一条update语句，都会把涉及到的行数据全部set值，所以binlog文件会比较大。
  （遇到的一个坑是，迁移时，从库改正了字段默认值定义，但数据在主库更改后，即使产生的新数据默认值是正确的，但基于行的复制依然用不正确的值字段全部更新了）
- 混合类型的复制: MIXED，默认采用基于语句的复制，一旦发现基于语句的无法精确的复制时，就会采用基于行的复制。
mysql系统库mysql库里面表的日志记录格式需要说明：在通过如INSERT、UPDATE、DELETE、TRUNCATE等方式直接修改数据的语句，使用binlog_format指定的方式记录，但使用GRANT、ALTER、CREATE、RENAME等改动的mysql库里数据的，会强制使用statement-based方式记录binlog。

可以在线修改二进制日志类型，如SET SESSION binlog_format=MIXED;，需要SUPER权限。

复制类型还可以分为异步复制和半同步复制。
通常没说明指的都是异步，即主库执行完Commit后，在主库写入Binlog日志后即可成功返回客户端，无需等等Binlog日志传送给从库，一旦主库宕机，有可能会丢失日志。而半同步复制，是等待其中一个从库也接收到Binlog事务并成功写入Relay Log之后，才返回Commit操作成功给客户端；如此半同步就保证了事务成功提交后至少有两份日志记录，一份在主库Binlog上，另一份在从库的Relay Log上，从而进一步保证数据完整性；半同步复制很大程度取决于主从网络RTT（往返时延），以插件 semisync_master/semisync_slave 形式存在。

原理
(1) master将改变记录到二进制日志(binary log)中（这些记录叫做二进制日志事件，binary log events）；
(2) slave将master的binary log events拷贝到它的中继日志(relay log)；
(3) slave重做中继日志中的事件，将改变反映它自己的数据。

该过程的第一部分就是master记录二进制日志。在每个事务更新数据完成之前，master在二进制日志记录这些改变。MySQL将事务串行的写入二进制日志，即使事务中的语句都是交叉执行的。在事件写入二进制日志完成后，master通知存储引擎提交事务。
下一步将master的binary log拷贝到它自己的中继日志。首先，slave开始一个工作线程——I/O线程。I/O线程在master上打开一个普通的连接，请求从指定日志文件的指定位置之后的日志内容，然后开始binlog dump process。Binlog dump process从master的二进制日志中读取事件，如果已经跟上master，它会睡眠并等待master产生新的事件。I/O线程将这些事件写入中继日志。
SQL slave thread（SQL从线程）处理该过程的最后一步。SQL线程从中继日志读取事件，并重放其中的事件而更新slave的数据，使其与master中的数据一致。只要该线程与I/O线程保持一致，中继日志通常会位于OS的缓存中，所以中继日志的开销很小。

此外，在master中也有一个工作线程：和其它MySQL的连接一样，slave在master中打开一个连接也会使得master开始一个线程。复制过程有一个很重要的限制——复制在slave上是串行化的，也就是说master上的并行更新操作不能在slave上并行操作。

补充:

mysql 5.7开始加入了多源复制，这个特性对同时有很多个mysql实例是很有用的，阿里云RDS（迁移）实现了类似的方式。
从MySQL 5.6.2开始，mysql binlog支持checksum校验，并且5.6.6默认启用（CRC32），这对自己模拟实现mysql复制的场景有影响。

下面开始配置主从：

　　主从版本一致—>主库授权复制帐号—>确保开启binlog及主从server_id唯一—>xtrabackup恢复到从库—>记录xtrabackup_binlog_info中binlog名称及偏移量—>从库change master to —>slave start—>检查两个yes

2. 创建复制账号

在主库上

mysql> GRANT REPLICATION SLAVE ON *.* TO 'slave_ali'@'192.168.5.%' IDENTIFIED BY 'slave_ali_pass';  
mysql> FLUSH PRIVILEGES;

3. 使用Percona-Xtrabackup恢复数据

这里假设比较简单的情况：全量备份，全量恢复，不涉及增量。

安装和具体使用，见文章。

赋予备份用户权限：

1
2
3

mysql> CREATE USER 'bkpuser'@'localhost' IDENTIFIED BY 'bkppass';
mysql> GRANT RELOAD, LOCK TABLES, REPLICATION CLIENT,PROCESS,SUPER ON *.* TO 'bkpuser'@'localhost';
mysql> FLUSH PRIVILEGES;

完整的选项使用请执行innobackupex –-help，这里只介绍使用常用的选项进行完整备份及增量备份和还原。

这一节是把数据恢复到从库，借此记录一下xtrabackup的使用（用了云之后，备份技能都丢了~）。生产环境你应该是早就有了xtrabackup的备份，做从库时只需要把备份拷过来，解压恢复。

假设 MySQL 安装目录在/opt/mysql，my.cnf配置文件/opt/mysql/my.cnf，端口3306，数据目录/opt/mysql_data，sock位于/opt/mysql_data/mysql.sock。备份数据放在/data/backup/mysql/。

3.1 全量备份

1 2	$ export BKP_PASS="bkppass" $ innobackupex --defaults-file=/opt/mysql/my.cnf --host=localhost --port=3306 --user=bkpuser --password=${BKP_PASS} /data/backup/mysql

默认会以当天日期+时间戳命名备份目录，如 2015-09-16_00-00-02。一般会对它进行tar压缩，由于tar只能单进程，所以往往这个压缩过程会比备份过程耗时2倍还多。拷贝到需要恢复（做从库）的目录。

如果手头有一份未压缩的全备数据，要在另一台恢复，其实还不如直接 rsync 过来，将近400G的数据压缩与解压缩过程特别漫长。

3.2 全量恢复

在恢复的数据库服务器（从库）上：

恢复准备
$ innobackupex --use-memory=16G --apply-log 2015-09-16_00-00-02

确认数据库是关闭的，并且datadir，目录下为空
$ innobackupex --defaults-file=/opt/mysql/my.cnf --use-memory=16G --copy-back 2015-09-16_00-00-02

第一步是恢复准备，apply-log应用全备时 log sequence number 之后的数据，完了后会输出类似 InnoDB: Last MySQL binlog file position 0 262484673, file name ./mysql-bin.000135 的信息，告诉我们了后面的从库应该从哪个地方开始复制。时间不会很长，但最好用screen之类的软件放到后台执行，以免终端断开，功亏一篑。第二步使用新的my.cnf文件，将完整的mysql数据文件拷贝到datadir下。

4. 做从库

上面恢复过程最后一步apply-log完成之后，会得到一个lsn position 和binlog文件名：262484673、mysql-bin.000135。下面开始从库制作。

一般在copy-back之后需要修改数据文件目录的属性：

1	# chown -R mysql.mysql /opt/mysql_data

4.1 my.cnf

从库的配置文件简单一点可以从主库拷贝过来，但根据需要，要注意以下几处

server-id一定不能与主库相同
否则，会出现如下错误：
Slave: received end packet FROM server, apparent master shutdown
从库一般作为只读库使用，所以为安全起见，设置只读 set global read_only=1;
可以在从服务器的 my.cnf 里加入read-only参数来实现这一点，唯一需要注意的一点事read-only仅对没有super权限的用户有效。所以最好核对一下连接从服务器的用户，确保其没有super权限。
关于从库的事件
MYSQL Replication 可以很好的达到你的预期：从库的事件不会自己去执行，主库会把event执行的结果直接同步。在statement模式下，复制的是 event BODY 里的SQL，在row模式下是主库事件执行完成后影响的行精确复制。

从库 event_scheduler 参数是被忽略的，并且每个event 状态会是 SLAVESIDE_DISABLED ，但CREATE/ALTER EVENT等操作语句是会复制。主从切换后，从库事件状态会变成ENABLE。
参数调整
从库是不允许写入的，否则数据就不一致了。从库实例的配置可以不要主库那么高，比如原16G的buffer pool，根据用途，从库可以设到4-8G（当时前提是将来你也不打算把它切换为主库用）。
相应的，read_buffer_size，sort_buffer_size, query_cache_size 这些读相关参数可以略微增大。当然我一般都懒得去改。
skip-slave-start
主从创建完成后，默认情况下次启动从库，会自动启动复制进程，一般这也正是我们需要的，但在维护阶段时你可能不想从库启动后立即开始复制，--skip-slave-start选项可以帮到你。
log-slave-updates
正常情况从库是不需要写回放日志产生的binlog，无形中增加服务器压力。但如果你想要实现级联复制即 A -> B -> C ，B同时是A的从库，也是C的主库，就需要开启 log-bin 和 log-slave-updates 。

另外，建议显示设置 log-bin=mysql-bin 确保主从正常切换。 show variables like 'log%' 查看当前值。
关于过滤表见mysql-replica-filter
sync_binlog
For the greatest possible durability and consistency in a replication setup using InnoDB with transactions, you should use innodb_flush_log_at_trx_commit=1 and sync_binlog=1 in the master my.cnf file.

上面的话同时也意味着性能最低。可以在这埋点，假如出现慢的情况，把两参数调成2。

4.2 启动从库

启动数据库，注意看日志

1	# /opt/mysql/bin/mysqld_safe --defaults-file=/opt/mysql/my.cnf &

提示：如果你不确定这个库是谁的从库，保守起见加上--skip-slave-start启动，兴许能防止数据不一致。

4.3 change master

在从库上

$ mysql -uslave_ali -p'slave_ali_pass' -S /opt/mysql_data/mysql.sock
mysql> change master to master_host=MASTER_HOST, master_port=3306, 
       master_user='slave_ali',master_password='slave_ali_pass',
       master_log_file='mysql-bin.000135', master_log_pos=262484673;

上面的 master_log_file 和 master_log_pos 即是输出的值，也可以在新的数据目录下xtrabackup_binlog_info找到信息。

mysql> show slave status\G
mysql> start slave;
mysql> show slave status\G

4.4 验证同步延迟

从库执行 show slave status\G
节选：

Slave_IO_State: Waiting for master to send event
      Master_Log_File: mysql-bin.000004
  Read_Master_Log_Pos: 931
       Relay_Log_File: slave1-relay-bin.000056
        Relay_Log_Pos: 950
Relay_Master_Log_File: mysql-bin.000004
     Slave_IO_Running: Yes
    Slave_SQL_Running: Yes
   Exec_Master_Log_Pos: 931
      Relay_Log_Space: 408
Seconds_Behind_Master: 0

Master_Log_File： I/O线程当前正在读取的主服务器二进制日志文件的名称
Read_Master_Log_Pos：本机I/O线程读取主服务器二进制日志位置
上面2各值，与在主库执行show master status;看到的值如果基本接近，说明从库IO线程已经赶上了主库的binlog。
Relay_Master_Log_File: 由SQL线程执行的包含多数近期事件的主服务器二进制日志文件的名称
Exec_Master_Log_Pos: SQL线程执行来自master的二进制日志最后一个事件位置
与上面的Relay_Master_Log_File一起，同Master_Log_File、Read_Master_Log_Pos比较，能看到SQL线程是否已经赶上从库本地的IO线程。
Slave_IO_Running：I/O线程是否启动并成功连接到主服务器上
一般和下面的Slave_IO_Running和Seconds_Behind_Master一起监控主从健康状态
Slave_SQL_Running：SQL线程是否启动
Seconds_Behind_Master: 从属服务器“落后”多少秒
官网的解释是：The number of seconds that the slave SQL thread is behind processing the master binary log。但是当 SBM 为 0 时也不代表一定没有延迟，因为可能因为网络慢的缘故，从库的IO线程传输binlog太慢，它的SQL线程应用日志很容易就赶上relay log，但实际主库产生的binlog比传输的快，就会造成为0的假象。
有时你反复status会发现 Seconds_Behind_Master 的值在0与一个很大的数之间波动，有可能是主库上执行了一个非常大的event，没执行完毕的时候从库SBM显示为0，event执行完成并传输完binlog后，就会显示SBM非常巨大。（我在从机房迁移mysql到阿里云上部分库老出现这种情况，应该跟网络和大event都有关系）。
另外，relay log 中event记录的时间戳是主库上的时间戳，而SQL thread的时间戳是从库上的，如果主库和从库的时间偏差较大，那么这个SBM的意义就基本不存在了。

Mysql主从不同步解决方法

主从同步配置好后，运行了一时间，出现了不同步现象，用命令检查，看到从上报下面错误：
msyq > show slave status \G; Last_Errno: 1062 Last_Error: Error 'Duplicate entry '149' for key 'PRIMARY'' on query. Default database: 'zabbix'. Query: 'insert into escalations (escalationid,actionid,status,triggerid,itemid,eventid,r_eventid) values (149,7,0,16272,null,3334811,null)'

看这个报错，应该是主MYSQL上建表时，主键有重复的值报错，造成从不能同步。
解决的办法是在从库上执行:
mysql> slave stop; mysql> set GLOBAL SQL_SLAVE_SKIP_COUNTER=1; mysql> slave start;
上面的方法可以解决问题，还有一种解决问题的办法是通过修改mysql的配置文件，让从库的同步线程忽略这个错误，方法：

修改mysql配置文件 /etc/my.cnf 在 [mysqld]下加一行slave_skip_errors = 1062 ,保存重启mysql
mysql slave可以正常同步了.

MySQL auto_increment_increment，auto_increment_offset 用法

MySQL中对于表上ID自增列可以在创建表的时候来指定列上的auto_increment属性；等同于SQL server中的identity属性；Oracle则是通过Sequence方式来实现。在MySQL中，系统变量auto_increment_increment，auto_increment_offset 影响自增列的值及其变化规则。

mysql环形主从配置

今天下午一直在试验mysql环形主从，试验过多次，但是最终成功了，不容易啊，此刻非常激动！！！特将整个过程共享出来！
结构：A->B->C->A

关于MHA

MHA（Master High Availability）是一款开源的mysql高可用程序，目前在mysql高可用方面是一个相对成熟的解决方案。MHA 搭建的前提是MySQL集群中已经搭建了MySql Replication环境，有了Master/Slave节点。MHA的主要作用就是监测到Master节点故障时会提升主从复制环境中拥有最新数据的Slave节点成为新的master节点。同时，在切换master期间，MHA会通过从其他的Slave节点来获取额外的信息来避免一致性的问题，整个的切换过程对于应用程序而言是完全透明的。MHA还提供了master节点在线切换功能，即按需切换master/slave节点。

MHA Manager 和 MHA Node

MHA 服务有两个角色，MHA Manager 和 MHA Node
MHA Manager: 通常单独部署在一台独立机器上管理 master/slave 集群，每个master/slave 集群可以理解为一个application。

MHA Node: 运行在每台mysql 服务器(master/slave)上。它通过监控具备解析和清理logs功能来加快故障转移。

整体上的架构如下图所示。

MySqlMHA

MHA 在自动切换的过程中会从宕掉的MySql master节点中保存二进制日志，以保证数据的完整性。但是如果master节点直接宕机了呢，或者网络直接不能联通了呢？MHA就没有办法获取master的二进制日志，也就没有办法保证数据的完整性了。这也就是为什么MHA应该与MySql主从复制结合起来。这样的话，只要有一个slave节点从master节点复制到了最新的日志，MHA就可以将最近的二进制日志应用到其他的slave节点上，这样就可以最大限度上保证数据的完整性。

MHA 自动切换的原理可以总结为下面几点.

从宕机崩溃的master保存二进制日志事件（binlog events）;
识别含有最新更新的slave;
应用差异的中继日志（relay log）到其他的slave;
应用从master保存的二进制日志事件（binlog events);
提升一个slave为新的master;
使其他的slave连接新的master进行复制;

MHA 工具组件

MHA 提供了很多的程序组件，通过这些组件，我们可以很方便的管理MHA集群。

Manager节点：

masterha_check_ssh：MHA依赖的环境监测工具;
masterha_check_ssh: MySql复制环境检测工具;
masterha_manager: MHA 服务主程序;
masterha_check_status: MHA运行状态探测工具;
masterha_master_monitor: MySql master节点可用性检测工具;
masterha_switch: master 节点切换工具;
masterha_conf_host: 添加或删除配置的节点;
masterha_stop: 关闭MHA服务的工具;

Node节点:

save_binary_logs:保存和复制master节点的二进制日志;
apply_diff_relay_logs: 识别差异的中继日志事件并应用于其他的slave;
purge_relay_logs:清除中集日志(不会阻塞SQL线程);

实验介绍

在实际的生产环境中有很多的因素需要考虑，例如MHA Manager的单点问题。但是我们由于环境有限，所以就暂时不考虑这些。此次实验中实验环境如下。

担任角色	主机名	地址	功能描述	对应软件版本
MHA Manager	manager	192.168.0.20	MHA Manager,控制Master节点故障转移	mha4mysql-manager-0.56-0.el6.noarch
MySql Master	master	192.168.0.21	MySql Master 节点	Mariadb-server-5.5.56-2.el7
MySql Slave	Slave1	192.168.0.22	Mysql Repliaction集群中的Slave1 节点	Mariadb-server-5.5.56-2.el7
MySql Slave	Slave2	192.168.0.26	MySql Repliaction 集群中的Slave2节点	Mariadb-server-5.5.56-2.el7

准备MySql Replication 环境

安装PLUGIN

某种意义上说，Master节点不会一直充当master节点。Master节点从故障状态中恢复之后，很有可能充当的是slave节点，所以我们在安装插件的时候，不做区别对待。
mysql 支持多种插件/var/lib/mysql/plugin 目录下，需要安装方可使用。在Master(192.168.0.21)，和Slave(192.168.0.22,192.168.0.26)节点上安装semisync_master.so semisync_slave.so 两个插件。

MariaDB [(none)]> INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so'; 
MariaDB [(none)]> INSTALL PLUGIN rpl_semi_sync_slave SONAME 'semisync_slave.so';

然后在三台主机上开启下面两个参数

MariaDB [(none)]> SET GLOBAL rpl_semi_sync_master_enabled=ON;                     
Query OK, 0 rows affected (0.00 sec)

MariaDB [(none)]> SET GLOBAL rpl_semi_sync_slave_enabled=ON; 
Query OK, 0 rows affected (0.00 sec)

MariaDB [(none)]> SHOW GLOBAL VARIABLES LIKE 'rpl_semi%';    
+------------------------------------+-------+
| Variable_name                      | Value |
+------------------------------------+-------+
| rpl_semi_sync_master_enabled       | ON    |
| rpl_semi_sync_master_timeout       | 10000 |
| rpl_semi_sync_master_trace_level   | 32    |
| rpl_semi_sync_master_wait_no_slave | ON    |
| rpl_semi_sync_slave_enabled        | ON    |
| rpl_semi_sync_slave_trace_level    | 32    |
+------------------------------------+-------+
6 rows in set (0.00 sec)

到目前而言，三台主机之间没有差别，也没有角色上的区分。接下来我们开始设置master与slave来实现主从复制。

编辑 /etc/my.cnf.d/server.cnf 文件，加入下面这样一段配置

[mariadb]
server-id=1    #Master设置1，Slave1设置2，Slave2设置3
log-bin=mysql-bin
relay-log=mysql-relay-bin
relay_log_purge=0

修改完配置文件之后，重启Mariadb. systemctl restart mariadb

在master节点上进行操作


# 这里需要记住 File 以及Position的数据,在SLAVE 节点上要用到
MariaDB [(none)]> show master status;
+------------------+----------+--------------+------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000001 |      245 |              |                  |
+------------------+----------+--------------+------------------+
1 row in set (0.00 sec)   

MariaDB [(none)]> GRANT REPLICATION MASTER ON *.* TO 'repl'@'%' IDENTIFIED BY '123'; 
Query OK, 0 rows affected (0.00 sec)

MariaDB [(none)]> FLUSH PRIVILEGES;
Query OK, 0 rows affected (0.00 sec)

在slave节点上进行操作

MariaDB [(none)]> GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%' IDENTIFIED BY '123';
Query OK, 0 rows affected (0.01 sec)

MariaDB [(none)]> CHANGE MASTER TO
    -> MASTER_HOST='192.168.0.21',
    -> MASTER_PORT=3306,
    -> MASTER_USER='repl',
    -> MASTER_PASSWORD='123',
    -> MASTER_LOG_FILE='mysql-bin.000001', 
    -> MASTER_LOG_POS=245; 
Query OK, 0 rows affected (0.03 sec)

MariaDB [(none)]> start slave;
Query OK, 0 rows affected (0.00 sec)

上面的操作完成后，在master主机上查看master的状态。

MariaDB [(none)]> SHOW SLAVE HOSTS;  
+-----------+------+------+-----------+
| Server_id | Host | Port | Master_id |
+-----------+------+------+-----------+
|         3 |      | 3306 |         1 |
|         2 |      | 3306 |         1 |
+-----------+------+------+-----------+

在slave主机上可以查看slave主机的状态。

*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 192.168.0.21
                  Master_User: repl
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mysql-bin.000001
          Read_Master_Log_Pos: 245
              .............
              .............
             Slave_IO_Running: Yes
             Save_SQL_Running: Yes
              .............

在Master节点上创建MHA监控所需要的用户，该用户会同步到slave端。


MariaDB [(none)]> GRANT ALL PRIVILEGES ON *.* TO 'mha_rep'@'%' IDENTIFIED BY '123'; 

MariaDB [(none)]>  flush privileges;

至此，MySql 主从复制环境就搭建好了。下面就可以开始来安装MHA了。

注：在查看slave节点状态时，如果出现问题，可以检查一下SELinux，iptables，以及其他权限问题，在实验开始之前，最好先将这些环境设置好，避免出现问题。

安装配置MHA

设置SSH免密通信

MHA 集群中的各节点之间需要基于SSH互相通信，以实现远程控制以及数据管理功能。简单起见，我们以Manager节点为例，然后将生成的文件发送到需要管理的主机上。四个节点都需要进行这个操作。


[root@manager ~]# ssh-keygen -t rsa 
[root@manager ~]# for i in 21 22 26;do ssh-copy-id -i ~/.ssh/id_rsa.pub root@192.168.0.$i; done

这样MHA Manager就实现了通过SSH免密管理其他的mysql节点

安装MHA

MHA 官方提供了rpm的安装包，通过搜索可以找到。CentOS 7 可以直接使用el6 的rpm安装包。下面是本次实验中rpm安装包的下载地址。https://github.com/yoshinorim/mha4mysql-manager/wiki/Downloads。

在所有节点上安装node安装包

[root@manager ~]# yum install mha4mysql-node-0.56-0.el6.noarch.rpm

在Manager节点上安装manager安装包

[root@manager ~]# yum install mha4mysql-manager-0.56-0.el6.noarch.rpm

还可以在上述网站上下载源码包，里面有很多的例子和脚本可以直接拿来使用。将下载的源码包解压之后在samples/scripts下的所有脚本复制到/usr/bin目录(因为安装的mha manager的相关命令就在/usr/bin/目录下，可以使用rpm -ql mha4mysql-manager-0.56-0.el6 来查看)下。
脚本如下：

master_ip_failover    #自动切换时vip管理的脚本，不是必须，如果我们使用keepalived的，我们可以自己编写脚本完成对vip的管理，比如监控mysql，如果mysql异常，我们停止keepalived就行，这样vip就会自动漂移
master_ip_online_change    #在线切换时vip的管理，不是必须，同样可以可以自行编写简单的shell完成
power_manager    #故障发生后关闭主机的脚本，不是必须
send_report    #因故障切换后发送报警的脚本，不是必须，可自行编写简单的shell完成。

这里有一点需要注意，拷贝到/usr/bin 目录下的文件如果没有执行权限，要加上执行权限。

初始化MHA

Manager节点需要为每个监控的master/slave 集群提供专用的配置文件，而所有的master/slave集群也可以共享全局配置。全局配置文件默认在/etc/masterha_default.cnf，其为可选配置。如果仅监控一组master/slave集群，也可以直接通过application 的配置来提供给个服务器的默认配置信息。而灭个application的配置文件路径为自定义，我们的实例中，只有一个master/slave集群，所以我们就定义一个配置文件好了。

[root@manager ~]# cat /etc/masterha/app1.cnf

[server default]
manager_workdir=/etc/masterha
manager_log=/etc/masterha/manager.log
user=mha_rep
password=123
ping_interval=3
remote_workdir=/etc/masterha
repl_user=repl
repl_password=123
ssh_user=root
master_ip_failover_script=/usr/bin/master_ip_failover
master_ip_online_change_script=/usr/bin/master_ip_online_change
report_script=/usr/bin/send_report
shutdown_script=""
secondary_check_script=/usr/bin/masterha_secondary_check -s 192.168.0.22 -s 192.168.0.26   --user=root --master_host=192.168.0.21  --master_ip=192.168.0.21  --master_port=3306

[server1]
hostname=192.168.0.21
port=3306
master_binlog_dir=/var/lib/mysql/
candidate_master=1 
check_repl_delay=0 

[server2]  
hostname=192.168.0.22 
port=3306
master_binlog_dir=/var/lib/mysql/
candidate_master=1  
check_repl_delay=0

[server3]  
hostname=192.168.0.26
port=3306
master_binlog_dir=/var/lib/mysql/
no_master=1

编辑一下 /etc/masterha_default.cnf 文件，添加一些全局的配置。配置文件的内容如下。

[root@manager ~]# cat /etc/masterha_default.cnf 

[server default]
user=mha_rep 
password=123 
repl_user=repl
repl_password=123
ssh_user=root
ping_interval=3
master_binlog_dir=/var/lib/mysql
remote_workdir=/etc/masterha
secondary_check_script=/usr/bin/masterha_secondary_check -s 192.168.0.22 -s 192.168.0.26 --user=root --master_host=192.168.0.21  --master_ip=192.168.0.21 --master_port=3306
# 设置自动failover时候的切换脚本;
master_ip_failover_script=/usr/bin/master_ip_failover
# 设置手动切换时候的切换脚本;
master_ip_online_change_script=/usr/bin/master_ip_online_change
# 设置发生切换后发送的报警的脚本;
report_script=/usr/bin/send_report
# 设置故障发生后关闭故障主机脚本（该脚本的主要作用是关闭主机防止发生脑裂,这里没有使用）;
shutdown_script=""

检查mysqlbinlog mysql 命令

在master，slave1 和slave2 节点上执行下面的命令检查一下mysqlbinlog和mysql 命令的位置。

[root@master ~]# type mysqlbinlog
mysqlbinlog is /usr/bin/mysqlbinlog
[root@master ~]# type mysql      
mysql is /usr/bin/mysql

一定要确保 mysqlbinlog 和mysql 两个命令在 /usr/bin 目录下。由于我安装的是mariadb ，所以这两个文件默认就在这两个目录，如果是其他版本的mysql，不在这两个目录下的话可以使用软连接的方式，在这个目录下添加两个软连接。
否则，在进行检查的时候，会出现如下的类似错误。

mysqlbinlog

.....

Can't exec "mysqlbinlog": No suchfile or directory at /usr/local/share/perl5/MHA/BinlogManager.pm line 106.
mysqlbinlog version command failed with rc1:0, please verify PATH, LD_LIBRARY_PATH, and client options

.....

mysql

.....
Testing mysql connection and privileges..sh: mysql: command not found
mysql command failed with rc 127:0!
.....

配置VIP

在master 节点上进行操作，给ens33网卡添加一个VIP，这样用户访问的时候，就会可以通过VIP进行访问，并不需要关心MySQL集群中的具体细节。同时如果master宕机之后，VIP会自动进行转移，并不会影响到用户的访问，后端VIP漂移的过程对用户来说完全透明。

[root@manager ~]# ifconfig ens33:1 192.168.0.88

在MHA manager上进行操作，修改/usr/bin/master_ip_failover脚本如下，主要是VIP的修改。

[root@centos7-1 ~]# cat /usr/bin/master_ip_failover 
#!/usr/bin/env perl
use strict;
use warnings FATAL => 'all';

use Getopt::Long;

my (
    $command,          $ssh_user,        $orig_master_host, $orig_master_ip,
    $orig_master_port, $new_master_host, $new_master_ip,    $new_master_port
);

my $vip = '192.168.0.88/24';
my $key = '1';
my $ssh_start_vip = "/sbin/ifconfig ens33:$key $vip";
my $ssh_stop_vip = "/sbin/ifconfig ens33:$key down";

GetOptions(
    'command=s'          => \$command,
    'ssh_user=s'         => \$ssh_user,
    'orig_master_host=s' => \$orig_master_host,
    'orig_master_ip=s'   => \$orig_master_ip,
    'orig_master_port=i' => \$orig_master_port,
    'new_master_host=s'  => \$new_master_host,
    'new_master_ip=s'    => \$new_master_ip,
    'new_master_port=i'  => \$new_master_port,
);

exit &main();

sub main {

    print "\n\nIN SCRIPT TEST====$ssh_stop_vip==$ssh_start_vip===\n\n";

    if ( $command eq "stop" || $command eq "stopssh" ) {

        my $exit_code = 1;
        eval {
            print "Disabling the VIP on old master: $orig_master_host \n";
            &stop_vip();
            $exit_code = 0;
        };
        if ($@) {
            warn "Got Error: $@\n";
            exit $exit_code;
        }
        exit $exit_code;
    }
    elsif ( $command eq "start" ) {

        my $exit_code = 10;
        eval {
            print "Enabling the VIP - $vip on the new master - $new_master_host \n";
            # 这一行很重要，表示在master上mysql服务停止之后，关闭掉VIP，以免地址冲突
            &stop_vip();
            &start_vip();
            $exit_code = 0;
        };
        if ($@) {
            warn $@;
            exit $exit_code;
        }
        exit $exit_code;
    }
    elsif ( $command eq "status" ) {
        print "Checking the Status of the script.. OK \n";
        exit 0;
    }
    else {
        &usage();
        exit 1;
    }
}

sub start_vip() {
    `ssh $ssh_user\@$new_master_host \" $ssh_start_vip \"`;
}
sub stop_vip() {
     return 0  unless  ($ssh_user);
    `ssh $ssh_user\@$orig_master_host \" $ssh_stop_vip \"`;
}

sub usage {
    print
    "Usage: master_ip_failover --command=start|stop|stopssh|status --orig_master_host=host --orig_master_ip=ip --orig_master_port=port --new_master_host=host --new_master_ip=ip --new_master_port=port\n";
}

验证MHA

经过上述的一系列的的配置和操作，我们就顺利的配置好了MySql replication 环境和MHA 环境，接下来开始验证一下。
在MHA manager 上进行一下下面的操作。

# 检测主机之间的SSH 联通性
[root@manager ~]#  masterha_check_ssh --conf=/etc/masterha/app1.cnf
.....
# 省略了很多非关键信息 出现类似下面的 successfully 表示SSH 联通性检测成功
Sun Jan 14 20:09:30 2018 - [info] All SSH connection tests passed successfully.

# 检测mysql 复制集群的配置参数是否正确
[root@manager ~]#  masterha_check_ssh --conf=/etc/masterha/app1.cnf

.......

#  可以看到我们配置的master/slave信息
192.168.0.21(192.168.0.21:3306) (current master)
 +--192.168.0.22(192.168.0.22:3306)
 +--192.168.0.26(192.168.0.26:3306)

.....

# 省略了很多非必要信息，出现下面的Health is OK ，说明主从复制检测成功
MySQL Replication Health is OK.

启动MHA

在manager 节点上进行操作。

[root@manager ~]# nohup masterha_manager --conf=/etc/masterha/app1.cnf < /dev/null > /etc/masterha/manager.log 2>&1 &
[1] 7861
[root@manager ~]#  masterha_check_status --conf=/etc/masterha/app1.cnf
app1 (pid:7861) is running(0:PING_OK), master:192.168.0.21

停止MHA

如果想要停止MHA 可以执行如下的命令

[root@manager ~]# masterha_stop --conf=/etc/masterha/app1.cnf                                                        
Stopped app1 successfully.
[1]+  Exit 1                  nohup masterha_manager --conf=/etc/masterha/app1.cnf < /dev/null > /etc/masterha/manager.log 2>&1

MHA 测试故障转移

在master节点关闭mariadb 服务

systemctl stop mariadb

在Manager 节点查看/etc/masterha/manager.log

在manager节点查看 manager.log 的日志，可以看到下面的切换过程

----- Failover Report -----

app1: MySQL Master failover 192.168.0.21(192.168.0.21:3306) to 192.168.0.22(192.168.0.22:3306) succeeded

Master 192.168.0.21(192.168.0.21:3306) is down!

Check MHA Manager logs at manager:/etc/masterha/manager.log for details.

Started automated(non-interactive) failover.
Invalidated master IP address on 192.168.0.21(192.168.0.21:3306)
The latest slave 192.168.0.22(192.168.0.22:3306) has all relay logs for recovery.
Selected 192.168.0.22(192.168.0.22:3306) as a new master.
192.168.0.22(192.168.0.22:3306): OK: Applying all logs succeeded.
192.168.0.22(192.168.0.22:3306): OK: Activated master IP address.
192.168.0.26(192.168.0.26:3306): This host has the latest relay log events.
Generating relay diff files from the latest slave succeeded.
192.168.0.26(192.168.0.26:3306): OK: Applying all logs succeeded. Slave started, replicating from 192.168.0.22(192.168.0.22:3306)
192.168.0.22(192.168.0.22:3306): Resetting slave info succeeded.
Master failover to 192.168.0.22(192.168.0.22:3306) completed successfully.

注意，故障转移完成之后，manager会自动停止，此时使用masterha_check_status命令检测将会是下面这种结果.

[root@manager ~]#  masterha_check_status --conf=/etc/masterha/app1.cnf
app1 is stopped(2:NOT_RUNNING).

在新的Master上进行验证

在新的master主机slave1上进行查看,master_id 已经进行了切换，并且少了一台slave 主机。

MariaDB [(none)]> show slave hosts;
+-----------+------+------+-----------+
| Server_id | Host | Port | Master_id |
+-----------+------+------+-----------+
|         3 |      | 3306 |         2 |
+-----------+------+------+-----------+
1 row in set (0.00 sec)

在slave2主机上查看slave 的当前状态。


MariaDB [(none)]> show slave status\G
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 192.168.0.22
                  Master_User: repl
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mysql-bin.000004
          Read_Master_Log_Pos: 384
               Relay_Log_File: mysql-relay-bin.000002
                Relay_Log_Pos: 529
        Relay_Master_Log_File: mysql-bin.000004
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes

            .......................

可以看到最新的master的IP 已经变成了之前slave1 主机的IP地址，这说明master 切换成功。

在新Master主机上查看VIP迁移，旧master主机上查看IP

在新的master 主机上查看ip地址的变化,如果VIP 漂移成功说明，之前的配置没有问题。


[root@slave1 ~]# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: ens33: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 00:50:56:37:c4:5e brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.88/24 brd 192.168.0.255 scope global ens33:1
       valid_lft forever preferred_lft forever
    inet 192.168.0.22/24 brd 192.168.0.255 scope global secondary dynamic ens33
       valid_lft 6390sec preferred_lft 6390sec
    inet6 fe80::e9cb:24a6:f81d:1810/64 scope link 
       valid_lft forever preferred_lft forever

在旧的master主机上查看VIP是否已经被移除。

[root@master ~]# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: ens33: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 00:50:56:29:d0:2d brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.21/24 brd 192.168.0.255 scope global dynamic ens33
       valid_lft 7198sec preferred_lft 7198sec
    inet6 fe80::c28a:e648:5959:5ad6/64 scope link 
       valid_lft forever preferred_lft forever

如果上面两项的检测都没有问题，说明在实际的使用过程中VIP 就不会产生地址冲突了。而且地址切换过程对用户来说，基本上没有任何感知，这样就保证了mysql服务的高可用了。

抢救故障节点，重新加入集群

生产中mysql服务停掉可以立即监监控到，而且这基本上属于以及故障需要立即进行排除。
重新恢复宕掉的mysql服务比较好的思路是，将其基于最新的master节点的数据备份进行数据恢复，然后重新启动服务，将其设置为slave节点，并加入到新的master集群，之后重启MHA监控。
备份还原过程，此处不再赘述。将启动后的节点重新加入到新的master集群中。过程与之前介绍的类似。


MariaDB [(none)]> CHANGE MASTER TO
    ->  MASTER_HOST='192.168.0.22',
    ->    MASTER_PORT=3306,
    ->    MASTER_USER='repl',
    ->   MASTER_PASSWORD='123',
    ->     MASTER_LOG_FILE='mysql-bin.000004', 
    -> MASTER_LOG_POS=384; 
Query OK, 0 rows affected (0.01 sec)

MariaDB [(none)]> start slave;
Query OK, 0 rows affected (0.00 sec)

在新的master节点上查看最新的slave主机状态。

MariaDB [(none)]> show slave hosts;
+-----------+------+------+-----------+
| Server_id | Host | Port | Master_id |
+-----------+------+------+-----------+
|         1 |      | 3306 |         2 |
|         3 |      | 3306 |         2 |
+-----------+------+------+-----------+
2 rows in set (0.00 sec)

可以看到slave 主机的server_id 已经变化了。

在manager主机上检查MHA

在manager上修改/etc/masterha/app1.cnf中secondary_check_script中的master IP值，将新的master ip修改上

secondary_check_script=/usr/bin/masterha_secondary_check -s 192.168.0.21 -s 192.168.0.26   --user=root --master_host=192.168.0.22  --master_ip=192.168.0.22  --master_port=3306

修改/etc/masterha_default.cnf 中secondary_check_script 中的IP地址

secondary_check_script=/usr/bin/masterha_secondary_check -s 192.168.0.21 -s 192.168.0.26 --user=root --master_host=192.168.0.22  --master_ip=192.168.0.22 --master_port=3306

在Manager 上启动MHA 然后检查MHA的状态

[root@centos7-1 ~]#  masterha_check_repl --conf=/etc/masterha/app1.cnf   

.........

192.168.0.22(192.168.0.22:3306) (current master)
 +--192.168.0.21(192.168.0.21:3306)
 +--192.168.0.26(192.168.0.26:3306)

......

MySQL Replication Health is OK.

启动MHA ，检查MHA的状态


[root@manager ~]# nohup masterha_manager --conf=/etc/masterha/app1.cnf < /dev/null > /etc/masterha/manager.log 2>&1 &
[1] 9186
[root@manager ~]#  masterha_check_status --conf=/etc/masterha/app1.cnf
app1 (pid:9186) is running(0:PING_OK), master:192.168.0.22

转载于:https://my.oschina.net/u/3992081/blog/2995284