本文分享自华为云社区《GaussDB（DWS） 备份问题定位思路》，作者： yd_216390446。
前言
在数据库系统中，故障分为事务内部故障、系统故障、介质（磁盘）故障。对于事务内部故障和系统故障，使用日志自动恢复，不需要人工参与。但对于介质故障，需事先备份数据。
那么对于DWS来说是如何进行备份的呢？以及备份的过程中容易出现哪些问题，又怎样去排查、解决呢？
本文主要讲述了DWS备份工具roach的备份的原理，以及常见的问题处理套路和相关案例。
一、备份原理
全量备份
本文主要说的备份均为物理备份，即通过物理文件拷贝的方式对数据库进行备份，通过备份的数据文件和日志等文件，数据库可以进行完全恢复。
全量备份大致分几个阶段：备份行存、创建barrier点、备份xlog、备份列存。
- 备份行存：每个节点的主DN的数据，压缩存到rch文件中
- 创建barrier点：保证CNDN上的所有的事务处于一致的状态，恢复到这个点比较可靠，创建时会在XLog中写入一条记录。
- 备份xlog：备份startLSN和stopLSN之间的xlog
- 备份列存：由于列存不写xlog，因此放在最后，其中列存的cudesc文件已在备份行存阶段备份
整体流程如下图所示
![cke_136.png]()
容易出现的问题：
- 禁用xlog回收容易造成集群只读
- 延迟DDL也会引起集群只读
注意的点：
- 备份过程必须开启FPW
- 备份XLog拷贝start_lsn和end_lsn之间的xlog
- 备份列存的时候才会开启DDL
为什么要有延时DDL？
DDL操作：alter/truncate/autovacuum/drop/vacuum full/insert overwrite 这些会改变relfilenode的语句，DDL操作在拿到行列存清单后，如果用户进行drop操作，为了保证文件存在，所以要开启延迟DDL
增量备份
![cke_137.jpeg]()
增量备份是基于某次备份进行的，在增量备份的命令中需要增加参数–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信息可以直接获取两次备份之间发生对于数据文件（行存、列存）的增量修改信息，并备份
![cke_138.png]()
备份对于系统的影响：
- 备份占用系统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/agent
- Python侧日志：$GAUSSLOG/roach/controller
- obs日志：
- 沙箱内 cd $GAUSSLOG/bin/gs_obs
- vi gs_obs.run.log查看对应的出错号此处注意的是obs日志需要到具体出错节点上查看
![cke_139.png]()
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）备份关键日志
|
关键字 |
说明 |
|
Creating Thread Roach Agent |
开始创建agent进程 |
|
RAGENT_EXEC_PREPARING_METADATA com |
开始准备metadata清单 |
|
enter the callback of rowstore copy |
开始备份行存 |
|
performBackup enter |
真正开始执行落盘到rch |
|
start delay ddl recycle before col file copy |
开启延迟DDL |
|
Setting agent state to [AGENT_CREATING_BARRIER] |
开始创建barrier |
|
RAGENT_EXEC_BACKUP_XLOGFILES come |
agent开始备份xlog |
|
enter the callback of colstore copy |
开始备份列存 |
|
stop delay ddl recycle after having copied all col files |
关闭延迟DDL |
|
Setting Master state to [PERFORM_BOOKKEEPING_INFO] |
备份结束，master节点开始汇总结果 |
三、相关案例
（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
![cke_140.jpeg]()
![cke_141.jpeg]()
【排查方案】
- 由于报错连接时“host:25308”，因此查看对应时间节点的cn日志
- cn报错 FATAL: “base/2278052” is not a valid data directory，怀疑是该数据库的问题
- 手动连接该数据库，发现也连不上
- dn实例目录下查看该目录并不存在，为残留导致
- drop database删除该数据库后备份成功
【问题原因】数据库存在残留文件
【规避方法】删除该数据库下的残留文件
（2）备份随机失败
【问题描述】NBU 问题导致备份随机失败
【排查方案】
- 查看controller日志，显示第一个报错的节点为xx.xx.xx.148
- 到上述节点查看agent日志，报错"Incomplete Message from Roach client"，发现日志指向media server，因此查看roach client日志
![cke_142.jpeg]()
- 怀疑是nbu的问题，到对应的roach_client节点查看相应日志，通过grep “Success to connected Remote Media” roach_agent*.log，找到roach_client的ip地址，ssh到对应的roach_client节点，对应的报错为NBU内的报错，“call NbuManager::CreateFile error”，协同NBU侧的同事排查
![cke_143.jpeg]()
【问题原因】一般情况下，上述情况是由于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.
![cke_144.jpeg]()
【问题原因】
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.
![cke_145.jpeg]()
【问题原因】细粒度备份期间不支持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"
![cke_146.jpeg]()
- $GAUSSLOG/bin/cm_ctl日志,报错"send query msg to cm_server failed"
![cke_147.jpeg]()
【问题原因】
在roach启动期间，频繁调用cm_ctl命令，而集群节点数多，并发数高，会导致页面集群状态监测的脚本执行cm_ctl失败
【问题规避】
升级到821版本
四、常见问题汇总
![cke_148.png]()
![cke_149.png]()
相关文档：
华为云数仓GaussDB(DWS)备份恢复的实现：https://bbs.huaweicloud.com/blogs/185928
数仓GaussDB(DWS)全量备份总结：https://bbs.huaweicloud.com/blogs/242694
点击关注，第一时间了解华为云新鲜技术~
