【问题描述】集群报错：Failed to read response from Datanode. Detail: 1049 Stream closed by remote【排查过程】1.对端通信总是被断掉，每次新的socket建连成功，old connection都会被断掉2.客户反馈有一批新业务在集群上跑，必现的报stream断连3.排查系统日志和操作系统参数都没有看到异常，业务掉起的时候网络流量比较高达到2GB/s4.让用户重新调作业，发现有网络重传导致dn断连的现象，且重传过程中会阻塞业务，导致业务卡住5.联系网络侧的人正一起排查抓包，发包发不出去的时候，网络流量很低，重传也重传不成功。【问题根因】1. 已经初步定界为网络问题，出现问题场景为，业务侧50并发跑sql集，并发跑这些sql会导致网络流量很大，2. 网络流量很大之后有个网络流一直在丢包，流量的峰值能达到2GB/s，产生丢包重传之后，网络流量就下来了，在重传过程中实际的网络流量只有几十MB/s，cpu的使用率也不是很高，也配置了网卡多队列，这个网络流重传达到最高上限12次之后就会断连，导致业务侧报网络断连的错误。3. 在50并发的时候是必现的，业务并发为40的时候是可以跑过，源端的ip不固定，目的端的ip固定【解决办法】降低并发（临时）数据库应用侧暂时未发现问题，需要拉通网络侧排查，已转接网络侧排查（后续补充结果）

【问题描述】ETL执行异常，连接DN失败【问题影响】调度报错，影响后续调度执行【排查过程】日志中报错时间点大量刷comm_max_stream comm_max_stream is not enough，无法获取streamcomm_max_stream设置值为4096涉及到一个update语句，查询后发现LTS调度任务并发过高，高峰时达3000多同时任意两个dn之间使用的STREAM连接达19200+，超出参数设置4096，导致后续SQL无法执行此sql中含有77次union all【解决办法】1、业务整改调度，降低并发2、审视comm_max_stream（最大并发数据流数） 参数是否需要修改3、整改业务sql

【问题现象】：13号、14号两天出现（WS-zhihuichengshiGJ）ETCD进程异常告警【问题版本】：1.6.0【问题根因】：1、进程异常根本原因在于磁盘空间使用问题，问题出现时间点日志中显示磁盘没有空间，空闲时有空间，业务高峰期manager盘会慢2、cn实例放在了manager盘下，此盘只有100G，manager盘在业务高峰期的时候下盘空间不够，历史堆积的日志过大、存在大量状态为deleted的进程（已删除空间但未释放的进程）【解决方案】：1、清理磁盘下的log日志2、清理deleted状态的进程现场清理后，释放了磁盘10%的空间大小，待后续观察是否还会出现告警【备注】：此版本不支持扩盘，同时这个版本的cn实例的确放在manager盘下，升级也无法从根本上解决此问题

【问题描述】：几个节点cdk告警：DWS-CDK-MASTER可能原因：The size of the system log file in the /var/log/messages directory is greater than 20MB.Check whether the log file is cut and clear it in time【排查过程】：message日志归档规则是当日志大小超过10MB的时候，会自动压缩日志超过20M就会出现告警现场环境/var/log/下的messages日志大小22M，未自动压缩，导致告警，删除一个节点日志后恢复正常【问题结论】：客户现场配置80M日志会转储，待日志达到转储值，再观察是否会压缩，后续观察日志大小到达80M后，转储成功，此告警不影响业

