今天热璞数据库跟大家分享的干货来自HotDB首席架构师关于MySQL数据高可用的详解。

前一篇文章只讨论了故障服务器彻底损毁的情况。但实际使用场景中，更多的时候遇到的是MySQL实例自杀\被kill -9、内核panic、服务器死机\重启等故障。在这些场景中再次启动MySQL实例时，多数情况下，MySQL会通过执行崩溃恢复流程，使自己恢复到可以运行的状态。我们来分析一下，相关的坑点，与应对方法。  

场景一、从机故障  

还是先看从机故障的场景，上篇文章已经明确：从机故障是不破坏“等效不丢”的。修复从机最简单直接的方法也是：故障过的从机直接放弃，然后根据现有主机中MySQL的数据，重新搭建一个新从机。在有自动化管理平台的情况下，这样的工作通常只需要点点鼠标，简单便捷，不易出错。DBA可能会出于各种不同的想法或者一些客观原因，尝试去修复从机并继续使用，但在生产环境这样做是不理性的。一方面，故障过的服务器，如果没有从根本上解决掉问题，未来可能还会继续故障；另一方面，故障对MySQL从机会造成各种千奇百怪的影响，花样繁多，防不胜防，稍不注意，就可能为未来留下隐患。 

 我们从探讨技术的角度出发，研究一下从机的状态。从机经历了崩溃恢复的流程，于是它的状态肯定和log_slave_updates、master_info_repository、relay_log_info_repository、relay_log_recovery等几个重要参数和复制是否基于gtid的自动位置都有关。

我们前文已经提到打开relay_log_recovery的问题，它在打开relay_log_purge（默认打开，crash-safe的复制也要求打开）时，可能导致已经接收到的relaylog在没有被SQL线程应用的情况下被删除。这样会破坏基于半同步复制做高可用所依赖的基础，考虑到这一点，笔者个人是决策放弃使用crash-safe的复制。同时，一般而言relaylog本身是不会配置持久化的（sync_relay_log不等于1），因此，出现操作系统及更底层层次的故障时，由于relaylog损坏导致出现一些复制方面的报错也是这个决策下不得不接受的缺陷。当然，这种删除relaylog破坏半同步进而导致严重后果的危险，只出现在主从机同时出现问题的场景，它本身超出我们设想的高可用方案容许的灾难级别；使用crash-safe的复制可以减轻一些处理复制故障的工作量，有一定微小的收益；但反过来思考，继续使用这个从机同时也意味着承担服务器再次故障的隐患风险；因此最终是否坚持使用crash-safe的复制，还是看DBA自己的想法。 

尽管笔者放弃了crash-safe的复制，但是还是可以尽量配置好一个从机，来降低遇到故障时的损害程度：如果我们设置log_slave_updates=on、master_info_repository=TABLE、relay_log_info_repository=TABLE，那么从机在顺利执行崩溃恢复后，gtid位置信息是正确的，复制执行到的位置信息也是正确的，尽管relaylog可能损坏，但是损坏的relaylog并不会被执行。

基于上述配置的前提，在relaylog确实损坏的情况下，DBA可以短暂地取消主机半同步复制的设置，然后在从机上删除复制关系，再使用自动位置的方式，重新完整配置半同步复制关系即可。但是在重新投入生产前，应仔细核对主从数据的一致性。 

 场景二、主机故障