高可用MySQL MHA介绍

MySQL MHA介绍

MHA简介

  MHA是一位日本MySQL大牛用Perl写一套MySQL故障切换方案，来保证数据库系统的高可用，在宕机的事件内（通常10-30秒），完成故障转意，部署MHA，可避免主从一致性问题，节约购买新服务器的费用，不影响服务器性能，易安装，不改变现有部署
 

MHA在生产环境的作用

  一主多从的环境下，MySQL的主从复制是异步或是半同步。
  Master发生故障的时候，有可能一部分（或者全部）的Slave未能获取到最新的binlog，造成Slave之间的binlog转发发生偏差。
如下图所示，Master宕机之后，id=102的binlog未能被发送到任何一个Slave上，id=101的binlog只有save2上有，slave3上未能收到id=100和id-101的binlog
 
 
如果想要正确恢复：
  • Master必须发出的ID=102的binlog
  • 还要消除各个Slave之间的差异性
MHA可以全自动的处理以上这些
 

MHA架构

可实现master工作状态的监控以及宕机时的故障转移
要求：MySQL版本要在5.0以上

MHA原理

1、等待SQL线程执行完毕
2、解析最新的Slave上的中继日志（relay log）的日志头（log Header），为其他各个服务器确定出差异位置
3、将i1-->i2-->X 全部组成一个二进制日志

MHA的主要特性

  • 从master的监控到故障转移全部都能自动完成，故障转移也可手动执行
  • 可在秒级单位内实现故障转移
  • 可将任意Slave提升至master
  • 具备在多个点上调用外部脚本（扩展）的技能，可以用在电源OFF或者IP地址的故障转移上。
  • 安装和卸载不用停止当前的mysql进程
  • MHA 自身不会增加服务器负担，不会降低性能，不用追加服务器
  • 不依赖Storage Engine
  • 不依赖二进制文件的格式（不论是statement模式还是Row模式）

拓展性

  • seconary_check_script
  1.   调用该脚本，从多个网络路径判断MASTER是否宕机
  2.   MASTER连接错误时会被调用
  3.   MHA标配的脚本masterhaseconarycheck方便
  • shutdown_script
  1.   电源强制OFF等
  2.   故障转移前的瞬间被调用
  3.   SSH可以链接到的情况下mysqld，mysqld_safe强制kill，ssh连不到的情况下关闭电源
  • master_ip_failover_script
  1.   MASTER的IP地址更新，新建和应用程序连接所需要的用户
  2.   故障转移前的瞬间和转移到新MASTER(差异反映结束后)被调用
  3.   根据用途的不同来写脚本可以实现不需要更改应用程序端就可以连接到新的MASTER
  4.   MASTER IP使用虚拟IP的场合
    将VIP让给新的MASTER
5.   用catalog database等来管理MASTER的IP地址的场合  
   更新该catalog database 中的信息
  •  report_script 发邮件通知故障转移成功或失败等的详细情况
  1.   故障转移结束后被调用

案例分析

  • 在DeNA的服务中（主要是社交游戏），针对有超过150组（对）MASTER/SLAVE的服务器引入MHA
  • MySQL一般不会出现服务宕机，通常是由OS和H/W故障引起
  • 拓展

    检测MASTER是否宕机

除了Manager会对MASTER进行监控外，另外还通过其他两处的远程数据中心来检测是否可以连接到MASTER

    强制宕机MASTER

ssh可以连接到的情况下用kill -9 mysqld mysqld_safe，ssh连接不到的情况下ipmitool等工具强制关闭电源。
 
  • 针对OS挂掉的故障转移，检测系统是否挂掉需要10秒，故障转移仅需4秒
  MASTER的生死判定
3*4-3 （9秒-12秒）

  判定是否可以进行故障转移

默认情况，只有其他所有的SLAVE都存货的情况下才进行故障转移
检测SLAVE，判断其工作状态（不到1秒）

  故障转移处理

  1. 强制将显著的MASTER关机
  2. SSH可以连接到的情况下，将有差异的二进制日志保存下来
  3. 确定新MASTER
  4. 将重新MASTER的IP地址有效化
  5. 重开其他的SLAVE从新的MASTER之间的主从复制
 

