扩容或重装主机时在第一步校验参数失败报Failed to verify nodes connection错误  操作场景  1、扩容主机失败，有如下提示信息： #发现节点未完成# Could not verify `ecdsa-sha2-nistp256` host key with fingerprint `31:90:be:5c:92:a4:62:90:7d:9a:d2:c2:4e:4f:d6:2a` for `xxx.xxx.xxx.xxx` on port 22 while Connecting via SSH to xxx.xxx.xxx.xxx using username root.     2、重装主机失败，提示： 重装主机失败，详细错误信息: Failed to verify nodes connection. Maybe the password is incorrect or the network is abnormal.  可能原因 待扩容或重装节点的HOSTKEY变更（重装OS或者重新生成HOSTKEY可能会导致HOSTKEY变更）。 处理步骤  1、使用PuTTY工具，以omm用户登录主管理节点。  2、执行vi /var/log/Bigdata/controller/controller_nodesetup.log命令，搜索“HOST_KEY_NOT_VERIFIABLE”关键字，有如下报错信息：  SSH Command Exectuion failed  3、执行vi ${BIGDATA_HOME}/om-server/om/etc/om/known_hosts命令，删除文件中包含待扩容或者重装节点主机名或者ip地址的行。  4、执行sh ${CONTROLLER_HOME}/sbin/restart-controller.sh命令重启controller，然后重新进行扩容或者重装主机。 

问题现象：集群主机管理中显示主机故障，但是地址能ping通，在CN节点使用cm_ctl query –Cv命令查看后端服务均正常，但是重启集群时有MPPDB实例启动失败 定位步骤： 1、 查看/var/log/Bigdata/mpp/omm/cm/cm_agent目录下的cm_agent和system_call日志发现集群节点互信丢失 2、 进一步发现集群所有节点在omm用户下直接ssh 该节点主机名都需输入密码（无法免密登录），而其他节点之间可以免密ssh 3、使用root用户登录互信不正常节点，通过命令ll /home查看，发现/home/omm目录已经被删除（或者破坏文件权限之类，正确的/home/omm文件夹权限是750），怀疑有人误删目录。通过操作系统命令history查看，发现确实有人执行了rm -rf omm操作： 解决方案： 步骤一、使用root用户登录到故障的节点上创建omm用户根目录并修改权限（若是/home/omm目录被破坏则直接删除后按下面步骤重建） mkdir /home/omm chmod 750 /home/omm chown omm:wheel /home/omm 步骤二、 将/etc/skel目录下的所有文件和目录复制到omm用户家目录下 cp -ra /etc/skel/. /home/omm 步骤三、 对比集群其他节点，修改omm用户家目录下所有文件和目录的权限 步骤四、 编辑ip列表文件保存到/temp/hostfile (加入集群所有节点IP。每个IP一行，不含空格。) 步骤五、 登录任意一个正常数据节点使用gs_sshexkey命令修复节点互信命令如下:su - ommsource /opt/huawei/Bigdata/mppdb/.mppdbgs_profile cd /opt/huawei/Bigdata/mppdb/wisequery/script gs_sshexkey -f /temp/hostfile -W omm用户密码 步骤六、 使用omm用户登录正常节点和非正常节点，相互发送文件验证 步骤七、 使用omm用户登录所有MPPDB实例所在节点，ssh 远程连接web和oms浮动IP地址（第一次互信提示输入yes），退出再次ssh浮动IP则免密连接  正常，集群告警自动清除，集群巡检健康，集群恢复正常。 

