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目的，因此该技术拥有较为广阔的前景和深远的意义。