技术解读丨 GaussDB 数仓高可用容灾利器之逻辑备份

摘要：GaussDB数仓的Roach工具，同时提供物理备份和逻辑备份两种主要形态的备份。逻辑备份针对数据库的逻辑对象进行抽取和备份，能够有效地应对单表、schema级等较细粒度的备份，较为灵活和便利。



一、简介



在大数据时代，数据的完整和可靠性成为一个数仓最核心的能力之一。GaussDB数仓以其出众的分布式计算和存储能力广受用户青睐的同时，也特别着眼于数据备份容灾领域的创新和打磨。数据的可靠性可以说是数仓的“命门”。对于企业、政府等用户，如果因为硬件故障导致的文件损坏，或是业务操作的误删，导致了数据损坏或丢失，那么损失将是不可估量的。GaussDB提供的Roach工具，将以其稳定、快速、可靠的备份能力，通过备份恢复数据库或业务表，为客户准备一个可靠的“后悔药”，从而有效地挽回客户损失。





图1 数仓备份恢复示意图



二、Roach备份恢复基本框架



GaussDB数仓的Roach工具，同时提供物理备份和逻辑备份两种主要形态的备份。物理备份直接通过拷贝文件块，存储于备份介质之上，恢复时使用备份的文件块，重建集群中实例DN与CN的数据目录进行恢复。本文中我们主要着眼于逻辑备份，在当前的GaussDB数仓中，相比于物理备份，逻辑备份拥有更好的灵活性，其充分利用了GaussDB强大的数据导入导出能力，不同于物理备份的文件整体拷贝，逻辑备份针对数据库的逻辑对象进行抽取和备份，粒度可以做到表级、schema级、database级，根据客户需要进行定制选择；在一个拥有成千上万表的客户数仓中，如果仅想要备份一张表，那么当前逻辑备份是更好的选择。



在逻辑备份讲解之前，我们首先讲一下Roach工具的设计架构，这个框架是一切逻辑或者物理备份的实现基础——





图2 Roach备份恢复工具框架示意图



Roach是一个分布式的备份恢复工具，以一个Node1、2、3组成的集群为例，备份的总入口是python进程GaussRoach.py，它将在当前节点拉起一个roach master进程，在集群其他所有节点各拉起一个roach agent进程，是典型的master-slave框架，master进程与所有的agent进程分别建立TCP长连接，并封装报文与各个节点通信，下发备份等任务，在每个节点上，将分布式地为节点上的CN、DN等数据库对象进行备份。



三、逻辑备份的原理



下面简述一下逻辑备份的执行过程



1）待备份表定义的导出和备份



如果是库级的备份，将逐个schema地进行元数据导出；处理每一个schema时，又将逐个导出所有的表定义，因此，我们下图展示了Roach逻辑备份导出一个表DDL的过程。Roach Master节点接到备份指令后，向一个有CN的节点Roach Agent下发指令，该Agent进程再调用gs_dump，连CN进行表定义DDL的导出。





图3 逻辑备份表元数据DDL导出备份示意图



2）创建外表



Roach逻辑备份过程，本质是建立外表进行数据导出的过程，类似上一步的表定义导出，Roach Agent接受Master指令后，基于导出的表定义，连CN创建写外表，创建的外表使用gsmpp_server， server的option中，location为roach://{Roach Agent监听端口}，其中，Roach Agent监听端口为参数可配置，将接受该节点上所有DN实例的连接，Roach逻辑备份外表定义类似如下形式，该待备份表仅有一个int类型字段id，图中举例的Roach Agent监听端口为8080，可配置，导出格式为csv。





图4 Roach逻辑备份创建的外表



3）Roach工具与DN的建连及数据导出备份



当前GaussDB数仓的集中主要数据导入导出外表包括GDS、HDFS、OBS、Roach等四种，Roach外表同其他几种外表类似，都通过FDW（Foreign Data Wrapper）完成，但注册了一系列属于Roach的FDW API接口实现，此外，Roach还实现了Open/Read/Write/Close/ErrorReport等五个主要的底层读写API，实现DN与Roach Agent之间的数据交互。





图5 逻辑备份表数据备份流程示意图



如图5所示，逻辑备份数据的流程可以用以下phase1 ~ phase5简单描述



• Phase1： 备份数据的命令被Master下发给所有Agent，连一个CN，连数据库创建外表导出server、创建导出外表，每个节点的Roach Agent同样会创建一个TblServer线程，监听Agent Port端口，等待DN连接；

• Phase2： 连一个CN执行insert into roachft select * from A；sql查询会被下发到所有DN，通过注册的Roach FDW API，DN调用回调函数，封装一个PGXCNode的消息，以自明instance身份，去尝试连接server url中的本节点Agent Port；

• Phase3： Roach Agent的TblServer每接收一个DN的连接，会分配一个数据通信的socket槽位，并fork一个子进程为该DN实例的备份服务；Agent会等待该节点上所有的DN都建立连接，创建lengthof（节点所有DN）个子进程，并行进行数据备份。

• Phase4： 每个备份子进程通过建立的连接，不断读取表数据，待该表所有切分的数据块读取完成，发送一个FINISH_BACKUP消息给Roach Agent，则停止数据传输，从DN读取的数据首先存入Agent子进程的buffer中。

• Phase5: 每个Agent进程内会创建一个BackupSender线程，负责消费存入buffer的表数据，与备份介质建立连接，流式进行数据的发送；Phase4、5在实际运行中是个异步并行的动作，并非等所有表数据都写入buffer后，才向备份介质发送。



四、小结



关于Roach逻辑备份的原理大致就讲解完成了，逻辑备份能够有效地应对单表、schema级等较细粒度的备份，较为灵活和便利。逻辑备份的恢复的过程，与上述备份过程基本是个逆向过程，简而言之即表定义恢复，节点及DN元数据恢复，数据导入的过程，恢复的一大优势是，不会停集群或移动其他数据，对其他库或者表的业务几乎不影响。在后续的博文中，我们可以更详细地解读。



点击关注，第一时间了解华为云新鲜技术~