【问题现象】DMS_安装Collection微服务、DMS_安装Monitor微服务执行失败    下载工步日志后，可见报错信息  TimeoutError: Timeout to excute _check_stack_job_status ,the task has been Failed 【常见版本】8.2.0版本   【定位思路】1、登录collection或monitor容器查看日志报错 ；2、发现是无法连接DMS数据库： 日志报错关键信息no pg_hba.conf entry for host'XXX.XX.XXX.XX',database "DMS",SSL off 3、 登录DMS数据库节点DWS-Gauss-DB01和DWS-Gauss-DB02节点/opt/gaussdb/data/db目录查看pg_hba.conf文件，发现缺少容器所在node节点IP白名单（根因未配置白名单） 。【解决方法】1、手动配置白名单：查询部署对应服务node节点IP（一般有3个node,要加3个），加到pg_hba.conf文件最后例如:host all omm XXX.XX.XXX.XX/32 sha256 2、登录collection或monitor容器，查看POD状态，如果正常则说明已经正常安装，可以跳过该工步。

GaussDB 线下集群 8009迁移到8.1.1.3版本集群是否可以平滑过渡？有什么已知风险？

想咨询下专家，当前局点有个场景，计划搭建一套arm架构的8.1.1.3版本的GaussDB，现网有一套x86架构的8.0.0.9版本的GaussDB。计划完全将GaussDB（8.0.0.9）的数据及业务迁移至GaussDB（8.1.1.3）版本的GaussDB。现有两套方案，请问专家哪套方案推荐:一  、将8.0.0.9版本的GaussDB升级为8.1.1.3版本，再进行数据作业迁移。二  、直接将8.0.0.9版本GaussDB中的数据及业务迁移至8.1.1.3版本的集群内，此项操作是否有风险？

一、问题背景：线下651集群升级到800，一个节点升级mppdb到75%报错：auto-upgrade failed二、定位过程 1.$GAUSSLOG/om/gs_upgradectl-xxx.log报错：failed to check parameter 'enable_transaction_read_only';2.将主备cmserver得只读参数值改成一致，都为on，重试仍然失败，日志报错：failed to delete the /opt/huawei/Bigdata/mppdb/core/3. 该节点$GAUSSHOME下的文件和其他节点$GAUSSHOME下的内容和权限都不一样4.将$GAUSSHOME下面的文件备份一份在临时目录下，将 $PGHOST 下的备份目录的core目录下的所有文件拷贝到$GAUSSHOME下，并手动执行报错的命令，升级成功

