7月份YOSHINORI MATSUNOBU在Blog上Release了第一个版本的MySQL Master High Availability manager and tools(简称MHA)。

1. Overview

用于自动主备切换（Master的Failover），切换时间大约是10-30秒，MHA主要的优势是解决了主备的一致性问题，是第三方脚本的方式，对原来的MySQL没有任何影响，也不需要改变任何原来的架构部署。当然也支持在线的计划切换，切换时间大约也就0.5-2秒【可读，不可写】

是一种简单、优雅的高可用解决方案，有一些功能：

1.1 主库监控和Failover

在一个配好的主从环境中，MHA能够实时的监控MySQL主库，如果探测到主库失败，则会启动自动的切换程序(master failover)。这时，MHA能够保证所有的备库上的数据都一致。MHA会检查所有备库上的relay log，并使用最靠前的relay log，来同步所有其他的备库，保证各个备库的数据一致。MHA一般能够很快完成切换工作：9-12秒来探测主库失败，7-10秒来关闭master来避免脑裂(可选的)，然后在各个落后的备库上应用最新的日志(某一个备库上受到的最新的日志)。整个downtime大概是10-30秒。可以设置某一个备库，总是优先成为主库（可以通过在配置文件中设置优先级来实现），因为各个备库会全部同步，所以任何一个备库都可以成为主库。由于不一致导致的备库失败，这里都可以避免。

1.2 命令行交互式切换（手动切换）

不监控，直接进行切换操作。

1.3 直接切换（非交互式）

1.4 在线切换主库

有时候，需要更换主库，例如原主库有已知的硬件故障（RAM、RAID control等）或者换上更好的硬件等等。这是一种计划切换，MHA能够非常快速、并且“一致的”的完成切换。所谓“一致的”，即避免在切换时，原主库上还存在存活的Session，在做一些事务，导致数据的不一致。MHA完成这个“一致的”切换，大概会有0.5-2秒的写阻塞，一般这都是可以接受的维护时间。

2. Master Failover的挑战

主库Failover并没有想象的那么繁琐。我们看看最典型的MySQL部署情况：单个主库拖多个备库。当主库挂了，则需要先找到“最新”的Slave，将其升级为新的主库，并且让其他的备库都指向这个新主库。这并不复杂。当找到“最新”的slave，很容易确定其他备库哪些event还没有收到，如果这些非“最新”的备库不问青红皂白就直接连到新主库上的话，则会导致一些数据不一致。为了避免这种不一致，则需要确定哪些是丢失的events，然后apply到这些备库上，再连新主库。如果手动来做这些事儿的话，那就十分繁琐而且复杂。在这个Slide里面详细描述了这个细节：Automated master failover

Fig: Master Failover: What makes it difficult?

“最新”的slave表示：获得最多binlog的备库。

Currently most MySQL Replication users have no choice but to perform failover manually on master crashes.
在主库crash的时候，目前还没有什么好办法保证各个备库的一致。所以，很多时候需要手动去做这些操作，虽然主库crash的时候不多，但是一旦出现，那将是“相当”（用宋丹丹的口气说）的痛苦。

MHA目标就是实现这样的自动恢复。这个恢复包括选定新主库、确定各个备库relay log的差异、在新主库上应用差异的relay log，然后将其他备库指向新主库。一般MHA10-30秒可以完成全部的操作（可能更久如果你的备库延迟了很久的话）。

MHA有自动和命令行切换工具，自动切换命令”masterha_manager (MHA Manager)”由主库监控和主库Failover两部分组成。masterha_manager一直监控主库是否可用，如果发现无法连接主库，则可以立即执行一个非交互是的切换过程。

手动切换命令：masterha_master_switch先检查主库是否确实挂了，如果真挂了，masterha_master_switch选一个备库作为新主库（也可以指定一个），然后做恢复和切换。命令行把前面的复杂操作全部都封装起来了。

当已经有了自己的监控系统时（例如，你可以使用Pacemake之类的监控），无需使用MHA的监控功能时，这个功能可以帮你实现MySQL的切换操作。

3. MHA使用注意事项

注意事项：

1. 检测Master是否挂了，可以通过两个路由来确认。详细参考：secondary_network_script
2. MHA完成切换后，应用还需要完成切换，可以通过脚本：master_ip_failover_script parameter来帮助你做后续的工作。
3. 为了避免脑裂，MHA提供了一个关闭原Master的脚本shutdown_script parameter
4. 另外MHA，还提供了一个发送Email切换报告的功能：report_script parameter
5. 需要考虑级联的情况
6. Relay log不能再做自动清除了，否则需要的时候可能就没了。需要手动清理relay log，清理relay log时需要注意，没有应用的relay log千万不要清，否则备库就需要重新指向了。MHA有个脚本可以做这个工作：purge_relay_logs script
7. 在SBR时不要使用LOAD DATA INFILE

参考资料

1. MHA Google code主页
2. MHA 文档资源
3. MHA download
4. MHA 介绍: Announcing MySQL-MHA: “MySQL Master High Availability manager and tools” |
5. MHA for MySQL 0.52 released

刚刚完成在idata-forum的主题分享，介绍了一下最近一年在MySQL方面的尝试，包括性能调优，代码优化方面的内容。

不再紧张了。