本文分享自华为云社区《GaussDB（DWS） 备份问题定位思路》，作者： yd_216390446。

前言

在数据库系统中，故障分为事务内部故障、系统故障、介质（磁盘）故障。对于事务内部故障和系统故障，使用日志自动恢复，不需要人工参与。但对于介质故障，需事先备份数据。

那么对于 DWS 来说是如何进行备份的呢？以及备份的过程中容易出现哪些问题，又怎样去排查、解决呢？

本文主要讲述了 DWS 备份工具 roach 的备份的原理，以及常见的问题处理套路和相关案例。

一、备份原理

全量备份

本文主要说的备份均为物理备份，即通过物理文件拷贝的方式对数据库进行备份，通过备份的数据文件和日志等文件，数据库可以进行完全恢复。

全量备份大致分几个阶段：备份行存、创建 barrier 点、备份 xlog、备份列存。

• 备份行存：每个节点的主 DN 的数据，压缩存到 rch 文件中

• 创建 barrier 点：保证 CNDN 上的所有的事务处于一致的状态，恢复到这个点比较可靠，创建时会在 XLog 中写入一条记录。

• 备份 xlog：备份 startLSN 和 stopLSN 之间的 xlog

• 备份列存：由于列存不写 xlog，因此放在最后，其中列存的 cudesc 文件已在备份行存阶段备份

整体流程如下图所示

容易出现的问题：

• 禁用 xlog 回收容易造成集群只读

• 延迟 DDL 也会引起集群只读

注意的点：

• 备份过程必须开启 FPW

• 备份 XLog 拷贝 start_lsn 和 end_lsn 之间的 xlog

• 备份列存的时候才会开启 DDL

为什么要有延时 DDL？

DDL 操作：alter/truncate/autovacuum/drop/vacuum full/insert overwrite 这些会改变 relfilenode 的语句，DDL 操作在拿到行列存清单后，如果用户进行 drop 操作，为了保证文件存在，所以要开启延迟 DDL

增量备份

增量备份是基于某次备份进行的，在增量备份的命令中需要增加参数–prior-backup-key 来表明是基于哪一次的备份。采用 cbm 文件识别增量页面。增量备份分为累计增量和差分增量两种

• 累计增量：每次备份都是基于同一个全量备份，备份的内容为全量备份与当前时刻的数据修改

• 差分增量：每次备份都是基于上一次的备份，备份的内容为两次备份之间的数据修改

增量备份的原理：

• 只拷贝上次并备份至今的数据修改部分，拷贝最小单位是 block（8KB）

• 集群首次备份时，GaussDB 内核会开启 guc 参数，enable_cbm_tracking=on，然后内核会持续记录数据库文件哪些 block 被修改过，记录在 pg_cbm 目录下。

• 增量备份时，查询 cbm 文件精准获得修改过的 block 存入内存，然后实施 lz4/zlib 压缩算法，写入备份介质。

• 增量恢复时，从增量备份集获取各个增量的 block 内容，对应修改数据库文件相应的 block。

• 注意：该 guc 参数被关闭，或 cbm 文件被误删后，只能重新做全量备份，无法继续做增量

cbm 文件是什么？

changed block map，对外提供数据页面的修改情况，并提供外部接口，根据 cbm 信息可以直接获取两次备份之间发生对于数据文件（行存、列存）的增量修改信息，并备份

备份对于系统的影响：

• 备份占用系统 IO，业务慢

• 延迟 DDL，导致 xlog 积压，磁盘空间上涨

• 增量备份易造成 cbm 文件积压，导致集群只读

二、问题定位套路

1）备份调用流程

DWS 管控面/FI 管控面-> GaussRoach.py/SyncDataToStby.py -> gs_roach 内核

管控面调用 roach 的 python 脚本，python 脚本进行解析参数，并调用内核侧的 gs_roach 命令。

2）备份失败需要查看日志路径：

• HC/HCS/HCSO 集群管控面调用日志: 沙箱外 /home/Ruby/log/cloud-dws-deploy.log 管控面归档日志：沙箱外 /home/Ruby/archivelog 内核日志：沙箱内 /var/chroot/DWS/manager/backup/log

• 线下集群内核日志：$GAUSSLOG/roach/agentPython 侧日志：$GAUSSLOG/roach/controller

• obs 日志：沙箱内 cd $GAUSSLOG/bin/gs_obsvi gs_obs.run.log 查看对应的出错号此处注意的是 obs 日志需要到具体出错节点上查看

3）常用 grep 命令：

• ​ 查看主节点 ip: grep “Master Ip” roach_agent*.log

• ​ 查看备份进度：grep “Setting agent state to” roach_agent*.log

• ​ 查看备份时间：grep “Time taken” roach_agent*.log | grep “MASTER”

