OLAP MPP分布式关系型数据库的双活容灾系统的设计

云原生数据库厂商 GBASE数据库

2024-11-02

本文转载自：ITPUB

随着《“十四五”大数据产业发展规划》的发布，大数据日趋成为重要的数字经济支撑，对承载数据仓库、负责高价值密度大数据存储分析的OLAP MPP集群进行全面的容灾以及双活系统的建设变的格外重要。

OLAP MPP集群容灾系统能满足对T+1，T+0.X等非实时的批处理的数仓场景的容灾需求，但是RPO，RTO会较大，往往达到小时级；随着数仓业务对连续性要求的不断提高，尤其是实时数仓的场景，需要建设实时的双活系统来满足对业务的连续性要求；当主库出现故障时，要求备库立即进行接管，对于实时数仓，要建立RPO，RTO达到分钟级或者秒级甚至到0的准实时或者实时双活系统才能保障主备库数据不丢失以及数据的一致性，从而保障业务的连续性。

OLAP MPP分析型集群的容灾以及双活在技术实现上、灾备级别要求上都与在线生产系统的OLTP事务数据库有较大差异。如事务数据库具有完备的WAL（write ahead logging）事务日志，灾备可以通过事务日志实现数据库的备份、双活复制、异地容灾等；OLAP MPP分析型数据库为追求大吞吐性能，无法完全按照事务数据库基于事务日志的容灾以及双活设计方案，目前业界采用的主流容灾和双活方案主要有：数据同步模式、ETL模式、双活模式，具体说明如下：

数据同步方式

主备集群间的数据同步是双活容灾系统建设的基础，高效、稳定、一致性的同步是双活容灾系统稳定运行的关键；本节列举下市面上常见的数据同步方式，以及各自的优缺点；

1.1 基于事务日志、数据块的数据同步

优势：直接同步变化的数据增量，只适合数据变化量较少的数据仓库。

劣势：对主数据库有侵入性，一旦主库繁忙，同步时效低；面对变化数据量大的场景，不适合。

1.2 基于备份恢复的数据同步

利用备份恢复工具进行数据的全量备份和增量备份，存放到某个存储介质上，然后恢复到备库上。

优势：采用产品已有的备份恢复工具来实现。

劣势：要求数据库支持增备能力，且往往锁等待严重；备库对外只能提供读；对备库进行恢复时不能马上提供服务，备份恢复无法达到与流式同步方式的RPO，做不到RPO=0的程度, RTO时间较长，而且需要较大空间保存备份的数据。

1.3 基于导入导出的数据同步

基于上层应用对主库导出，备库导入，业务需要设计对增量数据的识别，对业务的设计和调度有较高的侵入性。以作业为单位，需要应用记住该作业产生的相关表，等作业完成后，主库发起对这些表的导出操作，备库进行导入操作。

优势：可以基于表级进行数据同步，基于导入导出，导出的是文本文件，因此主库和备库可以是异构的，例如主库是产品A，备份是产品B。

劣势：对主库的应用调度和数据库设计侵入性高，实施困难。

双活容灾模式

本节介绍双活容灾的一些实现方案，有些是产品能力，有些是应用解决方案，供大家参考；

2.1 基于ETL双加工双活模式

采用两套独立的调度系统进行作业的加工，由上层应用进行控制。

优势：不依赖于数据库产品自生的容灾能力，有应用自己进行控制，不依赖产品。一般采取主库对外提供持续服务，待主备库数据准实时或批后校验一致后，再开放备库对外服务。

劣势：因为主备库同时跑ETL作业，需要同时消耗主备库的CPU，内存和IO资源；另外对存在不确定值的SQL函数导致主备集群数据不一致，例如now、random、row_number排序这种同一份数据产生不同结果集的函数。建议用户修改SQL语句，明确唯一取值、唯一排序，确保主备数据的一致性。若主备集群数据发生不一致场景，主要以主库数据为准，覆盖备库，该同步过程可以采用“基于事务日志以及数据块的数据同步”技术。

2.2 基于产品提供的中间件进行调度的双活模式

产品级调度中间件是由OLAP产品提供一个组件，对外提供产品统一接口，实现主备集群SQL的调度、校验和同步（同步采用数据库自生的基于事务日志以及数据块的数据同步的底层技术）；客户业务只需在产品级中间件下发任务；产品级中间件会自动调度任务：加载语句可以同时发送给主备库，实现双加载；DML语句可以灵活配置，可以主备库同时执行后进行校验，也可以主库执行完成后把增量数据同步到备库；只有主备库的数据校验成功后，本次任务才算执行成功。

