【问题现象】    ALM-12034 周期备份任务失败告警说明：系统每60分钟执行周期备份任务，如果周期备份任务执行失败，则上报该告警，如果下次备份执行成功，则恢复告警。【常见版本】全版本   【定位思路】   1、可以参考产品文档检查/srv/BigData/LocalBackup备份路径挂载点的剩余空间是否小于20GB，小于清理空间即可查看日志/var/log/Bigdata/controller/backup/controller_backup.log,报错信息如下：Free spaces not enough, free space: xxxxxxxxx,localbackupPathMinSize is /srv/BigData/LocalBackup.2、若大于20GB，查看日志/var/log/Bigdata/controller/backup/controller_backup.log，是否会打印backup gaussdb File failed on xxx.x.x.x.3、如果是，请排查floatip和节点间互信是否有问题4、仅出现一次失败日志和告警，但是后续备份都是正常的，可能是由于网络闪断或发生主备切换导致一次失败可以忽略。

【问题版本】 HCS831（其他版本也适用）【问题描述】 下发集群卡50%进度最后失败，无关键报错信息【问题影响】 无【问题根因】 裸金属接入交换机多组高速网络VLAN不通【定位思路】1、登录rms数据库查看失败task名称、jobid、执行任务的dwscontroller容器，操作方法：https://bbs.huaweicloud.com/blogs/427974；1) 失败任务：RdsInitInstanceTask;2) 拿对应失败jobid去dwscontroller容器grep 'jobid' ossres-dws.log | grep ERROR搜日志,只有如下信息：2025-xx-xx xx:xx:xx,xxx|xxxxx...xxxxx||ERROR|xxxxx...xxxxx|task[RdsInitInstanceTask] run fail.|com.huawei.hwclouds.taskmgr.job.impl.CommonJob.dealTaskResultFail(CommonJob.java:307)2025-xx-xx xx:xx:xx,xxx|xxxxx...xxxxx||ERROR|xxxxx...xxxxx|get dwsCreateInstanceJob JobConfig fail|com.huawei.hwclouds.taskmgr.job.impl.JobService.isNotAutoRolback(JobService.java:88)2、登录实例节点查看安装日志/home/Ruby/log/cloud-dws-deploy.log如下，发现只打到chroot步骤，无报错信息：[2025-xx-xx xx:xx:xx,xxx][INFO][xxxxx][xxxxxxxxxxxxxxx][init.py 571][Chroot succeed][2025-xx-xx xx:xx:xx,xxx][INFO][xxxxx][xxxxxxxxxxxxxxx][init.py 571][Chroot succeed][2025-xx-xx xx:xx:xx,xxx][INFO][xxxxx][xxxxxxxxxxxxxxx][init.py 469][Waiting to chroot finished][2025-xx-xx xx:xx:xx,xxx][INFO][xxxxx][xxxxxxxxxxxxxxx][init.py 469][Waiting to chroot finished]3、排查/home/root/log/ssh-agent-monitor.log日志如下，互信配置下发完成，无报错信息：[2025-xx-xx xx:xx:xx,xxx][INFO][create_trust][xxxxx][xxxxxxxxxxxxxxx][create_trust.py 217][Build authorized_keys succeed.][2025-xx-xx xx:xx:xx,xxx][INFO][create_trust][xxxxx][xxxxxxxxxxxxxxx][create_trust.py 311][Begin split authorized_keys file][2025-xx-xx xx:xx:xx,xxx][INFO][create_trust][xxxxx][xxxxxxxxxxxxxxx][create_trust.py 317][no need split authorized key]4、排查发现是节点互信有问题，进而排查是网络不通导致，集群节点间internalIp相互ping不通；1)  登录rms数据库查看rds_instance表获取internalIp，登录数据库方法见：https://bbs.huaweicloud.com/blogs/427974查询internalIp的sql：select id,name,status,manageIp,internalIp from rds_instance where clusterId='界面创建的集群ID';2)  登录实例节点ps -ef | grep ssh查询进程还在，未到达task的重试最大次数，但是前台已经超时失败了（task的最大重试次数是dwscontroller服务CDK参数 listenInitDbCount 乘以2）；3）实例节点root用户执行cat /etc/hosts查看节点hostname对应ip验证连通性，发现CN1节点ping不通CN2和CN3节点IP;5、高速平面网络不通导致，需要找网络侧排查原因（仅提供协助排查思路，具体定位细节需要给网络创建关联单进行排查）；1）定位是交换机高速平面VXLAN未打通（集中式跨leaf场景）；2）属于高速平面网络不通，排查是由于3台BMS服务器没在同一组接入交换机内（serviceOM界面裸机服务器配置下可查看端口），接入交换机之间的高速网络VLAN没有放通导致，需要排查所有裸机接入交换机组；3）找数通侧检查交换机配置是否有遗漏，排查发现只配置了一个VLAN（最佳实践文档有说明是要放通所有的，是以一个为例），需要把规划的VLAN段都放开（交换机上配置高速VLAN），发放后再删除集群重新下发；

