深度剖析数仓 CN 增量备份技术

摘要：为了解决 Roach 的性能问题，提出了 CN 增量备份手段，从而达到进一步优化 RPO 目的。

本文分享自华为云社区《GaussDB(DWS)备份容灾之CN增量备份》，作者： zxy_db 。

1. 摘要

在数据量增大时，如果 CN 每次都做全量备份，则会导致每次的备份数据量很大，不仅会降低备份的性能，也从造成备份集恢复性能的降低。如果改成 CN 增量备份，则备份集只会备份差异数据，这样不仅会使得备份数据量变小，而且也会提升备份集恢复的性能。

2. CN 备份原理

对于主备集群 CN 备份与恢复的过程，如下图所示：

• 在备份过程中，只备份主 CN 的数据，且只发送到备集群对应的主 CN 所在的节点上。

• 在恢复过程中，非主 CN 节点从主 CN 节点上拷贝 rch 文件，然后再将备份数据的 rch 文件恢复到实例目录。

• CN 备份同集群备份一样，先进行行存备份，后进行列存备份。

• 对于行存备份过程，首先是准备列表，然后备份文件。

• 准备列表主要分为 3 个步骤：第一步是获取 CN 备份类型，第二步是根据备份类型，决定 LSN 区间，第三步是根据 LSN 区间，准备备份列表(全量备份列表和增量备份列表)。

• 对于列存备份过程，同上述行存。

• 行存和列存区别在于增量备份 LSN 区间的取法：

• 行存文件来说，增量是上次 startLSN 到本次 startLSN 之间

• 列存文件来说，增量是上次 barrierLSN 到本次 barrierLSN 之间

3. CN 备份判断逻辑

1. 首先，CN 增量需要有一个基础备份，因此，集群在做全量备份时，CN 仍然做全量备份。

2. 其次，集群在两次增量备份过程中，CN 发生删除和加回后，新增的 CN 需要做全量备份。

对于支持异构的情况下，如果 ID 最小的 CN 发生变化，同样需要对 CN 做一次全量备份。

整体的备份逻辑如下图所示。

3.为了实现上述判断逻辑，通过创建标志文件 backup_label.old 来控制 CN 做全量备份还是增量备份。backup_label.old 在 Python 侧创建。即在 Python 侧，调用 gs_roach 备份前，在最小的 CN 上，即要进行备份的 CN 上，创建 backup_label.old 文件。根据 backup_label.old 的修改时间和 priorBackupKey 转化的时间，判断 CN 做增量备份还是全量备份。流程图如下图所示。如右半部分所示，如果 backup_label.old 文件的修改时间比 prriorBackupKey 转换获得的时间大，则进行全量备份。否则，进行增量备份。

4. CN 备份技术应用实测

4.1 CN 删除和加回后做全量备份

初始状态，ecs-env-3038 节点上的 CN 实例是最小 CN 编号，即主 CN

第一步：修改 XML 配置文件 xml,将主 CN 对应主机上的 cooNum 值从 1 改为 0

第二步：使用 gs_om 工具执行删除 CN 操作 gs_om -t managecn -m delete -X /data1/xml/3_node_3.xml

第三步：将要加回 CN 对应主机上的 cooNum 值从 0 改为 1

第四步：使用 gs_om 工具执行加回 CN 操作 gs_om -t managecn -m add -X /data1/xml/3_node_3.xml

删除和加回后，主 CN 的变化情况：

主 CN 由节点 ecs-env-3038 变为节点 ecs-env-2998.

此时查看日志可以发现，由于 CN 发生了增删，集群做增量备份时，CN 做全量备份。

4.2 备份集大小变化

第一步：拉起容灾，CN 增量备份阶段停止容灾；第二步：创建大量数据库和空表；第三步：连续执行增量备份，增量备份中途不插入任何数据。

如下图所示，不增加数据，增量备份集大小小于全量备份集大小

5. 技术总结

本文主要从技术价值、应用场景、技术原理、技术实测展示几个维度对 GaussDB(DWS) CN 增量备份技术进行了剖析，可以看到增量备份是对已有全量备份恢复的一个有效的增强，可以节省宝贵的备份存储空间和 cpu 资源，同时达到进一步优化 RPO 目的，因此该技术拥有较为广阔的前景和深远的意义。

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