问题现象使用FusionCompute对Cube下电后，数据平台GaussDB无法正常启动。原因分析使用FusionCompute批量提交关闭电源后，FusionCompute关闭虚拟机时异步的操作，高斯主备双机可能不是同时关闭的。例如主机先关闭，这个时候备机还没有关闭，这样就会导致触发双机切换动作，产生lock文件。lock文件产生后，备机还没有成功切主机，备机又被FusionCompute关掉，这样就会导致Lock文件遗留。等到上电时，双机检测就会产生异常。解决方法上电之后，以root用户分别登录GaussDB的主备机检查GaussDB的状态。# su - gaussadmin21.0之前的版本使用gaussdba。$ gs_ctl query然后分别在主备双机上执行gs_ctl query查看高斯数据库的状态是否为normal，角色是否正确。主机： Ha state: LOCAL_ROLE : Primary STATIC_CONNECTIONS : 1 DB_STATE : Normal DETAIL_INFORMATION : Normal ......备机： Ha state: LOCAL_ROLE : Standby STATIC_CONNECTIONS : 1 DB_STATE : Normal DETAIL_INFORMATION : Normal .....如果不是normal状态，继续下一步定位。以root用户分别登录主备机检查双机日志。检查/data01/keepalived/bin/keepalive_chk_gaussdb.log日志中是否一致在打印check lock file exist,stop switch日志。如果存在，进入到/data01/keepalived/bin目录下删除primary.lock或者standby.lock文件。等待一会后参考1检查双机状态。

以下两种方式二选一即可：自动化配置工具：cid:link_0手动配置步骤：1、以root用户登录OMS主节点切换至tmp路径下su - rootcd /tmp2、在新建目录下创建core.sh脚本，内容如下：sed -i '/^.*hard.*core.*$/d' /etc/security/limits.confsed -i '/^.*soft.*core.*$/d' /etc/security/limits.confecho "* soft core unlimited" >> /etc/security/limits.confecho "* hard core unlimited" >> /etc/security/limits.confsed -i "/fs.suid_dumpable/d" /etc/sysctl.confecho "core" > /proc/sys/kernel/core_patternsed -i '/^kernel.core_pattern.*$/d' /etc/sysctl.confecho "kernel.core_pattern=core" >> /etc/sysctl.confecho "fs.suid_dumpable = 1" >> /etc/sysctl.confecho "kernel.core_uses_pid=0" >> /etc/sysctl.conf/sbin/sysctl -p3、在新集群OMS主节点借助批量执行工具，配置集群所有节点core，用root执行如下命令即可分开命令执行core配置dos2unix /tmp/core.shcd /opt/FusionInsight_SetupTool/preinstall/tools/cluster./clusterscp.sh put /tmp/core.sh /tmp/./clustercmd.sh "sh /tmp/core.sh" 4、kill om_monitor重启集群后检查core配置是否生效gs_ssh -c "killall -u omm om_monitor"检查配置是否生效：1) ps -ef|grep masterx,找到进程号2) cd /proc/进程号。3) view limits4) cat /proc/sys/kernel/core_pattern5、 验证是否成功kill -11 从备DN进程号，查看对应实例目录下是否有core文件产生。 

【操作步骤&问题现象】GaussDB 产品是否可以部署在  海光、飞腾、龙芯、申威服务器上？有没有可以查询的兼容性列表？