2025留下你的新年学习目标，大家尽情分享吧

集群迁移断点续做https://bbs.huaweicloud.com/forum/thread-0272173601021304058-1-1.htmlscp动作介绍https://bbs.huaweicloud.com/forum/thread-0251173601104528058-1-1.html全量备份的断点续做https://bbs.huaweicloud.com/forum/thread-0248173601167597069-1-1.html 节省内存开销的方法https://bbs.huaweicloud.com/forum/thread-0296173601214152058-1-1.html备份过程实质介绍https://bbs.huaweicloud.com/forum/thread-02104173601257779065-1-1.html集群全量恢复https://bbs.huaweicloud.com/forum/thread-0272173601309699059-1-1.html全量恢复介绍https://bbs.huaweicloud.com/forum/thread-02104173601356000066-1-1.html集群间scp中断后的断点续做https://bbs.huaweicloud.com/forum/thread-0296173601429619059-1-1.html一站式实现数据业务科学决策https://bbs.huaweicloud.com/forum/thread-0271173601660275056-1-1.htmlSQL引擎无法支撑复杂SQL查询的挑战https://bbs.huaweicloud.com/forum/thread-0251173601707163059-1-1.html消除数据孤岛https://bbs.huaweicloud.com/forum/thread-0296173601740524060-1-1.html资源管理简介https://bbs.huaweicloud.com/forum/thread-0271173601892622057-1-1.html计算资源介绍https://bbs.huaweicloud.com/forum/thread-02127173601939038055-1-1.html异常处理规则https://bbs.huaweicloud.com/forum/thread-02109173601978478069-1-1.html资源池并发队列https://bbs.huaweicloud.com/forum/thread-0272173602035469060-1-1.html   

全局并发队列采用GUC参数max_active_statements控制单个CN上运行并发执行的作业数量。采用全局并发队列机制将控制所有普通用户的执行作业，不区分复杂度，即执行语句都将作为一个执行单元，当并发执行的作业数量达到此参数阈值时，将进入队列等待。对于初始用户(Oid=10)执行的作业，不走全局并发控制逻辑。 注：max_active_statements限制单CN上运行的作业数，默认值为60，假设用户有3个DN，则实际全局并发上限为3*60=180； DDL和DML语句均受max_active_statements并发控制。 资源池并发队列包含快车道并发队列和慢车道并发队列，配置方式如下： CREATE RESOURCE POOL respool_a WITH (max_dop=10,active_statements=5); 其中max_dop为快车道并发上限，active_statements为慢车道并发上限。 注：资源池队列只限制DML语句，不限制DDL语句； max_dop限制单CN上资源池快车道并发数； active_statements在静态负载管理模式下限制单CN上资源池慢车道并发数，在动态负载管理模式下限制所有CN上资源池慢车道并发数之和。