• ​ 查看备份是否成功：grep “Backup operation SUCCESSFUL. Backup key” roach_agent*.log

• ​ 查看 roach_client ip：grep “Success to connected Remote Media” roach_agent*.log

• ​ 查看线程分配情况：grep “allotInstanceForMyProc” roach_agent*.log

• ​ 查看备份命令参数：grep “command_dict” roach_controller*.log

• ​ 如果文件被打包，使用“zgrep 命令查看即可”

4）备份关键日志

三、相关案例

（1）细粒度备份报错 Failed to connect to gauss(xxx) via libqp

【问题描述】备份时 agent 报错 Failed to connect to gauss(host:local , port: 25308) via libpq, ERROR: connection pointer is NULL

【排查方案】

1. 由于报错连接时“host:25308”，因此查看对应时间节点的 cn 日志

2. cn 报错 FATAL: “base/2278052” is not a valid data directory，怀疑是该数据库的问题

3. 手动连接该数据库，发现也连不上

4. dn 实例目录下查看该目录并不存在，为残留导致

5. drop database 删除该数据库后备份成功

【问题原因】数据库存在残留文件

【规避方法】删除该数据库下的残留文件

（2）备份随机失败

【问题描述】NBU 问题导致备份随机失败

【排查方案】

查看 controller 日志，显示第一个报错的节点为 xx.xx.xx.148

到上述节点查看 agent 日志，报错"Incomplete Message from Roach client"，发现日志指向 media server，因此查看 roach client 日志

怀疑是 nbu 的问题，到对应的 roach_client 节点查看相应日志，通过 grep “Success to connected Remote Media” roach_agent*.log，找到 roach_client 的 ip 地址，ssh 到对应的 roach_client 节点，对应的报错为 NBU 内的报错，“call NbuManager::CreateFile error”，协同 NBU 侧的同事排查

【问题原因】一般情况下，上述情况是由于 roach 侧并发太大，导致 NBU 负载大，备份报错，但具体细节还得协调 NBU 同时排查

【规避措施】如果是并发问题，建议调大 filesplit-size 参数并减小 parallel-process 参数，重新拉起备份

什么情况下协同 NBU 同事排查？

一般 roach_client 日志出现 xbsa 、或者 create file 等关键字时

（3）master 和 agent 连接失败导致备份失败

【问题描述】master 和 agent 连接失败导致备份失败

【涉及版本】

【排查方案】日志报错 Master 和 agent 连接失败，Agents did not connect in 600 seconds.

【问题原因】

HCS 环境下只开放了 55000 和 56000 端口，端口未开放导致报错

【问题规避】

方案 1：修改 roach 命令端口

方案 2：开放对应端口

（4）细粒度备份找不到文件信息报错

【问题描述】细粒度备份时报错 Error:Getting file info failed.

【涉及版本】

【排查方案】查看报错节点 agent 日志，出现 Backup main fork of relation xxx failed, Error: Getting file info failed.

【问题原因】细粒度备份期间不支持 DDL 操作。细粒度备份前会生成所有表的 MAP 文件，记录涉及的表名、以及表的相关表等信息，所有涉及到修改 relfilenode 的 DDL 操作的语句都会导致备份失败，例如 alter/truncate/autovacuum/drop/vacuum full/insert overwrite 等

【问题规避】

方案 1：备份和涉及到 DDL 的业务时间错开

方案 2：适当减少每次备份涉及的表，可以降低由于 DDL 引起的备份失败率

（5）备份过程报错内存暂时不可用

【问题描述】备份 dump 元数据阶段报错 memory is tempararily unavailable.

【排查方案】

controller 报错 memory is tempararily unavailable.

【问题原因】参数 cpu-cores 过大，导致内存慢

【问题规避】调小 cpu-cores 参数

（6）大集群下 roach 读取 cms 频繁导致集群状态不稳定

【问题描述】备份发起时，管控面显示集群状态异常，大集群下 gs_roach 启动时会频繁访问 cms 读取集群状态，导致 cm_ctl 查询集群状态不稳定

【涉及版本】821 以下版本（不包括 821 版本）

【排查方案】

查询 cm_server 日志（roach 启动之后的时间点）,报错"CmPqPutMessage return error ret=xx"

$GAUSSLOG/bin/cm_ctl 日志,报错"send query msg to cm_server failed"

【问题原因】

在 roach 启动期间，频繁调用 cm_ctl 命令，而集群节点数多，并发数高，会导致页面集群状态监测的脚本执行 cm_ctl 失败

【问题规避】

升级到 821 版本

四、常见问题汇总

相关文档：

• 华为云数仓 GaussDB(DWS)备份恢复的实现：https://bbs.huaweicloud.com/blogs/185928
  

• 数仓 GaussDB(DWS)全量备份总结：https://bbs.huaweicloud.com/blogs/242694
  

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