【问题现象】    使用一个只读权限（ReadOnly）账号访问console，提示DWS.0032当前用户没有操作权限，请通过IAM检查账户权限【常见版本】全版本   【定位思路】   1、定位未开启细粒度鉴权开关2、登录CDK修改dwscontroller如下两个参数pdp.authenticationEnable 修改false->trueliveness_probe.perriod_seconds 修改在原有数值加1

目前FusionInsight Manager备节点故障，OMS备份任务不成功，查看  backupplugin.log 文件内容，则显示 OMS backup failed, std is start OMS backup.erro is Backup remote files error.backup files errorBackup Failed.从信息上看，需要主备节点状态都正常时才能备份，我备节点的 /srv/BigData/dbdata_om 目录文件系统错误，也就是Manager的数据文件没有了，所以找不到远程的文件。那么请问，如何只备份一个节点的OMS呢，也就是备份那个节点状态正常节点为的OMS数据。

目前部署的是双机 FusionInsight Manager，有一个节点的 /srv/BigData/dbdata_om目录出现文件系统损坏，无法修复 ，只能重新格式化文件系统，所以请教一下如何修复 FusionInsight Manager节点？

产品文档关于内存的概述分为max_process_memory、work_mem、shared_buffer、cstore_buffer，我看了下大概都是在做查询的时候用到的。请问一个新建的表，然后批量插入数据，这个时候用的内存缓冲区是由哪个参数控制的，是使用cn上的内存还是dn上的，达到多大开始落盘

版本： HCS 8.5.0现象： EICommon-Region-Master root 账户频繁锁住影响： 需要登录 EICommon-Region-Master root 用户的场景，例如登录rms查询后台日志、ECF 虚拟机安全加固工步等ECF 虚拟机安全加固工步报错场景页面点开错误详情如下：错误信息123011,执行交互式命令失败，返回消息中有error字段：ip:xx.xx.xx.xx，error为：The password is wrong or the account has been locked其中ip的值为三个EICommon-Region-Master节点中的一个.规避办法登录节点确认是否在切换root用户时上锁。每个节点上锁时间可能是不同了，也可能没有上锁（已超时解锁）。等待锁解除后切root（登录后如果不马上操作最好先用top保持住root用户）cd /etc/sudoers.d/cat dws_* 看一下是否缺少如下配置monitor ALL=(root) NOPASSWD: /usr/bin/kubectl get node monitor ALL=(root) NOPASSWD: /usr/bin/kubectl get pod --all-namespaces monitor ALL=(root) NOPASSWD:SETENV: /var/paas/kubernetes/kubectl确认缺少配置后，在当前目录（/etc/sudoers.d/）下新增一个文件 dws_pod_health_check，将上配置写入保存三个节点都做同样处理重试工步，并可以同时观察一下节点是否还会在切root时锁住没有解决的情况以上办法如果无法解决root锁住问题，优先参考《快速定位sudo导致节点被锁》https://3ms.huawei.com/km/blogs/details/12190229

1、Gaussdb(DWS)如何查询DN主实例对应的备实例的数据目录？2、DN主备如何切换，有详细的切换命令是什么？

【话题互动】华为云+DeepSeek可以有哪些使用场景

共享消息队列介绍cid:link_2向共享消息队列中写入消息cid:link_3GaussDB(DWS)功能介绍cid:link_0IO框架原理cid:link_4GaussDB(DWS)行存框架cid:link_5列存的IO管理框架cid:link_6双集群容灾设计cid:link_7分盘存储cid:link_8设置每个线程的临时文件落盘数据量限制cid:link_9为用户设置中间结果集落盘空间限额cid:link_10ODBC 问题定位指南cid:link_11驱动管理器加载驱动失败cid:link_12服务器不可达cid:link_13SSL配置不正确cid:link_1使用开源驱动连接问题cid:link_14 

我们的数据库是支持低版本及开源驱动的（V1R7C10及以后），所以可以放心使用。 但是偶尔一些从V1R6C10升级上来的数据库，接受开源驱动连接时，会碰到用户认证算法不支持的问题，典型报错如下： authentication method 10 not supported. 此问题机理比较复杂，下面详细展开，先说解决办法： 请使用管理新账号新建一个数据库的用户，并给予其相关的访问权限，使用新用户连接数据库。 更改当前业务用户的密码，使用新密码连接数据库。 解释一下此问题发生的机理： 我们的数据库在连接时，是会让客户端将认证信息发过来的。但是发过来的信息不会是明文密码，这是不安全的；客户端发到数据库的认证信息一般是经过加盐后的密码哈希(md5/sha256算法)，迭代次数也非常多。 数据库本身也并不存储用户的明文密码，存储的是一个哈希值（所以密码要是丢了，就真的丢了，只能重置不能找回）。数据库在校验这个密码的时候，是比较哈希的，这就涉及到数据库中存储的哈希是使用的什么算法得到的哈希值，常见的是sha256（高斯自研）及MD5（开源）。 V1R7C00及以前，数据库中只存储了SHA256的哈希，升级时我们也无法推导用户原有密码，所以升级后仍然只有SHA256的哈希；但是开源客户端只识别MD5的哈希，这就导致数据库无法认证；数据库也只会让客户端以SHA256的哈希来做认证，这时开源就不识别该认证请求，导致报出如上的错误。 在创建用户和修改用户密码时，我们的新版本会同时记录两份哈希，所以后续将会同时支持开源及自研的各个版本。

