扩容或重装主机时在第一步校验参数失败报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，然后重新进行扩容或者重装主机。 

【问题现象】console页面修改配置项报错，显示系统繁忙【问题分析】1、进入dwscontroller容器，查看ossres-dws.log1）日志中大量打印lock wait timeout，排查dwscontroller所依赖mysql数据库，HCS环境在service om页面搜索虚拟机DWS-DB01/02登录后查看【措施】登录mysql数据库排查是否有大量阻塞进程或长连接，清理后重启dwscontroller容器并页面重试。2) 日志报错连不上mysql数据库，登录数据库检查磁盘空间占用，是否磁盘空间占满【措施】清理磁盘空间后重新拉起mysql数据库1.进入审计日志目录，清理审计日志文件（DWS-DB-01和DWS-DB-02）。cd /var/log/auditcd /data/ ;du -sh audit.log //查看对应的审计日志大小2.以root用户回到DWS-DB01节点，切到mysql用户，登录本地数据库。3.执行set global audit_log_rotations=50; set global audit_log_rotate_on_size=20971520；4.退出数据库，修改配置文件，保证重启也生效vim /data/mysql/etc/my.cnf增加审计日志轮转参数audit_log_rotations=50 audit_log_rotate_on_size=20971520保存退出。5.观察审计日志是否开始轮转。6.该参数是单节点生效，需要在每个节点执行。附：检查mysql数据库状态：1、查看mysql进程是否正常：ps -ef |grep mysql2、数据库主备状态：mysql用户下执行Get_db_status.py

【问题现象】集群DN实例主备切换，日志报错Resource temporarily unavailable，could not fork new process for connection…【问题分析】此类报错问题基本为两方面，一为当时硬件故障或者OS配置问题，导致资源受限，可优先排查服务器是否存在大量僵尸进程；二，应用业务导致map使用过多。又从未来再次发现类似问题角度考虑，推出此类问题的分析步骤如下：1、查看线程数是否受限系统最大pid ：cat /proc/sys/kernel/pid_max系统最大线程数：cat /proc/sys/kernel/threads-max系统限制某用户下最多可以运行多少进程或线程：max_user_process（ulimit -u）上述三者一般取下限，当前线程数超过上面任意一个配置都是不允许的。当前系统的线程数量：pstree -p | wc -l以下为某一具体案例。可供参考：某集群执行pstree -p打印后台发现大量java程序，进一步执行ps -ef|grep java发现有大量java加密程序，路径为/rds/dms-agent/workplace/util/CryptTool.jar进一步分析加密程序卡死原因为信号量冲突，hung住后占用大量系统资源【解决方法】删除dms-agent下scc.conf中semKey配置以永久规避，规避措施无其他影响

