这是学习笔记的第 1906 篇文章
今天整理了一下数据库的高可用方案的内容，也是打算在今年好好在这方面出点东西。
首先高可用架构应该具备如下特征:
Ø 数据库对前端业务透明，业务不会因为数据库故障产生中断。
Ø 非主节点的数据应该和主节点的数据实时或者最终保持一致。
Ø 当业务因高可用机制发生数据库切换时，切换前后的数据库内容应当一致，不会因为数据缺失或者数据不一致而影响业务。
目前MySQL高可用方案有很多，几种典型的高可用架构选型有:
Ø 主从或主主半同步复制：通过依赖MySQL本身的复制，Master制作一个或多个热副本，在Master故障时，将服务切换到热副本从而达到高可用的效果。
Ø MHA+多节点集群：基于MHA的集群方案，通常和其他第三方方案组合实现
Ø 分布式协议：基于分布式协议的高可用方案，常见的有Galera Cluster,PXC和MGR
Ø 基于共享存储方案：如SAN存储，这种方案可以实现网络中不同服务器的数据共享，共享存储能够为数据库服务器和存储解耦。
Ø 基于磁盘复制方案：如DRBD，DRDB是一个以linux内核模块方式实现的块级别同步复制技术。它通过网卡将主服务器的每个块复制到另外一个服务器块设备上，并在主设备提交块之前记录下来。类似共享存储解决方案。
我们再来说一下MySQL高可用方案的建议，这些也是基于一些高可用的实践所做的总结。
1) 行业内多活的设计目标不是多写，需要先实现跨机房的高可用容灾和计划内的机房间数据切换
2) 引入consul的域名管理，解决VIP方案带来的一些潜在瓶颈（域名的业务属性，实现单机多实例，读写分离的域名配置）
3) 对于consul的整体定位不局限于集群环境，在单实例，集群，分布式中间件方向都可以采用，consul是作为一种通用的基础域名服务。
4) 同机房高可用方案的落地，需要和应用方对接程序端对域名的支持情况，在不同语言的客户端侧会有一些配置的差异。
5) 在已有高可用方案MHA基础上平滑过渡和改进，在后续新业务尝试引入MGR的方案
6) consul 业务API的开发，对数据库层面的业务可持续性访问（服务注销，服务发现）做一些补充和定制，保证consul服务的技术可控
7) 异机房高可用实现应用无缝切换，计划内切换，会有业务中断/延时，保证可控的基础上，应用端无须修改连接配置，需要测试DNS的域名转发等策略，计划外切换，需要做确认才可完成。
8) 对已有的分布式方案，可以采用MGR,中间件，consul的组合方案，实现读写分布式扩展。