背景：b集群使用互联互通能力从a集群获取数据，可通过gds服务进行可将gds起在b集群的dn6001上，通路是b集群通过dn6001上的gds访问a集群；设b集群是三节点集群，且节点网段处于165.101.102.0范围内，启动的gds使用的端口为50010。 1、 在b集群上启动gds云上集群在dn6001上沙箱内启动查询b集群对外ip，沙箱内ifconfig查询结果含多个，设查询到的对外ip为165.210.210.210，则gds可以启动为gds –p 165.210.210.210:50010 –H 0.0.0.0/0 –d /DWS/data1/gds/50010 –D –t 100 –l /DWS/data1/gds/50010/50010.log --pip-size 1M --pipe-timeout 300s查询进程，该节点gds进程启动完成后，需按此方法启动其他集群节点。补充，1个节点就可以正常提供服务，如果只使用1个gds，后续添加网段只需考虑1个即可，本文在3个节点上都启动了gds服务，故考虑到3节点的网络连通情况。 2、 打开a集群的入方向安全组，如图从b集群访问a集群，需打开a集群入方向的安全组，在集群的console界面，首页选中网络-> 网络ACL,在网络控制台中选中 访问控制->安全组选中对应集群的安全组，添加对应规则即可，规则必须包含b集群的所有节点网段选中对应安全组后->入方向规则->添加规则，按需求添加即可。举例，本文为b集群三节点网段为165.210.210.0，a集群启动的gds使用的端口为50010；则添加类型：ipv4，协议：tcp，端口范围：50010，远端：165.210.210.0/24，描述：用于gds点击确定即可 3、 添加b集群的路由b集群的三个节点的对外ip，添加到a集群的路由表中（route -n）到a集群的节点沙箱外查看route –n，查看是否添加b集群的路由（165.210.210.0）没有就添加上，本文为route add –net 165.210.210.0/24 dev bond0.1010 gw 165.210.210.1a集群所有节点都需要加上 4、 添加a集群的防火墙规则查询a集群的对外ip，进入节点，使用ifconfig查看，获取到对应的ip，假设是节点dn6001为165.110.110.110;在b集群的节点上，需要用最高权限用户（云上环境的话用户为root），添加a集群对应的防火墙规则，如以下命令Iptables –I INPUT –s 165.110.110.0/24 –p tcp –dport 50010 –j ACCEPTb集群的所有节点都需要添加，添加的内容必须为a集群的所有节点的网段，无效可尝试重启防火墙systemctl stop/start iptables，因没有持久化有些重启会规则会失效，请注意。 5、 检查添加完毕后可在a集群上尝试对b集群发起链接，观察通路是否正常。本文使用curl命令进行观察，在a集群节点上curl b集群的节点，看通路是否正常在a集群的沙箱外curl –vv http://ip:端口链接不正常有2中情况，其一是命令长时间未结束，这是因为命令未得到b集群的回应故未及时返回，其二是报错，信息为有：No route to host如果没有该报错，且出现when not allowed就表示通路已打开 

【问题现象】    页面点击重启集群后一直处于重启中状态【常见版本】全版本   【定位思路】   1、此案例适用于后台查看集群状态已经重启成功，但前台页面处于重启中。2、登录RMS库，select task.* from taskmgr_task as task left outer join taskmgr_job as job on job.job_id = task.job_id where job.request like '%集群名称%' order by job_id, task_index asc;2.1、使用查询失败的job_id去搜索dws-controller日志报错;2.2、常见报错由于网络闪断或偶现域名解析失败导致异常，其他报错具体问题具体分析。3、规避办法，登录RMS库，清理rds_action表(直接delete对应集群的失败记录)，等待集群再次上报正常状态即可。

【问题现象】    资源池监控-》资源池-》用户名称【常见版本】HCS8.2.1 或者HCS8.3.0  【定位思路】   1、首先按照问题现象点击页面，可以观察到用户名称数量与实际资源池绑定用户数量不一致2、无需定位，直接参考如下两步规避，规避前置条件是资源池必须无其他异常（能正常使用，绑定用户正常）2.1、登录DMS数据库执行SQL ：update dms_meta_collection_config set extra_settings= '{'max_collect_rate': -1}';2.2、登录serviceOM上重启dms-agent即可（手动重启需要清理agent配置文件）3、等待片刻，刷新页面即可