OS重启&hang死下面将根据现网遇到的历史案例，根据不同OS整理出不同原因引起的OS重启问题，后续会继续更新补充。last reboot 可查询系统上次启动时间欧拉（Euleros）1.重启网卡进程导致大量dhclient进程出现，OS侧软中断超出阈值时间，watchdog狗叫，触发softlockup，OS panic重启【排查方法】（1） ps -ef |grep dhclient 故障节点有大量dhclient相关进程（2）若OS已自重启，且生成vmcore，查看grep dhclient /var/crash/vmcore-dmesg.txt，结果类似如下[368606.181774] audit: type=1400 audit(1655663430.716:39128): avc: denied { read } for pid=96740 comm="dhclient" name="dhclient-bond0.pid" dev="tmpfs" ino=1546 scontext=system_u:system_r:dhcpc_t:s0 tcontext=system_u:object_r:var_run_t:s0 tclass=file permissive=0[368606.181780] audit: type=1400 audit(1655663430.716:39129): avc: denied { write } for pid=96740 comm="dhclient" name="dhclient-bond0.pid" dev="tmpfs" ino=1546 scontext=system_u:system_r:dhcpc_t:s0 tcontext=system_u:object_r:var_run_t:s0 tclass=file permissive=0。。。。。。。。。（3）vmcore-dmesg中关键词[last unloaded: sysmonitor]（4）OS软锁发生[400092.069204] WARN: soft lockup - CPU#61 stuck for 11s! [gaussdb:74740][400104.069135] watchdog: BUG: soft lockup - CPU#61 stuck for 22s! [gaussdb:74740][400105.167920] Kernel panic - not syncing: softlockup: hung tasks【解决方案】1. root下注释/rds/mgntAgent/v8.1.1.x/os/linux/netcardMonitor.sh中66~77行重启网卡代码段66 for card in $cardList; do...77 done2. ps -ef | grep dhclient | grep -v grep | awk '{print $2}' |xargs kill -93. 修改其他节点（步骤1），预防类似问题发生4. 均衡集群操作2.OS重导致主备切换（1）【排查方法】/var/crash下vmcore-dmesg中记录kernel BUG at drivers/md/raid5.c:527! [535089.369357] kernel BUG at drivers/md/raid5.c:527!。。。。触发os文件bug导致内核崩溃官方链接：https://bugzilla.kernel.org/show_bug.cgi?id=195781【解决方案】联系欧拉打os补丁（2）【排查方法】/var/crash/vmcore-dmesg记录：> watchdog: BUG: soft lockup - CPU#13 stuck for 22s! [swapper/13:0] & Kernel panic - not syncing: softlockup: hung tasks内核发生软死锁【解决方案】打os补丁 cid:link_03.硬件故障导致os重启【排查方法】vmcore中有报错： [Hardware Error]: CPU .....【解决方案】联系硬件专家解决4.kernel 用户态auditd进程阻塞导致内核panic【问题描述】内核启动参数配置audit=1，系统触发audit规则审计，当用户态auditd进程阻塞时，内核卡死产生panic【排查方法】1. 检查启动参数，是否有audit=1：2. kauditd进程导致内核卡死，产生panic复位，dmesg有如下打印：3. 调用栈显示卡死位置在kauditd_send_queue函数：【解决方案】规避：启动参数不配置audit=1解决：升级版本，官方链接cid:link_25.kernel audit缓冲区日志堆积，导致slab内存消耗增大或内核死锁【问题描述】问题1：用户态持续产生audit日志（如调用sudo命令），当audit日志产生速度超过auditd进程处理速度的情况下，audit日志缓冲区会持续增大，slab内存消耗也持续增大。问题2：内核参数配置audit=1的场景，当audit日志缓冲区满的情况下，kauditd发送日志失败导致内核死锁产生panic。【原因分析】问题1：当内核kaudit模块处理用户态进程生成的audit日志（如执行sudo产生的audit日志）时，社区原生实现未限制日志队列长度，当队列日志得不到及时处理时，会发生日志堆积现象，导致内存持续增加。问题2：社区对于问题1的修复补丁存在设计缺陷，补丁修改上下文会被多次调用处理不同的日志队列，当启动参数配置audit=1时，hold队列启用， kauditd在hold日志队列的执行流程中存在死循环，触发softlock复位。【问题触发场景 &确认方法】问题1：触发场景：用户态持续产生audit日志（如执行sudo），且auditd进程处理audit日志的速率低于日志产生速度时触发此问题。确认方法：1. 根据【受影响版本】判断版本是否受影响；2. 确认内核audit功能是否启用，检查启动参数是否配置audit=0，若配置，则audit功能关闭，不受影响，否则均有可能受影响；3. 确认backlog_wait_time是否设置为0，若设置为0，则问题触发概率增大。backlog_wait_time参数可通过auditctl -s 查询；4. 确认问题是否发生：检查backlog数量是否超过backlog_limit，且持续增长。backlog和backlog_limit参数可通过auditctl -s 查询。问题2：触发场景：1. 内核启动参数配置audit=1（如果未配置此参数，则不涉及）；2. 在audit日志压力较大时，audit缓冲队列满，内核kauditd进程发送日志失败。确认方法：1. 根据【受影响版本】判断版本是否受影响；2. 检查启动参数是否配置audit=1，若未配置，则不受影响；【影响和风险】问题1：1. 导致slab内存升高，持续时间长可能导致内存耗尽；2. 发生概率相对较低。问题2：1. 内核softlock产生panic复位；【规避手段】问题1：关闭auditd服务（需要root权限）：# systemctl disable auditd# systemctl mask auditd# service auditd stop问题2：启动参数不配置audit=1，可配置为：audit=0：audit功能关闭；不配置：audit功能开启，相比配置audit=1，在用户态auditd进程未启动或未及时处理日志时，不会启用hold队列缓存日志，可能导致一定程度的日志丢失。备注：修改启动参数需要重启系统。【解决方案】升级内核版本至修复版本，升级完成需要重启系统。官方链接：cid:link_36.agent-service进程内存持续上涨频繁触发oom，导致os重启【问题影响】单节点os重启，dws集群界面显示低性能【详细案例】【OS重启】agent-service进程内存持续上涨频繁触发oom，导致os重启Centos1.os频繁重启，ipmi已知bug【排查方法】堆栈搜关键字 deliver_response问题堆栈：官方链接：https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=77f8269606bf95fcb232ee86f6da80886f1dfae8详细案例：CentOS因ipmi模块bug导致重启/hang【解决方案】方案一：卸载ipmi模块进行规避第一步 rmmod ipmi相关4个module1.停止ipmievd服务：使用root用户执行systemctl stop ipmievd.servicesystemctl disable ipmievd.service2.卸载ipmi相关的module：使用root用户执行rmmod ipmi_ssif.kormmod ipmi_si.kormmod ipmi_devintf.kormmod ipmi_msghandler.ko第二步 持久化该操作用root用户在/etc/modprobe.d/blacklist.conf文件中增加下面四行；如果没有此文件则新建文件blacklist ipmi_ssif.koblacklist ipmi_si.koblacklist ipmi_devintf.koblacklist ipmi_msghandler.ko方案二：升级ipmi模块修复此bug2.重启os后报错起不来【排查方式】报错 error: file '/initramis-4.***aarchb4.img not found'Press any Key to continue…EFI stub: Booting Linux Kernel…EFI stub: Using DTB from configuration tableEFI stub: Exiting boot services and installing virtual address map…对比正常节点后，发现boot目录比正常节点缺少img文件【解决方案】将正常节点boot目录下的文件拷贝至异常节点后，重启异常节点，节点恢复正常redhat OS1.主机内存脏数据写入超时导致主机死机【排查方式】/var/log/message日志，提示： echo 0 > /proc/sys/kernel/hung_task_timeout_secs.【解决方案】修改内存脏页回收参数为红帽推荐值（注意时间单位是百分之一秒，不是秒）vm.dirty_background_ratio = 3dirty_expire_centisecs = 500vm.dirty_writeback_centisecs = 100BUG说明：cid:link_12.系统hang，某个节点出现大量D进程（包含gaussdb进程），页面显示“主机D状态进程数超过阈值”（根因同上）【排查方式】确认方式（注意D前后各有1个空格）：ps -elf | grep " D " | grep xfs根据打印的进程号，分别cat /proc/$pid/stack然后与https://access.redhat.com/solutions/4344841 中的堆栈对比，如果一致，INFO: task kswapd1:443 blocked for more than 120 seconds."echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.3.其他已知BUG导致系统hang【排查方式】messages日志kernel BUG at fs/gfs2/glock.c:249!表明触发了操作系统BUG：https://access.redhat.com/solutions/6712151messages日志kernel BUG at fs/xfs/xfs_aops.c:1062!表明触发了操作系统BUG：https://access.redhat.com/solutions/2779111Suse OS1.守护进程feed_watchdog重启引起OS重启【排查方式】集群在执行升级FIM相关步骤后，DN-01节点每20min重启一次，导致内核mppdb无法升级，回退FIM升级步骤后，DN-01节点不再重启，检查watchdog.log日志，每隔20min报错（与os重启时间刚好匹配）：setup_timer_feed_watchdog echo * * * * * sh /var/lib/sudo/Bigdata/sudo/runtime/sudoExecute.sh wdt_running > /dev/null 2>&1 & >> /var/spool/cron/root failed!【解决方式】关闭watchdog相关案例：cid:link_72.kernel.hung_task_panic=1导致hang该参数原理解释：创建一个内核线程(khungtaskd)，定期(120)唤醒后，遍历系统中的所有进程，检查是否存在处于D状态超过120s(时长可以设置)的进程；如果存在，则打印相关警告和进程堆栈。如果配置了hung_task_panic（proc或内核启动参数），则直接发起panic。D状态进程：D 即 disksleep,一般是由于等待IO资源时，获取不到资源时，进程会处于该状态。OS配置了hung_task_panic检测参数，会定期检测系统的D状态进程，如果进程处于D状态超过120s，就会自动触发OS的panic。【解决方式】关闭该OS参数，将kernel.hung_task_panic置为0即可。该参数已在最新巡检工具中，可以通过巡检工具一键整改。麒麟OS1.文件句柄数多，导致操作系统重启【排查方式】1.多个节点有告警，显示文件句柄数过多，Too many open files in system；OS自动重启后恢复2.查看os的参数file-max为64万，message日志里边也有显示句柄数超过64万的日志【解决方式】1.降低业务并发2.定时清理空闲连接 clean connection to all for database dbtest;3.修改操作系统配置的最大文件句柄数file-max4.集群重启后恢复相关案例：cid:link_82.其余OSbug导致重启巡检时服务器重启，vmcore-dmessage提示ifconfig软锁，需打OS补丁解决cid:link_6

