1. 初始化系统环境变量失败 查看etc/uid_list中存在omm用户id清除后执行成功2.初始化新实体报错，查看postinstall.log。执行/opt/huawei/Bigdata/FusionInsight_MPPDB_8.1.1/install/FusionInsight-MPPDB-8.1.1/package/MPPDB/sudo/gs_checkos -i A 有abnorm 状态执行/opt/huawei/Bigdata/FusionInsight_MPPDB_8.1.1/install/FusionInsight-MPPDB-8.1.1/package/MPPDB/sudo/gs_checkos -i B 修复后，安装集群成功gs_checkos工具来帮助检查操作系统、控制参数、磁盘配置等内容，并对系统控制参数、I/O配置、网络配置和THP服务等信息进行配置。3.安装新实体报错：提示sudoExecute.sh调用mpp_sudoExecute.sh报错，mpp_sudoExecute.sh脚本不存在，但其他两个节点有这个脚本，在安装mppdb过程中，手动从其他节点拷贝这个脚本，安装成功。注意：（813版本需要在安装集群时更新sudo脚本，按照产品文档执行命令即可）4.preinstall报错，操作系统版本不一致1.preinstall报错，提示操作系统版本不一致, 查看preinstall.ini文件参数g_pkgs_dir="redhat-6.4:/media/" 2.preinstall 包操作系统版本不一致，改路径下/etc/redhat_release文件 删除redhat_release文件后 ，修改preinstall.ini文件中g_pkgs_dir="redhat-6.4:/media/" 该参数和操作系统版本一致后可执行成功

1.dws部署架构cid:link_12. 基本视频资料：cid:link_4（3个视频）         3. GaussDB(DWS)培训视频cid:link_04. 案例查找：http://bi.dws.db.huawei.com:8888cid:link_3cid:link_25.其他学习资料：cid:link_5

dws服务后台数据库有两种：mysql，gaussdb100一：查询cdk参数登录cdk--》变更管理--》服务升级--》1.dwscontroller:选dwscontroller--》下一步--》使用“db.”过滤参数获取数据库连接信息2.dms-monitoring:选dwscontroller--》下一步--》使用“data”过滤参数获取数据库连接信息3.dbevent:选dbevent--》下一步--》使用“data”过滤参数获取数据库连接信息4.dbmonitor:选dbsmonitor--》下一步--》使用“data”过滤参数获取数据库连接信息二：密码解密     获取的数据库密码密文，需要使用工具解密     具体解密请参考        cid:link_0三：后台登录1.mysql 登录     1）.对应从cdk对应服务获取数据库连接信息     2）.登录运维容器解密密码同时连接mysql服务 mysql       mysql -u{db.username} -p{password} -D{dbname} -h{ip} -P{port}2.gaussdb 100登录      root登录     su abadmin     gsql -d dms -p 8635

       想跟您确认一下项目MPPDB环境本地gsql -d -p命令访问数据库时候，所需环境变量的问题。       经在现场测试环境测试，了解到项目MPPDB环境在每次执行gsql 命令前，需要使用source命令读取执行带环境变量的文件 （命令为：source ${BIGDATA_HOME}/mppdb/.mppdbgs_profile）。    ​   麻烦请基于项目的环境情况帮忙确认如下问题：    ​   1、如果${BIGDATA_HOME}为固定值，那么是否和测试环境一样统一都是/opt/huawei/Bigdata       2、如果${BIGDATA_HOME}为变量，可否提供该变量的定义位置。

一、整个节点未启动1. 查看集群状态：cm_ctl query -Cv 找到整节点未启动的主机；2. omm用户登录对应节点，查看om_monitor进程是否存在，如果om_monitor进程不存在，则可能是omm用户定时任务异常、omm用户密码超期、cgroup挂载异常，可通过分析om_monitor日志、omm用户定时任务、omm用户密码超期时间等方式进行进一步分析；3. 如果节点上om_monitor进程存在，cm_agent进程不存在，则可能原因是FIM界面启动命令未成功下发到后台、python版本过高或其它原因导致om_monitor未能启动cm_agent，可通过检查启停标志文件、节点上python版本、om_monitor日志等方式进一步分析。二、节点内部分实例未启动1. 查看集群状态：cm_ctl query -Cv 确认未启动的实例及所在节点主机；2. omm用户登录对应节点，查看cn/dn/gtm/cm_server实例进程是否存在，如果进程不存在，则可能原因是端口被占、lvs虚拟ip丢失、cn/dn的postgresql.conf配置文件的listen_address参数存在无效ip、进程监听端口号对应锁文件残留、cn/dn配置文件中存在无效GUC参数、系统信号量参数配置过小、存在多个cm_agent进程、路径无权限、磁盘满、数据目录权限异常等，需要结合日志具体分析；3.如果cn/dn/gtm/cm_server进程存在,但状态为down或者unknown，则可能原因是当前节点与主cm_server节点网络不通、cm_server无主、节点上存在子网卡等；4.如果cn/dn/gtm/cm_server进程存在,但状态为pending，则说明可能是在做redo，可通过查看堆栈来确认。

