为节省内存开销，主节点的gs_roach同时兼任Roach master和Roach agent身份。Roach master维护一个状态机，与其余节点的Roach agent通过TCP长连接进行通信，前者扮演主控角色，给其余节点发送命令，通知它们按状态机的次序逐个完成各项子任务，并控制其余节点的备份状态保持同步。目前集群全量备份共有十几个状态，各个Roach agent节点需要按Roach master的指令依次完成十几个子任务。Roach master会等待各个Roach agent都完成该项子任务才会推进到下一个状态。为了更好地控制分布式交互，各个Roach agent也维护了自己的一个状态机，其状态大体与Roach master的状态一一对应。用两个元数据文件resume_backup_master.metadata和resume_backup_agent.metadata，分别记录Roach master和Roach agent当前已完成到哪个状态机阶段，每完成一个子任务，就刷新一次续做的元数据文件。那么，中间出现故障后，需要拉起续做任务时，就读取这俩文件获知上次完成到哪个子任务，本次就从下一个子任务开始接着做。当然，每个节点都有Roach agent，所以resume_backup_agent.metadata也不止一个，每个节点负责维护自己的Roach agent续做元数据。同时，这个文件里面记录的信息也远远不止子任务状态。

全量备份调用的是GaussRoach.py备份工具，这个就是大家熟悉的单个集群的备份恢复工具Roach。要控制全量备份的断点续做，就需要了解Roach工具的架构、内部运转流程，作为基础。GaussDB(DWS)集群是分布式架构的，其备份工具Roach也基于分布式架构。Roach主要包括两个组件：调度框架GaussRoach.py和实际执行任务的gs_roach程序。假设集群有3个节点，用户在节点1调用GaussRoach.py发起备份操作，那么我们就将节点1称为master节点（主节点），其余节点称为agent节点。GaussRoach.py通过ssh命令给每个节点都拉起gs_roach进程，后者根据本节点DN个数fork相应数量的gs_roach子进程，每个gs_roach进程负责一个DN的备份任务。备份任务结束后，所有gs_roach和GaussRoach.py进程退出。同一时刻，集群内所有DN相当于都在并行备份数据。

scp动作发生在新老集群间的两个CN/DN实例之间，而非两个节点之间。因此，迁移框架支持两套集群节点数不同，只要两套集群的总DN个数相同即可（通常称为异构迁移或异形迁移）。该框架与GaussDB(DWS)双集群容灾架构完全相同。没错，该框架非常强大，对于异构或同构的双集群跨AZ容灾、集群间数据迁移都是通用的，且支持一次全量、多次增量容灾或数据同步，支持在线不停业务周期数据同步或容灾，支持容灾或迁移过程中断点续做。而集群数据迁移其实是使用了其最简单的一种场景，相当于离线场景下只做了一次全量数据同步到新集群。框架基于Roach物理备份恢复，生产集群相当于做了一次全量集群物理备份，新集群相当于做了一次全量集群物理恢复。全量备份和全量恢复两个过程之间基本解耦，通过scp备份文件将两个过程关联起来。因此，该框架下的断点续做实现，最主要的就是分别管理好生产集群的全量备份断点续做和新集群的全量恢复断点续做，以及两个集群间的scp动作中断场景的续做。

随着业务的迅速增长，客户原有的生产集群部署的服务器性能会逐渐无法满足业务需求，由此客户可能会采购一批高配置的服务器搭建新集群，希望将生产集群的数据迁移到新集群。先前客户通常使用GDS工具等方式，将生产集群数据先导出至中转服务器，然后从中转服务器再导入新集群。但这样周期很长，且需要客户提前准备大量机器用做GDS中转服务器。事实上，GaussDB(DWS)从两年前已研发出了一种新的集群数据迁移利器，可以高效完成该工作，该方案基于Roach物理备份恢复原理。考虑到OLAP场景下，用户集群动辄数百个节点，数据量则高达若干PB，集群数据迁移过程往往需要数小时之久。一种应对方案是一次全量迁移加多次增量迁移配合，另一种是全量迁移与断点续做配合。目前客户稳妥起见通常选择固定的变更时间窗，停业务离线迁移结合断点续做的方式。集群数据迁移框架是在SyncDataToStby.py工具中实现的，同时部署在新老集群上，该工具负责在生产集群上拉起GaussRoach.py -t backup备份任务，在新集群上拉起GaussRoach.py -t restore恢复任务。生产集群上由Roach备份生成的*.rch备份压缩文件，通过scp命令传输到新集群上，新集群通过Roach工具解压这些*.rch备份文件，从而将生产集群的数据文件以物理恢复的方式同步到了新集群。