另外，考虑到不确定值的SQL函数导致主备集群数据不一致（例如now、random、row_number排序这种同一份数据产生不同结果集的函数），如果采用主备集群双加工的调度方式，则建议用户修改SQL语句，明确唯一取值、唯一排序，确保主备库执行SQL结果的一致性，部分简单的系统时间函数，可以通过中间件改写，保障SQL执行结果的一致性；

建议采用的最佳方案是采用“基于事务日志以及数据块的数据同步”的同步技术，直接将主数据库SQL执行结果的日志以及变化的数据块同步到备库中。

优势：产品级提供，对应用完全透明。

劣势：引入了中间件作为接入服务，由于所有数据库访问行为均通过该中间件，中间件任何异常均影响整个双活系统的高可用，需要考虑中间件本身的高可用。

2.3 基于应用提供的中间件进行调度的双活模式

用户的应用加工作业连接主库完成写操作，支持两种调度方式：

方式一：作业级实时一致性方案，是在作业的最后一步将本作业影响的目标表增量数据同步至备库中，同步不成功则认为该作业加工失败。

方式二：作业级异步一致性方案，作业的最后一步将本作业信息记录至同步队列中，同步队列处理将已完成作业信息获取到，并获取作业目标表将其增量数据同步，何时同步及同步哪些表由“同步队列处理”应用保证。当主备库同步完成后进行数据的校验。

优势：应用控制加工逻辑，实现作业级的实时一致性和准实时的一致性，可灵活进行控制。主集群数据可写，承担数据统计分析等数据加工业务，完成数据加工后将结果数据同步到备份集群，备集群可以分担主集群对外业务查询服务，降低主集群读写对系统资源的争抢压力。

劣势：对应用逻辑有侵入性，增加了应用逻辑的复杂性。

2.4 基于强一致的实时同步的双活模式

通过统一的调度集群作为入口，采用虚拟集群技术，主备集群作为逻辑子集群纳入调度集群的统一管理，在虚拟集群中将两个同样规模和数据分布策略的子集群之间建立镜像关系，就称为镜像集群。顾名思义，两个镜像集群中的表和数据是一致的。主备计算集群通过建立镜像集群关系实现了强一致的实时双活，可以支持同城的实时双活场景。

(1) 在主备计算集群间建立镜像关系，镜像关系可以按表进行创建，也可以按照数据库进行创建；

(2) 虚拟集群中互为镜像的两个子集群可以部署在同机房内，也可以部署在同城的不同机房内，对两个子集群之间的网络质量和网络带宽有一定要求；当两个子集群位于不同机房时，就形成了同城异地的灾备；在同城异地部署中，可以在备份机房中部署1个coordinator节点，实现管理集群的数据灾备；

(3) 业务直接连接其中的一个子集群进行操作，下发DDL、DML、DQL等SQL语句，对于DDL，将同时下发到互为镜像的两个集群中执行；对于DML、DQL操作则直接下发到当前应用的默认子集群中执行，DML的执行结果采用链式转发方式传输到另一个子集群中；镜像集群中的数据修改操作，需要在两个子集群中统一提交后才返回执行结果给用户；

(4) 如果主备任何一个计算集群发生故障，应用无需做任何改变，调度集群对应用透明的完成了对业务的切换，如上图中的VC1集群和VC2集群为镜像集群关系，业务默认直接在VC1上执行，当VC1发生整体故障后，调度集群自动切换业务连接到VC2上来执行；

(5) 如果管理集群在主机房中的所有节点发送故障，需要人工修改集群管理节点的配置为备份机房中的管理节点为管理集群的唯一节点后，业务就可通过备份机房中的管理节点下发SQL任务。

优势：通过统一的调度集群对外提供服务，主备计算集群通过镜像关系实现了产品级的强一致的实时双活。主备计算集群的任何一个出现整体故障时，调度集群会把任务自动下发给没有故障的主备计算集群，对应用完全透明，应用不需要做任何切换。

劣势：主备计算集群的事务是强一致的，要求主备计算集群间为万兆网，不适用于跨广域网的异地实时双活。

方案对比汇总

本期排版 | 匆匆

THE END

往期文章

新闻资讯

GBASE南大通用成为先进计算产业发展联盟（ACIA）首批成员单位新闻月刊 | GBASE 2月市场动态一览告诉老板 | 我想“直播”了！

生态合作

GBASE&飞腾：炫“库”“芯”动能历史数据焕新生