【问题描述】查看集群状态，实例处于build failed状态【问题分析】实例处于build failed一般有以下几个原因：1）xlog被回收2）build过程中与主机网络断连（主机故障或者网络原因）3）build超时具体原因需要查看对应节点gs_ctl日志进行排查【修复方案】1）在任意节点执行全量build故障实例：cm_ctl build -n 1 -D /srv/BigData/mppdb/data2/slave1 -b full -t 10800-t 代表build超时参数2）在需要build实例所在节点执行：gs_ctl build -D /srv/BigData/mppdb/data2/slave1 -Z datanode -b full -r 10800-r 用于调整build超时参数3）如果全量build失败，可用gs_replace修复

DWS内核版本： PostgreSQL 9.2.4（GaussDB 8.1.1）现象描述：目前客户环境(已开启审计日志转储)的情况是只能查出近一天的数据，例如执行以下语句：select min(begintime),count(1) from pgxc_query_audit('2021-01-01 01:00:00','2022-09-26 23:00:00');返回的begintime最小值是2022-09-25 xx:xx:xx。求助：请问下DWS开启审计日志后，函数pgxc_query_audit可保留多老的审计日志，是否有参数进行控制。

可能原因：catchup原因一般都是由于某些业务在短时间内产生较多xlog文件，主备同步不及时，此时主备同步有排队情况影响事务提交导致业务出现比较卡的现象。造成该问题主要有带索引导入、频繁delete、频繁truncate、update导致，此时需要解析xlog查看对应操作以及相关业务表。处理：进入catchup实例，解析xlog：pg_xlogdump $xlog_filename，可能的场景如下：1.带索引导入，关键字：btree insert2.频繁delete或delete整张表场景，关键字：delete解决：带索引表入库产生大量xlog日志同步不及时导致catchup，影响事务提交引起业务卡。建议入库前删除索引，入库完成后进行索引重建。业务侧尽量避免对单张表进行频繁update、delete、truncate操作。

例：删除告警定义数据使用omm用户登录主OMS节点执行如下命令登录数据库gsql -p 20015 -U omm -W ${ gaussDBPassword}3.执行如下命令删除12059告警定义信息delete from omm_1.TBL_FM_ALARM_DEFINITION where svalarmId='12059';delete from TBL_FM_ALARM_DEFINITION where svalarmId='12059';4.执行如下命令删除12059告警附加信息delete from TBL_FM_ALARM_ADDITIONALINFO where svalarmId='12059';5.执行如下命令删除12059告警位置信息delete from TBL_FM_ALARM_LOCATIONINFO where svalarmId='12059';3.执行如下命令退出数据库\q关闭配置解析开关sh $CONTROLLER_HOME/sbin/update_monitor_config.sh false恢复12059告警定义数据1. 使用omm用户登录主OMS节点，执行如下命令，开启配置更新开关sh $CONTROLLER_HOME/sbin/update_monitor_config.sh true2. 重启controller、tomcat进程，重新解析配置文件sh $CONTROLLER_HOME/sbin/restart-controller.shsh ${BIGDATA_HOME}/om-server/tomcat/bin/shutdown.shsh ${BIGDATA_HOME}/om-server/tomcat/bin/startup.sh

一、实例状态1.长期处于need repair状态kill实例没有效果，集群处于降级状态。判断实例是否做redo？方法如下：  a.连接故障dn，select pg_last_xlog_replay_location()；查询多次，观察值是否有变化，若变化则在redo  b.gstack $pid，pid为故障dn的进程号2.实例处于standby need repair(disconnect)状态 查看该dn日志有gss相关报错重新刷新票据/opt/huawei/Bigdata/FusionInsight_BASE_6.5.1/install/FusionInsight-kerberos-1.17/kerberos/bin/kinit -k -t /opt/huawei/Bigdata/mppdb/auth_config/mppdb.keytab mppdb/hadoop.hadoop.com@HADOOP.COM3.实例分别处于 standby promoting、pending need repair 查看standby promoting dn6046日志报错： FATAL:dn_xxx_xxx:number of requested standby connections exceed max_wal_sendes 查看从备日志：FATAL:  number of requested standby connections exceeds max_wal_senders (currently 4)信号响应函数未生效，导致从备的datareceiver线程未退出，引起 failover 失败，后续备机升主继续连接从备请求同步数据引起从备实例复制槽满报错。kill 从备让其升主

