MySQL MHA原理（二）

2017-05-25 作者：SleepSir

暂无评论

测试MHA 的高可用

在MySQL MHA原理（一）中，我们已经可以完整的搭建配置MHA高可用集群了，本章节来主要讲述对高可用功能的验证。所谓高可用，就是能满足多种异常情况下的热服务，所以这里测试需要很详尽的测试用例。

这里我首先给出测试Case及结果，有兴趣的同学可以翻看后面的具体过程：

在MHA自动切换的情况下：

Case1：Master 意外宕掉，Slave正常，备选Slave正常。
Case2 : Master 意外宕掉，Slave落后很多binlog，备选Slave正常。
Case3：Master 意外宕掉，Slave正常，备选Slave落后很多binlog。
Case4：Master 意外宕掉，Slave复制意外停止，备选Slave正常。
Case5： Master 意外宕掉，Slave正常，备选Slave复制意外停止。
Case6：Master 意外宕掉，Slave正常，备选Slave也意外宕掉。
Case7：Master too many connection，Slave正常，备选Slave正常。
Case8：Master 正常工作，Slave （或备选Slave）意外宕掉。
Case9：Master 网路瞬断（1~30秒）。
Case10：有二次检测机制下，如果Manager通过一台Slave无法连接（另一台正常）。

在MHA手动触发的情况下：

Case1：Master 意外宕掉，Slave正常，备选Slave正常。
Case2 : Master 意外宕掉，Slave落后很多binlog，备选Slave正常。
Case3：Master 意外宕掉，Slave正常，备选Slave落后很多binlog。
Case4：Master 意外宕掉，Slave复制意外停止，备选Slave正常。
Case5： Master 意外宕掉，Slave正常，备选Slave复制意外停止。
Case6：Master 意外宕掉，Slave正常，备选Slave也意外宕掉。
Case7：Master too many connection，Slave正常，备选Slave正常。
Case8：Master 正常工作，Slave （或备选Slave）意外宕掉。
Case9：Master 有大的事务或写操作在进行，Slave正常，备选Slave也正常
Case10：有二次检测机制下，如果Manager通过一台Slave无法连接（另一台正常）。

如上，这些Case是我们线上的数据库可能会遇到的意外情况，不要觉得多，因为数据库宕机本身就发生在一些类似于上述的特定场景。接下来我们将一一尝试，进行上述case的验证。

在MHA自动切换的情况下

Case1：Master 意外宕掉，Slave正常，备选Slave正常

Step1：模拟Master意外宕机

# 在Master执行

[root@master]#  killall -9 mysqld mysqld_safe

# 在Master执行

[root@master]# killall -9 mysqld mysqld_safe

结果：MHA成功切换，Slave被执行新的Master并成功开始复制

下面是manager节点上的mha切换日志，我们可以清晰的看到它的工作流程：

·····省略一部分······

Phase 1: Configuration Check Phase..         //第一阶段，配置检测

·········

Phase 2: Dead Master Shutdown Phase..    //第二阶段，主动关闭有问题的master

·········

Phase 3: Master Recovery Phase..            //第三阶段，Master切换阶段

···········

Phase 3.1: Getting Latest Slaves Phase..    // 包含在第三阶段之内，3.1阶段，获得各个slave的状态

········

Phase 3.2: Saving Dead Master's Binlog Phase..   // 保存已死master的binlog日志

········

Phase 3.3: Determining New Master Phase..    // 抉择出新的Master

·········

Phase 3.4: Master Log Apply Phase..      // 应用以故master的binlog阶段

·······

Phase 4: Slaves Recovery Phase..     // 第四阶段，从库的恢复

·······

Phase 4.1: Starting Parallel Slave Diff Log Generation Phase..   // 启动从库sql线程去执行日志

·······

Phase 4.2: Starting Parallel Slave Log Apply Phase..   // 应用差异日志 ，并将从库切换到新的master

·······

Phase 5: New master cleanup phase..         //第五阶段，设置新master的一些东西，例如打开read_only,等等

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

·····省略一部分······

Phase 1: Configuration Check Phase.. //第一阶段，配置检测

·········

Phase 2: Dead Master Shutdown Phase.. //第二阶段，主动关闭有问题的master

·········

Phase 3: Master Recovery Phase.. //第三阶段，Master切换阶段

···········

Phase 3.1: Getting Latest Slaves Phase.. // 包含在第三阶段之内，3.1阶段，获得各个slave的状态

········

Phase 3.2: Saving Dead Master's Binlog Phase.. // 保存已死master的binlog日志

········

Phase 3.3: Determining New Master Phase.. // 抉择出新的Master

·········

Phase 3.4: Master Log Apply Phase.. // 应用以故master的binlog阶段

·······

Phase 4: Slaves Recovery Phase.. // 第四阶段，从库的恢复

·······

Phase 4.1: Starting Parallel Slave Diff Log Generation Phase.. // 启动从库sql线程去执行日志

·······

Phase 4.2: Starting Parallel Slave Log Apply Phase.. // 应用差异日志，并将从库切换到新的master

·······

Phase 5: New master cleanup phase.. //第五阶段，设置新master的一些东西，例如打开read_only,等等

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

如上是我省略了一些日志的内容的结果，我们发现MHA的工作内容被清晰的记录在了日志中，出了问题之后我们可以根据日志内容定位和查看。

Case2 : Master 意外宕掉，Slave落后很多binlog，备选Slave正常

Step1：模拟Slave延迟，在Slave执行如下语句

mysql> stop slave io_thread;

1	mysql> stop slave io_thread;

Step2：在Mster上生成大量请求

sysbench --test=oltp --oltp-table-size=1000000 --oltp-read-only=off --mysql-db=sbtest --oltp-table-name=sbtest2 --init-rng=on --num-threads=100 --max-requests=0 --max-time=100 --mysql-user=mha_user --mysql-socket=/tmp/mysql3306.sock --mysql-password="xxxxxx" --db-driver=mysql --oltp-test-mode=complex run         
sysbench 0.4.12:  multi-threaded system evaluation benchmark

Running the test with following options:
Number of threads: 100
Initializing random number generator from timer.


Doing OLTP test.
Running mixed OLTP test
Using Special distribution (12 iterations,  1 pct of values are returned in 75 pct cases)
Using "BEGIN" for starting transactions
Using auto_inc on the id column
Threads started!


Time limit exceeded, exiting...
(last message repeated 99 times)
Done.

OLTP test statistics:
    queries performed:
        read:                            15088850
        write:                           5383321
        other:                           2153711
        total:                           22625882
    transactions:                        1075936 (10758.62 per sec.)
    deadlocks:                           1839   (18.39 per sec.)
    read/write requests:                 20472171 (204707.67 per sec.)
    other operations:                    2153711 (21535.63 per sec.)

Test execution summary:
    total time:                          100.0069s
    total number of events:              1075936
    total time taken by event execution: 9993.0726
    per-request statistics:
         min:                                  2.24ms
         avg:                                  9.29ms
         max:                                136.91ms
         approx.  95 percentile:              14.55ms

Threads fairness:
    events (avg/stddev):           10759.3600/33.57
    execution time (avg/stddev):   99.9307/0.00

sysbench --test=oltp --oltp-table-size=1000000 --oltp-read-only=off --mysql-db=sbtest --oltp-table-name=sbtest2 --init-rng=on --num-threads=100 --max-requests=0 --max-time=100 --mysql-user=mha_user --mysql-socket=/tmp/mysql3306.sock --mysql-password="xxxxxx" --db-driver=mysql --oltp-test-mode=complex run

sysbench 0.4.12: multi-threaded system evaluation benchmark

Running the test with following options:

Number of threads: 100

Initializing random number generator from timer.

Doing OLTP test.

Running mixed OLTP test

Using Special distribution (12 iterations, 1 pct of values are returned in 75 pct cases)

Using "BEGIN" for starting transactions

Using auto_inc on the id column

Threads started!

Time limit exceeded, exiting...

(last message repeated 99 times)

Done.

OLTP test statistics:

queries performed:

write: 5383321

other: 2153711

total: 22625882

transactions: 1075936 (10758.62 per sec.)

deadlocks: 1839 (18.39 per sec.)

read/write requests: 20472171 (204707.67 per sec.)

other operations: 2153711 (21535.63 per sec.)

Test execution summary:

total time: 100.0069s

total number of events: 1075936

total time taken by event execution: 9993.0726

per-request statistics:

min: 2.24ms

avg: 9.29ms

max: 136.91ms

approx. 95 percentile: 14.55ms

Threads fairness:

events (avg/stddev): 10759.3600/33.57

execution time (avg/stddev): 99.9307/0.00

Step3：模拟主库意外宕屌，并立刻开启Slave的io线程，模拟Slave延迟

# 在Master 上执行

[root@master]#  killall -9 mysqld mysqld_safe


# 在Slave上执行

mysql> start slave io_thread;

# 在Master 上执行

[root@master]# killall -9 mysqld mysqld_safe

# 在Slave上执行

mysql> start slave io_thread;

结果：MHA成功切换，但耗时很长，大概耗时17分钟。

Case3：Master 意外宕掉，Slave正常，备选Slave落后很多binlog

