检查集群状态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

问题背景：业务调度锁超时时长与guc参数设置的updata_lockwait_timeout和lockwait_timeout,不符问题分析：lockwait_timeout参数可分别对不同database设置，不同库有各自对应的pg_settings，gs_guc查看的为postgresql.conf中设置的参数值，具体业务库的作业以各自库中pg_settings表的setting字段的值为准准确查看业务库锁超时参数的方式参考（连对应业务库）：show lockwait_timeout;select * from pg_settings where name = 'lockwait_timeout';​​​​​​​修改各数据库对应的参数值语句参考：ALTER DATABASE databasename SET gucname = value

1.GTM状态为Down[1.1]故障类型：GTM进程挂，cm_agent未拉起关键信息:检查gtm进程，发现进程不存在ps -ef | grep gtm | grep -v grep解决方案：手动查杀cm_agent进程，待进程重新拉起后，检查gtm进程状态，若依旧不存在，收集cm_agent日志，联系华为工程师。[1.2]故障类型：GTM与cm_agent之间连接断开关键日志:cm_server日志：${GAUSSLOG}/cm/cm_agent/cm_agent_创建时间.log在cm_agent日志中检查同时存在instanceId is 100*和dynamic_role * = Down,则可判定为cm_agent与GTM断连解决方案：1.可能是CPU或IO比较繁忙导致cm_agent与GTM之间无法建立连接，请排查当时业务CPU或IO等信息。2.可能被其他进程查杀，排查定时任务等信息。3.节点hang，一般会伴随着当前节点所有实例全部为Down，请联系华为工程师。2.GTM告警主备不同步/37003警告：GTM主备不同步的情况下如果出现主GTM挂掉的情况，不会引起主备切换，会造成集群不可用。​不会主备切换的原因如下：GTM实例作用说明：GTM的主要职责之一就是给客户端分发全局事务id (global xid, gxid)GTM首要保证在任何情况下，分发给客户端的gxid不能重复，只能单调递增（每个事务的gxid唯一）。在集群正常执行业务时，当多个客户端同时申请gxid，通过锁机制来防止GTM分发重复。仲裁的条件：(1)GTM1和GTM2均同步模式(2)GTM1连接状态异常在主GTM异常时，备GTM执行failover升主，由GTM的HA机制保证下发的gxid不会被复用。如若主GTM的xid没有同步给备机之前，备机升主，gxid 会重复。[2.1]故障类型：网络波动或断开关键日志:GTM ：${GAUSSLOG}/pg_log/gtm/postgresql-创建时间.log关键词:could not connect to the GTM * server， * connect_timeout=7：connection out of date解决方案：1.可能是网络丢包严重导致，请排查网络可通过$GAUSSHOME/bin/dfx_tool目录下的gsar.sh脚本抓取网络当时丢包情况sh gsar.sh {网卡名}2.规避方式：修改超时参数gs_guc reload -Z gtm -N all -I all -c "standby_connection_timeout=30"将参数修改以后可以达到规避的效果，不再上报告警。[2.2]故障类型：防火墙未关闭关键日志:GTM ：${GAUSSLOG}/pg_log/gtm/postgresql-创建时间.log关键词:could not connect to the GTM * server， * connect_timeout=x：wait xxx ，Operation now in progress解决方案：1. iptables -L -n --line-number 查看防火墙是否未关闭2. iptables -F 打开防火墙后，即可自行恢复​3.GTM执行报错[3.1]报错类型：Failed to receive GTM rollback transaction response for aborting transaction关键日志:GTM ：${GAUSSLOG}/pg_log/gtm/postgresql-创建时间.log关键词:GTM error, could not create sequence解决方案：gtm实例目录中cat gtm.sequence | wc -l检查sequence数量，sequence较大1.把sequence的cache调大，减少到gtm上写sequence的次数ALTER SEQUENCE {序列名} cache {数字};2.把gtm_rw_timeout调大，增加从gtm上接受结果的等待超时时间set gtm_rw_timeout='2min';3.如果依旧不能创建序列，kill掉GTM实例，待重启后即可[3.2]报错类型：FI界面出现MPPDBServer数据实例连接GTM异常关键日志:GTM ：${GAUSSLOG}/pg_log/gtm/postgresql-创建时间.log关键词:Too many threads active解决方案：1.并发偶尔冲高引起的，如果出现频繁并且影响业务可以尝试调整下gtm的连接数gs_guc reload -Z gtm -N all -I all -c "gtm_max_trans = 8192"gtm_max_trans参数说明：设置gtm最大可接收连接数， 不建议用户修改该参数。如果需要改动，此参数不能小于最大连接数加100。取值范围：整型，256~16384默认值：81922.gtm.conf文件中未设置gtm最大可接收连接数，使用默认值8192[3.3]报错类型：存储过程执行报错：GTMerror， could not obtain snapshot解决方案：通过JDBC在一个存储过程内执行delete, insert，vacuum等操作，vacuum报该错。将vacuum 与其他操作分开后可以正常执行。[3.4]报错类型：failed to get the sequence uuid xxx from etcd关键日志:GTM ：${GAUSSLOG}/pg_log/gtm/postgresql-创建时间.log关键词:failed to get the sequence uuid xxx from etcd此报错与vacuum 系列命令强关联，vacuum full 并发数高，占用GTM连接数解决方案：限制vacuum 系列命令并发数

【版本信息】不涉及【问题现象及处理方法】之前介绍的性能问题处理套路中查杀烂SQL（执行时间长的SQL，也称长SQL）作为应急处理整体性能问题的常用手段之一，被广泛使用，但是经常有人会发出疑问，为何一个长SQL会有那么大的影响，怎么能防止一粒老鼠屎坏了一锅粥？这里就聊下这个话题1、消耗大量CPU/IO/内存等资源性能影响点：执行时间长的SQL往往会消耗比较多的CPU/IO/内存等资源，当这些资源出现资源瓶颈，必然会影响整体性能预防方案：配置资源管控，防止单SQL消耗大量资源，影响整体性能，参考https://bbs.huaweicloud.com/blogs/1746372、长期持锁阻塞DDL及后续业务性能影响点：所有SQL都会持锁，长SQL即会对相关表长期持锁，阻塞DDL（ALTER等），进而阻塞后续的业务预防方案：合理配置配置lockwait_timeout、ddl_lock_timeout等参数，避免SQL长期持锁&等锁3、影响空间回收，空间膨胀性能影响点：长SQL老事务会影响vacuum/autovacuum对空间的回收（https://bbs.huaweicloud.com/blogs/278695），导致空间膨胀，查询扫描性能下降1）预期外的长SQL：通过应用端&服务端合理配置SocketTimeout、statement_timeout预防2）预期内的长SQL：规划好调度，避开高频update/delete/insert作业时间4、实时场景，影响写入速度性能影响点：高频的update/delete/insert场景因长SQL导致空间无法及时回收，新数据无法复用老页面，需要频繁的开辟新页面，导致写入性能会受到严重影响预防方案：1）预期外的长SQL：通过应用端&服务端合理配置SocketTimeout、statement_timeout预防2）预期内的长SQL：规划好调度，避开高频update/delete/insert作业时间