总体思路：先排查cma、om_momitor进程是否存在，然后定时任务是否有om_momitor得任务1.查看om_momitor进程不存在2.定时任务为空，手动添加报错3.找os人修复定时任务4.手动拷贝正常节点定时任务，om_momitor进程仍然不存在5.检查发现环境变量配置文件内容为空6.拷贝正常节点环境变量配置文件，集群启动成功7.使用gs_replace修复故障cn和dn

       有时候我们会发现GaussDB(DWS) 脏页率很高的表做了vacuum full 后大小却没有任何变化，这种问题两种有两个原因 ，第一是你没有做analyze就查询到这个表脏页很高，其实是很早前的统计信息数据； 第二点就是我们今天要讲到的所谓的“老事务”，这些事务可能是某些异常导致的残留事务，或者正常的一直未提交的事务 ，如果时间过长， 大部分情况下无法手工清理掉(可能需重启DN释放)，影响比较大  。 一， 老事务是如何影响vacuum full 的呢 ？          老事务的产生比较复杂，待和研发同学讨教后再探讨 。  那么它是如何影响vacuum full清理不生效的呢 ？ 比如有一个insert into test_t select xx from yy ; 是老事务，在 dn_6033_6034 上有残留，CN节点上相关会话早就不存在 (需要注意的是，残留会产生老事务，但老事务不一定产生残留，比如可能CN/DN都存在，只是没有提交) ，这个事务的事务号为 10291153622， 开始运行时间为3天前，那么这个时间点后的事务产生的脏页都不会被vacuum full清理，  这个设计是为了保证事务可见性 。如下为老事务例子 (非残留导致)  ：  事务1：   begin transaction 不做任何操作，也不提交，假设 idle 事务1天后才可能被系统杀掉  。事务2：   2分钟后事务2删除了 test1 表 (200笔记录)中的10笔记录，并提交 。  事务3：   6小时后事务3更新了 test2 表 (100笔记录)中的80笔记录，并提交。 事务4：   7小时后事务4对 test1 表进行 vacuum full 。 事务2在事务1之后，而事务1一直没有提交，那么对于事务1来说，如果它想在它的事务中访问test1表的话，它应该看到完整的200条记录，而不是190条，如果事务4的vacuum full test1 表能回收事务 2 产生的脏页，那么这删除的 10 笔记录会被物理清理，而我们都知道GaussDB(DWS)不像Oracle, 它是没有UNDO空间存放前镜像的，这个时候如果事务1 查询 test1 表，肯定就看不到完整的 200笔记录了。这显然违背了版本控制原则。所以事务4的vacuum full test1不会生效 。 直到事务1 结束或提交后事务4的 vacuum full才可能清理生效 。  二， 老事务还影响啥  ？         老事务不仅仅影响到vacuum full脏页清理，还会因为锁导致很多操作受阻，比如各种TRUNCATE, CREATE INDEX, ALTER 等，比较难发现的是，它的受阻是排队等待，而不是报错，相对对生产的影响时间会更长  。  三， 如何成功进行 vacuum full   ？ 要成功进行vacuum full, 我们应该尽量减少老事务问题的发生。我们可以做如下改进： 1.  除非特殊需求，使用高斯DWS官方驱动，并设置 autocommit=on 。      2.   务必将如下参数做保底设置：session_timeout (定时清理idle连接) 和 statement_timeout (活跃会话最长时间限制) 。  3.  养成良好编程习惯，及时提交事务，及时关闭连接，过长事务建议切分执行 。    4.  尽量不要使用存储过程进行大事务处理，以免事务长时间处于idle in transaction状态，存储过程运行到最后才会提交，中间无法提交 。 5.  除非特殊需求，不要主动使用begin transaction ...end 。  6.  大多数的残留是因为异常断开或大数据量处理时前端异常导致的信号传输问题，尽量减少人工cancel可有效减少。 7.  其他原因导致的老事务问题，需要产品逐步改进 。    8.  其他待补充....  四，  如何解决老事务问题 ？ 如何解决老事务问题 (如果怀疑有老事务，需联系 SRE) ： 官方的参考文档 (需要在SRE协助下进行) ： https://bbs.huaweicloud.com/forum/thread-153148-1-1.html步骤1 在postgres库内创建自定义函数CREATE OR REPLACE FUNCTION public.pgxc_all_running_xacts()RETURNS SETOF pg_running_xactsLANGUAGE plpgsqlNOT FENCED NOT SHIPPABLEAS $function$ DECLARE row_data pg_running_xacts%rowtype; row_name record; query_str text; query_str_nodes text; BEGIN query_str_nodes := 'SELECT node_name FROM pgxc_node';FOR row_name IN EXECUTE(query_str_nodes) LOOP query_str := 'EXECUTE DIRECT ON (' || row_name.node_name|| ') ''SELECT * FROM pg_running_xacts''';FOR row_data IN EXECUTE(query_str) LOOP return next row_data; END LOOP; END LOOP; return; END; $function$;步骤2      查找集群中最老快照oldestxmin以及获取最老快照的线程：select txid_current() as current,xmin,node,pid,gxid from pgxc_all_running_xacts() where xmin::text::bigint !=0 order by xmin::text::bigint limit 1;间隔10分钟多次查询 xmin 一直在变化， 说明不是老事务。 如果上面的sql查询正常，极少数情况下可能还会有老事务，需要使用如下SQL同样方式查询多次。      select txid_current() as current,xmin,node,pid,gxid from pgxc_all_running_xacts() where gxid::text::bigint != 0 order by gxid::text::bigint limit 1;步骤3      到对应实例根据pid查找xact_startexecute direct on ($node) 'select xact_start, query, query_id from pg_stat_activity where pid = $pid';两个pid中时间最早的就是最老事务，可以等待该事务结束或kill掉老事务。    