Step：测试步骤与Case2类似，这里忽略不再详述。
结果：MHA成功切换，但耗时很长。

Case4：Master 意外宕掉，Slave复制意外停止，备选Slave正常

Step1：模拟Slave复制意外停止

# 在Slave执行如下SQL，直接关停主从复制

mysql> stop slave;

# 在Slave执行如下SQL，直接关停主从复制

mysql> stop slave;

Step2：模拟主库意外宕机

# 在Master执行

[root@master]#  killall -9 mysqld mysqld_safe

# 在Master执行

[root@master]# killall -9 mysqld mysqld_safe

结果：MHA成功切换，Slave被执行新的Master并成功开始复制

Case5： Master 意外宕掉，Slave正常，备选Slave复制意外停止

Step：测试步骤与Case4类似，这里忽略不再详述。
结果：MHA成功切换，备选Slave成功上位，Slave指向新的Master。

Case6：Master 意外宕掉，Slave正常，备选Slave也意外宕掉

Step1：模拟备选Slave意外宕掉

# 在备选Slave执行

[root@slave2]#  killall -9 mysqld mysqld_safe

# 在备选Slave执行

[root@slave2]# killall -9 mysqld mysqld_safe

Step2：模拟Master意外宕掉

# 在Master执行

[root@master]#  killall -9 mysqld mysqld_safe

# 在Master执行

[root@master]# killall -9 mysqld mysqld_safe

结果：MHA切换失败，因为只剩一台Slave，也失去了切换的意义。

Case7：Master too many connection，Slave正常，备选Slave正常

Step1：模拟Master 链接数过多的情况

[root@ master]# mysqlslap  --concurrency=4000 --iterations=100  --query='insert into tc(name) select ("nxjisbxxs");'   -hlocalhost -uroot -p"xxxxxxx" --socket=/tmp/mysql3306.sock  --create-schema=sbtest  
mysqlslap: [Warning] Using a password on the command line interface can be insecure.
mysqlslap: Error when connecting to server: 1040 Too many connections
mysqlslap: Error when connecting to server: 1040 Too many connections
mysqlslap: Error when connecting to server: 1040 Too many connections
mysqlslap: Error when connecting to server: 1040 Too many connections
mysqlslap: Error when connecting to server: 1040 Too many connections
mysqlslap: Error when connecting to server: 1040 Too many connections
mysqlslap: Error when connecting to server: 1040 Too many connections

[root@ master]# mysqlslap --concurrency=4000 --iterations=100 --query='insert into tc(name) select ("nxjisbxxs");' -hlocalhost -uroot -p"xxxxxxx" --socket=/tmp/mysql3306.sock --create-schema=sbtest

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

mysqlslap: Error when connecting to server: 1040 Too many connections

结果：MHA不会自动切换，经过确认，MHA的Manager用于检测主库是否宕机的数据库链接是长链接，在MySQL默认的配置文件下，长链接只有空闲8小时才会断开，所以Master too many connection 会导致新的链接无法建立，但是已经存在的长连接并没有受影响，所以Manager仍然可以正常检测到主库没有宕机，不会触发切换。

Case8：Master 正常工作，Slave （或备选Slave）意外宕掉

Step：测试比较简单，直接干掉Slave观察即可，这里不再详述。
结果：MHA不会主动切换，Master不宕掉的话，他不会管Slave或者备选Slave的。

Case9：Master 网路瞬断（1~30秒）

Step1：模拟网路瞬断

# 在Master上将Manager和所有Slave的IP地址给禁掉

[root@master ]# iptables -I INPUT -s 10.67.250.2 -j DROP
[root@master ]# iptables -I INPUT -s 10.67.250.3 -j DROP

这样对于Manager和Slave来说Master的网路就断开了。

# 在Master上将Manager和所有Slave的IP地址给禁掉

[root@master ]# iptables -I INPUT -s 10.67.250.2 -j DROP

[root@master ]# iptables -I INPUT -s 10.67.250.3 -j DROP

这样对于Manager和Slave来说Master的网路就断开了。

Step2：等待你要测试的瞬断时长，然后再恢复Master网路

[root@master ]# /etc/init.d/iptables reload

1	[root@master ]# /etc/init.d/iptables reload

结果：大概在（5~8）秒左右不会引起MHA的切换，超过这个值就会了，与你设置的 ping_interval 参数有关。

Case10：有二次检测机制下，如果Manager通过一台Slave无法连接（另一台正常）

Step1：模拟Manager无法正常连接Master

# 在Master上将Manager的IP地址给禁掉

[root@master ]# iptables -I INPUT -s 10.67.250.2 -j DROP

# 在Master上将Manager的IP地址给禁掉

[root@master ]# iptables -I INPUT -s 10.67.250.2 -j DROP

Step2：观察Manager状态和日志

# 产生如下日志

