测试背景

以下所有测试,全部基于以下复制结构完成

一、MHA安装

mha node 所有服务器节点都要安装
mha manager 只需要安装在manager节点

  • MHA NODE

  • MHA Manager

  • MHA rpm安装路径

二、MHA配置文件

  • global scope

  • application scope

  • local scope

三、前提要求(必须满足)

3.1 SSH公钥认证

基本上MHA manager,MNA node,以及二次检测的节点,都需要互相信任

如果slave比较多,实例比较多,最好提高下 /etc/ssh/sshd_config MaxStartups 的值(默认是10)

3.2 操作系统

仅在Linux上测试过

3.3 单写master和多slave或者只读master

打从一开始,MHA就是为了解决数据一致性而出生,所以,最好是多个slave
如果你只有一个slave,根本就碰不到数据一致性问题,也就不需要mha了
如果是一个slave,用版同步复制也能解决

从0.52开始,MHA就支持多master的复制架构了,下面列举了多master环境下注意点

  • 多master,但是只允许单点写入
  • 默认情况下,只支持2层复制架构

3.4 三层或者多层复制环境

默认情况下,MHA是不支持3层或多层复制架构的(Master1 -> Master2 -> Slave3)
MHA可以恢复Master2,但是不能恢复Slave3,因为Master2,Slave3有不同的master
为了让MHA支持以上架构,可以参考如下配置:

  • 在配置文件中,只配置两层(master1 and master2)
  • 使用 “multi_tier_slave=1” 参数,然后设置所有hosts

3.5 MySQL版本必须是5.0 或者高于 5.0

  • MySQL版本必须大于等于5.0
  • 尽量使用高版本的MySQL

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

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

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

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

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

3.8 binlog,relay-log 主从环境必须全部一致

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

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

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

3.10 使用purge_relay_logs来定期删除relay logs

默认情况下,如果SQL线程执行完relay-log,relay logs就会被自动删除。
但是这些relay-logs 也许还会用来恢复其他的slave,所以你需要关闭自动删除relay-logs的purge线程,然后自己阶段性的来删除
如果是你自己来删的话,必须考虑repl 延迟问题

最好让slave删除relay log不要在同一时间点,假如需要恢复,那么这个时间点所有relay logs都被删除了就不好了

3.11 不要在SBR的环境中使用load data infile

不管是SBR,还是RBR,最好不要使用load data

四、实战演练

  1. [功能测试] 测试场景一、手工操作,手动完成,failover
  2. [功能测试] 测试场景二、手工操作, 自动完成,failover
  3. [功能测试] 测试场景三、手工操作,自动完成,online master switch
  4. [功能测试] 测试场景四、自动监控,自动操作,自动完成,failover
  5. [用例测试] MySQL master 服务 down掉,是否成功自动failover
  6. [用例测试] MySQL master too many connection,无权限,响应慢,是否自动failover
  7. [用例测试] MySQL master 服务器 down掉,且候选master落后的最多, 是否自动failover,知否可以成功的做日志补偿
  8. [用例测试] MySQL slave 服务 down掉,是否自动failover
  9. [用例测试] MySQL 有一台slave,或者多台slave服务器延迟很大,是否自动failover
  10. [用例测试] MySQL slave IO/SQL线程 stop,是否自动failover
  11. [用例测试] MySQL slave IO/SQL线程 报错,是否自动failover
  12. [用例测试] MySQL master 有大事务超过100s再执行,是否可以online master switch
  13. [用例测试] MySQL master 网络断掉,是否自动failover
  14. [用例测试] MySQL master 网路瞬断(1~30秒),是否自动failover
  15. [用例测试] MySQL master 和 候选master 网络都挂掉的情况,是否自动failover
  16. [用例测试] MHA manager 和 MySQL master之间的网络断掉,但是master和slave之间的网络是好的,是否自动failover
  17. [用例测试] MHA manager 和 MySQL master,slave 网络都断掉的情况,是否自动failover
  18. [用例测试] GTID模式下,还需要relay-log吗?是否能够成功的补齐日志
  19. [用例测试] 多线程复制模式下,做failover 和 online master switch,会不会有问题呢?
  20. [用例测试] 在一开始没有开启MHA的group中,如何做到日志补偿,然后change master呢?

4.0 简单的failover过程

  • step1:安装MHA node在所有节点上
  • step2:安装MHA manager
  • step3:创建配置文件

  • step4: 检查SSH 互信

  • step5: 检查复制配置

  • step6:开启Manager

  • step7: 检查manager的状态

  • step8: 测试关闭manager

  • step9:测试master failover

  • 未完成的步骤(进阶)

4.2 测试场景一、 手工操作,手动完成,failover

  • step1: 检查各种MHA manager的各种环境

  • step2: 手工制造master mysql挂了

  • step3: 人工交互式failover

4.3 [功能测试] 测试场景二、手工操作, 自动完成,failover

  • step1: 检查各种MHA manager的各种环境

  • step2: 手工制造master mysql挂了

  • step3: 人工-非交互式 failover

4.4 [功能测试] 测试场景三、手工操作,自动完成,online master switch

  • step1: 检查各种MHA manager的各种环境

  • step2: 手工制造master mysql挂了

  • step3: 手工操作,自动完成,online master switch

4.5 测试场景四、自动监控,自动操作,自动完成,failover

  • step1: 检查各种MHA manager的各种环境

  • step2: 手工制造master mysql挂了

  • step3: 自动监控,自动操作,自动完成,自动failover

4.6 [用例测试] MySQL master too many connection,无权限,响应慢

  • step1: 检查各种MHA manager的各种环境

  • step2: 手工制造master too many connection

  • step3: 检查是否发生failover

4.7 [用例测试] MySQL master 服务器 down掉,且候选master落后的最多, 是否自动failover,知否可以成功的做日志补偿

  • step1: 检查各种MHA manager的各种环境

  • step2: 手动制造候选master落后的情况

  • step3: 手动制造master 服务器挂掉的情况

  • step4: 观察MHA 日志

  • step5:重新修正配置文件

由于要指定特定的slave为候选master,而此slave还落后非常多
必须在每组服务器上都加上check_repl_delay=0

  • step6:用手工failover再来模拟

  • step7: 观察MHA 日志