【问题描述】dn被频繁kill【问题分析】1、排除了已知的ssl、Lvs问题2、替换了jemalloc SO文件，翻译地址分析3、排查后发现调用gs_cgroup_map_reload_conf和pgxc_cgroup_reload_conf触发了内存泄漏4、子系统配置是no就会有这个问题（systemctl show -- -.slicegrep -i accounting）5、本地环境测试调用gs_cgroup_reload_conf，复现泄漏【问题根因】others触发条件根因都是cgroup挂载失败，mount_gs_cgroup.py脚本里边，脚本是811合入的，之后版本cgroup挂载失败会有others高的问题OM侧在 欧拉2.9版本进行了适配，之前版本没有适配cgroup挂载失败的截图

【问题描述】数据库节点运行过慢告警【问题分析】1、通过gsar脚本发现网络重传较高：2、查看message日志有网卡重启的记录3、排查网络重启原因，定位到有个脚本netcardmonitor.sh在重启网卡4、查看netcardmonitor.sh脚本，发现该脚本如果检测不到eth网卡会重启网络服务，从而影响网络建联：【问题原因】慢节点告警分析如下：1、混合云bms高速组网，两个网卡做bond，然后再做vlan，导致网卡名称为bond.xxxx。和传统的网卡名称（eth1~eht3）不一样。2、netcardmonitor.sh因为逻辑判断错误（检测eth1~eth3，但是eth网卡不存在，认为网卡挂了），每分钟都重启 service network restart，影响网络建联，导致查询stream和gather算子慢【解决方案】#!/bin/bashnum1=67num2=78file = "xxx"sed -i "${num1},${num2}s/^/#/" $file执行如上脚本，把xxx替换成netcardmonitor.sh脚本名，如下图所示，完成后把集群上的这个脚本文件拉到最后拍张图确认，该操作不会影响DWS业务。

【问题描述】一个表的访问，只有seq_scan和idx_scan（视图pg_stat_user_tables） ？如果这两种scan都是0， 说明这个表从创建后就没有被访问  ？    有什么办法能够找到数据库内从来没有被访问过的表，需要清理这些没用的表【解决方案】      1.、访问的可以参考这个（对应视图pg_stat_user_tables），但前提是seq_scan中必须有出现顺序扫描才算，idx_scan中必须有索引扫描才算，但是这个访问数量比实际访问数量要少，因为可能还有除了顺序扫描和索引扫描的其它访问，目前能参考的就这两个数据，没其它的了，有这两个数据，就说明有顺序扫描或索引扫描方式访问了       2.、813版本有个global_table_stat 可以看，目前811这个版本，就之前发的这个视图pg_stat_user_tables，是查，增删改的话看pg_stat_all_tables视图，里面有last_data_changed时间字段，只要数据变动就会记录时间，可以两个视图结合起来看，pg_stat_all_tables视图还有个问题，就是CN或集群重启了信息就不见了，所以可以运行一段时间再看里面的信息。目前还是只有这两个视图可以看；还有个办法就是开审计，但这个代价估计有点大，审计量可能会很大，主要是存储空间膨胀会很验证，因为select语句全部都被记录