【问题版本】 HCS821(其他版本也适用)【问题描述】ServiceOM更新软件包报错DWS.9999【问题影响】 无【问题根因】 包未上传Swift桶里【定位过程】1、seriveOM界面更新软件包后点确认报错DWS.9999，但是点取消后，刷新界面实际已经修改成功；2、界面F12发现是insert-version接口报错报417；3、拿traceID搜日志报错请求Swift后返回404；...Request failed, Response code: 404; Request ID: xxxxxxxxxxxxxx-xxxxxxxx; Request path: https://dws-instance-{region名}.object-store.{region名}{swift域名}/8.1.3.110-GauestAgent -xxxxxxxx -xxxxxxx-2022xxxxxxxxxx.tar.gz.sha256 sun.reflect.GeneratedMethodAccess0r7421.invoke(null:-1)......Failedto save soft info. |com.huawei.hwclouds.dbs.api.platformapi.servcie.impl.ConfigManagerservicermpl.insertVersion(ConfigManagerServiceImpl.java:513)com.obs.services exception.Obsexception: Error messagu:Request Error.OBS servcie Error Message.4、在controller容器curl -kv Swift地址，发现能通；5、怀疑是桶里没包，求助Swift查询桶里是否有包，查询后确认没有包，让现场后期补全；Swift桶内包查询方法：cid:link_0上传包卡参考：cid:link_1     注：其中要获取DWS的账户和密码如下：（秘文都需要解密）     方式一、可通过select * from rds_obs_info;语句查询rms库，其中账号是op_svc_dws（不是查出来的用户，要去掉_readonly）          账号：obsUser、密码（密文）：obsUserPwd     方式二、也可COP界面CDK查询dwscontroller容器的参数：          账号：access.dns.domainName、密码（密文）：access.dns.pwd     方式三、登EICommon-Region-Master-01节点，进容器/webapps/rds/WEB-INF/classes目录下查询参数：     执行：grep "access.dns" system-parameter.properties命令查询出如下：          access.dns.domainName=账号          access.dns.pwd=密码密文6、补全包后界面不在报错；【规避措施】    上传Swift的包不全，重新把缺失的包上传Swift

企业部署的Gaussdb(DWS)如何配置MRS数据源，找不到关于Manage界面找不到配置数据源的信息。

说说你对DeepSeek大模型的看法

内存管控cid:link_0主备从HA技术cid:link_1日志分叉与脑裂cid:link_2数据可靠性cid:link_3PLSQL语言cid:link_4游标cid:link_5一键式锁等待cid:link_6智能监控系统告警cid:link_7监控指标采集cid:link_8负载管理cid:link_9query band负载识别cid:link_10资源池队列阻塞告警在DMS中的实现cid:link_11队列阻塞告警的实现cid:link_12SysCache原理cid:link_13SysCache对外接口https://bbs.huaweicloud.com/forum/thread-0225175602406337039-1-1.html

SysCache对外接口主要包括两个： 查询SysCache和释放SysCache，这两个方法需要配对使用，在SysCache返回查询结果后，需要再次调用释放SysCache接口，以释放SysCache相关数据。 在查询SysCache前，需要确保CatCache初始化，之后，需要依据查询的key信息计算哈希值，以定位哈希桶位置。对于SysCache而言，数据的key最多为4个，在上述例子中，key1=public，key2=abc，key3和key4将以0进行补全。 计算哈希值之后，将扫描对应哈希桶中的双向链表，逐个进行匹配，若未匹配到，将进一步扫描该系统表的数据页。若数据页中也没有该数据，则说明不存在该数据，需要建立一个假的CatCTup，并标记为negative，以提升查询miss效率，若数据页中包含该数据，则将该条数据进行封装，建立CatCTup，并插入到对应的哈希桶中。 在匹配到CatCTup后，需要将当前CatCTup的引用数量refcount加一，并进行返回，refcount的作用是计数引用，以防止被错误释放。 对于释放SysCache，其主要步骤是将引用数量refcount减一，并释放refcount为0的资源。