1.环境检查及命令参考1、查询登录运维容器。kubectl get pod -n dws-maintain 2、登录运维容器。kubectl  exec -ti <容器名称> /bin/bash -n  dws-maintain3、登录数据库。mysql -h<数据库地址> -P <端口> -u<用户名> -p<密码>4、根据集群ID查询实例节点名称，'***'表示集群ID。select name from rds_instance where clusterId = '***';5、登录实例节点。 cd opsToolsh connectTool.sh -u<用户名> -d<数据库名> -h<数据库地址> -p<端口> -n<实例节点名称> -t Standalone 6、切换Ruby用户su - Ruby7、查看数据库状态是否为Normalcm_ctl query -Cv2 配置os core步骤1： 本步骤之前，可以执行以下命令，测试是否开启了bbox core：gs_guc check -Z coordinator -Z datanode -N all -I all -c "enable_bbox_dump"如结果为off，可以跳过此步。如结果为on，执行以下命令关闭bbox core:gs_guc reload -Z coordinator -Z datanode -N all -I all -c "enable_bbox_dump=off"步骤2：通过ftp将zip文件上传至EICOMMOM节点/root目录下 （请在附件下载zip文件)在EICOMMOM节点，执行如下命令上传文件至maintain容器下opsTool目录下。kubectl cp /root/modify.zip dws-maintain/dwsmaintaintool-xxxxxxxxxxxx:/opt/cloud/3rdComponent/opsTool/modify.zip注意：根据实际情况修改红色容器名称步骤3：登录运维容器，解压软件并配置modify软件。kubectl  exec -ti dwsmaintaintool-xxxxxxxxxxxx /bin/bash -n  dws-maintaincd opsToolunzip modify.zipcp -rp AESTool.jar config modify/cd modifydos2unix *chmod +x *.py *.sh注意：根据实际情况修改红色容器名称步骤4：获取需要修改的实例id和实例名称mysql -uecf –p数据库密码 –h数据库ip -P7306 rms -s -N -e "select i.id,i.name from rds_instance i,rds_cluster c where c.id=i.clusterid and i.status=200 and c.name='集群名'" > dws_instances.txt注1：红色部分请根据实际情况填写注2：如果只修改部分实例，需修改dws_instatnces.txt文本dws_instatnces.txt示例如下图所示步骤5：根据实际情况更新conf，包含节点相关配置信息，内容如下：USER="ecf"HOST="xxxx.xxxx.xx.xx"PORT="7306"DATABASE="rms"PASSWORD="xxxxxxxx"mysql = /bin/mysql步骤6：执行以下命令批量配置core文件./modify_instance.py -s core.sh -r false3 重启相关进程，使配置生效。步骤1：登录任意cn节点执行以下命令进入沙箱su - Rubyssh `hostname -i`步骤2：执行以下命令，重启om_monitor、重启集群：1）gs_ssh -c "killall -u Ruby om_monitor"2）连接cn执行：checkpoint;3）cm_ctl stop && cm_ctl start4 验证配置结果，确认配置成功kill -11 从备dn进程号，检查对应的数据目录下是否生成core文件。 