一、假如文件地址：/srv/BigData/mppdb/data1/master1/base/15015/1500315015为数据库的oid, 15003是表的relfilenode二、过程：1.根据oid找到对应库名连上postgres库，select oid,* from pg_database where oid=15015；得到对应库名，假如为dbname2.切换到dbname库，查询该表的表名和schemaselect n.nspname, c.relname from pg_class   c, pg_namespace n where c.relnamespace=n.oid and c.relfilenode=15015;3. 如果步骤2没有找到,则从分区表中查找主表名称和分区表名称select n.nspname, c.relname,p.relname from  pg_partition p, pg_namespace n,pg_class c where p.parentid=c.oid and  c.relnamespace=n.oid and p.relfilenode=15015;4.如果步骤3没找到，进入目录/base/15015/，查看文件是否属于系统表pagehack -t filenode_map -f   pg_filenode.map | grep 15015找到则说明此文件为系统表对应的文件。5.如果上面得步骤都找不到对应的表，则开启脏页查找：start transaction read only;                         -- 开启只读事务set enable_show_any_tuples = true;         -- 脏数据开关set enable_indexscan = off;                        -- 关闭索引set enable_bitmapscan = off;                     -- 关闭bitmap索引再次执行2-3步rollback;    --回滚事务6.  如果以上步骤都找不到对应数据库对象，说明该文件残留，可以用文件残留扫描工具扫描清理

 1、 登录主管理节点 su – omm 2、 source /opt/huawei/Bigdata/om-server/om/meta-0.0.1-SNAPSHOT/kerberos/scripts/component_env 3、 export KRB5_CONFIG=/opt/huawei/Bigdata/om-server/om/kerberos_user_specific_binay/kerberos/var/krb5kdc/krb5.conf 4、 kadmin -p kadmin/admin(默认密码是Admin@123，输入完以后需要修改密码，请记住这个密码，下次执行kadmin -p kadmin/admin后输入密码就不是默认密码Admin@123，而是此次改的密码) 5、 cpw admin 输入想要修改的密码  

一.当两个事务的锁产生冲突时，未拿到锁的线程会等锁，等锁时间超过系统设置参数，会报锁等待超时错误：Lock wait timeout二.如何快速找到持锁语句，给它杀掉1.查询活跃视图，找到waiting为t得，表示正在等待执行select * from pgxc_stat_activity where user != 'omm' and state = 'active';2.根据上一步找到得语句，在对应节点上查询等待视图execute direct on （xxx）'select * from pgxc_thread_wait_status' where tid='xxx';3.根据pg_locks查看语句在哪张表上持锁select * from pg_locks where pid = 'xxx' and locktype ='relation';select * from pg_locks where relation='xxx';4.pg_locks中granted为t表示持锁语句，pid为持锁语句在该节点上的query对应的pid，可在pgxc_stat_activity中查看持锁语句select * from pgxc_stat_activity where pid = xxx;5.通过pg_terminate_backend函数去对应的节点上杀掉持锁语句

集群性能数据采集原理：a. MPPDB在CMS主节点上通过gs_checkperf进行性能数据采集。b. MPPDB将采集到的数据上报给om-agent。c. om-agent将收集到的数据写入共享内存并将数据发送给oms节点的pms监控模块。d. pms对cms节点发送的数据进行消费入库。1. FI界面不再显示监控信息，后台集群正常2.查看gs_checkperf日志，发现报错：No JSON object could be decoded，每隔一分钟打印一次4.单独执行gs_checkperf能收集到信息，但脚本里却不行5.查看gaussStartGsPerf.log日志，调用mpp-startGsPerf.sh脚本，打印/opt/huawei/Bigdata/tmp/pref_tmp.dat，与现场日志一样问题一：原因分析：线下mppdb服务监控数据一段时间不更新或者无数据，原因是机器重启或者网络中断导致数据收集写入json文件为空，下次采集拿的是上次的空文件，从而导致json解析失败。规避方案：进入集群第一个cn节点，切换到集群用户（默认omm用户）下 cd $PGHOST，删除文件大小为0的文件，再进入checkperf目录下，删除文件大小为0的文件。问题二：【问题描述】manager从6.5.16升级 高版本后，页面监控不显示【触发原因】升级时，采用了老版本的setuptool做的rpm步骤和preinstall步骤【问题根因】 老版本的setuptool，导致系统依赖不完整，检验命令ldd /opt/huawei/Bigdata/om-agent/OMA/bin/omm_agent.bin【规避方案】1.找到对应版本的setuptool2.补做，补充rpm包和提交preinstall章节3.ldd结果全都能找到了4.重启oma相关进程问题三：共享内存问题页面监控不显示排查方法：1. 查看PMS日志(/var/log/Bigdata/omm/oms/pms/scriptlog/pms_script.log)：解决办法：增大/opt/huawei/Bigdata/om-server/OMS/workspace/conf/pms/application.properties文件中pms.mem的值omm用户重启pms： restart_app pms2. 查看tomcat日志/var/log/Bigdata/tomcat/web.log中是否有Get metric collect time fail for null == metricInfoBean打印，如果有，omm用户重启oms的tomcat：sSh /opt/huawei/Bigdata/om-server/apache-tomcat-*/bin/ shutdown.shsh /opt/huawei/Bigdata/om-server/apache-tomcat-*/bin/ start.sh3. 以omm用户登录主管理节点，然后分别重启pms和cep，命令如下：重启pms：restart_app pms重启cep：restart_app cep重启NodeAgent：sh ${BIGDATA_HOME}/om-agent/nodeagent/bin/stop-agent.shsh ${BIGDATA_HOME}/om-agent/nodeagent/bin/start-agent.sh如果5分钟后仍未恢复，则执行下一步。4.使用PuTTY工具，以omm用户登录监控不显示的节点，执行如下命令，检查主机监控采集脚本是否出现异常卡死：sh ${BIGDATA_HOME}/om-agent/nodeagent/bin/pluginScript/host_metric_collect.sh如果10秒以上host_metric_collect.sh还没有执行完成，则认为监控采集脚本异常，中断执行脚本，再次执行如下命令：sh -x ${BIGDATA_HOME}/om-agent/nodeagent/bin/pluginScript/host_metric_collect.sh查看脚本具体卡在哪一个采集命令上，然后根据执行失败的采集命令分析失败原因。如果监控采集脚本执行正常，则执行下一步。5.使用PuTTY工具，以omm用户登录出现不可用的节点。通过ipcs -m | grep 0x54376801查看共享内存大小和权限是否正常。正常的共享内存信息，如下所示：0x54376801 65536      omm        600        125760048  2执行命令后，如果该共享内存的权限为root或者nattch的个数小于2个，则说明共享内存异常。如果共享内存异常，可执行ipcrm -M 0x54376801删除旧的共享内存，然后分别重启NodeAgent和omm_agent。重启NodeAgent：sh ${BIGDATA_HOME}/om-agent/nodeagent/bin/stop-agent.shsh ${BIGDATA_HOME}/om-agent/nodeagent/bin/start-agent.sh重启omm_agent：${BIGDATA_HOME}/om-agent/OMA/tools/restart_oma_app如果5分钟后仍未恢复，则执行下一步。6.查看“omm_agent.bin”的权限是否正确。在执行命令ll ${BIGDATA_HOME}/om-agent/OMA/bin/omm_agent.bin查看“omm_agent.bin”的权限是否正确。正常情况应该为omm:wheel，如果不是该权限，修改权限为“omm:wheel”，然后重启omm_agent。重启omm_agent：${BIGDATA_HOME}/om-agent/OMA/tools/restart_oma_app

