wjw555

MySQL之MHA架构的介绍

一、前言：

1.1 MHA介绍

MHA（Master High Availability）目前在MySQL高可用方面是一个相对成熟的解决方案，它由日本DeNA公司youshimaton（现就职于Facebook公司）开发，是一套优秀的作为MySQL高可用性环境下故障切换和主从提升的高可用软件。在MySQL故障切换过程中，MHA能做到在0~30秒之内自动完成数据库的故障切换操作，并且在进行故障切换的过程中，MHA能在最大程度上保证数据的一致性，以达到真正意义上的高可用。
MHA自动化主服务器故障转移，快速将从服务器晋级为主服务器(通常在10-30s)，而不影响复制的一致性，不需要花钱买更多的新服务器，不会有性能损耗，容易安装，不必更改现有的部署环境，适用于任何存储引擎。
MHA提供在线主服务器切换，改变先正运行的主服务器到另外一台上，这个过程只需0.5-2s的时间，这个时间内数据无法写入。
MHA Manager通过ssh连接mysql slave服务器。
虽然MHA试图从挡掉的主服务器上保存二进制日志，并不是总是可行的。例如，如果主服务器硬件故障或无法通过ssh访问，MHA没法保存二进制日志，只进行故障转移而丢失最新数据。
使用半同步复制，可以大大降低数据丢失的风险。MHA可以与半同步复制结合起来。如果只有一个slave已经收到了最新的二进制日志，MHA可以将最新的二进制日志应用于其他所有的slave服务器上，因此他们彼此保持一致性。

1.2 MHA有如下特性：

1.2.1. 主服务器的自动监控和故障转移

MHA监控复制架构的主服务器，一旦检测到主服务器故障，就会自动进行故障转移。即使有些从服务器没有收到最新的relay log，MHA自动从最新的从服务器上识别差异的relay log并把这些日志应用到其他从服务器上，因此所有的从服务器保持一致性了。MHA通常在几秒内完成故障转移，9-12秒可以检测出主服务器故障，7-10秒内关闭故障的主服务器以避免脑裂，几秒中内应用差异的relay log到新的主服务器上，整个过程可以在10-30s内完成。还可以设置优先级指定其中的一台slave作为master的候选人。由于MHA在slaves之间修复一致性，因此可以将任何slave变成新的master，而不会发生一致性的问题，从而导致复制失败。
1.2.2. 交互式主服务器故障转移
可以只使用MHA的故障转移，而不用于监控主服务器，当主服务器故障时，人工调用MHA来进行故障故障。

1.2.3. 非交互式的主故障转移
不监控主服务器，但自动实现故障转移。这种特征适用于已经使用其他软件来监控主服务器状态，比如heartbeat来检测主服务器故障和虚拟IP地址接管，可以使用MHA来实现故障转移和slave服务器晋级为master服务器。
1.2.4. 在线切换主服务器
在许多情况下，需要将现有的主服务器迁移到另外一台服务器上。比如主服务器硬件故障，RAID控制卡需要重建，将主服务器移到性能更好的服务器上等等。维护主服务器引起性能下降，导致停机时间至少无法写入数据。另外，阻塞或杀掉当前运行的会话会导致主主之间数据不一致的问题发生。MHA提供快速切换和优雅的阻塞写入，这个切换过程只需要0.5-2s的时间，这段时间内数据是无法写入的。在很多情况下，0.5-2s的阻塞写入是可以接受的。因此切换主服务器不需要计划分配维护时间窗口(呵呵，不需要你在夜黑风高时通宵达旦完成切换主服务器的任务)。
注：MHA可以应用于任何复制结构

二． MHA架构所需条件

2.1. SSH公钥验证

MHA管理节点通过ssh连接mysql服务器，MHA节点通过scp发送最新的relay log到其他slaves服务器上。为了使这些过程自动化，使用SSH公钥验证密码。

2.2. 操作系统

MHA目前只支持Linux系统

2.3. 单台可写主服务器和多台从服务器或只读主服务器

当主服务器当掉时，MHA修复从服务器之间数据一致性。MHA试图从当掉的主服务器上保存尚未发送的二进制日志文件并应用于所有从服务器。如果只有一个从服务器，就不需在意从服务器之间一致性问题。即使只有一个从服务器，MHA也会从当掉的主服务器上保存尚未发送的二进制日志事件只要能通过ssh访问到主服务器。使用半同步复制可以解决当主服务器当掉后，无法ssh到主服务器上保存尚未发送的二进制日志事件。
从MHA Manager0.52版本开始，支持多主复制结构。只允许其中一台主服务器可写，其他主服务器必须设置read-only=1。默认情况下，被管理服务器应该是两层复制结构。

2.4. 在三层或三层以上复制情况

默认情况下，MHA不支持三层或三层以上的复制结构。如master1—master2—-slave3。MHA故障转移和恢复是直接从从服务器中选择一台作为当前的主主服务器。MHA可以管理master1和master2，当master1当掉后，将master2作为主，MHA不会监控和恢复slave3因为slave3是从不同的主服务器上(master2)复制的。为了使MHA工作在这种架构下，需要做如下设置：

只在MHA配置文件中配置master1和master2

在MHA配置文件中所有主机上设置multi_tier_slave=1

在这种情况下，MHA只管理主主服务器和二层的从服务器，在故障转移过程中，三层从服务器仍然可以正常工作的。

2.5. mysql版本5.0或更高