一、版本：HCS DWS8112二、问题背景： 1.运维人员发现很多节点得盘使用率快到90% 2.进入相应路径，根据du -sh *找到占用空间大的库oid 3.进入库得路径里，ll *.800有一个结果，其他节点按照此法，也找到一个大文件 4.连上对应dn实例库，通过pg_class找到大文件对应得是一张临时表 5.到cn上删除该临时表，由于临时表只在当前会话有效，所以不能删除三、定位过程 1.手动在cn节点执行：gs_clean -a -e -v -p 25308 -r > /home/omm/gs_clean.log  2.打开gs_clean.log，语句drop schema if exists pg_temp_cn_xxxx卡住 3.连上该cn库，select * from pg_stat_activity where query like '%drop语句%';得到pid 4.根据上一步得pid查询等待视图，发现在等6445，一共在等8个dn 5.连上dn6445，在活跃视图里查询drop schema...，根据pid查询等待视图和锁视图，等待视图得wait_status为acquire lock，在等锁6.根据上一步锁视图得classid，在pg_class里查找出，对应得对象是表空间 7.根据第4步得到得objid，在pg_namespace查找，对应得schema名为正在drop得schema名 8.继续查询锁视图，where条件用第5步得objid过滤，granted为t得表示持锁，然后找到对应pid，查询活跃视图，找到持锁语句为inset into 9.根据上一步得到得活跃语句得query_id，在cn库里查询，结果为0，表示该insert into语句在dn上残留 10.在dn上杀掉该会话 11.重复执行第3-10步，直到第4步得wait_status结果为空 12.再次查看gs_clean.log，已成功删除，磁盘空间也下降  