典型报错1： The password-stored method is not supported. 解决办法1： 请将数据源配置中的的sslmode调整至allow及以上级别，允许使用SSL连接。 典型报错2： Server common name "xxxx" does not match host name "xxxxx" 此问题是由于sslmode中使用了全校验(verify-full)，它不仅会校验证书，还会校验证书所在的域名/机器名是否与证书符合，不符合时将报出此问题。 解决办法2： 重新让CA机构以新的域名/机器名签发证书；或者将SSLMODE调整至verify-ca选项或其以下级别（具体级别见产品资料中的说明）。 要处理这个问题，需要将unixodbc的安装目录下的lib，添加到LD_LIBRARY_PATH里，例如： export LD_LIBRARY_PATH=/where/unixodbc/installed/lib:$LD_LIBRARY_PATH 同时，在UnixODBC的安装的lib目录下，看看libodbcinst.so.x后边的后缀是.1还是.2。如果是.2，那么请建立一个软链接，链接到.1，便可以解决此问题。 如果该目录下只有.1的库，没有.2的库，也建议建立一个.2的软链接，防止应用程序依赖于.2，我们依赖于.1，引起冲突。 特别注意，当前会话的LD_LIBRARY_PATH不代表应用程序运行时也是同样的LD_LIBRARY_PATH，必要的时候，与应用程序开发人员对齐。

典型报错： connect to server failed: no such file or directory 此问题可能的原因： 配置了错误的/不可达的数据库地址，或者端口请检查数据源配置中的Servername及Port配置项，确认网络是通达的。 服务器监听不正确如果确认Servername及Port配置正确，请根据资料中listen_addresses参数的配置方法，确保数据库监听了合适的网卡及端口，特别是Servername中指定的网卡地址及LVS的虚拟IP地址。 修改完记得重启数据库，使监听生效。 防火墙及网闸、流控设备 请确认防火墙设置，将数据库的通信端口添加到可信端口中。 如果有网闸、流控设备，请确认一下相关的设置。 此问题一般都是第三方商业产品导致，需要咨询服务/产品提供商相关的策略。 这种勤快的用户比较少见，但是一旦出现，很难定位，典型的报错信息是： Driver's SQLAllocHandle on SQL_HANDLE_DBC failed 这种情况这时应用与驱动加载的是不同的物理文件，便会导致两套完全同名的函数列表，同时出现在同一个可见域里（UnixODBC的libodbc.so.*的函数导出列表完全一致），产生冲突，无法加载数据库驱动。

Windows最常见x86与x64架构不同导致的加载失败；此问题的典型报错为： 在指定的 DSN 中，驱动程序和应用程序之间的体系结构不匹配 此问题可能的原因：在64位程序中使用了32位驱动，或者相反。 在64位系统上： C:\Windows\SysWOW64\odbcad32.exe：这是32位ODBC驱动管理器。 C:\Windows\System32\odbcad32.exe：这是64位ODBC驱动管理器。 使用不同架构的应用程序时，请使用不同的驱动管理器；同时安装不同的驱动类型。 32位系统上只能跑32位程序，也无法安装64位驱动，所以基本不用区分。 如果是64位系统，那么它既支持32位程序，也支持64位程序；如果不能确定应用程序是32还是64，可以使用以下办法： ctrl + shift + esc 打开任务管理器。Linux环境中缺少psqlodbcw.so的库一般这个问题的报错是 [UnixODBC][Driver Manager]Can't open lib 'xxx/xxx/psqlodbcw.so' : file not found. 可能的原因有： odbcinst.ini中配置的路径不正确，最简单的办法是  ls -l 一下这个报错的文件，看看这个是不是真的存在，同时具有执行权限。

