【版本信息】不涉及【问题现象】数据库端CN有频繁报warning，不能够从客户端收到数据，不完整的数据包。can not receive data from client, incomplete package【问题根因】ELB配置健康检查，要连接数据库IP和端口，监测端口服务在线，就马上断开连接，不发送后续的认证请求。【问题影响】ELB健康检查导致的数据库后端每10s一次的warning，属于正常现场，不会造成可感知的压力。

版本信息：不涉及问题描述：执行正则表达式报错：invalid regular expression: invalid repetition count(s)，示例：postgres=# select regexp_like('123','^(?=.*[0-9])(?=.*[a-zA-Z])([a-zA-Z0-9]{255})$'); regexp_like ------------- f(1 row)postgres=# postgres=# select regexp_like('123','^(?=.*[0-9])(?=.*[a-zA-Z])([a-zA-Z0-9]{256})$');ERROR: invalid regular expression: invalid repetition count(s)CONTEXT: SQL function "regexp_like" statement 1referenced column: regexp_like问题原因：因为在DWS中，正则表达式a{n}中，n的范围不能超过255，超过255后会报上述错误解决方法：该报错是由于产品规格导致，需要改写正则匹配逻辑解决，保证n的范围在255以内。

【问题版本】 管控面升级811->821 【问题描述】 DWS秘钥挂载至CDK失败/ECF秘钥挂载至CDK失败 【问题影响】 无 【问题根因】 cdk接口问题，查询分页，代码limit=10，修改为100 【定位过程】 问题根因：     国网region多，有30个iam账号，一般别的局点没有这么多region，iam账号不超10个，也就不会出现； 规避措施： 1、登到HCC Turkey工具后台节点； 2、vi /opt/cloud/hcci/src/HCCI/solution_driver/hcs/v8_2_0/utils/business/CDK/cdk_api_common.py 3、在cdk_api_common.py里搜索get_iam_config方法； 4、在url里把limit=10修改为limit=100，然后保存；如下：     url = '/api/v2/cdk/user-center/iam-aggregation?limit=10&offset=0&sortBy=CREATED_TIME&order=desc'     改成：url = '/api/v2/cdk/user-center/iam-aggregation?limit=100&offset=0&sortBy=CREATED_TIME&order=desc' 5、最后执行sh /opt/rootscripts/restart.sh命令重启框架后，界面重试工步通过；

【问题版本】 811升级820 【问题描述】 管控面升级ECF组件服务工步跑失败 【定位过程】 问题的每个排查方向的排查结果 1、DWS db升级工步失败，查看是超时900秒，重试工步后成功； 工步详情：     "1859350,升级DWS Controller MySQL失败，错误信息：HCCI125003，执行sshcmd失败；     IP：XX.XX.XX.XX，在设定超时时间900秒内未获取到期待的返回值；实际返回值为：" 2、ECF组件服务升级工步失败，登EICommon-Region-Master节点发现ECF组件服务容器状态异常；     登录ECF-Region-Node节点查看haveged服务没有起来，手动restart失败，熵值太低；     cat /proc/sys/kernel/random/entropy_avail 查看熵值太低，     systemctl status haveged.service 查看haveged     systemctl restart haveged.service 重启haveged     解决方案(1、2任选其一即可)：         1）删除/usr/local/lib/libhavege.so.1         2）删除/etc/ld.so.conf中的/usr/local/lib，然后执行ldconfig         3）重启haveged 3、登EICommon-Region-Master，ECF组件服务容器状态异常，还是拉不起来；     去CDK界面查看Region-Node有一个节点的标签被改了，改回ecf后去重启容器，容器重启成功，应该是资源抢占不到导致；     最后重试工步成功，升级成功；

1.逻辑备份失败，master节点agent日志显示No matching tables were found. Failed to dump ddl table info to master.2.找到对应的表为scheduler.pg_task, 手动执行gs_dump也报同样的错误3.确认为系统表，备份以及gs_dump命令不支持系统表

