基于这三点总结就抛出了三个问题：
1. 现有的HA软件是否可靠，可信？是否在正确的时候做了正确的判断和操作？
2. 没有集中管理机的HA架构（即内部投票）是否可靠？
3. HA的Failover过程是否要考虑数据预热？
以下是对于这三个问题的一些分析和个人看法：
问题一：现有的HA软件是否可靠，可信？是否在正确的时候做了正确的判断和操作？
GitHub团队认为：The automated failover of our main production database could be described as the root cause of both of these downtime events.
而对于这个问题，我的想法和 Xaprd的观点 一致：事故的关键在于现有的HA软件都没法照顾到所有可能发生的情况，以至于在某些情况下的行为是不可预测的，或者非我们所想的。
因此一味的将切换操作置成手工模式，虽然避免了风险，但显然没有很好的使用HA软件所提供的service。
个人想法是，对于一些原因明确且有明确cookbook的事故，可以让HA去完成failover。而对于那些需要人工介入分析故障原因的事故，做手工切换，如果github遇到的timeout等。
问题二： 没有集中管理机的HA架构（即内部投票）是否可靠？
从目前的流行程度来看，MMM，MHA这些使用Manager管理模式的架构，已经逐渐替代 Heartbeat + LVS/ Pacemaker 等投票模式的架构。
其主要原因就是在没有仲裁机的情况下，发生网络partition会造成脑裂，从而导致active角色的互相争抢，最后使整个cluster瘫痪。
Github再次用血的教训告诉我们脑裂是无仲裁架构的致命缺陷。
问题三：HA的Failover过程是否要考虑数据预热？
这个问题显然是引起本次问题的关键：没有预热的切换才是万恶之源。脑裂只是连锁反应而已。
而貌似整个社区的blog中对于这个问题的讨论却是少之又少，也许是重视程度不够？
会造成切换后压力剧增可能的情况，我总结为以下三种：
1. stand-by-master完全作为冗余，BufferPool 基本没有热点数据
2. stand-by-master提供read-only服务，但read-only 和 acitve master 的请求业务类型不同，导致热点数据不同
3. 原本active的MySQL宕机后重新回归，此时重启后的MySQL是处于完全Cold 状态
但目前众多HA软件中都没有考虑预热的因素，毕竟所有的failover都希望尽快的将业务转移至stand-by master，而预热则需要尽可能多的时间来获取业务的请求。
也许这是一个无解命题？
bitsCN.com 下载本文