1. 摘要
在数据量增大时,如果CN每次都做全量备份,则会导致每次的备份数据量很大,不仅会降低备份的性能,也从造成备份集恢复性能的降低。如果改成CN增量备份,则备份集只会备份差异数据,这样不仅会使得备份数据量变小,而且也会提升备份集恢复的性能。
2. CN备份原理
对于主备集群CN备份与恢复的过程,如下图所示:
- 在备份过程中,只备份主CN的数据,且只发送到备集群对应的主CN所在的节点上。
- 在恢复过程中,非主CN节点从主CN节点上拷贝rch文件,然后再将备份数据的rch文件恢复到实例目录。
- CN备份同集群备份一样,先进行行存备份,后进行列存备份。
对于行存备份过程,首先是准备列表,然后备份文件。
准备列表主要分为3个步骤:第一步是获取CN备份类型,第二步是根据备份类型,决定LSN区间,第三步是根据LSN区间,准备备份列表(全量备份列表和增量备份列表)。
对于列存备份过程,同上述行存。
行存和列存区别在于增量备份LSN区间的取法:
行存文件来说,增量是上次startLSN到本次startLSN之间
列存文件来说,增量是上次barrierLSN到本次barrierLSN之间
3. CN备份判断逻辑
- 首先,CN增量需要有一个基础备份,因此,集群在做全量备份时,CN仍然做全量备份。
- 其次,集群在两次增量备份过程中,CN发生删除和加回后,新增的CN需要做全量备份。
对于支持异构的情况下,如果ID最小的CN发生变化,同样需要对CN做一次全量备份。
整体的备份逻辑如下图所示。
- 为了实现上述判断逻辑,通过创建标志文件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目的,因此该技术拥有较为广阔的前景和深远的意义。