存储资源包含：持久表空间、临时表空间和算子落盘空间。临时表空间和算子落盘空间是作业运行过程中占用的空间，属于临时占用空间。持久表空间和临时占  用空间采用两种不同的管控策略，持久表空间管控通过对用户(队列)和schema空间限制实现，8.1.1版本之后的GaussDB空间管控均为单实例空间，防止出现数据倾斜导致的磁盘使用问题。临时占用空间同样支持在用户层级设置空间限额，另外还提供异常规则查杀临时空间占用异常的作业。异常处理规则GaussDB目前支持算子落盘异常规则，用户通过管控面或gs_cgroup工具设置算子落盘异常规则，设置异常规则后作业执行过程中算子落盘空间达到阈值后报错退出。 用户连接数据库执行SQL后，SQL会经过全局并发队列管控以及资源池队列管控。在作业进入管控逻辑前设置定时器，作业pending超时报错退出，作业经过队列管控开始运行前重新设置定时器，作业运行超时报错退出。作业下推DN执行时实时监控作业消耗的资源并上报CN，CN根据DN上报资源信息提供异常处理和监控视图。

资源管控通过对计算资源和存储资源分别管控实现作业间资源隔离，保证单作业异常不会影响到其他作业运行。下面分别对计算资源和存储资源管控进行概述： 1.计算资源 计算资源包含：CPU、IO和内存。GaussDB中CPU和内存资源关联在队列上，用户通过关联队列使用计算资源。队列按使用场景分为超户队列、默认队列和用户队列。其中超户队列不受资源管控，用于运维和故障修复；默认队列(default_pool)为数据库初始化阶段创建的队列，未关联用户队列的用户使用默认队列；用户队列为用户自己创建的队列，按照用户配置的并发和资源进行管控。IO管控基于逻辑IO实现，根据作业运行时间及优先级对IO进行管控，配置异常处理规则后，在系统IO达到瓶颈后，主动降低作业IO优先级。 2. 存储资源 数据库只读检测主要为防止出现磁盘满的问题，实现逻辑如下：cm_server开启enable_transaction_read_only情况下，每十分钟检查一次磁盘空间占用率，当 磁盘空间占用率超过阈值(默认90%)时，就通过guc参数设置数据库只读，数据库只读后只允许只读作业运行，作业发生写盘操作报错退出。但是因为数据库只读会导致用户所有业务无法运行，因此在磁盘空间占用率达到80%时会提前告警提示用户。

通过引入资源监控和控制等手段，实现资源在可控的情况下被合理利用的目的，避免出现资源的无序使用，防止数据库系统性能变慢、停止响应。资源管理可以实现以下功能： 1、通过创建和管理队列，实现队列级别资源(CPU、内存、存储空间)隔离和作业的异常处理； 2、通过设置CN和队列的并发上限，限制允许运行的并发数，超出并发数后作业排队等待唤醒，防止并发过多导致性能下降； 3、通过优先级控制实现资源的有效调度，实现高优先级作业优先运行； 4、支持多维度资源监控视图，可以监控作业、用户和实例的资源消耗。 资源管理主要包含并发控制、资源管控、资源监控以及异常作业处理。并发控制主要分为全局并发控制和资源池并发控制，其中资源池并发管控由快慢车道实现，快车道管控简单作业，慢车道管控复杂作业，支持自动识别和手动切换快慢车道，理论上快车道并发大、作业运行时间短、占用资源少；慢车道并发少、作业运行时间长，占用资源多。