注：此方法仅适用于813及以上版本，以下版本需手动清理 步骤一：将集群内白名单改为trust gs_guc set -Z coordinator -Z datanode -N all -I all -h "local all all trust"步骤二：任意集群内节点，沙箱内执行 gs_ssh -c "python3 $GPHOME/script/local/LocalRoach.py -t cbm_recycle --backup-key 20230421_162811 --cbm-recycle-level 1 --metaPath /DWS/backup/metadata --env '/home/Ruby/.bashrc' -U Ruby -l /home/Ruby/recycle_backup01.log --task-type 0" >> /home/Ruby/recycle.log 2>&11、参数说明： --backup-key 备份集 --metaPath 备份的metadata --env 云上环境变量默认值：/home/Ruby/.bashrc 2、执行结果查看，执行节点查看以下日志 /home/Ruby/recycle.log统计执行正确节点：cat /home/Ruby/recycle.log |grep 'SUCCESS' |wc -l 统计执行异常节点：cat /home/Ruby/recycle.log |grep 'FAILURE' |wc -l 查看异常节点信息：cat /home/Ruby/recycle.log |grep -A 15 'FAILURE'步骤三：恢复集群内白名单为sha256 gs_guc set -Z coordinator -Z datanode -N all -I all -h "local all all sha256"

【问题版本】 dws8113 【问题描述】 告警语句堆积数量超阈值 【问题影响】 无 【问题根因】 阈值设置低 【规避措施】 阈值调高 【定位过程】     OC告警语句堆积数量实际超过默认阈值10，需要调大阈值，防止上报告警； 告警详情信息：     告警ID：DWS_2000000017_1_OM；     告警源：DWS_cn_xxx_1；     定位信息：cluster_id:xx-xx-xx-xx,cluster_name:XXXXX；     附加信息：CloudSerice=DWS,resourceId:xx-xx-xx-xxresourceIdName:XXXXX;         first_alarm_time:2023-09-13 16:14:22;10分钟内，堆积的查询语句数量平平均值为12.00，超过阈值10； 1、运维侧的告警语句堆积数量超阈值需要到serviceCM上改;     ServiceOM界面：服务列表-->数据仓库服务-->监控告警-->告警管理-->告警规则配置-->选 查询语句堆积数量超阈值-->修改；     console界面：数据仓库服务-->告警管理-->告警规则管理-->选 DWS_2000000017（查询语句堆积数量超阈值）规则-->修改； 2、后台规避措施：登后台DMS数据库改成50，观察一天看是否上报告警；     gsql -p 8635 -W XXXXXXXX -U dbadmin -d dms     select * from dms_meta_cluster_alarm_config_map where rule_id like 'DWS_2000000017%';     update dms_meta_cluster_alarm_config_map set threshold_value = 50 where rule_id like 'DWS_2000000017%';