MHA支持mysql5.0或以上版本。因为从mysql5.0版本起二进制日志格式(binlog v4格式)改变了。当MHA解析二进制日志来确定目标中继日志位置，是使用v4格式的。MySQL版本不得低于5.0.60。

2.6. mysqlbinlog版本3.3或更高

MHA在目标从服务器上应用二进制事件使用mysqlbinlog。如果主服务器使用基于行格式复制，基于行格式的事件写入到二进制文件中，这种二进制日志格式的文件只能被MySQL5.1或更高版本的mysqlbinlog解析。MySQL5.0.60以下版本中的mysqlbinlog不支持基于行格式的。

2.7. 候选主服务器log-bin必须开启

如果当前的从服务器没有开启log-bin，那么将不可能成为主服务器。MHA管理节点会检测是否有配置log-bin。如果当前所有从服务器都没有设置log-bin，那么MHA不进行故障转移。

2.8. 所有服务器上的二进制日志和中继日志过滤规则必须相同

binlog-do-db和replicate-ignore-db设置必须相同。MHA在启动时候会检测过滤规则，如果过滤规则不同，MHA不启动监控和故障转移。

2.9. 候选主服务器上的复制用户必须存在

当故障转移后，所有从服务器上将执行change master to命令。

2.10. 保留中继日志和定期清理

默认情况下，从服务器上的中继日志在SQL线程执行完后会被自动删除的。但是这些中继日志在恢复其他从服务器时候可能会被用到，因此需要禁用中继日志的自动清除和定期清除旧的中继日志。定期清除中继日志需要考虑到复制延时的问题。在ext3文件系统下，删除大的文件需要一定的时间，会导致严重的复制延时。为了避免复制延时，暂时为中继日志创建硬链接。
MHA节点包含pure_relay_logs命令工具，它可以为中继日志创建硬链接，执行SET GLOBAL relay_log_purge=1，等待几秒中以便SQL线程切换到新的中继日志，再执行SET GLOBAL relay_log_purge=0。

pure_relay_logs参数如下所示：

–user mysql用户名

–password mysql密码

–host mysql服务器地址

–port 端口号

–workdir 创建和删除中继日志硬链接目录。成功执行脚本后，硬链接的中继日志文件将被删除。默认目录是/var/tmp。

–disable_relay_log_purge 如果relay_log_purge=1，purge_relay_logs脚本将退出不做任何事情。设置–disable_relay_log_purge参数，purge_relay_logs脚本不会退去，且自动设置relay_log_purge=0。

定期执行purge_relay_logs脚本：

Purge_relay_logs脚本删除中继日志不会阻塞SQL线程。因此在每台从服务器上设置计划任务定期清除中继日志。

00 00 * * * /usr/bin/purge_relay_logs --user=root --password=passwd --disable_relay_log_purge >> /data/masterha/log/purge_relay_logs.log 2>&1

最好在每台从服务器上不同时间点执行计划任务。

2.11. LOAD DATA INFILE不要使用基于语句型的二进制日志

如果使用非事务性存储引擎，在执行完LOAD DATA INFILE基于语句型二进制日志时，主服务器当掉，MHA可能不会产生差异的中继日志事件。使用LOAD DATA INFILE基于语句型二进制日志有一些已知问题，在mysql5.1版本中不建议使用，同时还会引起严重的复制延时，因此没有理由使用它。

三.MHA软件的组织结构

3.1该软件由两部分组成：

MHA Manager（管理节点）和MHA Node（数据节点）。MHA Manager可以单独部署在一台独立的机器上管理多个master-slave集群，也可以部署在一台slave节点上。MHA Node运行在每台MySQL服务器上，MHA Manager会定时探测集群中的master节点，当master出现故障时，它可以自动将最新数据的slave提升为新的master，然后将所有其他的slave重新指向新的master。整个故障转移过程对应用程序完全透明。

在MHA自动故障切换过程中，MHA试图从宕机的主服务器上保存二进制日志，最大程度的保证数据的不丢失，但这并不总是可行的。例如，如果主服务器硬件故障或无法通过ssh访问，MHA没法保存二进制日志，只进行故障转移而丢失了最新的数据。使用MySQL 5.5的半同步复制，可以大大降低数据丢失的风险。MHA可以与半同步复制结合起来。如果只有一个slave已经收到了最新的二进制日志，MHA可以将最新的二进制日志应用于其他所有的slave服务器上，因此可以保证所有节点的数据一致性。

目前MHA主要支持一主多从的架构，要搭建MHA,要求一个复制集群中必须最少有三台数据库服务器，一主二从，即一台充当master，一台充当备用master，另外一台充当从库，因为至少需要三台服务器，出于机器成本的考虑，淘宝也在该基础上进行了改造，目前淘宝TMHA已经支持一主一从。（出自：《深入浅出MySQL(第二版)》）

3.2.架构图：

3.2.MHA工作原理总结如下：

（1）从宕机崩溃的master保存二进制日志事件（binlog events）;

（2）识别含有最新更新的slave;

（3）应用差异的中继日志(relay log) 到其他slave;

（4）应用从master保存的二进制日志事件(binlog events);

（5）提升一个slave为新master;

（6）使用其他的slave连接新的master进行复制。

四．MHA工作流程

4.1. 监控和故障转移过程

检测复制设置和确定当前主服务器

监控主服务器

检测主服务器当掉

再次检测从服务器配置

关闭当掉的主服务器(可选)

恢复一个新的主服务器

激活新的主服务器

恢复其余的从服务器

告警(可选)

4.2. 在线切换过程