一、问题版本线下6518二、问题背景现场更换配电箱，shutdown主机，然后上电，集群不可用三、处理过程1.查看03节点得cma、cm_monitor进程，cma进程未启动2.om_monitor日志，有kill cma得信息3.kill om_monitor，om_monitor起来后，cma进程仍然未启动4.ps ux，有cma进程5.一段时间后，cma进程启动，但集群状态仍是原样6.查看systemcall日志，报错： could not create semaphores: No space left on device......四、问题原因分析1.报错翻译：当超过最大信号量集数量（SEMMNI）或系统范围最大信号量数量（SEMMNS）的系统限制时，就会发生这种情况。您需要提升相应的内核参数。或者，通过减少PostgreSQL的max_connections来减少PostgreSQL对信号量的消耗。2.关于系统信号量原理：在PostgreSQL启动时会创建大量信号量,当PostgreSQL超出了这些限制之一时，PostgreSQL会拒绝启动并且留下一条有指导性的错误消息，其中描述了问题以及应该怎么做；本次报错信号量参数为SEMMNS和SEMMNI ，SEMMNS是系统里的最大信号量数目；参数SEMMNI 决定系统中同一时刻可以存在的信号量集合的数目限制3.查看系统信号量相关值，均为默认值4.去dn实例路径得postgresql.conf文件，查看max_connections参数值为60000，该值设置较大，导致信号量SEMMNI或SEMMNS超过了系统限制，进而导致postgressql服务无法启动五、解决措施.将max_connections参数值调整为默认5000，让postgressql服务得信号量不超过系统限制，集群变为normalgs_guc set -Z datanode -N all -I all -c "max_connections = 5000"

问题版本：dws管控面813 （管控面版本可以登录cdk查看dwscontroller服务的版本）问题现象：节点扩容后监控面板一直转圈卡住；扩容时将dms监控在监控面板的设置中关闭了；现在想打开监控；发现监控面板进不去；排查过程：1.f12查看请求；发现请求状态都是200；2.了解到最近做过扩容；将监控关闭了；现在显示的数据应该是空的3.当数据为空，f12有js报错，导致加载转圈的遮罩未能及时去除。规避方法：1.将跳转监控面板的浏览器地址栏里的地址复制；2.手动ping url 到监控面板设置页面 ； 将复制的地址dws版本后面加上setting/monitorSetting 将新地址 粘贴进浏览器地址栏 ，跳转进入监控面板设置页面，将监控打开 ，监控面板就可以加载出来了；根因分析：后台接口返回的数据为空时没有做非空判断，当数据为空，有js报错，导致加载转圈的遮罩未能及时去除。

问题现象   DWS管控面配套升级HCS803--810-软件包分发失败：上传SQL驱动与客户端失败日志详情：从日志信息看到：Failed to invoke the interfaceError occurred when create bucket.Failed to invoke the interfaceupload client tools failed:Failed to invoke the interface 问题影响     软件包分发失败，无法升级解决方法主从多region场景，升级脚本获取的uds_ip是从region的，桶dws-tool是建立在主region上的，查询桶位置会报错  修改脚本：vi  /opt/cloud/HUAWEI_CLOUD_Stack_Update/src/FusionCloudUpdate/plugins/project_585/DWS_hcsu_plugin/upgrade/dws/script/Sub_Job_SQLTools_Pkg_Distribute.py     注释掉53行，54行恢复确认     上传SQL驱动与客户端执行成功 

问题现象 新集群扩磁盘扩容失败 问题影响     磁盘扩容失败可能原因     配额不足处理思路       登录管控面rms数据库      1. 根据集群名称查询集群id          select id,status,name from rds_cluster where name = '集群名称';          记录status为200的集群id 2. 根据集群id找到报错快照的jobidselect job_id,job_def_name,begin_time,end_time,execution_status,right(server_hostname,5) as pod,fail_reason,fail_detail from taskmgr_job where request like '%集群id%' order by begin_time,job_id;3. 第三部根据jobid查看具体的快照是在哪一步骤报错select job_id,begin_time,fail_detail,fail_reason,job_def_name from taskmgr_job where job_id='backJobId' order by begin_time desc limit 100;backJobId可替换  根据fail_detail,fail_reason和job_def_name两列进行排查排查过程     根据上述fail_detail,fail_reason：volume gigabytes exceeded volume gigabytes quota!：配额不足job_def_name：diskExpandTask-fail:EVS.1042解决方法   在serviceCM修改配额