【问题版本】 ESL813.5 FI812.5（不限于版本）【问题描述】 监控显示异常【问题影响】 无【问题根因】 DBConfig.xml配置文件丢失（掉电导致）【定位过程】1、之前机房断电所有节点都掉过电，监控界面不显示数据，查询后台OMS状态都正常；1）排查/var/log/Bigdata/omm/oms/pms/scriptlog/pms_script.log日志；2）排查/var/log/Bigdata/omm/oms/pms/pms.log日志；2、查pms日志发现报内存不够的问题，调整到16G后重启pms还是不行；1）使用ps -ef|grep PMSMain 指令查询pms设置的内存大小；2）修改/opt/huawei/Bigdata/om-server/OMS/workspace/conf/pms/application.properties文件中pms.mem的值；3）使用omm用户重启pms，restart_app pms3、排查发现是pms数据库配置文件有问题DBConfig.xml文件大小为0，异常断电导致文件丢失；/opt/huawei/Bigdata/om-server/OMS/workspace0/conf/pms/DBConfig.xml4、没有别的集群，可以从iam的同级目录拷贝后重启pms界面恢复；1）和pms一样，fms及iam模块在启动时均需要连接gaussdb数据库，其密码存储在：/opt/huawei/Bigdata/om-server/OMS/workspace0/conf/iam/DBConfig.xml/opt/huawei/Bigdata/om-server/OMS/workspace0/conf/fms/DBConfig.xml文件中；2）查看/opt/huawei/Bigdata/om-server/OMS/workspace0/conf/iam/DBConfig.xml文件是否为空，异常掉电会导致文件内容丢失；使用/opt/huawei/Bigdata/LocalBackup/0/default-oms_20211014120526/本地备份文件，找丢失前的备份文件，替换DBConfig.xml后重启pms即可；3）如果没有别的集群，也可以在MRS环境拷贝一份，底座都是FI，配置文件都差不多，拷贝后修改password内容后重启pms即可；【规避措施】1、拷贝DBConfig.xml配置文件替换pms下的：cp /opt/huawei/Bigdata/om-server/OMS/workspace0/conf/iam/DBConfig.xml /opt/huawei/Bigdata/om-server/OMS/workspace0/conf/pms/DBConfig.xml2、重启pms：su - ommrestart_app pms

【问题现象】集群-》实例-》运行状态处于正在恢复【常见版本】全版本   【定位思路】   1、首先排查OMS状态和MPPDB状态，若均是正常2、进一步排查日志/var/log/Bigdata/mpp/healthCheck/nodeCheck.log3、可见报错：SyntaxError: invalid syntaxINFO (nodeStatusCheckMPPDB:[mpp-server-monitor.sh:])The cluster Unknown.ERROR (main:[mpp-server-monitor.sh:149]) nodeStatusCheckMPPDB failed.4、有如上报错就可以定位是python3问题4.1、检查是否安装python34.2、python3 -V检查版本是否是3.8.5以上4.3、python3 软链接是否正确5、python3修复后MPPDB状态会上报正常，nodeCheck.log日志会打印INFO (nodeStatusCheckMPPDB:[mpp-server-monitor.sh:]) The cluster Normal. 