GaussDB 8.1.1.3线下版本集群，如何对接OBS使用？

【问题版本】 8.2.0【问题描述】 单表单点查询语句, 偶发从80ms劣化到3s【问题影响】 用户一个作业中执行多条SQL, 这个作业执行耗时超过10s, 业务侧触发告警机制.【分析过程】1. 打开TOPSQL进行观察enable_resource_track = onresource_track_duration = 2 --将执行时间超过2s的SQL记录到TOPSQL，根据实际情况设置2. 再次发现SQL劣化后，比较TOPSQL中查询计划与正常performance计划--从TOPSQL中查找执行计划select query_plan from pgxc_wlm_session_info where query like '%XXXX%';--查看当前执行计划explain performance YourQuery;两者计划一致，说明不是查询计划劣化导致。3. 继续分析TOPSQLblock_time - 多次劣化语句的block_time都小于5ms，说明不是SQL排队导致。min_dn_time - 多次劣化语句的min_dn_time（执行最快的DN执行时间），可以看出3s是慢在DN上说明，相同的执行计划，执行快与慢时，卡点在DN资源上。4. 分析执行慢时DN资源情况a. 当时活跃会话数156, 是平时两倍b. 当时所有节点CPU都在90%, 是平时两倍5. 从TOPSQL统计当时stream数也较高【分析结论】当时业务并发压力大, CPU高, 每个SQL被分到执行时间片较少, 导致执行慢.【修复建议】1. 从业务角度, 看压力是否能均匀分布.2. 当前SQL查询未使用分布键, 扫描了所有分区. 使用分布键后IO明显降低, 执行时间从80ms优化到30ms. 预期并发劣化也能从3S变成1.2S左右, 可以满足需求.降低SQL执行时间来减少并发带来的劣化影响.

 --创建测试表  drop table if exists test_20190904; create table test_20190904(id int, c1 varchar2(10)); insert into test_20190904 select 1,'a'; insert into test_20190904 select 2,'b'; insert into test_20190904 select 3,'c'; insert into test_20190904 select 4,'d'; insert into test_20190904 select 5,'e';  --存储过程返回表：  --方法1  CREATE OR REPLACE FUNCTION func_return_table1(num in int default 1) RETURNS TABLE(a integer,b varchar2(10)) AS $$  declare query_str text; BEGIN query_str := 'select id ,c1 from test_20190904 limit '||num; return query execute(query_str); END; $$ LANGUAGE plpgsql;  select * from func_return_table1(2);  --方法2  CREATE OR REPLACE FUNCTION func_return_table2(num in int default 1) RETURNS SETOF t1 AS $$ DECLARE    r t1%ROWTYPE; BEGIN    FOR r IN select id,c1 from test_20190904 limit num    LOOP       RETURN NEXT r;    END LOOP;    RETURN; END; $$ LANGUAGE PLPGSQL;   select * from  func_return_table2(2);  --方法3  CREATE OR REPLACE FUNCTION func_return_table3(num in int,out a integer,out b varchar2(10)) RETURNS SETOF record  AS $$ declare  row_data record; BEGIN  FOR row_data IN (select id,c1 from test_20190904 limit num)  LOOP    a = row_data.id;    b = upper(row_data.c1);     return next;     END LOOP; return; END; $$ LANGUAGE plpgsql;  select * from func_return_table3(2);  --方法4  CREATE FUNCTION func_return_table4(num integer) RETURNS setof test_20190904     AS $$ DECLARE   a int;   b varchar2(10); --定义游标   CURSOR C1 IS (SELECT * FROM test_20190904 limit num); BEGIN     OPEN C1;--打开游标    LOOP         --通过游标取值         FETCH C1 INTO a,b;         EXIT WHEN C1%NOTFOUND;         --输出结果         DBMS_OUTPUT.PUT_LINE(a||'|'||b);     END LOOP;    CLOSE C1;--关闭游标 end$$  LANGUAGE plpgsql;  select * from func_return_table4(2);  --方法5  CREATE OR REPLACE FUNCTION func_return_table5(num in int) RETURNS setof test_20190904 AS  $$  DECLARE  result record;  BEGIN  for result in (SELECT * FROM test_20190904 limit num)  loop     return next result;    end loop;  return;  END;  $$ LANGUAGE plpgsql;  select * from func_return_table5(2);  --方法6  CREATE OR REPLACE FUNCTION func_return_table6(num in int) RETURNS SETOF test_20190904 AS $$  SELECT * from test_20190904 limit num;  $$ LANGUAGE 'sql';   select * from func_return_table6(2);  --方法7  CREATE OR REPLACE FUNCTION func_return_table7(num in int) RETURNS SETOF test_20190904 AS $$ BEGIN    RETURN QUERY SELECT * from test_20190904 limit num; END; $$ language plpgsql;  select * from func_return_table7(2); 

