MySQL高可用MHA方案那些事儿，聊聊我的理解和一些没整理全的想法

关于MySQL高可用MHA方案的那些事儿,我来聊聊我的理解和一些还没完全整理清楚的想法，这些东西主要来自我以前工作的实践，加上看一些技术博客（比如之前流行的“姜承尧的MySQL技术内幕”相关的文章、一些运维博客像“老叶茶馆”也零散提过）和官方文档的零碎信息，可能不成体系，但都是些实在的感触。

MHA,说白了，就是MySQL高可用的一个“老牌”工具，它的核心目标特别直接：当主库（Master）突然挂掉的时候，能自动且快速地选出一个从库（Slave）顶上，让它成为新的主库，并且让其他的从库都去跟这个新主库同步，从而让整个数据库集群尽快恢复服务，减少业务停摆的时间，这在当时（大概十年前吧）是非常厉害的想法。

我理解MHA的工作方式有点像“监工”，它由一个管理节点（MHA Manager）和一群“眼线”（MHA Node，部署在每个MySQL实例上）组成，Manager这个“监工”会定期地通过Node去检查每个MySQL实例的心跳，看看主库还活着没，一旦发现主库没响应了，它就会立刻启动一套“应急流程”。

这套流程有几个关键步骤,我觉得是MHA的精髓所在，它要确认主库是不是真的“死透了”，避免误判，它会从剩下的从库里面，选一个数据最新的（就是落后主库日志最少的）作为候选新主库，最关键的一步，MHA会尝试去旧主库服务器上，把可能还没同步到从库的二进制日志（binlog）给抢救出来，应用到新选出来的主库上，这一步是为了最大程度地减少数据丢失，才是指挥其他从库改变同步目标，指向新主库，并把这个变化记录下来。

MHA的好处很明显,就是简单、相对轻量，对于传统的“一主多从”自动化程度已经很高了，能大大降低人工切换的复杂度和出错风险，而且它那个“抢救binlog”的机制，在当时是很大的一个亮点。

用久了,或者随着技术发展，我也发现MHA有不少让人头疼的地方，或者说一些我没完全想明白怎么处理才最好的点：

第一,MHA Manager本身是个单点，这个“监工”自己挂了怎么办？虽然可以想办法给它做高可用，比如也用主备，但这又增加了部署和管理的复杂度，这就有点讽刺，一个做高可用的工具，自己的核心组件却有单点风险。

第二,对网络和环境的要求挺高的，MHA的自动切换严重依赖于SSH免密登录，这在一些对安全有严格管控的环境里，配置起来很麻烦，而且网络稍微有点波动，可能就会引发误报警，甚至误切换，有时候感觉它有点“神经质”。

第三,也是我觉得现在MHA逐渐被其他方案替代的主要原因，就是它只负责故障切换，不负责读写分离和负载均衡，你需要结合像HAProxy、LVS这样的中间件来实现读流量的分发，整个架构就变得复杂了，现在流行的MySQL Router或者ProxySQL这类东西，似乎把高可用、读写分离、故障感知都集成在一起了，管理起来更一体化。

第四,当集群规模变大，从库数量很多的时候，MHA在切换时重新配置所有从库的过程可能会变慢，因为它是串行操作还是怎么的，我记不清了，反正效率是个问题。

第五,脑裂”问题，这是所有主从切换方案的通病，但MHA也需要妥善处理，万一主库其实没挂，只是和MHA Manager之间的网络断了，但和客户端网络还是好的，这时候就可能出现两个“主库”都在写数据，导致数据彻底混乱，虽然MHA有一些防止机制，但总觉得不够完美。

我现在对MHA的看法是,它是一个在特定历史时期非常成功和实用的方案，思想很经典，很多后来的高可用方案都能看到它的影子，对于中小规模、架构相对简单的场景，它依然是一个不错的选择，在面对更复杂的云环境、更大规模的集群、以及对运维自动化有更高要求的今天，可能就需要考虑更现代、更集成的方案了，比如基于MGR（MySQL Group Replication）的方案，或者各大云厂商自己提供的RDS服务（它们底层的高可用机制其实更黑盒但也更省心）。

还有一些零碎的想法,比如MHA和数据库中间件的结合到底怎么做最优雅？监控MHA自身的状态有哪些除了看日志以外的好方法？这些我觉得我还没整理得很全，可能还需要更多的实践。