一、背景客户在执行业务sql产生报错：ERROE:dn_xxxx_xxxx:gc_fdw foreign scan rows verfify failed:node index 2/6,received 21,expected 0 Line Number:1。二、原因这个报错可以参考下这个函数：gc_fdw_verify_option_开发人员选项_数据仓库服务 GAUSSDB(DWS)-华为云问题根因：在协同分校验逻辑中，获取返回数据时，仅取了第一个聚集结果，应该汇总多节点结果作为判断依据，导致检查count校验实际获取到的数据量 不一致语句报错三、解决规避方案：gs_guc reload -Z coordinator -Z datanode -N all -I all -c "gc_fdw_verify_option=off"规避影响：该参数只是对协同分析的校验有影响，关闭不影响性能是个bug，高版本821已修复补充：这里做下记录，因为遇到2次了，第2次完全不记得遇到过，经同事提醒后查询记录后想起。

TPOPS页面的实时告警怎么推送至第三方接收平台

1、license导入主要看如下两个日志：/var/log/Bigdata/tomcat/web.log/var/log/Bigdata/controller/controller.log2、其次就是看导入的license文件，因为不同版本的license文件不一致；3、还有个判断点就是是否有license相关告警，从license告警也可作为思路；问题一：（线下ESL821.3版本才支持动态脱敏特性）1）原来是数据仓库正常的license现在导入动态脱敏的license激活失败，界面有12060 license维保过期的告警；2）排查web.log日志发现是有错误码ErrorMsg:RESID_OM_API_LICENSE_0001；3）license导入没报错，激活时报错，让反馈license文件，查看特性；3）动态脱敏特性是要叠加到标准数仓上的，申请的license只有动态脱敏不行，需要重新申请叠加上标仓的才行；问题二：（HCSEIBDDWSTB是821版本新支持的量纲）1、license导入失败，申请的模式HCSEIBDDWSTB是821版本新支持的量纲，现场环境低于821，需要重新申请产品为GaussDB A重新导入； 

【问题版本】ESL821（所有版本适用）【问题描述】部分节点有ALM-25006 Sssd服务异常告警【问题影响】无【排查思路】1、可以按照产品文档排查，先排查进程是否存在：ps -ef | grep sssd，排查/var/run/下面是否有sssd.pid文件：ll /var/run/sssd.pid；进程正常状态为：存在/usr/sbin/sssd进程和三个子进程/usr/libexec/sssd/sssd_be、/usr/libexec/sssd/sssd_nss、/usr/libexec/sssd/sssd_pam。2、排查/var/log/sssd.log日志，看是否有报错，具体报错具体分析；重复打印如下日志：[monitor_restart_service] (0x0010): Process [nss], definitely stopped![monitor_cleanup] (0x0010): Error removing pidfile! (2[No such file or directory])3、排查告警节点/var/挂载盘容量是否满了，满了则需要清理；4、查看/var/lib/sss下面的权限与正常节点是否一致，不一致需要改成一致；5、排查/etc/sssd/sssd.conf文件配置，告警节点对比正常节点配置是否有差异；1）若有差异，ldap_tls_cacert、ldap_uri对应配置，需要拷贝正常节点到告警节点；2）以root用户执行service sssd restart命令重启sssd服务；注：其中ldap_tls_cacert、ldap_uri对应配置可在/etc/openldap/ldap.conf配置文件里找；6、执行命令cat /var/log/messages，查看sssd是否频繁重启或者存在Can't contact LDAP server的异常信息。可以删除/var/run/sssd.pid文件重启sssd服务尝试；7、若sssd服务还是一直重启，可找操作系统的看看；