准备工作

一个可以写的MASTER和多个SLAVE或只读MASTER

当MASTER崩溃时，MHA会修复SLAVE之间的一致性问题。另外，MHA会尝试从崩溃的MASTER保存未能发送的二进制日志并应用到所有Slave。如果仅有一台SLAVE服务器，就不需要担心SLAVE之间的一致性问题。但是即使只有一台SLAVE服务器，在SSH可以连通的情况下，MHA在MASTER崩溃时抢救日志上也会非常有帮助，当然，通过半同步也可以解决这个问题。
 
从MHA Manager 0.52 开始支持多个MASTER(multi master)的复制。下面是MHA在多MASTER复制时注意的事项
  • 只允许有一个MASTER（可写）。在其他MASTER上必须设置MySQL全局变量"read-only=1"
  • 缺省情况下，所有被管理的服务器（在配置文件中定义的服务器）应该是2层级联复制。
 
在0.52版本以前，MHA仅在所有SLAVE都从同一个MASTER上进行复制才能进行检测，监控和故障转移操作。也就是说MHA不支持多主的配置形式。一般情况下，只要MHA可以管控自动故障转移，使用多MASTER配置的意义会很有限，比如在线模式更改。如果只是尝试使用多MASTER配置（比如仅仅为了在线模式更改）仅需在操作期间停止MHA并配置多主设置。当操作结束后，重新改为单主多从的配置，并重启MHA。

管理3层或更多曾的及联复制环境

MHA默认不支持三次或更多曾的级联复制架构（比如Master->Master2->Slave3）。MHA仅在SLAVE直接从当前主要MASTER进行复制时，才会进行故障转移和恢复操作。MHA可以管理MASTER1和MASTER2并且当MASTER1崩溃提升MASTER为主MASTER，但是MHA不能监控和恢复SLAVE3，因为SLAVE3从不同的MASTER(MASTER2)上进行主从复制。为了让MHA在这种架构下能进行工作，需要以下设置：
 
  • 在MHA的配置文件中设置MASTER和二层级联中的主机（MASTER1和MASTER2）
  • 使用multi_tier_slave=1 参数并在MHA配置文件中设置所有主机。
不管在那种情况中，MHA都只管理主MASTER和第二层的级联SLAVE，即使MASTER崩溃，MASTER2会成为主要MASTER,从MASTER进行复制的SLAVE依然可以运行
 

MySQL5.0或更高的版本

MHA支持MySQL5.0或更高的版本。MHA不支持MySQL4.1，因为MySQL5.0开始，二进制日志的格式发生了改变（binlog v4） MHA分析二进制日志并确定位置点时止支持v4版本，所以MySQL4.1 在这里不能工作。MySQL5.0或更高版本中的mysqlbinlog同样也需要v4版本的binlog格式。在早起的MySQL版本中主从复制处理存在一些非常严重的问题，所以高度推荐使用高版本的MySQL.特别是如果你还在使用MYSQL 5.06.0 以前的版本，请考虑升级
 

在候选MASTER 上必须开启log-bin

如果当前SLAVE未设置log-bin，很明显他们都不能成为MASTER，MHA Manager内部将会检查log-bin的设置，不会将未开启binlog的Slave提升为MASTER、如果当前的Slave都没有设置log-bin，MHA将会不尽兴故障转移

在所有服务器上二进制日志和中继日志过滤规则必须一致

所有服务器上的主从复制过滤规则（binlog-do-db，replicate-ignore-db等）MHA在启动时检查过滤规则，如果发现各服务器之间的配置不一致将不会进行监控或故障转移

在被选MASTER上必须存在具有复制权限的用户

当故障转移完成后，所有Slave将执行CHANGE MASTER TO 语句。必须存在一个具有复制权限的用户才能进行复制
posted @ 2017-12-15 14:45  活的潇洒80  阅读(572)  评论(0)  编辑  收藏  举报