MySQL高可用架构的演进( 三 ) _高可用架构

Data Node
存取数据，提供真正的数据查询操作。
依赖集群自身提供的同步机制，每个数据节点中的数据都是强一致的，事务的执行是同步的。
NDB Cluster的优缺点都比较明显：
优点：
1、数据能够实现自动分片，具备较强的写入扩展能力。
2、分布式、无共享架构，强一致性，具备较强的故障恢复能力。
3、基于内存，实时性较高，性能较好。
缺点：
1、数据存放在内存，扩展能力受到内存大小的限制。
2、随着节点数量的增加，网络通讯的代价会越来越高，性能会容易产生瓶颈。
3、引入了Management Node和SQL Node，集群管理成本显著增加。
故障切换的方式随着不同的高可用架构的出现，伴随而来的是多种不同的故障切换的方式，不同的高可用架构需要配套合适的切换方式才能真正发挥故障容灾的作用。
1、应用修改配置切换
当某个数据库节点出现故障以后，手工修改配置指向备库节点，需要重启服务，人工介入，效果极差。
2、DNS动态解析
使用域名访问数据库，采用DNS解析的方式将具体连接的IP信息返回给应用程序，编写特定的检查脚本检测主节点的可用性，当出现故障时动态修改DNS解析到备节点。这种方式的困难点在于DNS会有有效期内的缓存，虽然可以调整缓存时间，但操作起来还是不够方便。
3、MMM
MMM（Master-Master replication manager for MySQL），是一套支持双主故障切换和双主日常管理的脚本程序，其原理是通过漂移虚拟IP的方式来处理单点故障，主要应用于MySQL双主模式，注意，双主只是意味着两个节点都可以当作主节点使用，但是同一时刻只能有一个主节点对外提供服务。
其架构图如下所示，每个节点上都安装了mmm_agent，用于与mmm monitor通讯。
mmm_monitor：监控进程，负责所有的监控工作，决定和处理所有节点角色活动。
mmm_agent：运行在每个mysql服务器上的代理进程，完成监控的探针工作和执行简单的远端服务设置命令。
mmm_monitor端会决定哪些VIP应该挂载哪个mysql节点上，当某一个节点出现异常，其能够将VIP切到其他的节点。
【MySQL高可用架构的演进】值得注意的是，MMM模式使用起来并不方便，生产应用证明也不是很可靠，故应用不广泛，项目已经很久没有更新了。

文章插图

4、MHA
MHA（Master High Availability）是目前相对成熟的一套方案，用于进行故障切换和主从提升，能够在0~30秒之内自动完成数据库的故障切换操作，并且在进行故障切换的过程中，MHA能在最大程度上保证数据的一致性。
MHA支持修改全局配置以及漂移虚拟IP，能够实现故障切换对应用无感知，应用比较广泛，被普遍生产应用证明了可靠性。
MHA架构引入了MHA Manage，可以独立部署在一台服务器上MHA Manager会定时探测集群中的master节点，当master出现故障时，它可以自动将最新数据的slave提升为新的master，然后将所有其他的slave重新指向新的master 。整个故障转移过程对应用程序完全透明,MHA模式适用于一主多从的场景。

文章插图

文章插图

5、自定义Proxy
采用Haproxy等负载均衡设备，在Haproxy上配置虚拟IP，应用程序访问虚拟IP，haproxy负责进行连接管理和请求的转发，另外可以编写故障检查脚本，当发现故障节点，haproxy自动将相关请求转发到其他节点，实现自动恢复，这是一种比较灵活的方案。
总结一下，本文从复制技术开始，逐一分析了Mysql从最基本的异步复制到组复制，业内常用的多种高可用方案和故障切换方式，也对相关方案的优缺点进行了讨论。实际应用中，需要根据具体业务场景进行方案的选择，综合对于数据一致性的要求、运维复杂程度、跨机房的要求等方面的考虑，选择合适的方案。