1.查询表得脏页率很高，对表做vacuum后，但空间并未释放2.按照排查老事务得方法排查，清理老事务后，再进行vacuum full仍未释放，此时可能有如下两个场景： 2.1 版本较老，show vacuum_defer_cleanup_age；该参数值为8000，表示最近8000得事务产生得脏数据不会回收 规避：将该参数值设为0 2.2 脏数据的事务号，大于当前活跃最老事务号，那么这部分脏数据也不会清理，这是为了保证事务可见性。举个说明：有一张表tab，对该表做如下操作： 开启事务1，但是没有访问表tab，且事务未提交 开启事务2，删除了tab中的数据，并提交 此时做vacuum full，由于事务2在事务1之后，而事务1此时未提交，对事务1来说，tab中的这条数据还是可见的，即使事务1当前未使用表tab，但是无法保证未来是否会访问表tab，快照拿的仍是事务开启时刻的状态，因此vacuum full并不会回收这条脏数据的物理空间规避：排查老事务，杀掉老事务后重新执行排查老事务：https://bbs.huaweicloud.com/forum/thread-153148-1-1.html

rms数据库节点vip丢失;数据库浮动ip  ping不通    问题现象： Get_db_status.py   执行结果显示Can not find VIP xxxxxx/xx both on the xxx.xxx.xxx.xxx  xxx.xxx.xxx.xxx, 说明浮动IP丢失，继续按照下面方法修复。规避方法：1、以opsadmin登录到需要数据库主节点IP，并切换到root用户，再执行su - mysql切到mysql用户执行。2、使用查看数据库主备状态： Get_db_status.py，命令执行结果显示:       Can not find VIP 10.170.181.70/23 both on the 10.170.181.68,10.170.181.69, 说明浮动IP丢失，继续按照下面方法修复。3、在数据库 主节点上执行命令查看当前数据库浮动IP信息：       cat /usr/local/bin/ha_config        4、挂载浮动IP并刷新arp缓存vip: 带掩码的浮动IP地址，vip_ip的值里面找,   gate_ip：网关地址 ，对应上图gateway_ip# root用户执行sudo ifconfig eth0:1 {vip_ip}    #挂载浮动ipsudo /usr/sbin/arping -I eth0 -c 5 -U -s {vip} -b {gate_ip}   # 刷新arp缓存                示例：# root用户执行sudo ifconfig  eth0:1 10.170.181.70/23sudo /usr/sbin/arping -I eth0 -c 5 -U -s  10.170.181.70  -b 10.170.180.1     再次切换到mysql用户下，查看数据库状态： Get_db_status.py。