用户的应用程序，调用的ODBC的API，其实是由驱动管理器提供的，这个驱动管理器在微软上就是odbcad32(.exe/.dll)，在Linux上就是UnixODBC。再由它们来调用ODBC的具体驱动（Gauss、Oracle、TD……）。所以一般问题基本会出在以下几个方面：应用加载驱动管理器驱动管理器加载驱动驱动连接数据库应用程序加载驱动管理器失败Windows Windows由于操作系统实现机制的问题，ODBC属于操作系统组件的一部分，除非操作系统损坏，一般不会出现应用程序加载驱动管理器失败；只会出现驱动管理器加载驱动失败。所以本文不再赘述。LinuxLinux上应用程序加载驱动管理器，是指的应用程序依赖于UnixODBC的相关动态库，启动时要将其加载到自己的进程空间中。加载出现问题多表现为在启动时找不到libodbc.so.x/libodbcinst.so.x等库。 解决此问题： 首先确认环境中是否安装了UnixODBC。如果安装了，那么至少会有isql/odbcinst等工具可用。例如可使用which isql这样的命令来确定安装路径。相关的lib库一般会在which isql指定的bin目录的同级目录下，将其添加到LD_LIBRARY_PATH中重启应用程序便可。 export LD_LIBRARY_PATH=/where/unixodbc/installed/lib:$LD_LIBRARY_PATH 特别注意，此语句只影响当前shell会话中的后续命令，其他会话不受影响，特别是后台启动的进程。如果是后台进程，请与应用程序的开发人员确认其运行环境如果修正。 如果确认LD_LIBRARY_PATH已经生效（可以打开/proc/应用程序pid/environ文件确认）,依然无法加载libodbc.so.x/libodbcinst.so.x，那么可能是.1或者.2的库的问题。历史原因，一般的开发环境中，UnixODBC提供的库既可能叫libodbc.so.1也可能叫libodbc.so.2。用户程序可能依赖了.2，但是环境中只有.1；也有可能是存在.2，但是依赖了.1。解决此问题，只需要在UnixODBC的lib目录下，将不存在的版本建立成软链接，保证.1与.2都存在，这样出问题的机率便会小很多。特别注意，这里强烈建议是建立软链接，而不要拷贝物理文件，不然可能出现一个应用程序进程中，加载了两个导出函数完全相同的.so，这样可能会引起一些比较难定位的启动错误。

1、如何设置用户中间结果集落盘空间限额 有两种方式可以设置用户中间结果集落盘空间限额：1）通过CREATE USER指定SPILL SPACE，为新建用户设置中间结果集落盘限额       CREATE USER user_name … SPILL SPACE 'spillspacelimit';2）通过ALTER USER指定SPILL SPACE，修改已有用户的中间结果集落盘空间限额       ALTER USER user_name … SPILL SPACE 'spillspacelimit'; 比如：CREATE USER u1 PASSWORD ‘abcd@1234’ SPILL SPACE 'unlimited'; --创建用户并设置中间结果集落盘限额为无限制ALTER USER u1 SPILL SPACE '1G'; --修改用户u1的中间结果集落盘限额为1G 说明：1）此设置是对所有节点生效的，即一条SQL在集群的CN和所有DN的落盘数据量之和超过限制，则语句就会报错终止。2）当中间结果集落盘时，该用户的临时文件落盘数据量相应增加；当临时文件删除时，该用户的临时文件落盘数据量相应减少。3）此设置是用户级的，如果同一用户同时并发运行多个query，则会累计每个query中间结果集落盘数据量。 注意：要使上面的设置生效，需要设置GUC参数enable_perm_space为on。如果多个用户都会执行大量中间结果集下盘操作，那么需要对涉及到的每个用户都进行设置。

设置GUC参数temp_file_limit可以限制每个线程的临时文件落盘数据量限制。temp_file_limit属于SUSET类型参数，取值范围：整型，单位为KB。其中-1表示没有限制。默认值：-1。1、如何设置temp_file_limit参数 可通过gs_guc工具进行全局设置，如下：gs_guc reload -Z coordinator -Z datanode -N all -I all -c "temp_file_limit = 1024"2、temp_file_limit取值计算公式可以用下面的公式粗略的计算一个temp_file_limit的取值：temp_file_limit = 预计的总下盘量/同时下盘线程数总下盘量一般可设置为可用空间的20%，这个百分比可根据用户的可接受程度进行调节。同时下盘线程数是业务运行中，通常情况下并发的query中产生中间临时数据下盘的线程数。随着数据库中存储的数据量增加，temp_file_limit的值要适时调整。注意：此参数是限制每个线程的临时文件落盘数据量，如果一个query有多个线程，单个线程落盘数据量超过此参数限制，query会报错退出。如果每个线程都没超过限制，但多个线程下盘数据量累计超过此参数限制，并不会报错退出。3、示例以TPC-DS 1x数据中的customer_demographics表为例。SQL查询不下推，中间结果集仅在CN上落盘