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，查看是否有丢包

检查集群状态cm_ctl query -Cvd重新拉起失败检查cms日志发现报错 could not connect to server无法连接到对端cms检查端口发现对端cms服务器上的25303端口被占用杀掉所有占用的进程，cms之间建立连接，cms状态恢复。

xlog堆积，磁盘即将只读连接xlog堆积实例，检查堆积实例的复制槽select * from pg_get_replication_slots();发现复制槽中存在gs_roach_common，且不存在备份任务应急方案：1.首先再次手动停止备份任务：python3 $GPHOME/script/GaussRoach.py -t stop -F2.再次检查复制槽3.如果复制槽依旧存在gs_roach_common，则检查所有节点roach进程gs_ssh -c 'ps -ef | grep -i roach | grep -v grep'4.如果确定不存在roach进程，则连接xlog堆积实例set application_name='gs_roach';select pg_drop_replication_slot('gs_roach_common');  5.检查复制槽，如果gs_roach_common不存在执行以下命令进行redo：checkpoint;如果依旧不存在，或xlog依旧未回收，请联系华为工程师

【问题现象】在线扩容，界面报 DWS.9999，无法继续【解决方案】  因为有风险评估没有完成 评估代码报错，在界面使用离线扩容跳过该过程

Child processes exit and exit status is:15子进程使用kill命令把这些进程杀死之后默认返回的就是15状态码应该是kill之后返回143，status的低16位的高8位保存子进程的返回值，如果我们想要获取子进程的返回值，就是说要获取低16位的高八位，导致状态码变成15，正常机制详情参见：cid:link_0这个是子进程收到了kill信号，导致退出。可以检查定时任务等，检查查杀记录。

查看日志发现被远端关闭报错Stream closed by remote检查日志中的远端，日志显示SQL语句报错could not poll socket:Interrupted system call 导致执行失败2、LibcommPollWait中每隔9秒调用一次CheckClientConnectionStatus->PqCheckConnection检查与客户端连接是否正常PqCheckConnection中调用poll对客户端连接的socket进行有效性检查，如果poll过程中刚好被信号打断，就会报错could not poll socket: Interrupted system call3、客户返回结果集1200w，属于较大的结果集，在吐数据时会造成CN线程堵住，变得卡顿，导致poll过程时间拉长，容易被打断，触发概率上升，此次报错触发打断过程，属于新版本特性引入BUG，820,821均可能出现此问题4、client_connection_check_interval设置为0后，已经进行临时规避

问题现象：       重分布失败，重分布进程退出，重分布状态未变为no原因分析：1.查看重分布状态：cm_ctl query -Cv2.查看哪些表没有完成重分布1）、 找到老的nodegroup名称old_group_nameselect group_name from pgxc_group where in_redistribution='y';2）、 分别连接每个database统计各个database下未重分布的表数量select count(*) from pgxc_class where pgroup='old_group_name';3）、 如果想知道具体未重分布的表名称，可换成如下sql：select pcrelid::regclass from pgxc_class where pgroup='old_group_name';3.查看重分布日志   1）登录cn-1-1进入到沙箱内 ssh ·hostname -i·  2）查看最新的日志：cd $GAUSSLOG/bin/gs_redis/gs_redisxxx      grep 表名 gs_redisxxx 查看报错，有报锁超时解决方法：      界面重试重分布

【问题现象】       界面显示升级dbsmonitor，ecf-clustermanager容器工步工步失败，报资源不足【问题版本】        升级到HCS811【问题根因】       cdk集群node节点资源不足之ecf命名空间资源不足【原因分析】 1.界面显示升级dbsmonitor，ecf-clustermanager失败，资源不足2.查看标签为ecf的node资源上有mrs的pod3.了解到mrs有一个服务mrszookeeper，没有删除升级导致残留在ecf标签的node到，新版本HCS811node受标签影响导致ecf的服务获取pod资源不足，导致失败4.下线mrs的服务mrszookeeper，界面重试升级通过【处理方法】         与mrs沟通下线mrszookeeper服务，下线完成后，界面重试失败的服务通过

【问题现象】 点击升级，弹出 DWS.9015 升级任务下发失败【解决方案】查看空闲节点是否有失败记录，有责删除，重试升级

问题现象：重启集群，一个节点上的进程均启动失败问题分析：登录对应节点查看om_monitor进程没有正常拉起解决方案：1.crontab -l 查看定时拉起命令，手动拉起2.查看定时脚本问题，历史问题时 定时脚本人为导致语法错误

问题现象：集群1.7.2版本升级813.322失败过程中升级到8.1.1.500后卡住解决措施：1 8.0升级811.500后cn5002卡住，无法提交也无法回滚2 后台紧急应急：登录cn5002节点后台，kill cn后自动回滚，继续完成升级

问题现象：低版本8.1.1的agent升级到8.2.1.310导致agent引用内核的python版本，升级失败unable to import module解决方法：# 租户侧规避方案sourceVersion=v8.2.1.1_59b8d48a_4a6b6a0ctargetVersion=v8.2.1.310_06c3fedd_307d3b1acd / && find /rds -name *.pyxargs chattr -i && cd -cp -rf /rds/mgntAgent/version /rds/mgntAgent/version_bak_0830cp -rf /rds/datastore/dws/version /rds/datastore/dws/version_bak_0830cp -rf /var/spool/cron/root /home/Ruby/root_bak_0830cp -rf /etc/sudoers /etc/sudoers_bak_0830cp -rf /var/spool/cron/Ruby /home/Ruby/Ruby_bak_0830sed -i "s#$targetVersion#$sourceVersion#g" /rds/mgntAgent/version /rds/datastore/dws/version /var/spool/cron/root /etc/sudoers /var/spool/cron/Rubyrm /rds/mgntAgent/workplace -rfln -sfn /rds/mgntAgent/$sourceVersion /rds/mgntAgent/workplacerm /rds/datastore/dws/workplace -rfln -sfn /rds/datastore/dws/$sourceVersion /rds/datastore/dws/workplace# 租户侧还原方案sourceVersion=v8.2.1.310_06c3fedd_307d3b1atargetVersion=v8.2.1.1_59b8d48a_4a6b6a0ccd / && find /rds -name *.pyxargs chattr -i && cd -sed -i "s#$targetVersion#$sourceVersion#g" /rds/mgntAgent/version /rds/datastore/dws/version /var/spool/cron/root /etc/sudoers /var/spool/cron/Rubyrm /rds/mgntAgent/workplace -rfln -sfn /rds/mgntAgent/$sourceVersion /rds/mgntAgent/workplacerm /rds/datastore/dws/workplace -rfln -sfn /rds/datastore/dws/$sourceVersion /rds/datastore/dws/workplace

问题现象：扩容失败之文件目录权限不足，导致新节点rpc无法正常启动问题版本：2023年830的agent升级解决方法：     如下命令修改后重启haagent 重试：chattr -R -i /rds/chmod -R 755 /rds/mgntAgent/v8.2.1.310_bcf43ca7_f59ab299/chmod -R 755 /rds/datastorechmod -R 755 /rds/rpcsed -i 's#export PATH=\$PATH:\${JAVA_HOME}/bin#export PATH=\${JAVA_HOME}/bin:\$PATH#g' /home/Ruby/.bashrcservice haagent restart