问题现象    打开监控面板主页无数据问题影响  无法查看监控可能原因   升级前手动关闭了DMS的总开关，升级后未手动开启，所以重启dms-agent进程后数据未正常上报排查过程          1.  查看页面接口状态：接口状态200                2. 查看agent日志：日志时间有间断，且日志时间截止到26日再无新日志       3. 进一步查询agent进程：进程存在4.  了解到升级前手动关闭了DMS的总开关，升级后未手动开启，所以重启dms-agent进程后数据未正常上报解决方法  尝试通过mv /home/Ruby/log/dms_workdir,然后kill agent进程让其重新拉起，可以看到上报恢复正常恢复确认    页面已正常显示

问题现象无法创建DWS集群问题影响  无​​​​​​​法创建DWS集群可能原因    前端未做弱密码校验，后端有弱密码校验导致客户创建集群失败解决方法  后台屏蔽密码校验​​​​​​​

问题现象kubectl无法登陆容器，命令异常kubectl执行命令返回异常：The connection to the server localhost:8080 was refused, did you specify the right host or port?问题影响无法进入容器可能原因环境变量或者镜像异常处理思路1.尝试退出root使用su -root切换root用户并加载root的环境变量2.如果1尝试还不行，请联系cdk的onall进行处理

问题现象    管控面节点监控和历史查询无数据，接口无报错可能原因        因为dmsagent先于内核升级的原因获取老的配置导致initCes.JSON cesAK 和 cesSK两个参数为空 为空排查过程  1.  查看dmsagent 日志发现报错：x-auth-toke not founddmsagent 日志：2.  怀疑InitCes.json文件有问题沙箱外操作cd /home/Rubycat InitCes.json3.  发现cesAK 和 cesSK 不能为空解决方法（集群每个节点都要操作）（注：需要有后台权限的工作人员操作）1. 从本集群其他节点的InitCes.json文件的cesAK 和 cesSK两个参数拷贝2. 如果本集群所有节点cesAK 和 cesSK参数为空，则kill掉dws-log进程，从同一个region的其他集群找到两个参数的值，拷贝到问题集群

问题现象数据概览部分没数据（业务负载，数据量，查询统计）可能原因因为dmsagent先于内核升级的原因获取老的配置导致InitDms.json文件中域名配置错误排查过程   1.查看dmsagent日志，发现域名配置错误  2. 查看InitDms.json文件，发现域名dms.dws.cn-north-9.myhuaweicloud.com错误，应去掉dms.解决方法（集群每个节点都要操作）       修改InitDms.json文件域名参数：去掉域名“dms.dws.cn-north-9.myhuaweicloud.com”中的dms.恢复确认     客户已确认恢复

一、版本：GaussDB 300 651二、定位过程1.问题出现背景：故障实例所在节点有僵尸进程，重启os，主备切换了，状态为：该实例为Building（8%），对应从备为 Down Unknown2.查看该实例对应从备实例日志：could not create shared memory segment：Cannot allocate memory3.连上故障实例 show shared_buffers，结果为64G。4.从备实例，free -g 可用为58G5.原因：DN的shared_buffers参数为64G，节点剩余内存为58G，导致无法拉起6.解决/规避：通过kill其他dn释放一些内存让从备可以拉起，使集群恢复至降级

一、版本信息：HCS DWS810二、定位过程：1.一个节点的CN 和DN down掉2.按照标准方案对该cn进行修复，结果报错：Failed to start CN3.对应故障cn报错如下：4.原因：日志报错在两阶段事务清理时告警发送失败，cn退出卡住5.解决：暂时屏蔽告警，即重命名告警二进制文件（日志会显示），重试gs_replace，实例修复成功gs_ssh -c 'mv /opt/huawei/snas/bin/snas_cm_cmd /opt/huawei/snas/bin/snas_cm_cmd_bak'6.恢复告警二进制文件gs_ssh -c 'mv /opt/huawei/snas/bin/snas_cm_cmd_bak /opt/huawei/snas/bin/snas_cm_cmd'