>摘要：为了解决Roach的性能问题，提出了CN增量备份手段，从而达到进一步优化RPO目的。本文分享自华为云社区《[GaussDB(DWS)备份容灾之CN增量备份](https://bbs.huaweicloud.com/blogs/280676?utm_source=csdn&utm_medium=bbs-ex&utm_campaign=ei&utm_content=content)》，作者： zxy_db 。 # 1. 摘要 在数据量增大时，如果CN每次都做全量备份，则会导致每次的备份数据量很大，不仅会降低备份的性能，也从造成备份集恢复性能的降低。如果改成CN增量备份，则备份集只会备份差异数据，这样不仅会使得备份数据量变小，而且也会提升备份集恢复的性能。 # 2. CN备份原理 对于主备集群CN备份与恢复的过程，如下图所示：  - 在备份过程中，只备份主CN的数据，且只发送到备集群对应的主CN所在的节点上。 - 在恢复过程中，非主CN节点从主CN节点上拷贝rch文件，然后再将备份数据的rch文件恢复到实例目录。 - CN备份同集群备份一样，先进行行存备份，后进行列存备份。 对于行存备份过程，首先是准备列表，然后备份文件。 准备列表主要分为3个步骤：第一步是获取CN备份类型，第二步是根据备份类型，决定LSN区间，第三步是根据LSN区间，准备备份列表(全量备份列表和增量备份列表)。 对于列存备份过程，同上述行存。 行存和列存区别在于增量备份LSN区间的取法： 行存文件来说，增量是上次startLSN到本次startLSN之间 列存文件来说，增量是上次barrierLSN到本次barrierLSN之间 # 3. CN备份判断逻辑 1. 首先，CN增量需要有一个基础备份，因此，集群在做全量备份时，CN仍然做全量备份。 2. 其次，集群在两次增量备份过程中，CN发生删除和加回后，新增的CN需要做全量备份。 对于支持异构的情况下，如果ID最小的CN发生变化，同样需要对CN做一次全量备份。 整体的备份逻辑如下图所示。  3.为了实现上述判断逻辑，通过创建标志文件backup_label.old来控制CN做全量备份还是增量备份。backup_label.old在Python侧创建。即在Python侧，调用gs_roach备份前，在最小的CN上，即要进行备份的CN上，创建backup_label.old文件。根据backup_label.old的修改时间和priorBackupKey转化的时间，判断CN做增量备份还是全量备份。流程图如下图所示。如右半部分所示，如果backup_label.old文件的修改时间比prriorBackupKey转换获得的时间大，则进行全量备份。否则，进行增量备份。  # 4. CN备份技术应用实测 ## 4.1 CN删除和加回后做全量备份 初始状态，ecs-env-3038节点上的CN实例是最小CN编号，即主CN  第一步：修改XML配置文件xml,将主CN对应主机上的cooNum值从1改为0  第二步：使用gs_om工具执行删除CN操作 gs_om -t managecn -m delete -X /data1/xml/3_node_3.xml  第三步：将要加回CN对应主机上的cooNum值从0改为1 第四步：使用gs_om工具执行加回CN操作 gs_om -t managecn -m add -X /data1/xml/3_node_3.xml  删除和加回后，主CN的变化情况：  主CN由节点ecs-env-3038变为节点ecs-env-2998. 此时查看日志可以发现，由于CN发生了增删，集群做增量备份时，CN做全量备份。  ## 4.2 备份集大小变化 第一步：拉起容灾，CN增量备份阶段停止容灾； 第二步：创建大量数据库和空表； 第三步：连续执行增量备份，增量备份中途不插入任何数据。 如下图所示，不增加数据，增量备份集大小小于全量备份集大小  # 5. 技术总结 本文主要从技术价值、应用场景、技术原理、技术实测展示几个维度对GaussDB(DWS) CN增量备份技术进行了剖析，可以看到增量备份是对已有全量备份恢复的一个有效的增强，可以节省宝贵的备份存储空间和cpu资源，同时达到进一步优化RPO目的，因此该技术拥有较为广阔的前景和深远的意义。

【问题现象】某现网环境高频出现随机DN报错“memory is temporarily unavailable”，且日志中显示当前使用内存最大的theadid是0，使用内存也是0，而非正在执行的正常SQL。----debug_query_id=xxxxx, The abnormal query thread id 0.It current used memory is 0 MB and estimated memory is 0 MB.It also is the query which costs the maximum memory.【排查方法】1、连接曾经报错的任意DN查询pv_total_memory_detail信息执行SQL：select * from pv_total_memory_detail;   nodename     |       memorytype                    | memorymbytes-----------------+-------------------------------+-------------- dn_6021_6022 | max_process_memory           |        40960 dn_6021_6022 | process_used_memory          |        7885 dn_6021_6022 | max_dynamic_memory          |       17210 dn_6021_6022 | dynamic_used_memory         |       17212 dn_6021_6022 | dynamic_peak_memory         |       17212 dn_6021_6022 | dynamic_used_shrctx             |       90 dn_6021_6022 | dynamic_peak_shrctx             |       90 dn_6021_6022 | max_shared_memory             |       7365 dn_6021_6022 | shared_used_memory            |       3586 dn_6021_6022 | max_cstore_memory              |       16384 dn_6021_6022 | cstore_used_memory             |       1664 dn_6021_6022 | max_sctpcomm_memory       |       4000 dn_6021_6022 | sctpcomm_used_memory      |       80 dn_6021_6022 | sctpcomm_peak_memory      |       103 dn_6021_6022 | other_used_memory              |       584 dn_6021_6022 | gpu_max_dynamic_memory  |       0 dn_6021_6022 | gpu_dynamic_used_memory |       0......发现报错时dynamic_peak_memory已经超过max_dynamic_memory，且sctp等其他内存较小，可判断为业务SQL动态内存使用多导致2、连接曾经报错的任意DN，通过pv_session_memory_detail和pg_stat_activity的关联查询获取各session使用内存信息执行SQL：select sessid,contextname, pg_size_pretty(totalsize) as total ,pg_size_pretty(freesize) as freesize, pg_size_pretty(usedsize) as usedsize, datname,state, substr(query,1,50) from pv_session_memory_detail a , pg_stat_activity b where split_part(a.sessid,'.',2) = b.pid order by totalsize desc limit 50;           sessid                                |      contextname               |  total        | freesize   | usedsize   |      datname    | state  |                       substr------------------------------------+---------------------------+-----------+----------+-----------+----------------+------+---------------------------------------------------- 1646898616.139665138407168 | CacheMemoryContext     | 274 MB  | 1257 KB   | 272 MB  | postgres          | idle   | select * from xxxx 1646883079.139665289430784 | CacheMemoryContext     | 274 MB  | 1270 KB   | 272 MB  | postgres          | idle   | select * from xxxx 1646895016.139672582272768 | CacheMemoryContext     | 272 MB    | 272 MB    | 907 KB     | postgres          | idle    | COMMIT PREPARED 'T32714470_cn_5003'监控发现占用total内存高的是一些idle线程的CacheMemoryContext。3、在CN执行清理空闲连接的操作执行SQL ：clean connection to all force for database “CacheMemoryContext高的datname”执行后发现该DN pv_total_memory_detail中的dynamic_used_memory迅速降低，但是很短时间内又再次飙升说明：历史上有一些场景CacheMemoryContext是缓慢增长，这种可以定期clean connection解决此类问题，但是本次问题仅靠clean connection无法解决4、连接曾经报错的任意DN，通过pv_session_memctx_detail打印CacheMemoryContext占用高session的具体内存占用信息执行SQL：select pv_session_memctx_detail(139665138407168,'');查看信息：vim /tmp/dumpmem/139672582272768_xxxx.logTopMemoryContext, 25926984, 20978856heap sync rel table, 8192, 768Record information cache, 24576, 13904TableSpace cache, 8192, 1280Type information cache, 73216, 1808CONST_COMPARE_CONTEXT, 0, 0VecFuncHash, 138504, 19904MaskPasswordCtx, 8192, 8144RowDescriptionContext, 8192, 7104MessageContext, 8192, 7104Operator class cache, 24576, 16080smgr relation table, 8380416, 1372928tokenize file cxt, 0, 0hba parser context, 7168, 1136TransactionAbortContext, 32768, 32720bad block stat thread hash table, 8192, 640bad block thread memory context, 0, 0Portal hash, 24576, 16080PortalMemory, 8192, 8144Partcache by OID, 2088960, 865232Relcache by OID, 4186112, 525232CacheMemoryContext, 285876704, 227989440pg_namespace_oid_index, 3776, 280pg_cudesc_part_3668144_index, 5824, 1808pg_cudesc_part_3668143_index, 5824, 1808pg_cudesc_part_3668142_index, 5824, 1808pg_cudesc_part_3668141_index, 5824, 1808pg_cudesc_part_3668140_index, 5824, 1808pg_cudesc_part_3668139_index, 5824, 1808pg_cudesc_part_3668138_index, 5824, 1808pg_cudesc_part_3668137_index, 5824, 1808pg_cudesc_part_3668136_index, 5824, 1808pg_cudesc_part_3668135_index, 5824, 1808pg_cudesc_part_3668134_index, 5824, 1808pg_cudesc_part_3668133_index, 5824, 1808pg_cudesc_part_3668132_index, 5824, 1808pg_cudesc_part_3668131_index, 5824, 1808pg_cudesc_part_3668130_index, 5824, 1808pg_cudesc_part_3668129_index, 5824, 1808pg_cudesc_part_3668128_index, 5824, 1808pg_cudesc_part_3668127_index, 5824, 1808pg_cudesc_part_3668126_index, 5824, 1808pg_cudesc_part_3668122_index, 5824, 1808......发现某些表pg_cudesc的index过多（1w+）,导致内存占用过大【触发场景】机制说明：列存表有对应的cudesc表管理记录列存的cu信息，而列存分区表每个分区都有各自的cudesc，且每个cudesc都有自己的索引，当访问这些表时，CacheMemoryContext会加载所有的cudesc index信息。场景说明：现场存在一些列存且分区非常多的表（3000-6000分区），对应的cudesc index也非常多，当业务中经常访问这些表时，就会触发CacheMemoryContext缓存大量cudesc的索引，导致内存占用过大。【解决方案】本问题只要列存多分区表的查询业务起来，CacheMemoryContext增长非常快，仅靠clean connection无法解决，需要通过调整这类列存表的分区间隔、删除无用分区以减少分区个数后，再通过clean connection清理idle连接，最终解决。

帖子标题链接玩转PB级分布式数仓GaussDB(DWS)性能调优黑科技cid:link_0玩转PB级数仓深度调优之依“计”行事GaussDB(DWS)性能调优cid:link_1GaussDB(DWS)安全与权限设计cid:link_2GaussDB(DWS) 补丁、升级及扩容流程cid:link_3GaussDB(DWS) 备份与恢复cid:link_4GaussDB(DWS) 日常巡检cid:link_5GaussDB(DWS) 常见问题三板斧cid:link_6【云小课】不可不知的调优技巧-GaussDB(DWS)表结构优化cid:link_7

帖子标题链接玩转PB级数仓磁盘空间使用cid:link_0程序猿的世界没有单身汪，数仓界达芬奇带您手动设计心仪对象cid:link_5“绿波带”，华为云数仓给您开绿灯cid:link_6GaussDB(DWS) 数据迁移cid:link_7GaussDB(DWS) SQL进阶及应用开发指南cid:link_8GaussDB(DWS)事务、锁机制管理https://bbs.huaweicloud.com/forum/forum.php?mod=viewthread&tid=180947GaussDB(DWS)资源负载管理cid:link_9三步搞定PB级数仓空间回收cid:link_2【云小课】运筹帷幄-GaussDB(DWS)教你分析阻塞SQL的几个妙招cid:link_10【云小课】打造企业数据“高内聚，低耦合”--试试GaussDB(DWS)逻辑集群，实现数据物理隔离cid:link_11【云小课】GaussDB(DWS)数据落盘安全吗？来直面三大灵魂拷问！cid:link_12【云小课】大数据时代的隐私利器-GaussDB(DWS)数据脱敏cid:link_13统计信息大揭秘，SQL执行优化之密钥cid:link_3数仓过载不用愁，资源管理帮分忧cid:link_4

帖子标题链接从数据仓库发展史浅析数仓未来技术趋势cid:link_6探秘华为云数仓GaussDB(DWS)核心技术cid:link_7GaussDB（DWS）产品介绍cid:link_8GaussDB(DWS)集群部署与管理cid:link_9GaussDB(DWS) 数据库对象设计cid:link_10【云小课】如何通过Data Studio连接数据仓库？https://bbs.huaweicloud.com/forum/forum.php?mod=viewthread&tid=69901【云小课】数据量太大？试试使用GDS并行导入GaussDB(DWS)https://bbs.huaweicloud.com/forum/forum.php?mod=viewthread&tid=72416【云小课】车海茫茫中寻找你--GaussDB(DWS)海量数据分析https://bbs.huaweicloud.com/forum/forum.php?mod=viewthread&tid=73654【云小课】大数据融合分析：GaussDB(DWS)轻松导入MRS-Hive数据源cid:link_11数仓本地及上云的对比及为何选择华为数仓?cid:link_16【资料汇总平台】智能数据信息中心cid:link_17华为云GaussDB(DWS)视频演示——导入MRS数据源cid:link_18华为云GaussDB(DWS)视频演示——交通卡口数据分析cid:link_19华为云GaussDB(DWS)视频演示——使用GDS导入数据cid:link_20GaussDB(DWS) 补丁、升级及扩容流程培训cid:link_12送一套环境，手把手教会您驾驭云数仓cid:link_13送一套环境，教您数据上云，分析无忧cid:link_14送一套环境，教您掌握工作负载管理，玩转云数仓cid:link_15玩转PB级数仓磁盘空间使用cid:link_0一招鲜，锁与权限为您的数仓保驾护航cid:link_1深度解析集群高可用设计及监控告警cid:link_2

本讲为您总结了华为云数仓GaussDB(DWS)在集群，sql，内存方面的常见问题的定位思路及实战演练 。

本讲介绍GaussDB(DWS) 日常巡检。

本讲主要讲了GaussDB(DWS) 的备份恢复工具Roach，介绍了其运作原理，操作命令，注意事项等。

本讲主要介绍GaussDB(DWS)如何打补丁，升级及扩容，有哪些注意事项等。 

本讲围绕华为云数仓GaussDB(DWS) 数据安全的核心问题：谁能看？能看啥？看没看？依托分布式架构，逐层为您解答，透明加密，数据加密，三权分立，行列及控制，用户管理，私有用户等概念 

本讲为您介绍华为云数仓GaussDB(DWS) 调优的基本理论、常见的SQL性能问题的定位手段和解决方案