【问题版本】 管控面813【问题描述】 OC告警硬盘使用率阈值告警，dms-collection日志不回收【问题影响】 无【问题根因】 容器日志未清理就重启导致日志残留【定位过程】1、DWS-Region-Node节点日志盘快满告警，告警信息如下：一般告警，数据仓库-ManageOne-Service02（XX.XX.XX.XX）,[告警描述]故障时间:2024-xx-xx xx:xx:xx故障内容:故障设备：XX.XX.XX.XX,告警详情：硬盘使用率阈值告警,定位信息：云服务=DWS; 服务=S-DWS; 微服务=DWSController; 实例名称=DWSController_DWS_Region_Node_XXX; 部署节点名称=DWS_Region_Node_XXX, 管理IP=XX.XX.XX.XX, 区域=XXXX,告警类型：异常告警,告警TYPE：6,进程读写磁盘过于频繁,告警ID: -1,2、dms-collection日志不回收，导致DWS_Region_Node_XXX节点磁盘快打满，之前说过让一线定时清理，防止打满；3、排查发现生产节点数200多过多导致容器老是重启，还没回收就重启了，导致残留；4、让部署定时任务去清理，已经强调清理前保留目录日志文件大小数量，建议保留一个月或者半个月（按实际情况定）；【规避措施】部署定时任务定期清理，步骤如下：1、登录虚拟机节点,检查/var/log/路径使用率：df -h2、登录对应节点清理日志：find /var/log/dbs/dms-collection/dms-collection.* -type f -mtime +30 -exec ls -lrt {} \;find /var/log/dbs/dms-collection/dms-collection.* -type f -mtime +30 -exec rm -f {} \;find /var/log/dbs/dms-collection/dms-collection.* -type f -mtime +30 -exec ls -lrt {} \;3、部署定时清理任务：crontab -e 添加定时任务0 18 * * * find /var/log/dbs/dms-collection/dms-collection.* -type f -mtime +30 -exec rm -f {} \;crontab -l 查询定时任务3、检查/var/log/路径使用率：df -h

【问题版本】HCS831【问题描述】打开DWS控制台报错CF2.E00002.001 Connecttimeout, connection exception【问题影响】对集群业务无影响，只影响管控面【定位过程】1、DWS控制台报CF2.E00002.001 Connecttimeout, connection exception；2、首先排查容器状态(EICommon-Region-Master-01/02/03节点)和rms数据库状态（DWS-DB01、DWS-DB02节点）；3、排查发现是dwscontroller两个容器都挂了，describe容器排查日志没看出啥，容器一直在重启，怀疑是资源不够，手动干预重启一个容器能启起来，界面恢复，找CDK排查原因；3、CDK侧定位怀疑是docker运行时间长了，有些资源没释放，手动释放两个节点资源，防止再次重启失败；【规避措施】1、手动重启dwscontroller服务后恢复；（可在CDK界面删除pod,或者后台节点kubectl delete pod XXXXX -n  xxx）2、释放两个dwscontroller容器所在node节点资源：（kubectl get pods -A -owide命令查询容器所在node节点IP；）如下顺序：docker system prune -a 清理Docker系统中未使用的镜像、容器、网络和数据卷等资源，释放因临时或废弃的 Docker 对象占用的存储空间；systemctl daemon-reload 重新加载守护进程systemctl resrart docker 重启dockersystemctl resrart kubelet 重启kubelet