--查询用户对哪些库有哪些权限select a.datname,b.rolname,string_agg(a.pri_t,',') from(select datname,(aclexplode(COALESCE(datacl, acldefault('d'::"char",datdba)))).grantee as grantee,(aclexplode(COALESCE(datacl, acldefault('d'::"char", datdba)))).privilege_type as pri_tfrom pg_database where datname not like 'template%') a,pg_roles b where (a.grantee=b.oid or a.grantee=0) and b.rolname='omm' group by a.datname,b.rolname;--用户和schema的权限信息SELECT n.nspname AS "Schema",pg_catalog.pg_get_userbyid(n.nspowner) AS "Owner",pg_catalog.array_to_string(n.nspacl, ',') AS "Access privileges"FROM pg_catalog.pg_namespace nWHERE n.nspname !~ '^pg_' AND n.nspname <> 'information_schema'ORDER BY 1;-- 哪些用户对表test的操作权限select table_catalog as datname,grantor as table_owner,table_schema,table_name,grantee as role_priv,privilege_type from information_schema.role_table_grants where grantee <> grantor and table_name = 'test';--哪些用户对表test的哪些字段的操作权限select * from information_schema.role_column_grants where table_name='test' and grantor <> grantee order by 1,2;

【问题现象】：    重分布失败报错：The size of CU is larger than 1GB,please lower the GUC check_cu_size_threshold and retry to insert【问题版本】：    8.1.3.200【解决方法】：1）设置 check_cn_size_threshold 为512MB 然后重新拉起缩容：   gs_guc reload -Z datanode -Z coordinator -N all -I all -c 'check_cn_size_threshold=512MB'2）查询相关表成功   可以在$GAUSSLOG/bin/gs_redis/gs_redisxxxx.log日志里面查看之前报错的表是否还报错：   grep '$tabname' gs_redisxxx 3）等相关表成功后，将参数修复为1G：  gs_guc reload -Z datanode -Z coordinator -N all -I all -c 'check_cn_size_threshold=1GB'