GaussDB(DWS)在处理用户查询请求过程中，会频繁访问表相关元数据，那么如何在不损失性能的前提下快速访问表元数据呢？答案是建立Cache。DWS在针对系统表数据和表定义分别建立了两套不同的Cache体系，SysCache主要针对系统表，对系统表中访问频繁的记录进行缓存，以达到性能提升的目的；RelCache主要针对表定义，包括所有用户表和系统表进行缓存。虽然简单执行了一条insert语句，其中涉及到的解析、校验逻辑是异常复杂的，会关联大量系统表相关查询操作。为了加快系统表查询速率，GaussDB(DWS)中针对系统表查询操作构建了SysCache缓存，以加速系统表查询速率。在上述例子中，语句b)在执行时，会访问相关系统表元数据，并通过SysCache进行缓存，之后在语句c)和语句d)执行时，直接从SysCache获取相应的缓存信息，以加速执行效率。SysCache在内存中以指针数组的形式进行存储，数组中每个元素均为一个CatCache结构体，CatCache中存储了系统表中的元数据信息。在CatCache中可能存在大量被缓存的数据，为加速查找，CatCache中设计了哈希数组，哈希数组包含多个哈希桶，每个哈希桶中记录了元数据链表信息，最终元数据是以双向链表的形式存于哈希桶中的。

资源池队列阻塞告警是基于DMS原有告警功能进行实现，实现流程依旧是分为数据上报与采集—>告警判断—>上报告警。信息采集线程会将资源池中任务的状态实时上报，形成原始指标落盘，然而我们需要判断不同优先级的任务排队情况，直接用原始数据进行处理会比较繁琐，所以我们借助一个定时任务，定时采集原始指标数据，并进行整合、转置，最后我们用整合后的数据，判断是否发生了资源池阻塞。 如果用户设置的资源池并发数过小，会出现资源池队列排队，此时应当调大资源池并发数量。 资源池通过绑定控制组进行实现资源的分配，作业的优先级和其关联的资源池的资源数量有关。一般情况下，我们认为作业关联到的资源池拥有的资源数量越多，则其优先级越高，因为该作业能够拥有更多的资源去执行。如果一个资源池拥有的资源比例发生了变化，则其对应的优先级也会发生变化，可以通过调整资源池中属性来修改优先级。 在开启资源负载管理功能之后，default_pool是由系统自动创建，当一个会话或者用户没有指定关联的资源池时，都会被默认关联到default_pool，并且default_pool默认绑定到DefaultClass:Medium控制组，并且不限制所关联的业务并发数，而且一个控制组可以绑定多个资源池。

影响作业在资源池运行的要素有并发数、CPU和内存等资源限制，也可能是由于集群状态异常导致的，下面我们将从以下两种情况进行分析。 第一种情况，如果并发或CPU等资源不够用，会出现资源池队列排队，但并非阻塞的状态，因为作业结束后，处于队首的作业会开始运行，那么资源池队列中的作业是动态变化的。 第二种情况，如果用户下发的作业就是特别的复杂，运行时间可能有几十分钟，那么在默认情况下，资源池队列中的作业始终不变，但是如果用户在调整作业优先级之后，作业能够正常运行，也不能说明资源池是阻塞的。 结合以上两种情况，我们结合资源池队列中作业的状态，以及不同优先级作业在资源池的运行情况判断资源池是否阻塞。首先我们将范围限定在默认资源池中，因为默认资源池是开启资源管理功能后又系统创建，代表系统的状态；其次资源池执行任务异常，必定引起资源池队列出现排队现象，且处于队首的任务始终不变，排队时间增加；并且运行在资源池上所有优先级的作业都不能正常下发。 总结下来就是，在一定时间内，集群默认资源池队列中处于各个优先级的作业不变即可判定为资源池队列发生阻塞。

