本博客套路MHA+VIP架构。
1.架构说明
这种架构的MySQL集群中，包含至少3个MySQL节点，和1个MHA管理节点。可以确保在挂掉当前对外服务的主MySQL节点的情况下，能够快速启用其它2个从节点中的一个对外提供服务。
MHA+VIP架构有三种工作方式：
故障监控和自动转移。
故障人工转移。
在线切换。
2.核心原理
MHA+VIP架构的MySQL集群使用VIP作为MySQL服务对外提供服务的IP地址，即应用程序可以连接到拥有该VIP地址的主节点上执行数据读写操作。在主节点宕机后，可以将该VIP地址从主节点上解除，并同时选取一个从节点，并将VIP挂载到该从节点上，使得从节点具有对外提供服务的能力。通过这种方式保障应用程序能够继续访问到MySQL数据库中的数据。
3个MySQL节点中，1个是主节点，对外提供服务，另外2个是从节点，不对外提供服务，或者仅仅提供只读服务。因此，MHA+VIP架构实质上是基于MySQL主从复制技术，在此基础上增加了一些MySQL节点状态监控和VIP转移的组件。
MHA+VIP架构与MM+Keepalived架构有一个类似的地方，就是两者实质上都是通过VIP对外提供服务，不同的是，MHA+VIP架构中，需要在脚本中显式的调用命令ip addr add xxx.xxx.xxx.xxx dev eth0来为新的节点挂在VIP，而MM+Keepalived架构中，仅仅需要在Keepalived的配置文件中指定VIP地址，Keepalived自动完成VIP的挂载和卸载。
MHA+VIP架构有三种工作方式：
（1）故障监控和自动转移。
此时需要在MHA管理节点上启动MHA监控程序，自动定时检测MySQL节点的状态，当发现主节点宕机后，自动执行自定义的master_ip_failover脚本，该脚本实际上是在新的主节点上挂在VIP。
（2）人工故障转移。
此时不需要启动MHA监控程序，也不会自动检测MySQL节点的状态。在发现MySQL主节点宕机后，人工执行MHA的故障转移程序masterha_master_switch，带参数--dead_master_host=xxxx指定新的主节点，转换过程跟自动转换类似。
（3）在线切换。
此时是在主节点正常服务的情况下，因为某些原因需要将主节点切换到其它节点。人工执行masterha_master_switch程序，带参数--master_state=alive，表示当前主节点并没有宕机，因此在切换主节点后需要将其转换为从节点。
MHA+VIP架构的重点在于理解以下几个问题：
MHA监控程序如何知道MySQL节点宕机了？
MHA会在管理节点上检测MySQL节点的状态，同时会通过一个第三方节点来检测MySQL节点的状态，如果检测结果都是宕机了，那么就认为这个节点宕机了。如果该节点是主节点，就会启动故障转移程序。
MHA如何确保故障转移后的新的主节点的数据的完整性和一致性，即跟原主节点的数据相同？
从以下几个方面分析：
选择一个最佳的从节点。优先选择跟当前主节点的数据最接近的从节点，即binlog的位置最接近原来主节点的那个从节点。这样数据恢复的工作量最小。
等待新主节点将现存的binlog全部执行完毕，因为IO线程保存binlog的速度和SQL线程执行binlog的速度可能有差异。
将需要那一部分binlog从原来的主节点上通过scp复制到新主节点上,然后依据新主节点的binlog的位置精确复制真正需要的那一部分数据。将这一部分差异的binlog执行完毕。可以简单理解为通过mysqlbinlog程序根据binlog 位置精确的导出真正需要的那部分binlog产生的SQL语句，然后通过mysql程序执行这些SQL语句。
这样的工作完成之后，新的主节点和原来的主节点的数据就完全一致了。如果开启了半同步复制，则基本上可以保证最新的主节点和原来的主节点的数据完全一致，从而减少或者去掉这里的binlog执行的工作量。
MHA如何保证其它从节点与新的主节点的数据的一致？
在只有3个MySQL节点的情况下，另外的这个没有提升为主节点的从节点，就是所谓的最老的从节点，即数据与原来的主节点的差异最大的那个从节点。如果集群中不只有3个MySQL节点，则还需要考虑所有的其它从节点。为了描述方面，本文仅仅考虑总共3个MySQL节点的情况。
首先MHA等待这个最老的从节点将其现存的binlog全部执行完毕。
然后检查这个最老的从节点和新的主节点的relay log之间的位置差异。通过与前面类似的方式，将新的主节点的那一部分relay log复制到最老的从节点上并找出真正需要的那一部分relay log，然后执行完毕。
这样这个最老的从节点就跟新的主节点的数据完全一致了。需要注意的是，仅仅是跟新的主节点在应用从原来的主节点的binlog数据之前的状态完全一致，而不是应用binlog之后。
最后将在新的主节点上执行过的从原主节点拷贝过来的binlog执行一遍。这样最老的从节点的数据跟原来的主节点的数据完全一致了，即所有3个节点的数据完全一致了，而且都是最新的数据。
如果有超过2个从节点，需要对其它所有从节点执行一次在最老的从节点上执行过的所有操作，确保所有节点的数据一致。
3.架构缺点
MHA架构中很多工作基于ssh和scp，需要集群中各个节点开启免密码验证的主机互信机制，即使用ssh的公钥和私钥验证机制。一旦一个节点被黑客攻克，则所有节点全部会被攻克。
MHA架构中要求开启半同步复制，相比于默认的异步复制，在提升数据一致性的同时，会降低主节点的写事务的性能。
4.适用场景
MHA架构适用于互联网应用,被大量互联网公司广泛使用。
5.搭建环境
MHA+VIP架构的环境搭建工作包括以下步骤：
安装好MySQL的主从复制架构。这是基础，同时也相对比较简单。
安装MHA V0.57软件包。需要在联网情况下安装，因为涉及到MHA所依赖的大量perl软件包需要在线下载安装。
编写MHA所需要的两个脚本。failover脚本和online-change脚本，主要功能就是切换VIP。
根据MHA+VIP架构的三种模式，启动相应的程序。如果是自动切换模式，需要提前启动MHA监控程序，否则不需要启动MHA监控程序。
6.故障转移
MHA的故障转移有三种模式：
（1）自动模式。 MHA监控程序自动检测MySQL主节点的状态，在主节点不可用时自动选择新的主节点，并使得所有节点的数据保持一致，同时其它所有的从节点均从新主节点复制数据。另一个工作是VIP的切换。这种全自动化的模式使得MHA+VIP架构实现了秒级故障转移。
（2）人工模式。不启动MHA监控程序。在发生故障时，DBA收到报警邮件，并人工执行MHA提供的故障转移程序。其它过程跟自动转移相同。
（3）在线切换。在没有任何故障的情况下，有可可能DBA根据其它原因需要切换到新的主节点。同样人工执行故障转移程序，只是参数跟有故障时的人工模式有所不同而已。在线切换完成后原来的主节点成为从节点。