对于集群迁移来说，备份文件不仅要在本地生成，还需要scp到远端新集群，这里就得额外考虑一些问题。本地rch文件生成速度往往较快，如果集群间带宽有限，则rch文件会来不及scp到新集群，积压在生产集群本地。对于生产集群来说，积压过多备份文件在本地会导致磁盘空间紧张引发其它问题，因此断点续做通过流控机制完美解决了积压问题。对于新集群来说，如果出现断点续做，那么下次续做时，就得先查看本地rch编号和新集群已经scp过去的rch文件编号。另外，考虑网络传输时如果新集群设备掉电，可能造成新集群rch文件残缺，因此scp过去时先落盘为*.tmp后缀，fsync成功后，再重命名回*.rch。由于恢复集群前，先停止了集群，所以截止此时集群还处于停止状态，需要拉起集群。有了上面的backuprestoreinfo.csv和rch续做机制后，启动集群就变得比较简单，完全可以复用全量恢复的命令，再拉起一遍恢复续做任务即可。SyncDataToStby.py工具内部会检查核实是否所有rch都已恢复完毕，是则执行集群启动动作，否则续做全量恢复。恢复可能异常中断，导致Roach进程退出。另外若集群间带宽为瓶颈，则新集群恢复rch文件的速度大于生成集群scp拷贝rch文件过来的速度，则也会导致Roach提前完成任务而退出。由此，需要保证过段时间新的rch文件被scp过来后，仍然能接着恢复。 为实现该目的，SyncDataToStby.py工具借助了双集群之间的纽带文件backuprestoreinfo.csv，该文件记录了备份和恢复的当前状态等信息。如果当前备份状态为未完成，则恢复线程就会不断检测是否有新的rch文件传输过来，若有则先scp到新集群内的备实例，然后调度gs_roach并行恢复各个实例的新rch文件。直至所有的rch文件都恢复出来。

全量恢复是不是也是由状态机驱动、分为若干子任务。实际的情况是，全量恢复虽然也由状态机驱动，但状态个数非常少。这是因为恢复过程本身比较简单，所有实例、行列存/xlog对于Roach来说都可以一视同仁，因为rch备份文件最初就设计为自解析模式的，Roach解析rch文件就完全可以知道是哪个节点、哪个实例、行列存还是xlog的数据文件，因此主要的恢复过程只需要一个子任务调度就可以了。 全量恢复的断点续做，就只需处理好上次恢复到哪个rch。一种思路是也用meta元数据记录上次恢复进度信息，另一种更简单的思路是：不使用元数据，直接遍历本地已恢复完的rch文件，即可得知本次需要从哪个rch开始续做恢复。为了在线集群迁移方便扩展，新集群恢复完的rch文件并没有立即删除，而是重命名为*.rch.resume_delete后缀，所以断点续做时只需遍历找到当前目录下过滤掉*.rch.tmp、*.rch.resume_delete文件后，编号最小的那个*.rch文件，就是本次续做需要开始的文件。上次中断后，本次恢复只需从file_10.rch开始恢复即可。

集群全量恢复分为三个阶段：停止集群、恢复集群、启动集群。由于主备DN数据互为副本，备份DN时只备份了主DN数据，恢复集群过程中也只恢复主DN数据。然后在启动集群阶段，一方面会将主DN数据redo到barrier点，另一方面会用主DN数据build到备DN，使得备DN成为主DN数据的副本。这三个阶段中，最耗时的就是恢复集群阶段，本节主要展开讨论这个阶段的续做。 集群迁移场景下，为了尽可能缩短迁移时间窗，采用了很多黑科技，其中之一就是主备DN并行恢复。这样省去了主DN数据build备DN过程，使得恢复和迁移时间缩短一半以上。原理是先将主DN的rch备份压缩文件拷贝到备DN的关联路径下（都在新集群内部拷贝），然后主DN和备DN就可以同时进行解压恢复rch文件了。最后只需特殊处理一下备DN的postgresql.conf即可。

备份过程实质是将各个CN/DN等实例下的数据文件生成*.rch格式的压缩包，每个压缩包最大不超过4GB（可配置）。每个4GB的文件通常都能在几分钟内完成生成和备份，记录这些rch文件编号信息，就可以在下次续做时接着上次rch编号继续备份，从而每个实例续做浪费的时间就控制在几分钟内。这个思想简单，但实现起来却非常复杂，与当前Roach的核心流程、各种性能优化机制都息息相关，要考虑很多因素。由于Roach支持在线备份，且PG不支持undo，我们在备份文件之前会先生成备份开始时刻的数据文件清单，备份时按当时时刻的文件大小截取拷贝到内存中。而从磁盘读取文件内容开销会很大，因此Roach设计了多reader线程机制来加速读IO性能，小于8MB的文件（可配置）由reader线程负责读取，较大文件则由主线程exec负责读取，最后由exec负责内存数据汇总。这个性能优化机制带来了一个问题，就是rch文件中的备份文件顺序和文件清单中文件顺序可能出现不连续跳变，下次续做就无法接着上次文件清单进度进行。由此，新增了roach_resume_trans_log日志文件记录各个实例下的大小文件序号，分两条线保证续做的正确性。

为节省内存开销，主节点的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