一、DWS管控面查看traceId在dws console中，按F12，在network标签下找对应请求，从headers列表中查找traceid二、DWS controller日志查看方式登录CDK master节点执行以下命令列出dwscontroller容器列表。kubectl get pods -n dws进入DWS controller容器kubectl exec -ti dwscontroller-xxx -n dws bash进入容器中，默认在logs目录下，查看ossres-dws.log, 搜索日志。三、DWS task失败日志查看方式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 '%{clusterName}%' order by job_id, task_index asc;从失败行中找到对应JobId，在controller日志中搜该jobid四、DWS 查看失败快照JobIdSelect job_id,begin_time,job_def_name from taskmgr_job where job_def_name like 'ºckup%' order by Begin_time desc limit 5;在controller日志中搜该jobidcat ossres-dws.log | grep jobid | grep ERROR

【问题描述】：查询sql，报内存临时不可用：memory is temporarily unavailable【排查过程】：查看日志，running的线程很多，有529个dn总共可用内存9G【问题根因】：并发高导致，一分钟90+并发，导致把内存打满，语句被判定为简单sql，全是select语句，执行时间都为1分钟左右【解决办法】：1. 并发降低：总并发数max_active_statements先保持不变，当前为60，共3个cn，总共180并发，可以给这个用户关联一个资源池，简单作业20并发，复杂10并发，cpu配额50%2. 语句调优：对语句执行explain performance，之后analyze语句涉及的表，对表做analyze，之后再打explain performance，对比analyze前后的执行计划，看看是否是最优。3. 调高内存 ：当前节点32G内存，dn max_process_memory 为12G，可以适当的调高 max_process_memory，由12G设置为16G（此参数需要重启集群生效）

问题现象     解绑弹性IP时页面报错：弹性ip的ID取值非法 版本信息      集群版本：1.5.201问题影响     无法解绑弹性IP可能原因      客户在vpc解绑后使得public_connect_ip_id为空，但public_connect_ip的值还在，所以页面显示未解绑，客户在页面上解绑时，需要看public_connect_ip_id不为空，所以客户无法解绑；处理思路     在报错页面点击F12，找到报错接口找到header的traceid，从dwscontroller日志按traceid搜索报错，排查问题排查过程     1. 根据traceid搜索dwscontroller日志，EIP id is invalid     2.  从接口中的Payload中看到eipId为空3. 后了解到客户之前vpc把这个eip给释放掉了，导致eipid为空4. 查看connections接口Preview，发现public_connect_ip_id为空，public-connect_ip不为空，原因找到代码截图解绑时需要判断public_connect_ip_id，展示时用public-connect_ip5.  客户在vpc解绑后使得public_connect_ip_id为空，但public_connect_ip的值还在，所以页面显示未解绑，客户在页面上解绑时，需要判断public_connect_ip_id的值，所以客户无法解绑；规避方法     通过把rds_instance的publicIp字段置空，使得参数public_connect_ip为空修改前修改后pubilcIp为NULL

版本信息1. 此方法适用于DWS的HC、HCS、HCSO形态。2. 适用版本：2021年6月30日之后DWS版本。部署及使用方法一、录入/替换巡检插件包方案一：管控面已经录入最新DWS版本，可以直接通过service_om/service_cm进行插件升级。方案二：管控面未录入最新DWS版本，可以手动更新巡检插件后，再通过service_om/service_cm进行插件升级 。1. 下载8.1.3或者之后的Instance包， 解压后得到inspect插件包。2. 将文件名更改为OBS中的inspect的文件名，并用新文件覆盖旧的inspect文件。3. 删除MySQL中的inspect插件记录。（此处为一个集群的处理方法，需要对所有集群进行操作。）3.1 获取集群id：select name, id from rds_cluster where name = '集群名称' and status = 200;3.2 获取插件信息中inspect的cpid：select a.id, a.package_name as packagename, package_type as packagetype, a. status, a.sub_type as subtype, a.update_time as updatetime, a.version, a.version_id as versionid,b.id as cpId from rds_package_info a, cluster_plugin b where a.version_id = b.pluginid and a.sub_type = 'inspect' and b.clusterid = '集群id';3.3 删除插件记录delete from cluster_plugin where id='cpId';二、插件升级1、登陆service_cm/service_om -> 插件升级2、页面上勾选内容：类型选择： inspect源版本： 不指定目标版本： x.x.x.x (新插件包版本)3、勾选集群 > 允许升级 > 勾选集群 > 升级 （这地方相当于重新安装inspect插件，覆盖掉集群中旧的inspect文件）三、集群巡检1、登陆service_cm/service_om -> 集群巡检2、填写 巡检任务名称 > 勾选 巡检集群 > 选择 巡检场景和巡检项

