MHA 架构介绍：
MHA（Master High Availability）目前在 MySQL 高可用方面是一个相对成熟的解决方案，它由日本人 youshimaton 开发，是一套优秀的作为 MySQL 高可用性环境下故障切换和主从提升的高可用软件。在 MySQL 故障切换过程中，MHA 能做到 0~30 秒之内自动完成数据库的故障切换操作，并且在进行故障切换的过程中，MHA 能最大程度上保证数据库的一致性，以达到真正意义上的高可用。MHA 由两部分组成：MHA Manager（管理节点）和 MHA Node（数据节点）。MHA Manager可以独立部署在一台独立的机器上管理多个Master-Slave集群，也可以部署在一台Slave上。当 Master 出现故障是，它可以自动将最新数据的Slave 提升为新的 Master,然后将所有其他的 Slave 重新指向新的 Master。整个故障转移过程对应用程序是完全透明的。
存在的隐患：
在 MHA 自动故障切换的过程中，MHA 试图从宕掉的主服务器上保存二进制日志，最大程度保证数据的不丢失，但这并不总是可行的。例如，如果主服务器硬件故障或无法通过 SSH 访问，MHA 没有办法保存二进制日志，只能进行故障转移而丢失了最新数据。拓：MySQL 服务挂了，但是可以从服务器拷贝二进制。但如果硬件宕机或者 SSH 不能连接，不能获取到最新的 binlog 日志，如果复制出现延迟，会丢失数据。使用 MySQL5.5 的半同步复制，可以大大降低数据丢失的风险。MHA 可以和半同步复制结合起来。如果只有一个 Slave 已经收到了最新的二进制日志，MHA 可以将最新的二进制日志应用于其他所有 Slave 服务器上，保持数据一致性。最新版 0.56 版本，增加了支持 GTID 的功能，建议在 MySQL5.6 及之后版本使用。MySQL5.5建议使用管理节点版本 0.55，数据节点 0.54。
适用场景：
目前 MHA 主要支持一主多从的架构，要搭建 MHA，要求一个复制集群必须最少有 3 台数据库服务器，一主二从，即一台充当 Master，一台充当备用 Master，另一台充当从库。出于成本考虑，淘宝在此基础上进行了改造，目前淘宝开发的 TMHA 已经支持一主一从。
MHA工作原理：
1.从宕机崩溃的 Master 保存二进制日志事件（binlog event）；
2. 识别含有最新更新的 Slave；
3. 应用差异的中继日志（relay log）到其他 Slave；
4. 应用从 Master 保存的二进制日志事件；
5. 提升一个 Slave 为新的 Master；
6. 使其他的 Slave 连接新的 Master 进行复制；
MHA 的组成：
MHA 软件由两部分组成，Manager 工具包和 Node 工具包，具体如下。
Manager 工具包情况如下：
masterha_check_ssh:检查 MHA 的 SSH 配置情况。
masterha_check_repl:检查 MySQL 复制状况。
masterha_manager:启动 MHA。
masterha_check_status:检测当前 MHA 运行状态。
masterha_master_monitor:检测 Master 是否宕机。
masterha_master_switch:控制故障转移（自动或手动）。
masterha_conf_host:添加或删除配置的 server 信息。
Node 工具包（通常由 MHA Manager 的脚本触发，无需人工操作）情况如下：
save_binary_logs:保存和复制 Master 的 binlog 日志。
apply_diff_relay_logs:识别差异的中级日志时间并将其应用到其他 Slave。
filter_mysqlbinlog:去除不必要的 ROOLBACK 事件（已经废弃）
purge_relay_logs:清除中继日志（不阻塞 SQL 线程）
拓展思想：为了保证数据一致性，MySQL 复制中，常常会在 Master 上使用 sync_binlog 参数
保证 binlog 持久化，保证数据一致性。但这种方式对磁盘 I/O 会造成 10~20%的影响。但是
还有另外一个思路，就是使用 MySQL 半同步复制来保证数据一致性，MySQL 半同步复制是在
从服务器的内存中处理数据并进行发聩，虽然也会造成性能影响，但是相对于对 Master 造成
的磁盘 I/O 的影响来说，反而是个更好的方法。据《高性能 MySQL》 第三版中 10.9 的测试，
写入远程的内存（一台从库的反馈）比写入本地的磁盘（写入并刷新）要更快。使用半同步
复制相比主在主库上进行强持久化的性能有两倍的改善。