当一个控制组关联的资源池有多个的时候，用户下发的作业应该使用哪个资源池来执行任务呢？如果用户已经下发了很多作业，但是某个新作业又非常紧急怎么办？类似的问题可能还有很多，那么如何解决上述的问题呢，这时候我们就要借助一个手段：query band。 GaussDB(DWS)实现基于query band的负载识别和队列内优先级控制，一方面提供了更为灵活的负载识别手段，可根据作业类型、应用名称、脚本名称等识别负载队列，使用户根据业务场景可灵活配置query band识别队列；另一方面实现了队列内作业下发优先级控制。管理员用户可根据业务场景及作业类别配置query_band所关联队列及估算内存限制等实现更为灵活的负载控制与资源管控。 query_band支持关联作业优先级，支持高中低(High/Medium/Low)三个优先级，同时提供Rush作为特殊优先级，默认优先级为Medium。 如果业务未配置query band或用户未将query band关联行为时，作业会默认使用用户关联队列和队列内优先级。 从上述的介绍可以理解为，query band可以设置任务在资源池中的执行顺序，优先级高的任务优先执行；如果出现资源不足等不能立刻执行任务的情况，则会触发排队优先级，优先级高的优先在队列中排队。

DWS的负载管理分为两层，第一层为CN的全局并发控制，第二层为资源池级别的并发控制。在通过第一层控制的时候，会继续向前走到第二层资源池控制，根据资源池当前的负载资源情况决定作业继续执行或者排队。影响一个集群的资源包括内存、CPU、磁盘I/O和存储空间等。GaussDB(DWS)提供了一系列资源负载管理手段，通过对资源的集中管控，可以有效避免作业占用资源的冲突，高优先级作业优先执行，以及用户间的资源隔离。负载管理是为了解决排队的问题，将任务能够平均到不同的cn或资源池上；然而在实际应用中，作业是否排队与资源池的资源有着直接关系；资源管理通过一定手段提高资源的利用率。

监控数据库，必须要对数据库各指标数据进行采集，通过合理的统计查询，获得实时或周期性的数据库和集群的状态，结合告警策略触发告警。修改绑定集群可以设置次告警规则适用的集群范围，默认为全部，可多选。修改阈值可以调整触发告警的上限或下限，每种指标默认提供了阈值范围，可按照页面提示和实际情况进行合理修改。修改持续周期，可以拉长或缩短指标数据的查询范围，检测的是长周期的指标变化趋势，还是某时刻的指标异常变化。修改抑制条件可以控制告警的发送频率，处于抑制期的告警不会重复发送。DMS告警框架还在建设当中，后续还会提供更多的监控指标，支持多种策略配置方式，告警框架后续也会与系统的功能模块联动起来，让监控系统更“智能”。

告警功能是各大云平台必不可少的模块，个性化的告警配置，为帮助用户和运维人员及时发现问题发挥着重要作用。 数据库智能监控系统（简称DMS）告警框架（以下简称告警框架）用于监控数据仓库的集群信息，且基于8.1.1以上版本的集群进行开发，如果您的集群版本低于8.1.1或没有安装DMS，则不能适用此告警功能。 告警功能是结合产品自身需求、业务需求、客户需求独立进行设计与开发，为了能够让用户更快速的熟悉和使用此功能，告警功能在设计之初也参照了其他平台的使用方式、相关概念，并结合自身情况进行调整，完成了初版的设计与开发。 在说具体实现之前，先了解下告警框架中涉及的相关概念。 告警指标：告警指标是实际监控的内容，如：CPU使用率、磁盘使用率、IO等。 告警策略：告警策略是触发告警的最小单元，每一条策略针对一种告警指标。告警策略分为阈值策略、状态策略等。 告警规则：告警规则是实际监测（任务调度）的最小单元，是告警策略的集合。告警规则包含自默认规则和自定义规则。 默认告警规则：默认规则是系统提供的基础告警项，用户只需根据业务简单的配置，即可收到告警信息。 自定义告警规则：当默认告警规则不能满足实际需求时，用户可根据自己的实际需求创建自定义告警规则。 规则、告警策略、告警指标三者关系：一个告警规则（默认/自定义）可包含多个告警策略，并且规则中的策略存在不同关系。