Fri May 26 21:24:03 2017 - [warning] Got timeout on MySQL Ping(SELECT) child process and killed it! at /usr/share/perl5/vendor_perl/MHA/HealthCheck.pm line 431.
Fri May 26 21:24:03 2017 - [info] Executing secondary network check script: /usr/bin/masterha_secondary_check -s 10.67.250.2 -s 10.67.250.3 --user=mha_controller --port=4344  --master_host=10.67.250.1 --master_ip=10.67.250.1 --master_port=3306 --master_user=root --master_password="xxxxxx" --ping_type=SELECT  --user=mha_controller  --master_host=10.67.250.1  --master_ip=10.67.250.1  --master_port=3306 --master_user=root --master_password=xxxxxx --ping_type=SELECT
Fri May 26 21:24:03 2017 - [info] Executing SSH check script: save_binary_logs --command=test --start_pos=4 --binlog_dir=/home/data/mysql3306 --output_file=/home/mha_controller/workdir//save_binary_logs_test --manager_version=0.56 --binlog_prefix=mysqld-bin
Fri May 26 21:24:06 2017 - [warning] Got error on MySQL connect: 2003 (Can't connect to MySQL server on '10.67.250.1' (4))
Fri May 26 21:24:06 2017 - [warning] Connection failed 2 time(s)..
Fri May 26 21:24:08 2017 - [warning] HealthCheck: Got timeout on checking SSH connection to 10.67.250.1! at /usr/share/perl5/vendor_perl/MHA/HealthCheck.pm line 342.
Monitoring server 10.67.250.2 is reachable, Master is not reachable from 10.67.250.2. OK.
Master is reachable from 10.67.250.3!
Fri May 26 21:24:08 2017 - [warning] Master is reachable from at least one of other monitoring servers. Failover should not happen.
Fri May 26 21:24:09 2017 - [warning] Got error on MySQL connect: 2003 (Can't connect to MySQL server on '10.67.250.1' (4))
Fri May 26 21:24:09 2017 - [warning] Connection failed 3 time(s)..
Fri May 26 21:24:12 2017 - [warning] Got error on MySQL connect: 2003 (Can't connect to MySQL server on '10.67.250.1' (4))
Fri May 26 21:24:12 2017 - [warning] Connection failed 4 time(s)..
Fri May 26 21:24:12 2017 - [warning] Secondary network check script returned errors. Failover should not start so checking server status again. Check network settings for details.
Fri May 26 21:24:15 2017 - [warning] Got error on MySQL connect: 2003 (Can't connect to MySQL server on '10.67.250.1' (4))
Fri May 26 21:24:15 2017 - [warning] Connection failed 1 time(s)..
Fri May 26 21:24:15 2017 - [info] Executing secondary network check script: /usr/bin/masterha_secondary_check -s 10.67.250.2 -s 10.67.250.3 --user=mha_controller --port=4344  --master_host=10.67.250.1 --master_ip=10.67.250.1 --master_port=3306 --master_user=root --master_password="xxxxxx" --ping_type=SELECT  --user=mha_controller  --master_host=10.67.250.1  --master_ip=10.67.250.1  --master_port=3306 --master_user=root --master_password=xxxxxx --ping_type=SELECT
Fri May 26 21:24:15 2017 - [info] Executing SSH check script: save_binary_logs --command=test --start_pos=4 --binlog_dir=/home/data/mysql3306 --output_file=/home/mha_controller/workdir//save_binary_logs_test --manager_version=0.56 --binlog_prefix=mysqld-bin
Fri May 26 21:24:18 2017 - [warning] Got error on MySQL connect: 2003 (Can't connect to MySQL server on '10.67.250.1' (4))
Fri May 26 21:24:18 2017 - [warning] Connection failed 2 time(s)..
Fri May 26 21:24:20 2017 - [warning] HealthCheck: Got timeout on checking SSH connection to 10.67.250.1! at /usr/share/perl5/vendor_perl/MHA/HealthCheck.pm line 342.
Monitoring server 10.67.250.2 is reachable, Master is not reachable from 10.67.250.2. OK.
Master is reachable from 10.67.250.3!
Fri May 26 21:24:20 2017 - [warning] Master is reachable from at least one of other monitoring servers. Failover should not happen.
Fri May 26 21:24:21 2017 - [warning] Got error on MySQL connect: 2003 (Can't connect to MySQL server on '10.67.250.1' (4))
Fri May 26 21:24:21 2017 - [warning] Connection failed 3 time(s)..
Fri May 26 21:24:24 2017 - [warning] Got error on MySQL connect: 2003 (Can't connect to MySQL server on '10.67.250.1' (4))
Fri May 26 21:24:24 2017 - [warning] Connection failed 4 time(s)..
Fri May 26 21:24:24 2017 - [warning] Secondary network check script returned errors. <span style="color: #ff0000;"><strong>Failover should not start so checking server status again. Check network settings for details.</strong></span>

# 产生如下日志

Fri May 26 21:24:03 2017 - [warning] Got timeout on MySQL Ping(SELECT) child process and killed it! at /usr/share/perl5/vendor_perl/MHA/HealthCheck.pm line 431.

Fri May 26 21:24:03 2017 - [info] Executing secondary network check script: /usr/bin/masterha_secondary_check -s 10.67.250.2 -s 10.67.250.3 --user=mha_controller --port=4344 --master_host=10.67.250.1 --master_ip=10.67.250.1 --master_port=3306 --master_user=root --master_password="xxxxxx" --ping_type=SELECT --user=mha_controller --master_host=10.67.250.1 --master_ip=10.67.250.1 --master_port=3306 --master_user=root --master_password=xxxxxx --ping_type=SELECT

Fri May 26 21:24:03 2017 - [info] Executing SSH check script: save_binary_logs --command=test --start_pos=4 --binlog_dir=/home/data/mysql3306 --output_file=/home/mha_controller/workdir//save_binary_logs_test --manager_version=0.56 --binlog_prefix=mysqld-bin

Fri May 26 21:24:06 2017 - [warning] Got error on MySQL connect: 2003 (Can't connect to MySQL server on '10.67.250.1' (4))

Fri May 26 21:24:06 2017 - [warning] Connection failed 2 time(s)..

Fri May 26 21:24:08 2017 - [warning] HealthCheck: Got timeout on checking SSH connection to 10.67.250.1! at /usr/share/perl5/vendor_perl/MHA/HealthCheck.pm line 342.

Monitoring server 10.67.250.2 is reachable, Master is not reachable from 10.67.250.2. OK.

Master is reachable from 10.67.250.3!

Fri May 26 21:24:08 2017 - [warning] Master is reachable from at least one of other monitoring servers. Failover should not happen.

Fri May 26 21:24:09 2017 - [warning] Got error on MySQL connect: 2003 (Can't connect to MySQL server on '10.67.250.1' (4))

Fri May 26 21:24:09 2017 - [warning] Connection failed 3 time(s)..

Fri May 26 21:24:12 2017 - [warning] Got error on MySQL connect: 2003 (Can't connect to MySQL server on '10.67.250.1' (4))

Fri May 26 21:24:12 2017 - [warning] Connection failed 4 time(s)..

Fri May 26 21:24:12 2017 - [warning] Secondary network check script returned errors. Failover should not start so checking server status again. Check network settings for details.

Fri May 26 21:24:15 2017 - [warning] Got error on MySQL connect: 2003 (Can't connect to MySQL server on '10.67.250.1' (4))

Fri May 26 21:24:15 2017 - [warning] Connection failed 1 time(s)..

Fri May 26 21:24:15 2017 - [info] Executing secondary network check script: /usr/bin/masterha_secondary_check -s 10.67.250.2 -s 10.67.250.3 --user=mha_controller --port=4344 --master_host=10.67.250.1 --master_ip=10.67.250.1 --master_port=3306 --master_user=root --master_password="xxxxxx" --ping_type=SELECT --user=mha_controller --master_host=10.67.250.1 --master_ip=10.67.250.1 --master_port=3306 --master_user=root --master_password=xxxxxx --ping_type=SELECT

Fri May 26 21:24:15 2017 - [info] Executing SSH check script: save_binary_logs --command=test --start_pos=4 --binlog_dir=/home/data/mysql3306 --output_file=/home/mha_controller/workdir//save_binary_logs_test --manager_version=0.56 --binlog_prefix=mysqld-bin

Fri May 26 21:24:18 2017 - [warning] Got error on MySQL connect: 2003 (Can't connect to MySQL server on '10.67.250.1' (4))

Fri May 26 21:24:18 2017 - [warning] Connection failed 2 time(s)..

Fri May 26 21:24:20 2017 - [warning] HealthCheck: Got timeout on checking SSH connection to 10.67.250.1! at /usr/share/perl5/vendor_perl/MHA/HealthCheck.pm line 342.

Monitoring server 10.67.250.2 is reachable, Master is not reachable from 10.67.250.2. OK.

Master is reachable from 10.67.250.3!

Fri May 26 21:24:20 2017 - [warning] Master is reachable from at least one of other monitoring servers. Failover should not happen.

Fri May 26 21:24:21 2017 - [warning] Got error on MySQL connect: 2003 (Can't connect to MySQL server on '10.67.250.1' (4))

Fri May 26 21:24:21 2017 - [warning] Connection failed 3 time(s)..

Fri May 26 21:24:24 2017 - [warning] Got error on MySQL connect: 2003 (Can't connect to MySQL server on '10.67.250.1' (4))

Fri May 26 21:24:24 2017 - [warning] Connection failed 4 time(s)..

Fri May 26 21:24:24 2017 - [warning] Secondary network check script returned errors. Failover should not start so checking server status again. Check network settings for details.

结果：MHA可以通过另外一个Slave检测到Master是OK的，所以不会触发切换

在MHA手动触发的情况下

Case1：Master 意外宕掉，Slave正常，备选Slave正常

Step1: 模拟Master意外宕掉

# 在Master执行

[root@master]#  killall -9 mysqld mysqld_safe

# 在Master执行

[root@master]# killall -9 mysqld mysqld_safe

Step2：在Manager主动触发切换

[mha_user@slave1 ~]$ masterha_master_switch --master_state=dead --dead_master_host=10.67.250.1 --ignore_last_failover  --global_conf=/etc/mha.cnf  --conf=/etc/mha.cnf

1	[mha_user@slave1 ~]$ masterha_master_switch --master_state=dead --dead_master_host=10.67.250.1 --ignore_last_failover --global_conf=/etc/mha.cnf --conf=/etc/mha.cnf

结果：成功触发MHA切换

Case2 : Master 意外宕掉，Slave落后很多binlog，备选Slave正常

Step1：模拟Slave延迟，在Slave执行如下语句

mysql> stop slave io_thread;

1	mysql> stop slave io_thread;

Step2：在Mster上生成大量请求

sysbench --test=oltp --oltp-table-size=1000000 --oltp-read-only=off --mysql-db=sbtest --oltp-table-name=sbtest2 --init-rng=on --num-threads=100 --max-requests=0 --max-time=100 --mysql-user=mha_user --mysql-socket=/tmp/mysql3306.sock --mysql-password="xxxxxx" --db-driver=mysql --oltp-test-mode=complex run         
sysbench 0.4.12:  multi-threaded system evaluation benchmark

Running the test with following options:
Number of threads: 100
Initializing random number generator from timer.


Doing OLTP test.
Running mixed OLTP test
Using Special distribution (12 iterations,  1 pct of values are returned in 75 pct cases)
Using "BEGIN" for starting transactions
Using auto_inc on the id column
Threads started!


Time limit exceeded, exiting...
(last message repeated 99 times)
Done.

OLTP test statistics:
    queries performed:
        read:                            15088850
        write:                           5383321
        other:                           2153711
        total:                           22625882
    transactions:                        1075936 (10758.62 per sec.)
    deadlocks:                           1839   (18.39 per sec.)
    read/write requests:                 20472171 (204707.67 per sec.)
    other operations:                    2153711 (21535.63 per sec.)

Test execution summary:
    total time:                          100.0069s
    total number of events:              1075936
    total time taken by event execution: 9993.0726
    per-request statistics:
         min:                                  2.24ms
         avg:                                  9.29ms
         max:                                136.91ms
         approx.  95 percentile:              14.55ms

Threads fairness:
    events (avg/stddev):           10759.3600/33.57
    execution time (avg/stddev):   99.9307/0.00

sysbench 0.4.12: multi-threaded system evaluation benchmark

Running the test with following options:

Number of threads: 100

Initializing random number generator from timer.

Doing OLTP test.

Running mixed OLTP test

Using Special distribution (12 iterations, 1 pct of values are returned in 75 pct cases)

Using "BEGIN" for starting transactions

Using auto_inc on the id column

Threads started!

Time limit exceeded, exiting...

(last message repeated 99 times)

Done.

OLTP test statistics:

queries performed:

write: 5383321

other: 2153711

total: 22625882

transactions: 1075936 (10758.62 per sec.)

deadlocks: 1839 (18.39 per sec.)

read/write requests: 20472171 (204707.67 per sec.)

other operations: 2153711 (21535.63 per sec.)

Test execution summary:

total time: 100.0069s

total number of events: 1075936

total time taken by event execution: 9993.0726

per-request statistics:

min: 2.24ms

avg: 9.29ms

max: 136.91ms

approx. 95 percentile: 14.55ms

Threads fairness:

events (avg/stddev): 10759.3600/33.57

execution time (avg/stddev): 99.9307/0.00

Step3：模拟主库意外宕掉，并立刻开启Slave的io线程，模拟Slave延迟

# 在Master 上执行

[root@master]#  killall -9 mysqld mysqld_safe


# 在Slave上执行

mysql> start slave io_thread;

# 在Master 上执行

[root@master]# killall -9 mysqld mysqld_safe

# 在Slave上执行

mysql> start slave io_thread;

Step4：手动触发MHA切换

masterha_master_switch --master_state=dead --dead_master_host=10.3.250.88 --ignore_last_failover  --global_conf=/etc/mha.cnf  --conf=/etc/mha.cnf

1	masterha_master_switch --master_state=dead --dead_master_host=10.3.250.88 --ignore_last_failover --global_conf=/etc/mha.cnf --conf=/etc/mha.cnf

结果：MHA成功切换，但耗时很长，大概耗时17分钟。

注意：这里你没有再配置文件的每个Server选项中指定如下参数，那么很有可能，会切换到Slave上，而不是备选Slave，这个参数会忽略各个Slave的主从延迟，而固执的切换到你指定的备选Slave上。

check_repl_delay = 0

Case3：Master 意外宕掉，Slave正常，备选Slave落后很多binlog

Step：测试步骤与Case2类似，这里忽略不再详述。
结果：MHA成功切换，但耗时很长。

Case4：Master 意外宕掉，Slave复制意外停止，备选Slave正常

Step1：模拟Slave复制意外停止

# 在Slave执行如下SQL，直接关停主从复制

mysql> stop slave;

# 在Slave执行如下SQL，直接关停主从复制

mysql> stop slave;

Step2：模拟主库意外宕机

# 在Master执行

[root@master]#  killall -9 mysqld mysqld_safe

# 在Master执行

[root@master]# killall -9 mysqld mysqld_safe

结果：MHA成功切换，Slave被执行新的Master并成功开始复制

Case5： Master 意外宕掉，Slave正常，备选Slave复制意外停止

Step：测试步骤与Case4类似，这里忽略不再详述。
结果：MHA成功切换，备选Slave成功上位，Slave指向新的Master。

Case6：Master 意外宕掉，Slave正常，备选Slave也意外宕掉

Step1：模拟备选Slave意外宕掉

# 在备选Slave执行

[root@slave2]#  killall -9 mysqld mysqld_safe

# 在备选Slave执行

[root@slave2]# killall -9 mysqld mysqld_safe

Step2：模拟Master意外宕掉

# 在Master执行

[root@master]#  killall -9 mysqld mysqld_safe

# 在Master执行

[root@master]# killall -9 mysqld mysqld_safe

结果：MHA切换失败，因为只剩一台Slave，也失去了切换的意义。

Case7：Master too many connection，Slave正常，备选Slave正常

Step1：模拟Master 链接数过多的情况

[root@ master]# mysqlslap  --concurrency=4000 --iterations=100  --query='insert into tc(name) select ("nxjisbxxs");'   -hlocalhost -uroot -p"xxxxxxx" --socket=/tmp/mysql3306.sock  --create-schema=sbtest  
mysqlslap: [Warning] Using a password on the command line interface can be insecure.
mysqlslap: Error when connecting to server: 1040 Too many connections
mysqlslap: Error when connecting to server: 1040 Too many connections
mysqlslap: Error when connecting to server: 1040 Too many connections
mysqlslap: Error when connecting to server: 1040 Too many connections
mysqlslap: Error when connecting to server: 1040 Too many connections
mysqlslap: Error when connecting to server: 1040 Too many connections
mysqlslap: Error when connecting to server: 1040 Too many connections

[root@ master]# mysqlslap --concurrency=4000 --iterations=100 --query='insert into tc(name) select ("nxjisbxxs");' -hlocalhost -uroot -p"xxxxxxx" --socket=/tmp/mysql3306.sock --create-schema=sbtest

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

mysqlslap: Error when connecting to server: 1040 Too many connections

结果：可以手动触发切换

Case8：Master 正常工作，Slave （或备选Slave）意外宕掉

Step：测试比较简单，直接干掉Slave观察即可，这里不再详述。
结果：MHA无法成功切换，会报出如下错误：

masterha_master_switch --master_state=alive  --global_conf=/etc/mha.cnf  --conf=/etc/mha.cnf 
Sat May 27 16:47:05 2017 - [info] MHA::MasterRotate version 0.56.
Sat May 27 16:47:05 2017 - [info] Starting online master switch..
Sat May 27 16:47:05 2017 - [info] 
Sat May 27 16:47:05 2017 - [info] * Phase 1: Configuration Check Phase..
Sat May 27 16:47:05 2017 - [info] 
Sat May 27 16:47:05 2017 - [info] Reading default configuration from /etc/mha.cnf..
Sat May 27 16:47:05 2017 - [info] Reading application default configuration from /etc/mha.cnf..
Sat May 27 16:47:05 2017 - [info] Reading server configuration from /etc/mha.cnf..
Sat May 27 16:47:05 2017 - [info] GTID failover mode = 0
Sat May 27 16:47:05 2017 - [error][/usr/share/perl5/vendor_perl/MHA/MasterRotate.pm, ln93] Switching master should not be started if one or more servers is down.
Sat May 27 16:47:05 2017 - [info] Dead Servers:
Sat May 27 16:47:05 2017 - [info]   10.67.250.2(10.67.250.2:3306)
Sat May 27 16:47:05 2017 - [error][/usr/share/perl5/vendor_perl/MHA/ManagerUtil.pm, ln177] Got ERROR:  at /usr/bin/masterha_master_switch line 53

masterha_master_switch --master_state=alive --global_conf=/etc/mha.cnf --conf=/etc/mha.cnf

Sat May 27 16:47:05 2017 - [info] MHA::MasterRotate version 0.56.

Sat May 27 16:47:05 2017 - [info] Starting online master switch..

Sat May 27 16:47:05 2017 - [info]

Sat May 27 16:47:05 2017 - [info] * Phase 1: Configuration Check Phase..

Sat May 27 16:47:05 2017 - [info]

Sat May 27 16:47:05 2017 - [info] Reading default configuration from /etc/mha.cnf..

Sat May 27 16:47:05 2017 - [info] Reading application default configuration from /etc/mha.cnf..

Sat May 27 16:47:05 2017 - [info] Reading server configuration from /etc/mha.cnf..

Sat May 27 16:47:05 2017 - [info] GTID failover mode = 0

Sat May 27 16:47:05 2017 - [error][/usr/share/perl5/vendor_perl/MHA/MasterRotate.pm, ln93] Switching master should not be started if one or more servers is down.

Sat May 27 16:47:05 2017 - [info] Dead Servers:

Sat May 27 16:47:05 2017 - [info] 10.67.250.2(10.67.250.2:3306)

Sat May 27 16:47:05 2017 - [error][/usr/share/perl5/vendor_perl/MHA/ManagerUtil.pm, ln177] Got ERROR: at /usr/bin/masterha_master_switch line 53

Case9：Master 有大的事务或写操作在进行，Slave正常，备选Slave也正常

Step1: 在Master模拟大事务

mysql> 
mysql> use test;
Database changed
mysql> 
mysql> 
mysql> 
mysql> select id , sleep(20) from kobe for update ;

mysql>

mysql> use test;

Database changed

mysql>

mysql> select id , sleep(20) from kobe for update ;

Step2：在Manager出发MHA主从切换，并观察结果

masterha_master_switch --master_state=alive  --global_conf=/etc/mha.cnf  --conf=/etc/mha.cnf

1	masterha_master_switch --master_state=alive --global_conf=/etc/mha.cnf --conf=/etc/mha.cnf

日志如下 > 如果有大事务，MHA会一直等待，直到事务结束：

Sat May 27 17:03:19 2017 - [info] MHA::MasterRotate version 0.56.
Sat May 27 17:03:19 2017 - [info] Starting online master switch..
Sat May 27 17:03:19 2017 - [info]
Sat May 27 17:03:19 2017 - [info] * Phase 1: Configuration Check Phase..
Sat May 27 17:03:19 2017 - [info]
Sat May 27 17:03:19 2017 - [info] Reading default configuration from /etc/mha.cnf..
Sat May 27 17:03:19 2017 - [info] Reading application default configuration from /etc/mha.cnf..
Sat May 27 17:03:19 2017 - [info] Reading server configuration from /etc/mha.cnf..
Sat May 27 17:03:19 2017 - [info] GTID failover mode = 0
Sat May 27 17:03:19 2017 - [info] Current Alive Master: 10.67.250.1(10.67.250.1:3306)
Sat May 27 17:03:19 2017 - [info] Alive Slaves:
Sat May 27 17:03:19 2017 - [info]   10.67.250.2(10.67.250.2:3306)  Version=5.7.18-14-log (oldest major version between slaves) log-bin:enabled
Sat May 27 17:03:19 2017 - [info]     Replicating from 10.67.250.1(10.67.250.1:3306)
Sat May 27 17:03:19 2017 - [info]   10.67.250.3(10.67.250.3:3306)  Version=5.7.18-14-log (oldest major version between slaves) log-bin:enabled
Sat May 27 17:03:19 2017 - [info]     Replicating from 10.67.250.1(10.67.250.1:3306)
Sat May 27 17:03:19 2017 - [info]     Primary candidate for the new Master (candidate_master is set)

<span style="color: #ff0000;"><strong>It is better to execute FLUSH NO_WRITE_TO_BINLOG TABLES on the master before switching. Is it ok to execute on 10.67.250.1(10.67.250.1:3306)? (YES/no): yes
Sat May 27 17:03:21 2017 - [info] Executing FLUSH NO_WRITE_TO_BINLOG TABLES. This may take long time..</strong></span>

<strong><span style="color: #ff0000;"># 一直卡在这里直到事务结束才会继续</span></strong>

Sat May 27 17:04:35 2017 - [info]  ok.
Sat May 27 17:04:35 2017 - [info] Checking MHA is not monitoring or doing failover..
Sat May 27 17:04:35 2017 - [info] Checking replication health on 10.67.250.2..
Sat May 27 17:04:35 2017 - [info]  ok.
Sat May 27 17:04:35 2017 - [info] Checking replication health on 10.67.250.3..
Sat May 27 17:04:35 2017 - [info]  ok.
Sat May 27 17:04:35 2017 - [info] Searching new master from slaves..
Sat May 27 17:04:35 2017 - [info]  Candidate masters from the configuration file:
Sat May 27 17:04:35 2017 - [info]   10.67.250.3(10.67.250.3:3306)  Version=5.7.18-14-log (oldest major version between slaves) log-bin:enabled
Sat May 27 17:04:35 2017 - [info]     Replicating from 10.67.250.1(10.67.250.1:3306)
Sat May 27 17:04:35 2017 - [info]     Primary candidate for the new Master (candidate_master is set)
Sat May 27 17:04:35 2017 - [info]  Non-candidate masters:
Sat May 27 17:04:35 2017 - [info]  Searching from candidate_master slaves which have received the latest relay log events..
Sat May 27 17:04:35 2017 - [info] 
From:
10.67.250.1(10.67.250.1:3306) (current master)
 +--10.67.250.2(10.67.250.2:3306)
 +--10.67.250.3(10.67.250.3:3306)

To:
10.67.250.3(10.67.250.3:3306) (new master)
 +--10.67.250.2(10.67.250.2:3306)

Starting master switch from 10.67.250.1(10.67.250.1:3306) to 10.67.250.3(10.67.250.3:3306)? (yes/NO): Continue? (yes/NO):

Sat May 27 17:03:19 2017 - [info] MHA::MasterRotate version 0.56.

Sat May 27 17:03:19 2017 - [info] Starting online master switch..

Sat May 27 17:03:19 2017 - [info]

Sat May 27 17:03:19 2017 - [info] * Phase 1: Configuration Check Phase..

Sat May 27 17:03:19 2017 - [info]

Sat May 27 17:03:19 2017 - [info] Reading default configuration from /etc/mha.cnf..

Sat May 27 17:03:19 2017 - [info] Reading application default configuration from /etc/mha.cnf..

Sat May 27 17:03:19 2017 - [info] Reading server configuration from /etc/mha.cnf..

Sat May 27 17:03:19 2017 - [info] GTID failover mode = 0

Sat May 27 17:03:19 2017 - [info] Current Alive Master: 10.67.250.1(10.67.250.1:3306)

Sat May 27 17:03:19 2017 - [info] Alive Slaves:

Sat May 27 17:03:19 2017 - [info] 10.67.250.2(10.67.250.2:3306) Version=5.7.18-14-log (oldest major version between slaves) log-bin:enabled

Sat May 27 17:03:19 2017 - [info] Replicating from 10.67.250.1(10.67.250.1:3306)

Sat May 27 17:03:19 2017 - [info] 10.67.250.3(10.67.250.3:3306) Version=5.7.18-14-log (oldest major version between slaves) log-bin:enabled

Sat May 27 17:03:19 2017 - [info] Replicating from 10.67.250.1(10.67.250.1:3306)

Sat May 27 17:03:19 2017 - [info] Primary candidate for the new Master (candidate_master is set)

It is better to execute FLUSH NO_WRITE_TO_BINLOG TABLES on the master before switching. Is it ok to execute on 10.67.250.1(10.67.250.1:3306)? (YES/no): yes

Sat May 27 17:03:21 2017 - [info] Executing FLUSH NO_WRITE_TO_BINLOG TABLES. This may take long time..

# 一直卡在这里直到事务结束才会继续

Sat May 27 17:04:35 2017 - [info] ok.

Sat May 27 17:04:35 2017 - [info] Checking MHA is not monitoring or doing failover..

Sat May 27 17:04:35 2017 - [info] Checking replication health on 10.67.250.2..

Sat May 27 17:04:35 2017 - [info] ok.

Sat May 27 17:04:35 2017 - [info] Checking replication health on 10.67.250.3..

Sat May 27 17:04:35 2017 - [info] ok.

Sat May 27 17:04:35 2017 - [info] Searching new master from slaves..

Sat May 27 17:04:35 2017 - [info] Candidate masters from the configuration file:

Sat May 27 17:04:35 2017 - [info] 10.67.250.3(10.67.250.3:3306) Version=5.7.18-14-log (oldest major version between slaves) log-bin:enabled

Sat May 27 17:04:35 2017 - [info] Replicating from 10.67.250.1(10.67.250.1:3306)

Sat May 27 17:04:35 2017 - [info] Primary candidate for the new Master (candidate_master is set)

Sat May 27 17:04:35 2017 - [info] Non-candidate masters:

Sat May 27 17:04:35 2017 - [info] Searching from candidate_master slaves which have received the latest relay log events..

Sat May 27 17:04:35 2017 - [info]

From:

10.67.250.1(10.67.250.1:3306) (current master)

+--10.67.250.2(10.67.250.2:3306)

+--10.67.250.3(10.67.250.3:3306)

To:

10.67.250.3(10.67.250.3:3306) (new master)

+--10.67.250.2(10.67.250.2:3306)

Starting master switch from 10.67.250.1(10.67.250.1:3306) to 10.67.250.3(10.67.250.3:3306)? (yes/NO): Continue? (yes/NO):

Case10：有二次检测机制下，如果Manager通过一台Slave无法连接（另一台正常）

Step1：模拟Manager无法正常连接Master

# 在Master上将Manager的IP地址给禁掉

[root@master ]# iptables -I INPUT -s 10.67.250.2 -j DROP

# 在Master上将Manager的IP地址给禁掉

[root@master ]# iptables -I INPUT -s 10.67.250.2 -j DROP

结果：MHA可以手动出发切换并且成功

7.1 在确认MHA正常运行之后，我直接模拟Master主库宕机，并同时查看MHA的切换日志：

mysqladmin -uroot -pxxxxx shutdown

MySQL MHA原理（一）

2017-02-04 作者：SleepSir

暂无评论

MHA的存在意义及基本特性

我们都知道MHA是一套优秀的作为MySQL高可用性环境下故障切换和主从提升的高可用软件。在MySQL故障切换过程中，MHA能做到在0~30秒之内自动完成数据库的故障切换操作，并且在进行故障切换的过程中，MHA能在最大程度上保证数据的一致性，以达到真正意义上的高可用。下面是他作为高可用框架的一些基本特性。

参数	值
故障响应时间	0 - 30s
服务器资源的利用率	很高，MHA是独立于MySQL集群本身的，只是保证了集群的高可用。不会因为架构的原因导致某个从库单纯的只作为备份而不提供服务。
故障切换是否安全	MHA会在切换过程中尽可能的保证数据的一致性。
维护成本和难度	是比较成熟且受欢迎的开源高可用框架，所以文档和网上的FAQ案例也相对来说比较完善。
二次开发特性	可以按需调整故障检测和故障响应的方式，算是比较灵活了吧
是否会产生脑裂等现象	不会

MHA的限制条件

1. 目前MHA主要支持一主多从的架构

要搭建MHA,要求一个复制集群中必须最少有三台数据库服务器，一主二从，即一台充当master，一台充当备用master，另外一台充当从库，因为至少需要三台服务器，出于机器成本的考虑，淘宝也在该基础上进行了改造，目前淘宝TMHA已经支持一主一从。
默认情况下，MHA是不支持3层或多层复制架构的（Master1 -> Master2 -> Slave3）, MHA可以恢复Master2，但是不能恢复Slave3，因为Master2，Slave3有不同的master，为了让MHA支持以上架构，可以参考如下配置：
在配置文件中，只配置两层(master1 and master2)
使用 “multi_tier_slave=1” 参数，然后设置所有hosts

2. MySQL版本必须是5.0 或者高于 5.0

3. 使用mysqlbinlog 5.1+ 支持MySQL5.1+

MHA使用mysqlbinlog来应用日志到目标slave上的
如果MySQL master设置的是row格式，那么MySQL必须是大于等于5.1版本，因为5.0不支持row
mysqlbinlog版本可以这样被检测：

[app@slave_host1]$  mysqlbinlog --version
mysqlbinlog Ver 3.3 for unknown-linux-gnu at x86_64

[app@slave_host1]$ mysqlbinlog --version

mysqlbinlog Ver 3.3 for unknown-linux-gnu at x86_64

如果你使用的是MySQL5.1，那么mysqlbinlog必须大于等于3.3
如果mysqlbinlog的版本是3.2，而mysql的版本是5.1，那么mha manager会报错，且停止monitoring

4. log-bin必须在候选master上开启

如果当前slave没有设置log-bin，那么很显然它不能成为提升为new master
如果没有任何机器设置了log-bin，那么mha会报错且停止failover

5. binlog，relay-log 主从环境必须全部一致

复制过滤规则（binlog-do-db, replicate-ignore-db 等等）必须全部一致

6. 复制用户必须在候选master上要存在

切换完成后，所有slave都必须执行change master 命令。在new master上复制用户必须有（REPLICATEION SLAVE权限）

7. 使用purge_relay_logs来定期删除relay logs

默认情况下，如果SQL线程执行完relay-log，relay logs就会被自动删除。但是这些relay-logs 也许还会用来恢复其他的slave，所以你需要关闭自动删除relay-logs的purge线程，然后自己阶段性的来删除如果是你自己来删的话，必须考虑repl 延迟问题，最好让slave删除relay log不要在同一时间点，假如需要恢复，那么这个时间点所有relay logs都被删除了就不好了。

MHA 的基本结构

从架构上来说，MHA分为如下两大部分：

1. Node部分

我们知道，MHA是基于MySQL Replication环境的，在该环境中，不管是Master角色，还是Slave角色，都称为Node，是被监控管理的对象节点。

Node服务器上需要安装MHA Node包。

2. Manager部分

Manager为MHA架构中的管理者，建议部署在一台独立的服务器上，当然也可部署在某个Slave上，但该Slave永远不要被选择成为新的Master，否则故障切换后的MHA架构就失去了高可用性。Manager服务器需要安装MHA Manager包，并完善一个主配置文件。

一个Manager可管理多套MySQL Replication环境（图片摘自网上）。

MHA安装配置

现在我有这样一套基于3306端口的主从复制结构，需要加上MHA的高可用：

IP地址	角色	hostname	server id	类型
10.67.250.1	Master	server1	1	写
10.67.250.2	slave1 + Manager	server2	2	只读
10.67.250.3	slave2 (backup)	server3	3	只读

1. 在每台MHA集群服务器上安装依赖

$ yum install -y perl-DBD-MySQL

1	$ yum install -y perl-DBD-MySQL

2. 在每台机器上安装MHA Node软件包

推荐使用rpm的方式安装：

$ curl http://www.mysql.gr.jp/frame/modules/bwiki/index.php\?plugin\=attach\&pcmd\=open\&file\=mha4mysql-manager-0.56-0.el6.noarch.rpm\&refer\=matsunobu -o mha4mysql-manager-0.56-0.el6.noarch.rpm

$ yum localinstall -y mha4mysql-node-0.56-0.el6.noarch.rpm

$ curl http://www.mysql.gr.jp/frame/modules/bwiki/index.php\?plugin\=attach\&pcmd\=open\&file\=mha4mysql-manager-0.56-0.el6.noarch.rpm\&refer\=matsunobu -o mha4mysql-manager-0.56-0.el6.noarch.rpm

$ yum localinstall -y mha4mysql-node-0.56-0.el6.noarch.rpm

也可以选择源码安装：

wget http://mysql-master-ha.googlecode.com/files/mha4mysql-node-0.56.tar.gz
tar xf mha4mysql-node-0.56.tar.gz
cd mha4mysql-node-0.56
perl Makefile.PL
make && make install

wget http://mysql-master-ha.googlecode.com/files/mha4mysql-node-0.56.tar.gz

tar xf mha4mysql-node-0.56.tar.gz

cd mha4mysql-node-0.56

perl Makefile.PL

make && make install

Node工具包（这些工具通常由MHA Manager的脚本触发，无需人为操作）主要包括以下几个工具：

$ rpm -ql mha4mysql-node-0.56-0.el6.noarch
/usr/bin/apply_diff_relay_logs                     # 识别差异的中继日志事件并将其差异的事件应用于其他的slave
/usr/bin/filter_mysqlbinlog                        # 去除不必要的ROLLBACK事件（MHA已不再使用这个工具）
/usr/bin/purge_relay_logs                          # 清除中继日志（不会阻塞SQL线程）
/usr/bin/save_binary_logs                          # 保存和复制master的二进制日志
/usr/share/man/man1/apply_diff_relay_logs.1.gz
/usr/share/man/man1/filter_mysqlbinlog.1.gz
/usr/share/man/man1/purge_relay_logs.1.gz
/usr/share/man/man1/save_binary_logs.1.gz
/usr/share/perl5/vendor_perl/MHA/BinlogHeaderParser.pm
/usr/share/perl5/vendor_perl/MHA/BinlogManager.pm
/usr/share/perl5/vendor_perl/MHA/BinlogPosFindManager.pm
/usr/share/perl5/vendor_perl/MHA/BinlogPosFinder.pm
/usr/share/perl5/vendor_perl/MHA/BinlogPosFinderElp.pm
/usr/share/perl5/vendor_perl/MHA/BinlogPosFinderXid.pm
/usr/share/perl5/vendor_perl/MHA/NodeConst.pm
/usr/share/perl5/vendor_perl/MHA/NodeUtil.pm
/usr/share/perl5/vendor_perl/MHA/SlaveUtil.pm

$ rpm -ql mha4mysql-node-0.56-0.el6.noarch

/usr/bin/apply_diff_relay_logs # 识别差异的中继日志事件并将其差异的事件应用于其他的slave

/usr/bin/filter_mysqlbinlog # 去除不必要的ROLLBACK事件（MHA已不再使用这个工具）

/usr/bin/purge_relay_logs # 清除中继日志（不会阻塞SQL线程）

/usr/bin/save_binary_logs # 保存和复制master的二进制日志

/usr/share/man/man1/apply_diff_relay_logs.1.gz

/usr/share/man/man1/filter_mysqlbinlog.1.gz

/usr/share/man/man1/purge_relay_logs.1.gz

/usr/share/man/man1/save_binary_logs.1.gz

/usr/share/perl5/vendor_perl/MHA/BinlogHeaderParser.pm

/usr/share/perl5/vendor_perl/MHA/BinlogManager.pm

/usr/share/perl5/vendor_perl/MHA/BinlogPosFindManager.pm

/usr/share/perl5/vendor_perl/MHA/BinlogPosFinder.pm

/usr/share/perl5/vendor_perl/MHA/BinlogPosFinderElp.pm

/usr/share/perl5/vendor_perl/MHA/BinlogPosFinderXid.pm

/usr/share/perl5/vendor_perl/MHA/NodeConst.pm

/usr/share/perl5/vendor_perl/MHA/NodeUtil.pm

/usr/share/perl5/vendor_perl/MHA/SlaveUtil.pm

3. 安装MHA Manager

推荐使用rpm的安装方式：

$ curl http://www.mysql.gr.jp/frame/modules/bwiki/index.php\?plugin\=attach\&pcmd\=open\&file\=mha4mysql-manager-0.56-0.el6.noarch.rpm\&refer\=matsunobu -o mha4mysql-manager-0.56-0.el6.noarch.rpm

$ yum localinstall -y mha4mysql-manager-0.56-0.el6.noarch.rpm

$ curl http://www.mysql.gr.jp/frame/modules/bwiki/index.php\?plugin\=attach\&pcmd\=open\&file\=mha4mysql-manager-0.56-0.el6.noarch.rpm\&refer\=matsunobu -o mha4mysql-manager-0.56-0.el6.noarch.rpm

$ yum localinstall -y mha4mysql-manager-0.56-0.el6.noarch.rpm

也可以使用源码方式安装：

wget http://mysql-master-ha.googlecode.com/files/mha4mysql-manager-0.56.tar.gz
tar xf mha4mysql-manager-0.56.tar.gz 
cd mha4mysql-manager-0.56
perl Makefile.PL
make && make install

wget http://mysql-master-ha.googlecode.com/files/mha4mysql-manager-0.56.tar.gz

tar xf mha4mysql-manager-0.56.tar.gz

cd mha4mysql-manager-0.56

perl Makefile.PL

make && make install

Manager工具包主要包括以下几个工具：

# rpm -ql mha4mysql-manager-0.56-0.el6.noarch
/usr/bin/masterha_check_repl                           # 检查MHA作用集群的主从复制
/usr/bin/masterha_check_ssh                            # 检查MHA作用集群的SSH连通性
/usr/bin/masterha_check_status                         # 检查MHA Manager的状态
/usr/bin/masterha_conf_host                            # 添加过删除配置的server信息
/usr/bin/masterha_manager                              # 启动MHA Manager
/usr/bin/masterha_master_monitor                       # 检测MySQL是否宕机
/usr/bin/masterha_master_switch                        # 手动触发MHA的切换
/usr/bin/masterha_secondary_check                      # 用于故障产生时的二次检测
/usr/bin/masterha_stop                                 # 关闭MHA Manager
/usr/share/man/man1/masterha_check_repl.1.gz
/usr/share/man/man1/masterha_check_ssh.1.gz
/usr/share/man/man1/masterha_check_status.1.gz
/usr/share/man/man1/masterha_conf_host.1.gz
/usr/share/man/man1/masterha_manager.1.gz
/usr/share/man/man1/masterha_master_monitor.1.gz
/usr/share/man/man1/masterha_master_switch.1.gz
/usr/share/man/man1/masterha_secondary_check.1.gz
/usr/share/man/man1/masterha_stop.1.gz
/usr/share/perl5/vendor_perl/MHA/Config.pm
/usr/share/perl5/vendor_perl/MHA/DBHelper.pm
/usr/share/perl5/vendor_perl/MHA/FileStatus.pm
/usr/share/perl5/vendor_perl/MHA/HealthCheck.pm
/usr/share/perl5/vendor_perl/MHA/ManagerAdmin.pm
/usr/share/perl5/vendor_perl/MHA/ManagerAdminWrapper.pm
/usr/share/perl5/vendor_perl/MHA/ManagerConst.pm
/usr/share/perl5/vendor_perl/MHA/ManagerUtil.pm
/usr/share/perl5/vendor_perl/MHA/MasterFailover.pm
/usr/share/perl5/vendor_perl/MHA/MasterMonitor.pm
/usr/share/perl5/vendor_perl/MHA/MasterRotate.pm
/usr/share/perl5/vendor_perl/MHA/SSHCheck.pm
/usr/share/perl5/vendor_perl/MHA/Server.pm
/usr/share/perl5/vendor_perl/MHA/ServerManager.pm

# rpm -ql mha4mysql-manager-0.56-0.el6.noarch

/usr/bin/masterha_check_repl # 检查MHA作用集群的主从复制

/usr/bin/masterha_check_ssh # 检查MHA作用集群的SSH连通性

/usr/bin/masterha_check_status # 检查MHA Manager的状态

/usr/bin/masterha_conf_host # 添加过删除配置的server信息

/usr/bin/masterha_manager # 启动MHA Manager

/usr/bin/masterha_master_monitor # 检测MySQL是否宕机

/usr/bin/masterha_master_switch # 手动触发MHA的切换

/usr/bin/masterha_secondary_check # 用于故障产生时的二次检测

/usr/bin/masterha_stop # 关闭MHA Manager

/usr/share/man/man1/masterha_check_repl.1.gz

/usr/share/man/man1/masterha_check_ssh.1.gz

/usr/share/man/man1/masterha_check_status.1.gz

/usr/share/man/man1/masterha_conf_host.1.gz

/usr/share/man/man1/masterha_manager.1.gz

/usr/share/man/man1/masterha_master_monitor.1.gz

/usr/share/man/man1/masterha_master_switch.1.gz

/usr/share/man/man1/masterha_secondary_check.1.gz

/usr/share/man/man1/masterha_stop.1.gz

/usr/share/perl5/vendor_perl/MHA/Config.pm

/usr/share/perl5/vendor_perl/MHA/DBHelper.pm

/usr/share/perl5/vendor_perl/MHA/FileStatus.pm

/usr/share/perl5/vendor_perl/MHA/HealthCheck.pm

/usr/share/perl5/vendor_perl/MHA/ManagerAdmin.pm

/usr/share/perl5/vendor_perl/MHA/ManagerAdminWrapper.pm

/usr/share/perl5/vendor_perl/MHA/ManagerConst.pm

/usr/share/perl5/vendor_perl/MHA/ManagerUtil.pm

/usr/share/perl5/vendor_perl/MHA/MasterFailover.pm

/usr/share/perl5/vendor_perl/MHA/MasterMonitor.pm

/usr/share/perl5/vendor_perl/MHA/MasterRotate.pm

/usr/share/perl5/vendor_perl/MHA/SSHCheck.pm

/usr/share/perl5/vendor_perl/MHA/Server.pm

/usr/share/perl5/vendor_perl/MHA/ServerManager.pm

如果你采用的是源码安装，那么安装完Manager后在安装目录底下存在一个 sample/scripts 目录，里面存在了一些功能性脚本：

$  ll  mha4mysql-manager-0.56/samples/scripts
总用量 32
-rwxr-xr-x. 1 4984 users  3648 4月   1 2014 master_ip_failover     
-rwxr-xr-x. 1 4984 users  9870 4月   1 2014 master_ip_online_change
-rwxr-xr-x. 1 4984 users 11867 4月   1 2014 power_manager
-rwxr-xr-x. 1 4984 users  1360 4月   1 2014 send_report

上面的这几个脚本都不是必须的，可根据自己的业务需求决定是否使用和调整。

master_ip_failover      # 是自动切换时vip管理的脚本，不是必须，如果我们使用keepalived的，我们可以自己编写脚本完成对vip的管理，比如监控mysql，如果mysql异常，我们停止keepalived就行，这样vip就会自动漂移.

master_ip_online_change # 在线切换时vip的管理，不是必须，同样可以可以自行编写简单的shell完成.

power_manager           # 故障发生后关闭主机的脚本，不是必须.

send_report             # 因故障切换后发送报警的脚本，不是必须，可自行编写简单的shell完成.

$ ll mha4mysql-manager-0.56/samples/scripts

总用量 32

-rwxr-xr-x. 1 4984 users 3648 4月 1 2014 master_ip_failover

-rwxr-xr-x. 1 4984 users 9870 4月 1 2014 master_ip_online_change

-rwxr-xr-x. 1 4984 users 11867 4月 1 2014 power_manager

-rwxr-xr-x. 1 4984 users 1360 4月 1 2014 send_report

上面的这几个脚本都不是必须的，可根据自己的业务需求决定是否使用和调整。

master_ip_failover # 是自动切换时vip管理的脚本，不是必须，如果我们使用keepalived的，我们可以自己编写脚本完成对vip的管理，比如监控mysql，如果mysql异常，我们停止keepalived就行，这样vip就会自动漂移.

master_ip_online_change # 在线切换时vip的管理，不是必须，同样可以可以自行编写简单的shell完成.

power_manager # 故障发生后关闭主机的脚本，不是必须.

send_report # 因故障切换后发送报警的脚本，不是必须，可自行编写简单的shell完成.

4. 配置前的准备工作

首先需要做一些配置之前的准备工作：

4.1 两台slave服务器设置read_only

set global read_only = ON；
set global relay_log_purge = 0 ;

1 2	set global read_only = ON； set global relay_log_purge = 0 ;

4.2 创建监控用户,用于MHA Manager管理其他数据库node节点

grant all on *.* to "mha_user"@"10.67.250.%" identified by "xxxxxx";
flush privileges;

1 2	grant all on . to "mha_user"@"10.67.250.%" identified by "xxxxxx"; flush privileges;

4.3 实现三台服务器之间的SSH免密码登录

详情可参考 http://www.foreverlakers.com/tag/ssh/

注：这里要注意，如果我们配置免密码登录的用户不是root用户（比如是mhatest用户），那么需要注意以下几点：

1. 将Manager的配置文件中指定的 manager_workdir 目录的权限修改为免密码登录认证的用户权限。比如，我们在配置文件中写到： manager_workdir = /usr/local/mha ，那么一定要确保

chown -R mhatest:mhatest /usr/local/mha

2. 将Manager的配置文件中指定的remote_workdir 目录也在对应的node节点将权限改为免密码登录认证的用户权限，比如，我们在配置文件中写道： remote_workdir = /home/data/mha，那么一定要确保

chown -R meatiest:mhatest /home/data/mha

5. 配置MHA Manager

5.1 配置MHA的Manager

$ mkdir -p /usr/local/mha
$ vim /etc/mha.cnf

[server default]
manager_workdir                     = /usr/local/mha                   // MHA Manager的工作目录
manager_log                         = /usr/local/mha/manager.log       // MHA Manager的log文件
master_binlog_dir                   = /home/data/mysql                 // master 保存binlog的位置，以便MHA可以找到master的日志

#master_ip_failover_script          = /usr/local/bin/master_ip_failover    // failover时候的切换ip的脚本，如果运用了keepalived等虚IP保证高可用的话可以加上, 如果你是源码安装则此默认存在与安装目录的sample目录下，rpm包安装则没有。


user                              = mha_user          // MHA Manager来进行管理控制MySQL的用户名
password                          = xxxxx             // MHA Manager来进行管理控制MySQL对应的密码
ping_interval                     = 3                 // 监控主库，发送ping包的时间间隔，默认是3秒，尝试三次没有回应的时候自动进行failover

remote_workdir                    = /home/data/mha                 // 远端mysql在发生切换时binlog的保存位置,
repl_user                         = replicauser                    //  复制用户的用户名          
repl_password                     = xxxx                           //  复制用户的密码
report_script                     = /usr/local/bin/send_report     //切换后发送报警的脚本,可以自己定义

secondary_check_script            = /usr/bin/masterha_secondary_check -s 10.67.250.2 -s 10.67.250.3 --user=mha_test --port=4344  --master_host=10.3.250.88 --master_ip=10.3.250.88 --master_port=3306 --master_user=mha_user --master_password="xxxxxx" --ping_type=SELECT                 // 二次检测的脚本，当发生故障后会通过次脚本检测从指定host到主库的连通性来判断主库是否真的宕机了，降低误切换的可能性

shutdown_script                   = ""                             // 故障发生后关闭故障主机脚本（该脚本的主要作用是关闭主机放在发生脑裂,这里没有使用）

ssh_user                          = mha_test                       // ssh的登录用户名
ssh_port                          = 4311                           // ssh的登录端口号


[server1]
hostname                          = 10.67.250.1
port                              = 3306

[server2]
hostname                          = 10.67.250.2
port                              = 3306


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

check_repl_delay                  = 0               // 默认情况下如果一个slave落后master 100M的relay logs的话，MHA将不会选择该slave作为一个新的master，因为对于这个slave的恢复需要花费很长时间，通过设置check_repl_delay=0,MHA触发切换在选择一个新的master的时候将会忽略复制延时，这个参数对于设置了candidate_master=1的主机非常有用，因为这个候选主在切换的过程中一定是新的master

$ mkdir -p /usr/local/mha

$ vim /etc/mha.cnf

[server default]

manager_workdir = /usr/local/mha // MHA Manager的工作目录

manager_log = /usr/local/mha/manager.log // MHA Manager的log文件

master_binlog_dir = /home/data/mysql // master 保存binlog的位置，以便MHA可以找到master的日志

#master_ip_failover_script = /usr/local/bin/master_ip_failover // failover时候的切换ip的脚本，如果运用了keepalived等虚IP保证高可用的话可以加上, 如果你是源码安装则此默认存在与安装目录的sample目录下，rpm包安装则没有。

user = mha_user // MHA Manager来进行管理控制MySQL的用户名

password = xxxxx // MHA Manager来进行管理控制MySQL对应的密码

ping_interval = 3 // 监控主库，发送ping包的时间间隔，默认是3秒，尝试三次没有回应的时候自动进行failover

remote_workdir = /home/data/mha // 远端mysql在发生切换时binlog的保存位置,

repl_user = replicauser // 复制用户的用户名

repl_password = xxxx // 复制用户的密码

report_script = /usr/local/bin/send_report //切换后发送报警的脚本,可以自己定义

secondary_check_script = /usr/bin/masterha_secondary_check -s 10.67.250.2 -s 10.67.250.3 --user=mha_test --port=4344 --master_host=10.3.250.88 --master_ip=10.3.250.88 --master_port=3306 --master_user=mha_user --master_password="xxxxxx" --ping_type=SELECT // 二次检测的脚本，当发生故障后会通过次脚本检测从指定host到主库的连通性来判断主库是否真的宕机了，降低误切换的可能性

shutdown_script = "" // 故障发生后关闭故障主机脚本（该脚本的主要作用是关闭主机放在发生脑裂,这里没有使用）

ssh_user = mha_test // ssh的登录用户名

ssh_port = 4311 // ssh的登录端口号

[server1]

hostname = 10.67.250.1

port = 3306

[server2]

hostname = 10.67.250.2

port = 3306

[server3]

hostname = 10.67.250.3

port = 3306

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

check_repl_delay = 0 // 默认情况下如果一个slave落后master 100M的relay logs的话，MHA将不会选择该slave作为一个新的master，因为对于这个slave的恢复需要花费很长时间，通过设置check_repl_delay=0,MHA触发切换在选择一个新的master的时候将会忽略复制延时，这个参数对于设置了candidate_master=1的主机非常有用，因为这个候选主在切换的过程中一定是新的master

5.2 配置检查

$ masterha_check_ssh --conf=/etc/mha.cnf     //检查ssh链接是否OK
$ masterha_check_repl --conf=/etc/mha.cnf    //检查主从复制是否OK

1 2	$ masterha_check_ssh --conf=/etc/mha.cnf //检查ssh链接是否OK $ masterha_check_repl --conf=/etc/mha.cnf //检查主从复制是否OK

5.3 通过master_check_status脚本查看Manager的状态

$ masterha_check_status --conf=/etc/mha.cnf   //如果正常，会显示"PING_OK"，否则会显示"NOT_RUNNING"，这代表MHA监控没有开启。

mha is stopped(2:NOT_RUNNING).

$ masterha_check_status --conf=/etc/mha.cnf //如果正常，会显示"PING_OK"，否则会显示"NOT_RUNNING"，这代表MHA监控没有开启。

mha is stopped(2:NOT_RUNNING).

5.4 启动MHA Manager 即可正常运行

$ nohup masterha_manager --conf=/etc/mha.cnf --ignore_last_failover < /dev/null > /usr/local/mha/manager.log 2>&1 &

1	$ nohup masterha_manager --conf=/etc/mha.cnf --ignore_last_failover < /dev/null > /usr/local/mha/manager.log 2>&1 &

5.5 再次check MHA 的Manager 是否启动成功

$ masterha_check_status --conf=/usr/local/mha/mha.cnf 
mha (pid:29299) is running(0:PING_OK), master:10.67.250.1

1 2	$ masterha_check_status --conf=/usr/local/mha/mha.cnf mha (pid:29299) is running(0:PING_OK), master:10.67.250.1

6. MHA 功能分离实现

6.1 自己监控，调用mha进行切换

有时候，我们可能因为各种原因不想让MHA承担监控和切换的全部工作。或许是因为不相信它，或许是因为特殊的业务逻辑，那么如果我们想自己来监控数据库的可用性，而在我们自己确定数据库故障时，用MHA作为主从切换的工具呢？

其实也很简单，在上面安装完MHA 的 Manager节点完后，会有一个masterha_master_switch 脚本，他就是MHA本身的切换脚本，所以完全可以调用他来实现手动的数据库切换。

我们直接打开这个脚本就可以看到：

······省略部分·······

# For master failover // 当master宕机时，可以用下面类似的形式调用

masterha_master_switch –master_state=dead –global_conf=/etc/masterha_default.cnf –conf=/usr/local/masterha/conf/app1.cnf –dead_master_host=host1

# For online master switch //当master在线切换时，可以用下面类似的参数

masterha_master_switch –master_state=alive –global_conf=/etc/masterha_default.cnf –conf=/usr/local/masterha/conf/app1.cnf

See online reference (http://code.google.com/p/mysql-master-ha/wiki/masterha_master_switch) for details.

=head1 DESCRIPTION

See online reference (http://code.google.com/p/mysql-master-ha/wiki/masterha_master_switch) for details.

6.2 自己设置主从切换时的逻辑

如果我在故障发生时，由于业务架构的原因，不想让MHA按照既定的原则切换Master，而是按照我们自己的设定进行故障处理该怎么做呢？

在上面安装完MHA 的 Manager节点完后，会有一个 master_ip_failover , 我们根据自己的需求将此脚本更新为我们想要的操作即可。这里举个例子，如果我们的数据库复制群是建立在Atlas为proxy的基础之上的话，我们想要做到在主库宕机后，在proxy里自动下掉，或者在主库发生故障时将主库的Keepalive停掉，使得虚拟IP被切换到备库上去，我们就可以在此脚本中加上一些操作满足我们的需求。

至此，MHA的简单原理和部署已经告一段落，后续我会专门再总结一下MHA高可用性能的测试：

http://www.foreverlakers.com/2017/05/mysql-mha原理（二）/

参考

HA方案之MySQL半复制+MHA+Keepalived+Atlas+LVS

https://yq.aliyun.com/articles/58920

MySQL MHA原理（二）

测试MHA 的高可用

在MHA自动切换的情况下

Case1：Master 意外宕掉，Slave正常，备选Slave正常

Case2 : Master 意外宕掉，Slave落后很多binlog，备选Slave正常

Case3：Master 意外宕掉，Slave正常，备选Slave落后很多binlog

Case4：Master 意外宕掉，Slave复制意外停止，备选Slave正常

Case5： Master 意外宕掉，Slave正常，备选Slave复制意外停止

Case6：Master 意外宕掉，Slave正常，备选Slave也意外宕掉

Case7：Master too many connection，Slave正常，备选Slave正常

Case8：Master 正常工作，Slave （或备选Slave）意外宕掉

Case9：Master 网路瞬断（1~30秒）

Case10：有二次检测机制下，如果Manager通过一台Slave无法连接（另一台正常）

在MHA手动触发的情况下

Case1：Master 意外宕掉，Slave正常，备选Slave正常

Case2 : Master 意外宕掉，Slave落后很多binlog，备选Slave正常

Case3：Master 意外宕掉，Slave正常，备选Slave落后很多binlog

Case4：Master 意外宕掉，Slave复制意外停止，备选Slave正常

Case5： Master 意外宕掉，Slave正常，备选Slave复制意外停止

Case6：Master 意外宕掉，Slave正常，备选Slave也意外宕掉

Case7：Master too many connection，Slave正常，备选Slave正常

Case8：Master 正常工作，Slave （或备选Slave）意外宕掉

Case9：Master 有大的事务或写操作在进行，Slave正常，备选Slave也正常

Case10：有二次检测机制下，如果Manager通过一台Slave无法连接（另一台正常）

MySQL MHA原理（一）

MHA的存在意义及基本特性

MHA的限制条件

MHA 的基本结构

1. Node部分

2. Manager部分

MHA安装配置

1. 在每台MHA集群服务器上安装依赖

2. 在每台机器上安装MHA Node软件包

3. 安装MHA Manager

4. 配置前的准备工作

5. 配置MHA Manager

6. MHA 功能分离实现

参考

Tag Cloud

Where amazing happened