GaussDB A 8.1.1.3版本集群为什么建议大表update或大量不同表的update 改成delete加insert实现？

【问题现象】：    重分布的时候，报主键索引重建失败：    REINDEX TABLE XXXX SET (append_mode=read_only) ERROR: dn_6181_6182: could not create unique index "xxxxx_pk“【问题版本】：    8.1.3.200【规避方案】：1、查询表定义（\d+ $table）,找到索引列对应的字段2、用找到的字段查询（如：id）$table=lts.lts_task_t groupselect id::text ,count(1) as num from lts.lts_task_t group by 1 having num >1;3、随意再找另一个非空字段（如：tsk_group_id）排查SELECT xc_node_id,tsk_group_id,xmin FROM lts.lts_task_t WHERE id::text::bigint = 44727;4、起事务执行（tsk_group_id以及xmin均为第3步查出的结果）start transaction;select tsk_group_id from lts.lts_task_t where tsk_group_id=1118 and xmin=9247872954;---查出唯一1条记录时再进行删除delete job_id from lts.lts_job_running_log_t where job_id=15 and xmin=9247873466;commit;

问题现象：       逻辑集群缩容失败，但是界面不能重入，比如LC_DL1逻辑集群缩容失败，但是编辑灰色集群版本：      8.1.3.200解决方法：1）登录rms数据库修改集群信息，SQL如下：update rds_cluster set logicalClusterInitialed=false where id='$clusterid';select * from logical_cluster where cluster_id='19fc6607-0936-4734-aad8-90e2d7129972' and name='LC_DL1';update logical_cluster set action_info=null where cluster_id='$clusterid ' and name='$lgclusteriname ';2）修改后界面进行编辑重试；

GaussDB A 纯软场景线下那个版本有物化视图？