在系统中，拟采用基于MySQL Group Replication和MySQL Router的高可用方案(简称MGR方案)。该方案能够在一致性、数据完整性、高可用性等方面达到金融级的要求。

MGR方案的特点

完备的理论基础。相对于以前的基于keepalived+异步复制、Orchestrator+半同步复制等方案，MGR方案具有完备的理论基础。从理论基础上能够确保在实现高可用的同时，达到数据的一致性、完备性。MySQL官方的支持。MGR方案是MySQL官方提出并实现的方案，所需要的组件已经在官方版本的MySQL中提供。从稳定性、可靠性、易用性等方面都比其他基于第三方组件的方案都好很多。运维的简洁性。MGR方案在安装配置，以及后期的运行维护都非常简单，基本都按部就班地操作，不需要运维人员做很多定制化的配置和操作。

理论篇

基于数据复制的MySQL的高可用实现模型是Share nothing模型。在MySQL的Share nothing模型中存在2个重要问题：

当某些节点宕机时，数据丢失问题。因为在节点之间是采用数据复制，而MySQL数据复制(异步复制或半同步复制)都存在数据丢失的可能。当发生异常时，进行故障切换的一致性问题。因为整个集群系统由多个节点参与，是一个典型的分布式系统，当发生一些异常情况情况时，各个节点对于故障切换的判断可能产生不一致的结论(俗称脑裂)，进而导致严重的后果。

这两个问题都是根本问题，只要有一个不能完全解决，就不能得到真正可靠的完备的高可用方案。实际上导致这两个问题的本质原因，是分布式系统的一致性问题。在目前的分布式理论中，真正解决了分布式一致性问题的方法，只有基于Paxos/Raft算法的方法。

在基于keepalived的方案中，要在故障切换过程中达到一致性，必须要使用一个单点的仲裁机制。这导致不能达到真正的高可用，同时，故障判断方法和过程需要运维人员通过定制化脚本来实现，非常复杂，很难做到完备。Orchestrator在故障切换的判断和执行过程中采用了基于Raft算法的方法，并对各种故障情况进行分类定义，大大提高了故障切换过程中判断的可靠性，也大大简化了运维的难度。但由于数据复制过程采用的仍然是MySQL的异步复制或者半同步复制，所以，仍然存在故障切换过程中数据丢失的可能。

MGR方案采用的MySQL Group Replication是MySQL5.7中引入的新的数据复制方法，不同于传统的异步复制和半同步复制，该数据复制过程采用了基于Paxos算法的方法，实现了严格意义上的同步复制。每个事务提交，都要求半数以上的节点都写成功后，才能真正提交。这种方案，不但保证只要半数以上的节点存活的前提下数据不会有任何丢失，同时，故障切换也从中收益。当当前的主节点故障，重新选择主节点，也同样需要超过半数的节点的一致意见。这已经在理论上完全解决了高可用实现中所遇到的所有问题。

另外，MySQL Group Replication中的节点可以配置为多节点写入或者单节点写入。多节点写入在实践中存在一些限制。其中最大的限制是事务模型和普通的单数据库中的事务模型有少许差异：事务使用乐观模型，在进行提交的时候再进行冲突检查，如果冲突则回滚事务。而在传统的单数据库事务模型中，基本都是悲观锁模型(有不同的实现，这里就不详细讨论了)。并且多节点写入也并没有提高整个数据库集群的吞吐量(因为实际上所有的写入都要写入到每个节点)，所以，建议采用单节点写入模式，这样事务模型就和传统的事务模型完全一致，应用系统不需要做任何修改。

实践篇

MGR方案中，至少需要3个MySQL数据库节点。在这个配置下，允许1个节点宕机的情况下，继续对外提供数据库访问服务。这3个节点之间配置为MySQL Group Replication，并设置为单节点写入模式。这样就已经自动实现了数据可靠复制，故障自动切换的功能。不需要做额外的工作。

当发生故障切换后，写入的主数据库节点地址发生变化。为了让应用系统更加方便，也让这个过程更加可靠。方案中引入了MySQL Router中间件(也是由MySQL官方提供的组件)。MySQL Router对外提供一个端口供应用系统连接，它则根据MySQL Group Replication的工作状态，连接到当前的主节点，发生故障切换时也自动改变连接的数据库服务器。得益于MySQL Router能够理解MySQL Group Replication的工作过程，使得整个过程的可靠性稳定性很高，也只需要运维人员很简单的配置工作。

考虑到方便性、可靠性等，建议将MySQL Router采用Agent方式部署，即将MySQL Router部署到每个应用节点，应用则配置为连接本机的MySQL Router中间件。

监控

在系统表

performance_schema.replication_group_members中，可以查看MySQL Group Replication的工作状态，包括节点的存活状态，角色等。通过定期查看该表，可以对整个数据库集群进行监控。

恢复

当某些异常，包括某节点发生故障，或者网络问题等，MySQL Group Replication集群将发生故障切换，原来的主节点将被隔离，不再成为活动集群成员，集群将处于降级模式工作。值得注意的是，此时系统性能不受影响，只是不能允许再有节点发生故障。重新加入新的节点，让集群恢复到完整的模式，需要运维人员参与。