万里数据库GreatDB 主推的数据库方案有哪些？

1. 读写分离方案

基于 GreatDB Paxos+内部 vip Plugin 的读写分离方案。支持最少 2 个节点的读写分离配置，有较好的扩展性，最大可扩展到 9 个节点。纯数据库内部vip组件，写vip 自动绑定primary主实例网卡子口，当主节点发生故障切换时，vip根据内部拓扑视图变化，自动漂移到新primary节点。无需业务层ip反复调整，具有切换效率高，无性能损耗的vip接入方案。

2.业务多点接入方案

GreatDB Paxos+GreatDB Router方案，支持业务多点接入访问。数据库底座 Paxos 高可用内部保证数据库的自动选举切换，和数据一致性判断。GreatDB Router（以下简称 router）仅做业务应用的 SQL 透明转发，和业务层的多点接入。Router对业务侧屏蔽后端数据库架构，但感知后端主备变化，自动将业务数据转发到主库处理，自身无状态，可以部署一个或多个，做到“即用即启，不用即抛“的轻量化管理。

3、基于主备复制的高可用方案

架构建立在GreatDB 主从复制基础之上，增加GreatDB Router 中间层，此模式中 GreatDB Router 层会负责高可用的探测和 SQL 解析转发，以及主从故障切换，需结合zookeeper配置组件(以下简称zk)一起部署。标准架构部署时要求router、zk、GreatDB均为 3 个节点，三者可以混合部署在3台主机上。此架构的优势是兼容传统 MySQL 的主从复制架构，提供自动故障切换和异地容灾的跨机房部署。

且支持跨机房容灾部署

4、基于组复制的多机房方案

GreatDB 新地理标识特性，用户可根据多机房部署时设置zone_id。在同城多机房部署方案中，同一个机房的节点可以设置相同的数值，其余机房里的节点设置不同的zone_id标识，这样在事务提交时会要求每组 group_replication_zone_id 中至少有1个节点确认事务，然后才能继续处理下一个事务。这就可以确保每个机房的某个节点里，总有最新的事务。有效解决了多机房节点故障切换时，因机房无最新日志，或数据差异较大引起切换时间较长的问题。

基于仲裁节点和zone_id，配置组复制的三中心方案。

仲裁节点，该节点仅参与组复制的投票仲裁，不存放实际数据，不执行业务层的DML操作，因此可以用低配服务器，在保证MGR可靠性的同时还能降低服务器成本。

新增参数group_replication_arbitrator用于设置仲裁节点。比如可在下列同城IDC1或者2中任一个secondary设置为仲裁节点，可增加整体的故障切换的效率和架构性能。

基于原生组复制的MGR A 和 MGR B  主备机房切换，可能引起的数据差异，以及修复主机房发生内部节点选举切换之后，导致备机房识别同步异常等问题。