原标题：关于MySQL高可用，快速恢复是最好的补充，顺带两个设计方案
这是学习笔记的第 2152 篇文章
之前关注了很多高可用方面的事情，但是似乎有一点我们忽略了，那就是我们所谓的高可用关注的更多是一种临界状态，更多是为了数据一致性和完整性努力，而对于切换时长存在一些问题，对于业务来说，这就会导致服务中断过长，服务不可用。对很多业务(除了一些交易系统)来说，能够最快恢复也许是重中之重，而在这个基础上能够延迟修复数据或者补数据，对于多方来说是一种性价比最高的事情。比如正常情况下，我们考虑了很多的异常，恢复业务需要10秒钟，但是如果我们采取最折中的方式，使得最快的切换方式保持在1秒或者毫秒，那么从这个层面我们可做的事情就很多了，所以有了这篇文章和两个相关方案，在此我们更多聊的是关于如何快速切换的方案。
1.方案概览
为了保证业务的可持续性，高可用方案主要覆盖三类场景：故障转移和主动切换和容灾切换。
其中，
故障转移方案具有不确定性，需要做故障预判和故障确认后方可进行故障切换，预计影响时长在分钟级
而快速切换可以作为高可用的补充方案，是主动发起的方案，属于计划内任务，预计影响时长可以控制在秒级
容灾切换方案属于决策方案，在重大故障时需要前后端联动完成
其中主动切换方案是该方案讨论的重点，主要有以下的一些预设条件
l 业务低峰期
l 数据延迟控制在1s以内
l 应用层具有自动重连机制
l MySQL基于异步复制模式
切换前，整个服务状态如下，其中主库可读写，从库只读，通过Consul服务访问至主库
2.快速切换参考方案1
1)建立双向复制关系，主从均开启读写，但是从库无业务数据写入
2)主库置为Read_only状态，业务写入失败，业务读依然可用
3)Consul域名服务切换到从库，取消之前的双向复制改为单向
3.快速切换参考方案2：
1)将主库置为Read_only状态，业务数据写入失败，但是依然可以查询
2)检测从库的数据延迟，检测N次，偏移量稳定无变化
3)配置数据库双向复制，从库置为可写状态
4)Consul域名切换到从库
小结：两个方案中，第1个方案比第2个要少一个步骤，而且建立反向复制的过程可以提前验证，相对来说更加便捷和有效。