【问题现象】业务报错[HeapTupleSatisfiedVacuum set HEAP_XMIN_INVALID xid don't abort]  tuplexid = xxx !【处理方法】1、kill报错对应DN2、在DN执行select * from pg_get_variable_info(); 查看startupMaxXid字段的值，如果startupMaxXid的值大于报错的tuplexid的值，则可以恢复。3、若kill DN后查看startupMaxXid的值小于报错的tuplexid的值，连续执行select txid_current()来推进事务号，然后再kill DN查看startupMaxXid值。

问题：DI工具抽取DWS任务报错连接失败（下图），重试几次后成功问题根因：该局点之前刚做了iam扩容，增加了新节点；新节点被防火墙限制了。解决方法：开通新增DI节点到DWS 的防火墙策略即可。

dws/ecf微服务的数据库审计日志总是占满目录的规避问题版本：all问题现象：dws/ecf微服务审计日志总是占满目录规避方法：1.进入审计日志目录，清理审计日志文件（DWS-DB-01/02、ECF-COMMON-DB01/02、ECF-CM-DB01/02共六个节点都需要做）。     cd /data/ ; du -sh audit.log   //查看对应的审计日志大小 cat /dev/null > {需要清空的文件名}2.以root用户回到DWS-DB01节点，切到mysql用户，登录本地数据库。su - mysqlmysql --defaults-file=/data/mysql/etc/my.cnf -uroot -hlocalhost -P7306 -pxxxxxxx 3.执行set global audit_log_rotations=50; set global audit_log_rotate_on_size=20971520； 4.退出数据库，修改配置文件，保证重启也生效vim /data/mysql/etc/my.cnf增加审计日志轮转参数audit_log_rotations=50 audit_log_rotate_on_size=20971520保存退出。 5.观察审计日志是否开始轮转。 6.该参数是单节点生效，需要在每个节点执行。 7.（选做）如果不需要审计功能，可以登录库后设置关闭set globalaudit_log_policy=none; 每个节点都需要执行，该步骤请谨慎选择。

问题背景业务表数据量很少,但是占用空间很大问题原因1.脏数据多 2.列存表膨胀 3.使用大量varchar(不合理长度)排查过程1.查看脏页率（查之前先执行analyze 表名，如果脏页率很高，需要对表进行vacuum full analyze，如果脏页比较低看第二步） select c.oid AS relid, n.nspname AS schemaname, c.relname, pg_stat_get_tuples_inserted(c.oid) AS n_tup_ins, pg_stat_get_tuples_updated(c.oid) AS n_tup_upd, pg_stat_get_tuples_deleted(c.oid) AS n_tup_del, pg_stat_get_live_tuples(c.oid) AS n_live_tup, pg_stat_get_dead_tuples(c.oid) AS n_dead_tup, cast( (n_dead_tup / (n_live_tup + n_dead_tup + 0.0001) * 100) AS numeric(5,2)) AS dirty_page_rate from pg_class c LEFT JOIN pg_namespace n ON n.oid = c.relnamespace where c.oid = (select 'public.t4'::regclass::oid); /* public为模式名，t4为表名 */ 2.小CU多只有列存表涉及 参考如下链接排查,如果嫌排查麻烦，建议直接执行vacuum full analyze进行CU整合再次查询表大小。 https://bbs.huaweicloud.com/forum/thread-96965-1-1.html 3.使用大量character(不合理长度)，相同数据量可以看到测试结果，使用character(8000)表占2667 MB使用text表占60 MB postgres=# \d+ yyb.test_row Table "yyb.test_row" Column | Type | Modifiers | Storage | Stats target | Description --------+---------+-----------+----------+--------------+------------- id | integer | | plain | | name | text | | extended | | name1 | text | | extended | | name2 | text | | extended | | name3 | text | | extended | | name4 | text | | extended | | name5 | text | | extended | | Has OIDs: no Distribute By: ROUND ROBIN Location Nodes: ALL DATANODES Options: orientation=row, compression=no postgres=# \dt+ yyb.test_row List of relations Schema | Name | Type | Owner | Size | Storage | Description --------+----------+-------+-------+-------+----------------------------------+------------- yyb | test_row | table | yyb | 60 MB | {orientation=row,compression=no} | (1 row) postgres=# \d+ yyb.character_test_row Table "yyb.character_test_row" Column | Type | Modifiers | Storage | Stats target | Description --------+-----------------+-----------+----------+--------------+------------- id | integer | | plain | | name | character(8000) | | extended | | name1 | character(8000) | | extended | | name2 | character(8000) | | extended | | name3 | character(8000) | | extended | | name4 | character(8000) | | extended | | name5 | character(8000) | | extended | | Has OIDs: no Distribute By: ROUND ROBIN Location Nodes: ALL DATANODES Options: orientation=row, compression=no postgres=# \dt+ yyb.character_test_row List of relations Schema | Name | Type | Owner | Size | Storage | Description --------+--------------------+-------+-------+---------+----------------------------------+------------- yyb | character_test_row | table | yyb | 2667 MB | {orientation=row,compression=no} | (1 row)解决方案1.脏数据和cu膨胀均可通过vacuum full analyze 表名进行解决。 2.character建议定长数据使用，不确定数据长度的场景下建议使用text或character varying代替。

单看产品文档的压缩比介绍，感觉在数据压缩比这块不占优势，能简单解释下吗？

问题版本：8.1.15问题现象：导入dws的license失败，前台报错：上传产品license失败排查步骤：1.检查license文件是否正确；正确2.排查manageone日志：cid:link_0发现报错：get cert config info from database failed3.登录dwscontroller容器查看ossre-dws.log 日志：发现有执行sql错误：锁等待超时 Lock wait timeout4.登录rms数据库所在节点；df -h  检查磁盘发现data目录100%进入data目录du -sh * 找到最大的文件进去查看最终发现audit.log太大了：审计日志将磁盘占满了清空审计日志:cat /dev/null > filename5.检查数据库状态：数据库节点su - root  su - mysql Get_db_status.py发现备库挂了问题根因：审计日志满了导致数据库执行license相关的sql失败；解决方法：清空审计日志，做一下规避防止审计日志再次占满cat /dev/null > {需要清空的文件名}1.进入审计日志目录，清理审计日志文件（DWS-DB-01和DWS-DB-02）。    cd /data/ ; du -sh audit.log   //查看对应的审计日志大小 cat /dev/null > {需要清空的文件名}2.以root用户回到DWS-DB01节点，切到mysql用户，登录本地数据库。su - mysqlmysql --defaults-file=/data/mysql/etc/my.cnf -uroot -hlocalhost -P7306 -pxxxxxxx 3.执行set global audit_log_rotations=50; set global audit_log_rotate_on_size=20971520； 4.退出数据库，修改配置文件，保证重启也生效vim /data/mysql/etc/my.cnf增加审计日志轮转参数audit_log_rotations=50 audit_log_rotate_on_size=20971520保存退出。 5.观察审计日志是否开始轮转。 6.该参数是单节点生效，需要在每个节点执行。 7.（选做）如果不需要审计功能，可以登录库后设置关闭set globalaudit_log_policy=none; 每个节点都需要执行，该步骤请谨慎选择。如果备库挂了需要拉起备库1.查看另一个节点是否为主节点，ip a，浮动ip在该节点则说明其是主节点2.登录备节点，切换到mysql用户，使用pathon脚本进行重建python /usr/local/bin/MHA_RebuildSlave.py  ip  //ip为对应主节点对应的ip3.等待build完成，查看备节点mysql进程是否正常 ps -ef|grep mysql  有mysqld则正常

一、版本信息：线下811二、定位过程1.主备OMS节点okerberos状态均异常2.查看oms-krb5kdc.log，报错 Cannot bind to LDAP Server；Unable to read Realm3.执行ldapsearch -H ldaps://节点ip:端口 用户名 密码 有时能连，有时不能连，不能连，报错 Can't contact LDAP server [-1]3.查看ldap进程，发现进程存在4.查看ldap得运行和启动日志，均正常5.手动启动 okerberos服务，krb_server.sh，仍然异常6.对比du -sh /srv/BigData/ldapData/oldap和du -sh /srv/BigData/ldapData/ldapserver，发现oldap比ldapserver小很多7.怀疑oldap数据有缺少68停止主备oms7.将ldapserver的数据目录/srv/BigData/ldapData/ldapserver拷贝给oldapserver的/srv/BigData/ldapData/oldap目录8.启动oms，状态恢复

一、版本信息：线下813二、定位过程1.安装集群到第7步配置集群失败2.查看postinstall.log，报错 mppdb-install-config.xml解析错误3.查看该文件显示内容为空，在主oms节点没有该文件4.查看preinstall.ini，g_hostname_conf字段的ip显示有误，应该是管理ip-业务ip-主机名，现场是业务ip-管理ip-主机名5.hostname -i 显示的是管理ip，正常应该是业务ip6.现场在LLD规划工具填写ip是管理ip和业务ip顺序写反，改过来后，重新生成preinstall.ini，重装成功备注：您所上传的图片不在允许的白名单范围内，请通知管理员添加白名单或者下载后通过本地上传的方式进行上传。

一、问题版本：811二、问题现象：oc 许可管理  dws服务许可状态连接异常三、问题排查：1.查看异常旁的？提示：请求4002.检查是否导入license文件；通过一线得知之前是导入了license文件但是hcs升级后licanse文件就没有了四、规避方法：重新导入license文件

问题现象：     创建集群在执行到RdsInitInstanceTask时失败问题版本：     HCS 8.2.0 DWS 8.2.0问题分析：   1.登录cdk修改参数needDeleteCluster参数为false   2.发放集群，并登录节点，查看网卡情况，有bond，enp集中式，分布式网卡标识同时存在，且只有一个bond0绑定了ip   3.查看规格对应的底层规格      select c.* from rds_cluster_spec a ,rds_cluster_instance_resspec b,rds_resSpecAttr c        where a.id=b.cluster_spec_id and b.instance_spec_id=c.specId        and a.`code`='console界面显示的规格名';           查询结果networkType 的值为sdi  4.确定客户网卡为集中式网卡问题根因：     在serviceOM 数据仓库服务 自定义规格时网关选择错误，应该选择集中式网卡解决方法：     删除失败的集群，删除有问题的规格，重建正确的规格，选择集中式网关，重建集群成功

一、版本信息：纯软800二、定位过程1.页面有ntp服务器异常告警2.查看oms状态，所有组件均正常3.检查主oms 节点防火墙，关闭状态4.ntp调试：ntpdate -d 外部始终源IP，能连通5.执行ntpq -np检查时间同步状态，外部始终源的refid状态为.INIT.6.查看ntpChecker.log、ntp.log、ha_ntp.log、ntpMonitor.log，未发现有用报错信息7.检查配置文件 /etc/ntp.conf，未发现错误8.切换主备oms，新的主oms检查时间同步状态正常；新的备oms也同步正常9.再次切换主备oms，检查主备oms节点的ntp同步情况，均正常

一、版本信息：HC DWS810.100二、定位过程1.一个磁盘得使用率相比其他盘高出10%，约150G2.通过du -sh *，一层层进入该盘下，找到占用磁盘高得目录为base3.进入base目录下，找到占用空间大的库目录4.分别进入正常磁盘和异常磁盘下得base下得该目录，ll *.10，个数相等，应该不是表倾斜场景5.lsof -n $data目录 |grep deleted，有许多记录，应该是文件句柄未释放导致盘使用率高6.执行clean connection to all for database xxx，一段时间后，空间下降备注：贴上图片，发布不了，将图片去掉就能发布