问题现象某国网业务主要连接GaussDB（DWS）的一个CN（cn5001），平常毫秒级的查询出现了偶发劣化到秒级的现象，在其他的CN上执行SQL语句，性能是正常的。语句的查询计划显示GATHER算子慢，需要3秒多。问题影响业务反馈SQL执行速度慢，任务产生积压cn5001上的活跃会话数不断增加，大量业务处于waiting in global queue的排队状态排查过程1. 按照GaussDB（DWS）性能问题的排查思路，查看活跃会话视图和等待视图，排查是否有明显的瓶颈点。2. 根据CN5001的进程号，通过ps命令查询进程，看CN进程是否在不断启动新的进程。找CN进程号命令为：ps -ef | grep coo通过进程PID找是否在启动进程的方法：ps -ef | grep 上一步找到的进程PID，显示进程号为23741的CN在不断启动新的进程。3. 查看该CN的pg_log日志是否有报错。CN的日志显示有too many connections for role "xxxx"的报错，并通过/opt/huawei/snas/bin/snas_cm_cmd命令来上报告警信息。解决方案将CN5001上报告警的命令/opt/huawei/snas/bin/snas_cm_cmd重命名，暂停上报告警后，验证语句的执行性能恢复正常取消对用户的连接数限制，避免频繁触发告警问题原因对用户设置了30个连接数的限制，当前该用户的连接数已达到30个，此时用户新建连接会触发报错too many connections for role "xxxx"报错会触发一个用户连接数过多的告警，这个告警通过执行/opt/huawei/snas/bin/snas_cm_cmd命令来进行上报。snas_cm_cmd命令是通过gaussdb进程通过fork新的进程的方式来调用。用户连接数过多时，告警频繁上报，进程的不断启动导致GaussDB进程的性能波动大。

一、集群版本：线下813二、处理过程1.页面显示ntp服务异常告警2.查询oms状态，ntp组件为Exception3.ntpq -np，时间偏差在正常范围内，且同步正常4.查看ha_ntp.log日志，循环报错：copy config file /etc/ntp.conf to /opt/huawei/Bigdata/tmp/ntp/ntp.conf.tmp failed5.现场反馈给813打补丁前，ntp服务正常，打了补丁后就异常6.查看变更方案，发现打补丁时少执行了一步：更换sudo脚本7.按照813产品文档，执行更换sudo脚本步骤，告警消除

问题现象     获取工作负载队列信息失败版本信息guestagent 8.2.0，内核版本低于8.1.0，管控面会报错问题版本：GaussDB A 8.0.0    guestagent 8.2.0问题影响     无法配置工作负载队列问题原因  之前做了脚本迁移，配置脚本从内核迁移到guestAgent了，导致short_acc这个参数兼容性有问题排查过程    1.  查看controller日志，发现报错信息         进入dwscontroller容器，         cd /opt/cloud/3rdComponent/tomcat/logs，找到相应时间段ossres-dws.log日志，搜索ERROR2. 通过ip找到问题节点在管控面rms数据库查询select id,name,manageIp from rds_instance where clusterId ="2b44d137-8f82-4d0e-a715-27f6d035ea35";3. 进入问题节点，进入目录cd /rds/datastore/dws/workplace/找到错误脚本gs_wlm.py 解决方法    1.  修改脚本gs_wlm.py修改前：596行删掉short_acc字段605行值改成on修改后修改后即可，无需启动其他服务2. 内核升级到8.1.0及以上也可解决本问题