1、用得随心：用户可以随时查询、使用自己想要的数据，不再因“数据隔夜”而烦恼； 2、用得开心：提供统一的数据入口和数据指标，且保持数据在数仓平台中的唯一性，用户不必担心统一数据指标在不同表单中出现不同数值的问题； 3、用得放心：对每一层数据模型的构建进行质量监控，用户不必担心数据质量问题。消除数据孤岛，链接数据与用户，共创数据智能时代在全面数字化、智能化的时代，互联网行业将产生海量的业务数据。如何将这部分数据进行高效串联，进而挖掘数据价值、盘活数据资产、实现业务创新升级，已成为企业数字化升级的共识与挑战。 作为具备分析及混合负载能力的分布式数据仓库，华为云GaussDB(DWS)基于企业级内核，提供了PB级数据分析能力和实时处理能力，能够用于数据仓库、数据集市、实时分析和实时决策等场景，支持全场景一站式分析，帮助治理数据孤岛的顽疾，解决互联网行业在数据分析时面临的系统扩展性不足、分析能力欠缺、数据集成和流转困难等诸多痛点。华为云GaussDB(DWS)让一站式分析成为现实，数据分析更加民主化，人人都能成为分析师。

华为云FusionInsight智能数据湖为兴盛优选提供了数仓底座，使用Hudi+flink来构建实时数据湖，支持电商数据的采集工作。在此基础上，针对实时分析的诉求，华为云分析了对实时性和查询响应时延要求更高的数据，并将原业务中的Clickhouse、TiDB等多个查询服务全部迁移到华为云GaussDB(DWS)上，改善了基于开源组件自建的数仓使用效果，解决了异构数据查询结果不统一的问题。 针对开源SQL引擎无法支撑复杂SQL查询的挑战，华为云GaussDB(DWS)内置多层级全并行计算引擎，为兴盛优选提供极速性能，极大地提升了分析师的工作效率。以用户七日留存数据的分析场景为例，在过去，用户在对十余张数据表单进行关联查询和分析时往往需要等待5分钟以上，现在华为云GaussDB(DWS)能够秒级反馈查询结果，大幅缩短分析等待时间。 此外，为应对业务快速增长对资源需求激增的挑战，华为云GaussDB(DWS)提供了在线扩容技术，能够做到按需进行计算、存储，且在保持业务连续性的前提下进行在线扩容。这相当于在不停车、不降速的基础上，为一列高速运行的列车平稳地增加车厢数量，使得兴盛优选无需再担心由于资源不足而导致计算失败的问题。

随着生活水平的提高和生活节奏的加快，人们在购物时除了追求物美价廉，更多地开始关注消费过程中的时间成本和便利性。在该背景下，提供“预售+自提”服务的社区团购方式应运而生。兴盛优选是推动这场社区电商浪潮的开创者之一。 近年来，兴盛优选的业务规模不断扩大，电商数据量也随之不断激增。从消费者行为分析，到营销策略分析，再到报表开发分析，兴盛优选业务分析师需要及时地分析平台上的行为数据，以此来指导产品方案和活动策略的调整。 首先，相比在实体超市购物，消费者在社区电商平台购物时有更多商品可供选择，但缺少消费参考和建议。为提升用户的购物体验，兴盛优选需要及时分析电商平台产生的业务数据，将用户的购物行为实时反馈到他们的消费习惯中去，并为用户的下一次浏览提供精准推荐服务。 其次，在推出营销活动之后，兴盛优选需要实时分析各类营销策略（如秒杀、拼团、二件折扣、优惠券等）的推广效果。当效果不明显时，平台需要灵活且及时地调整活动策略，从而降低营销活动中的无效支出，提高营销收益。 此外，为了辅助专业或非专业的数仓工作人员对各种类型的业务工作进行实时在线地分析，兴盛优选需要提供更加便捷的数据使用方式，帮助业务人员充分挖掘数据价值。 综合上述业务痛点，兴盛优选需要性能强大的大数据技术，来支撑业务增长对于数仓运营的诉求，包括应对实时分析、及时查询复杂SQL、让非专业数仓工程师能够便捷地使用数据等。

对于集群迁移来说，备份文件不仅要在本地生成，还需要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日志文件记录各个实例下的大小文件序号，分两条线保证续做的正确性。