【问题版本】 HCS831【问题描述】 下发集群失败报DWS.0042【问题影响】 创建集群失败【定位过程】1、按照此案例排查失败步骤：https://bbs.huaweicloud.com/blogs/427974，并获取失败task的jobid;2、通过jobid去dwscontroller服务过滤日志，发现有"errorcode message":"FSOPS.NOVA.Schpduler.HuaweiDiskFilter"，找BMS侧排查；BMS侧排查发现：下发选的az不对，筛选到的裸机都是bmsaz2.r1的，目标裸机都是bmsaz.r1下3、选对az后重新创建，发现还是失败，同样的找jobID去搜日志，发现到下载包失败，找OBS侧排查，日志如下；[4a90xxxx-xxxx-xxxx-xxxx-xxxxxxx28965b].installPackage download check result failed.instance return failMsg:{'errorCode': 'E001',errorMsg': 'Failed to download or pre install packages. Error: Failed to download package [8.1.3.333-dws-x86_64-91636-8f04b691-0b660213-20240612155607.tar.gz] from OBS at 3 times. Error: udstool download failed: ...下面有打印：...internal.utils.RestUtils$DefaultObsDnslookup|493|internet host address:[dws-instance-xxxx.obsv3.ndc-r-1.egov.iq/194.xxx.xxx.xxx]2025-01-10 20:23:30 900|com.obs.services.internal.RestStorageService executeRequest 600 OkHttp cost 20022 ms to apply http request2025-01-10 20:23:30 901 com.obs.services.internal.RestStorageService handleThrowable 220 Request failed, Response code: 408; Request ID: null; Request path: https://dws-instance-ndc-r-1.obsv3.ndc-r-1.egov.iq/8.1.3.333-dws-x86_64-91636-8f04b691-0b660213-20240612155607.tar.gz2025-01-1020:23:30 901|com.obs.services.AbstractClient|doActionWithResult|403|Storage|1|HTTP+XML|getObject|I||2025-01-10 20:22:10|2025-01-10 20:23:30|||408|\n, None..'}. RPC msg|com.huawei.hwClouds.dbs.executor.RdsDownloadPackageTask.getInstallCheckResult(RdsDownloadPackageTask.java:220 )4、OBS侧排查发现：手动wget能下载，请求未走到OBS，返回的是公网IP，怀疑是DNS解析问题，让找CloudDNS的人排查；dws-instance-xxxx.obsv3.ndc-r-1.egov.iq/194.xxx.xxx.xxx5、客户这边配置了公网的DNS解析，导致内网的CloudDNS解析也是公网的IP地址；6、让客户修改回去，修改后重新下发成功； 

 请看图：无缘无故报个这个问题，官网文档搜不到一点有用信息，搞什么？tpops 是 24.1.30版本                 

【问题版本】 ESL821【问题描述】 chronyc同步状态有问题【问题影响】 无【问题根因】 告警检查时间精度太粗，导致连续十次检查结果相同进而导致告警上报【定位过程】 1、FI界面上报ALM-12012 NTP服务异常和ALM-12037 NTP服务器异常告警，排查网络正常，123端口也是通的；2、排查发现chrony同步状态异常，排查发现配置文件/etc/chrony.conf中外部时钟源配置的noselect；3、手动将配置文件/etc/chrony.conf中外部时钟源的noselect修改为iburst后，能短暂同步成功，但是过会儿就会被刷回去；4、需要删除主OMS节点/opt/huawei/Bigdata/om-server/OMS/workspace0/conf/chrony.conf.active文件，然后修改/etc/chrony.conf，再重启systemctl restart chronyd服务后，不再被刷回去，记住还需要杀掉主oms节点ntpMonitor进程让自己拉起；5、若还告警，由于告警检查时间精度太粗，导致连续十次检查结果相同进而导致告警上报，修改脚本后恢复正常；【规避措施】1、root修改主备OMS节点如下两个文件：（find /opt/huawei/  -name chrony查出来）/opt/huawei/Bigdata/om-server_8.2.0.X/OMS/workspace0/ha/module/harm/plugin/script/chrony/opt/huawei/Bigdata/om-server_8.2.0.X/om/inst/script/chrony注释213、214行，下面另起一行添加如下：EXTERNAL_NTP_OFFSET=$(sudo ${SUDO_PATH_OMS} external_offset_record $ntp_server_ip)2、root修改主备OMS节点如下三个文件：（find /opt/huawei/ -name "manager_sudoExecute.sh"查出来）/opt/huawei/Bigdata/om-server_8.2.0.X/om/sbin/sudo/runtime/manager_sudoExecute.sh/opt/huawei/Bigdata/om-agent_8.2.0.X/nodeagent/bin/sudo/runtime/manager_sudoExecute.sh/opt/huawei/Bigdata_func/sudo/runtime/manager_sudoExecute.sh修改2536行为如下：offset_record=$(echo $offset_record 1000 | awk '{printf "%f\n" ,$1*$2}')