【问题版本】 812->813.110 【问题描述】 集群升级失败报memory is temporarily unavailable 【问题影响】 影响升级 【问题根因】 数据库删除有残留，未删干净，元数据不一致 【定位过程】  1、nedw-test集群升级失败serviceOM数仓服务升级管理任务报EU030；     Error:{'errorCode':'EU030','errorWsg':Failed to doOnline upgrade and failed to do rollback of Online upgrade.'} 登CN节点查看gs_local日志报内存不足memory is temporarily unavailable、死锁问题；     ERROR: cn_5004:deadlock detected     ERROR: dn_6083_6084:memory is temporarily unavailable 2、登postgres库查询work_mem参数为2GB；show work_mem; gsql命令调整为4GB后重试升级；    gs_guc reload -Z coordinator -Z datanode -N all -I all -c "work_mem=4GB" 3、重试升级级失败，还是报的内存不足； 查询shared_buffers参数为2GB：show shared_buffers 查询CN_5001和报错日志的dn_6083_6084节点的内存pv_total_memory_detail值；     select * from pv_total_memory_detail; 4、重试失败，查gs_upgradectl和gs_local日志，发现有一个citic_nedw_lcyw数据库升级失败；     [FAILURE]host-11-0-0-XX     Rolling back catalog.     Failed to upgrade citic_nedw_lcyw catalog,ret_queue is -1. 5、一线说之前可能删过，找业务确认该数据库是否可以删除，确认是之前删除没有删干净；需删除后重试； 6、删不掉，调整upgrade_mode=0，后删除drop citic_nedw_lcyw ，一个小时后删除成功；     drop citic_nedw_lcyw;     ERROR:The database cannot be dropped during the database upgrade     gs_guc reload -Z coordinator -Z datanode -N all -I all -c "upgrade_mode=0";     drop citic_nedw_lcyw; 7、删除后把upgrade_mode改回原来的2，重试升级；     gs_guc reload -Z coordinator -Z datanode -N all -I all -c "upgrade_mode=2" 8、升级时间过长，判断是tmp文件下gauss开头的文件太多导致（排查每个CN节点），删除8月份前的文件后升级变快，最后升级成功； 统计命令：(/tmp/下执行)     ls -Rf wc -l 删除命令：（沙箱内执行）     find /tmp/ -name "gauss_*_2021-*" xargs -n 1000 rm -rf     find /tmp/ -name "gauss_*_2022-*" xargs -n 1000 rm -rf     find /tmp/ -name "gauss_*_2023-01-*" xargs -n 1000 rm -rf     find /tmp/ -name "gauss_*_2023-02-*" xargs -n 1000 rm -rf     find /tmp/ -name "gauss_*_2023-03-*" xargs -n 1000 rm -rf     find /tmp/ -name "gauss_*_2023-04-*" xargs -n 1000 rm -rf     find /tmp/ -name "gauss_*_2023-05-*" xargs -n 1000 rm -rf     find /tmp/ -name "gauss_*_2023-06-*" xargs -n 1000 rm -rf     find /tmp/ -name "gauss_*_2023-07-*" xargs -n 1000 rm -rf     find /tmp/ -name "gauss_*_2023-08-*" xargs -n 1000 rm -rf

1.排查cpu低，io低，topsql语句报错An I/O error occured while sending to the backend2.排查脏页率，发现部分系统表和业务表脏页率到99％，建议清理3.连接到客户端，数据堆积过多；排查CN日志，有大量的主键冲突；提醒客户端解决主键冲突后，问题解决

【规避方法】in 后面的条件默认就只能是5个,超过6个就过滤不下推在820版本之前,默认为5个,且不可修改.820版本之后,可以修改最大个数-- 谓词不下推的算子 3-4s6 --Partitioned CStore Scan on dmmds_mdr_dta.rit_cr030607_a001 aFilter: ((a.tim_cod = ANY ('{M,Y}'::bpchar[])) AND ((a.spp_cod)::text = 'BOD'::text) AND ((a.spp_val)::text = 'BOD'::text) AND (a.are_cod = 'A'::bpchar) AND ((a.drv_src)::text = 'SET:02'::text) AND ((a.chl_cod)::text = 'A'::text) AND (a.row_seq = ANY ('{1,10,19,28}'::integer[])) AND (a.tpp_val = ANY ('{2023-09-19,2023-08-19,2022-09-19,2022-08-31,2022-09-30,2022-03-19}'::date[])))Rows Removed by Filter: 484387263Pushdown Predicate Filter: (((a.tim_cod = 'M'::bpchar) OR (a.tim_cod = 'Y'::bpchar)) AND ((a.spp_cod)::text = 'BOD'::text) AND ((a.spp_val)::text = 'BOD'::text) AND (a.are_cod = 'A'::bpchar) AND ((a.drv_src)::text = 'SET:02'::text) AND ((a.chl_cod)::text = 'A'::text) AND ((a.row_seq = 1) OR (a.row_seq = 10) OR (a.row_seq = 19) OR (a.row_seq = 28)))- 谓词下推的算子 0.4s6 --Partitioned CStore Scan on dmmds_mdr_dta.rit_cr030607_a001 aFilter: ((a.tim_cod = ANY ('{M,Y}'::bpchar[])) AND ((a.spp_cod)::text = 'BOD'::text) AND ((a.spp_val)::text = 'BOD'::text) AND (a.are_cod = 'A'::bpchar) AND ((a.drv_src)::text = 'SET:02'::text) AND ((a.chl_cod)::text = 'A'::text) AND (a.row_seq = ANY ('{1,10,19,28}'::integer[])) AND (a.tpp_val = ANY ('{2023-09-19,2023-08-19,2022-09-19,2022-08-31,2022-09-30}'::date[])))Rows Removed by Filter: 479328840Pushdown Predicate Filter: (((a.tim_cod = 'M'::bpchar) OR (a.tim_cod = 'Y'::bpchar)) AND ((a.spp_cod)::text = 'BOD'::text) AND ((a.spp_val)::text = 'BOD'::text) AND (a.are_cod = 'A'::bpchar) AND ((a.drv_src)::text = 'SET:02'::text) AND ((a.chl_cod)::text = 'A'::text) AND ((a.row_seq = 1) OR (a.row_seq = 10) OR (a.row_seq = 19) OR (a.row_seq = 28)) AND ((a.tpp_val = '2023-09-19'::date) OR (a.tpp_val = '2023-08-19'::date) OR (a.tpp_val = '2022-09-19'::date) OR (a.tpp_val = '2022-08-31'::date) OR (a.tpp_val = '2022-09-30'::date)))

一、问题现象DWS访问集群内的普通表速率正常，访问hdfs集群的外表速率慢，慢的程度limit 1时间min起步，最后也能出结果，就是慢，无报错；二、问题排查1、检查hdfs集群访问；这里主要检查DWS集群节点访问HDFS集群是否互通；2、外部server配置正常；不光检查DWS集群，实际也要看HDFS文件等；3、外表创建正常；外表是否指定正确的server;4、以上检查都正常，检查配置正确的“错误域名”，1.1.1.1实际这个地址不通的，将域名和错误地址配置，意思让跳过域名访问，默认DWS访问HDFS使用IP连接，而不是域名，发现已配置：cat /etc/hosts1.1.1.1 hadoop.hadoop.com这里1.1.1.1固定，hadoop.hadoop.com把hadoop集群的域名都添加到这，按实际情况来；5、检查server缓存；每个DN路径下，如下文件，就是DN和hdfs的datanode交互时的缓存文件；md508a869c15082653caa1db1da2877dcc改文件属于二进制文件，可使用strings命令查看三、问题原因缓存未刷新。当遇到配置发生变化时，需要重新集群或者刷新配置，如果没有做，就会遇到访问慢的问题，而且这里慢，是部分外表访问慢。ALTER SERVER server_name REFRESH OPTIONS;四、解决方案ALTER SERVER server_name REFRESH OPTIONS;刷新HDFS配置文件。仅8.0.0.10及以上版本支持(8.1.0除外)。五、其他如果遇到刷新配置解决不了的慢，而且无报错，可以打印访问外表的等待视图，看在那个DN上发起访问外表，去对应DN上打印堆栈，实例：gstack $lwtid可以进一步定位，已知的访问慢，有可能是域名问题；

1、背景某局点用户查询表某字段发现都是科学计数法的形式，并且此字段经round函数处理之后全是0，怀疑是显示问题2、分析经过（1）通过查询表结构是double precision双精度类型不是科学计数法类型（2）该字段可以通过科学计数法的方式赋值（3）也可以正常赋值（4）由上图可以发现当赋值一个0.00000000154的值显示依旧是科学计数法，即当我们赋值一个10的负数次方的值时显示的就是科学计数法，正常现象。round函数返回的时离输入参数最近的整数，结果正确没有问题3、double precision类型对10的负数次方的值是以科学计数法显示的不影响计算

1、背景变更前参数校验失败：DWS_params_check参数校验失败2、解决过程经沟通发现，可以正常登录节点，因为密码有过更新，参数配置没有更新所以报错。3、总结经验要对局点相关参数的变更有关注，及时更新参数配置

一、问题背景DN实例状态显示异常二、问题排查1、排查DN日志，无明显报错信息，DN日志路径cd $GAUSSLOG/pg_log/dn_6017/2、排查cm_agent日志无明显异常，cm_agent日志路径cd $GAUSSLOG/cm/cm_agent/3、排查system_call日志，发现如下报错：2023-09-19 11:21:37.331 650913c1.10000 [unknown] [unknown] 140455595393344 [unknown] 0 dn_6017_6018 42601 0 [GUC] LOG: missing keywords "on" or "off"2023-09-19 11:21:37.331 650913c1.10000 [unknown] [unknown] 140455595393344 [unknown] 0 dn_6017_6018 42601 0 [GUC] DETAIL: Must begin with keyword "on" or "off".2023-09-19 11:21:37.334 650913c1.10000 [unknown] [unknown] 140455595393344 [unknown] 0 dn_6017_6018 F0000 0 [BACKEND] FATAL: configuration file "/data1/mppdb/slave2/postgresql.conf" contains errors确定是DN实例参数修改错误导致；三、问题原因logging_module参数修改非法导致，请检查DN实例参数配置文件：四、解决方案“功能参数只能在on() -> off() 括号内移动”，括号内！括号内！括号内！现网配置一般改错都是因为这样的错误修改，错误示例如下，功能我选了一部分：错误示例：gs_guc reload -Z datanode -N redhat-1 -I dn_6017_6018 -c "logging_module = 'ALL,on(HDFS,ORC),off(SLRU,MEM_CTL,AUTOVAC,ANALYZE,CACHE,ADI)'"修正方式可以选择单DN修复，正确示例：gs_guc reload -Z datanode -N redhat-1 -I dn_6017_6018 -c "logging_module = 'on(HDFS,ORC)'"gs_guc reload -Z datanode -N redhat-1 -I dn_6017_6018 -c "logging_module = 'off(HDFS,ORC)'"gs_guc reload -Z datanode -N redhat-1 -I dn_6017_6018 -c "logging_module = 'on(all)'"gs_guc reload -Z datanode -N redhat-1 -I dn_6017_6018 -c "logging_module = 'off(all)'"修正方式可以选择整集群修复，正确示例：gs_guc reload -Z datanode -N all -I all -c "logging_module = 'on(all)'"gs_guc reload -Z datanode -N all -I all -c "logging_module = 'off(all)'"最简单的修改方式，就是全关。gs_guc用法，可通过gs_guc --help自行了解。影响：无影响，不会对DN实例运行日志有任何影响，这些参数一般默认关闭为功能模块深入分析时才会用到。五、其他场景使用gs_guc修改参数analysis_options和logging_module，极容易引起集群不可用，因实例发生重启后重新读取配置文件，导致集群不可用；

通常一些连接突然中断等问题，经过排查均未发现DWS有异常行为导致，则有概率为网络问题导致的上层应用受影响，下面提供几种网络排查手段供定界网络问题；排查到网络问题后，可根据局点情况协调网络同事，裸机网关，交换机等协助分析1. gsar.sh【存放位置】一般在 $GAUSSHOME/bin/dfx_tool 目录下【功能】对指定网卡流量重传丢包等指标监控【参数】1.网卡名（图中 eno2）：指定检测的网卡名称，可使用ifconfig命令查找到ip对应的网卡2.监控时间（图中 5）：gsar每一秒执行一次，该参数缺省则不停止【结果说明】time：系统时间，每一秒打印一次；recv_kbyte：接收流量大小（老版本为byte）；recv_pkg：接收包数量；ave_len：接收包平均长度（单位byte）；recv_drop：接收丢包数量；drop_per：丢包率；send_kbyte：发送流量大小（老版本为byte）；send_pkg：发送包数量；ave_len：发送包平均长度（单位byte）；tcp_send：tcp发包数量；timeouts：TCP协议超时重传量；fasts：TCP协议快速重传量；resend：tcp重传包数量；resend_per：tcp重传率；【结果应用】recv_kbyte/send_kbyte：接收/发送流量接近网卡上限，网络存在瓶颈；drop_per/resend_per：丢包/重传率超过0.05%，网络链路问题；ave_len：包长过大（通常小于1500），网卡参数排查；2.netstatnetstat最后一列括号中第二个数字表示重传次数，次数稳定不为0，判断网络有异常，一般gsar排查发现重传超过0.05%后，可补充netstat同步验证常用命令：长时间监控：while true;do date;netstat -anop|grep "on ("|grep -v "/0/0"|sort -rnk3|head;echo;sleep 5;done查网络报错：while true;do date;netstat -s|grep -iE 'drop|error';sleep 1;echo;done查tcp重传：watch -n 1 "netstat -anpto | grep ESTA | grep -v '0/0)' | grep 'on (' |head"linux原生命令，检查网络丢包：while true;do date;netstat -ano|grep 'on ('|sort -rnk3|head;sleep 1;echo;done3.ping虚拟机远程连接等，确认对端ip后，也可直接长ping，查看是否有丢包