【问题现象】            ECF库中手动添加可用区 【常见版本】       全版本    【解决方法】    1、登录ECF-CM-DB01/02 节点，连接ecf_cm数据库 ；su - mysqlmysql -uecf  -hXX.XX.XX.XX -P7306 -Decf_cm -pXXXXXXXXXXXX2、执行SQL（按需修改）以下举例已存在可用区az1，需要添加az3 ；insert into rds_availablezone(id, code, name, regionCode) values (uuid(), 'az3.sxdc2', 'az3.sxdc2', 'sx-region-2'); insert into rds_availablezone_i18n(id, region, language, available_zone, available_zone_name) values (uuid(), 'sx-region-2', 'ZH-CN', 'az3.sxdc2', '可用区3'); insert into rds_availablezone_i18n(id, region, language, available_zone, available_zone_name) values (uuid(), 'sx-region-2', 'EN-US', 'az3.sxdc2', 'az3'); insert into rds_spec_region select uuid(), cluster_spec_id, region, 'az3.sxdc2', status from rds_spec_region where zone = 'az1.sxdc2'; 

 1    前提条件： （1）已安装OBS服务。 （2）已准备好巡检软件包。  2    上传工具到OBS桶 操作步骤： a.进入ManageOne运营面，依次点击“首页 > 左上角图标 > 对象存储服务”，跳转到OBS页面。      b.登录OBS页面并点击创建桶，根据向导创建桶。 c.桶名可以自定义，下图创建了以test-hcs命名的桶。并单击“立即创建”，创建完成后会跳转至桶列表页面。 d.单击创建的桶名，按下图步骤上传nmon工具及CheckTools.zip工具 e.单击已上传的文件名，再单击"对象ACL"，编辑匿名用户的权限"匿名读写"，单击“保存”。 f.复制并保存文件链接，将在步骤2中使用。 3    在管控面节点下载   以DWS CDK节点，NGINX为例 3.1    DWS CDK节点 wget --no-check-certificate  https://h30008669.obsv3.cn-dwsglobal-1.dwscloud.com/baseFile.sh 3.2    NGINX wget --no-check-certificate  https://h30008669.obsv3.cn-dwsglobal-1.dwscloud.com/baseFile.sh  4    在租户面节点下载 使用PUTTY工具，登录DWS集群第一个CN节点，切换到Ruby用户 从OBS下载文件。通过步骤1.f中的获取到的文件链接下载巡检工具。 例如链接为： https://obs-cq-test.obs.cq-region-2.sgic.sgcc.com.cn/CheckTools.zip 下载脚本： wget --no-check-certificate https://obs-cq-test.obs.cq-region-2.sgic.sgcc.com.cn/CheckTools.zip  

FusionInsightManager(线下管控面)是Gaussdb的运维管理系统，为部署在集群内的服务提供统一的集群管理能力，支持大规模集群的安装部署、性能监控、告警、用户管理、权限管理、审计、服务管理、健康检查和日志采集等功能。产品架构分为server端与agent端，server端称为OMS，部署为管理节点，程序目录在$BIGDATA_HOME/om-server；agent端称为OMA，每个节点都有OMA进程，程序目录在$BIGDATA_HOME/om-agent。1 oms原理OMS作为服务端，部署主备管理节点，由ha进程实现oms的高可用；oms可以理解为整个管理系统的大脑，由多个子服务组成fi manager管理系统在管理的每个主机上，都部署一个agent进程，主要用于：接收oms下发到各个节点的命令，并将本节点的状态、监控数据进行上报【常见问题】FI界面显示主机故障，后台集群状态正常（前后端显示不一致），FI监控不显示【问题分析】首先排查故障节点nodeagent进程是否启动 ps -ef|grep nodeagent场景一：合并部署场景,主备oms 也是集群数据节点----不推荐此部署场景，非标【分析】：1.nodeagent进程启动，但是nodeagent调用其他脚本报错，一般是用户为了方便操作，把source mppdb写入了omm的环境变量文件里，导致nodeagent被omm拉起时也source了mpp的环境变量。导致环境变量污染cat /home/omm/.bashrc文件中写如了mpp的环境变量场景二：FI界面显示主机故障，该节点nodeagent 无法启动【分析】检查tmp下是否存在nodegaent.lock锁文件--问题根因 nodeagent锁文件未清除导致删除后重启nodeagent成功常用命令重启nodeagent进程方法  先停止 sh /opt/huawei/Bigdata/om-agent/nodeagent/bin/stop-agent.sh 再启动 sh /opt/huawei/Bigdata/om-agent/nodeagent/bin/start-agent.sh     重启nodeagent：$CONTROLLER_HOME/inst/restartAllNoes.sh  ---注该脚本会重启所有节点nodeagentnodeagent：http://3ms.huawei.com/km/blogs/details/6198189oms故障（1）分析思路当oms的子服务不能提供服务，导致oms状态异常时，由于子服务之间存在依赖关系，例如kerberos依赖于ldap服务，当ldap异常时，kerberos以及依赖于ldap和kerberos的其他服务往往会同时异常。在着手处理前，先要分析异常服务的依赖关系，先从被依赖的服务开始处理。cd /opt/huawei/Bigdata/om-server/om/inst/confgrep -ri depend *以如下图片为例，当controller同时与fms都上报故障时，应对先处理fms的问题各个组件相关日志见产品文档”manager日志“章节FI界面监控原理a. MPPDB在CMS主节点上通过mpp-startGsPerf.sh (接入层)，调用gs_checkperf（om层）进行性能数据采集。b. MPPDB将采集到的数据上报给om-agent。c. om-agent将收集到的数据写入共享内存并将数据发送给oms节点的pms监控模块。d. pms对cms节点发送的数据进行消费入库。常见问题参考案例：https://bbs.huaweicloud.com/forum/thread-0261102334922441004-1-1.html    

1.1.1  FusionInsight集群NTP机制1. FusionInsight的主OMS节点向NTP外部时钟源同步2. 所有业务节点向OMS主节点同步3. 由于Hbase、hdfs以及包含的数据库实例都依赖日志（包含时间戳）来完成数据的一致性保证，所以FusionInsight把利用NTP进行时间同步做了更多的优化，在保证与外部时钟源同步的同时保证即使外部时钟源发生了问题，或者与外部时钟源断连，仍然能够正确的运行。4. 为了保证数据的可靠性，OMS主节点最多以每秒0.06毫秒的速度追外部NTP时间，每天最多同步0.06*60*60*24=5184毫秒基于上述原理可以看出，实际上整个集群都是最终向NTP时钟源同步的，这样做的最大好处是：无论何时，整个集群内的时钟都是同步的，如果ntp时钟源没任何问题，整个集群也是与ntp时钟源同步的！1.1.2  配置与实现方式说明以测试环境配置为例：主OMS配置：主备OMS中NTP的配置文件/etc/ntp.conf/opt/huawei/Bigdata/OMSV100R001C00x8664/workspace0/conf/ntp.conf.active/opt/huawei/Bigdata/OMSV100R001C00x8664/workspace0/conf/ntp.conf.standby/opt/huawei/Bigdata/OMSV100R001C00x8664/workspace0/ha/module/harm/plugin/conf/ntp.xml/etc/ntp.conf 会根据ntp.conf.active和ntp.conf.standby生成，主节点的生成从active生成，备节点的按照standby生成配置文件出错会导致时间同步失败或者文件不匹配的异常， 配置与实现方式说明：1. 主OMS作为整个集群的时钟源，配置127.127.1.0 prefer，即主OMS以本机作为优选时钟源2. 192.168.166.22 noselect 配置外部时钟源为noselect，这样做的原因是在该节点上运行的有一个守护进程ntp_tickadj.sh，该进程的作用是检查本地与192.168.166.22 的时间差，如果出现偏差则调整本地时间脚本路径6.5.1 版本路径：/opt/huawei/Bigdata/om-server_6.5.1/om/inst/script/ntp_tickadj.shC60版本路径：/opt/huawei/Bigdata/om-0.0.1/inst/script/ ntp_tickadj.sh其他版本路径参考以上各个Agent中NTP的配置文件•       /etc/ntp.conf•       /opt/huawei/Bigdata/nodeagent/ntp.conf.agent配置文件中主要配置的是同步时间的IP信息1.    备OMS及业务节点直接以主OMS所在的OMS浮动IP192.168.164.163 作为外部时钟源日志目录：主备OMS节点/var/log/Bigdata/omm/oms/ha/scriptlog/ha_ntp.log/var/log/ntp.log/var/log/Bigdata/nodeagent/scriptlog/start_ntp.logNodeagent节点/var/log/Bigdata/nodeagent/scriptlog/start_ntp.log/var/log/ntp.log1.1.2        为什么不采用所有节点都向外部时钟源同步1.     在正常场景下没有任何问题2.     异常场景下，假如业务节点2与ntp时钟源发生断连，因为其他节点都是与ntp时钟源同步，所以业务节点2就有可能与整个集群时间不一致，导致集群内数据发生损坏3.     异常场景下，假如OMS节点与ntp时钟源断连，如果oms所在机器时钟走不准，那么相当于管理节点与其他节点时间都不一样，整个集群会进入时钟错乱状态，影响整个集群正常运行1.1.3  为什么业务节点或备OMS不能配置成主选外部时钟源？1.     防止OMS节点与外部时钟源断连，而其他业务节点与外部时钟源连接正常的场景2.     Hadoop集群对集群内时间同步要求比较高，这是因为hbase、hdfs以及包含的数据库实例都依赖日志来完成数据的一致性保证，所以FusionInsight把利用NTP进行时间同步做了更多的优化，在保证与外部时钟源同步的同时保证即使外部时钟源发生了问题，或者与外部时钟源断连，仍然能够正确的运行。1.1.5  检查节点ntp状态方法ntpq –np•       remote:响应这个请求的NTP服务器的名称。•       refid:NTP服务器使用的上一级ntp服务器。•       st:当前NTP服务器所在的层数。•       t:本地NTP服务器与远程NTP服务器的通信方式，u: 单播； b: 广播； l: 本地。•       when:上一次成功请求之后到现在的秒数。•       poll:本地NTP服务器查询远程NTP服务器的时间间隔。•       reach:是一种衡量前8次查询是否成功的位掩码值，377表示都成功，0表示不成功。•       delay:网络延时，单位是10的-6次方秒。•       offset:本地NTP服务器与远程NTP服务器的时间偏移。•       jitter:查询偏差的分布值，用于表示远程NTP服务器的网络延时是否稳定，单位为10的-6次方秒。

对于数仓来说，需要存储大量的历史分区数据。    我测试了单个表在不同分区个数下的analyze耗时，    单分区（共57w行，81Mb）需 4s，43个分区（共2千百万行，3485Mb）需 7s，400个分区（共2.3亿行，32Gb）需 29s。从结果上看，分区个数会影响收集统计信息的效率。对于数仓来说，需要保留所有历史日期分区数据，为了保证日批效率，需要如何操作才能不全表收集，仅收集部分分区数据的统计信息？

​线下管控面下载客户端后发现无JDK1.问题背景：集群服务器是arm的，安装客户端的服务器是集群外的x86，从FI界面下载客户端后无法使用，下载包中无JDK，从其他包中copy过来后问题可解决2.分析过程：1.执行  sh /opt/huawei/Bigdata/om-server/om/sbin/pack/queryPack.sh，发现ARM和X86的组件部件包都已经对应注册2.进入客户端JDK目录，手动解压jdk.tar.gz压缩包，发现只有tomcat.crt及cacerts两个文件。3.执行  sh /opt/huawei/Bigdata/om-server/om/sbin/pack/queryManager.sh  查看manager部件包注册情况时，发现有报错：提示  /opt/huawei/Bigdata/om-server/om/inst/jre/redhat-x86_64 目录下没有 jdk文件4.注册跨平台需要注册manager 包，操作见bi系统单号9404370，解注册：sh unregister_pack.sh -p euleros-x86_64，其他客户端问题可参考http://rnd-dayu.huawei.com:8081/index.php/Question/detail?id=46683​

如题，比较初级的疑问，还望各位大佬指教。1、GaussDB的官方文档对于架构方面的描述感觉有点欠缺，搞不懂分布式版和主备版的区别在哪?2、此外，现有的材料看起来GaussDB的分布式版看起来跟DWS差别不是很大？

【问题现象】     SQL诊断搜索框显示位置错位 【常见版本】8.1.1  【定位思路】    1、CDK找到console-static01/02节点信息登录 2、找到文件app_themes.combined 文件路径/opt/onframework/static/private/dws/app_themes.combined 一般后缀会有8256ec47.min.css 3、添加.float-left { float: left;},规避修复(注意两个节点均要修复) 4、不用重启服务,刷新生效 

FusionCare 8.0.8 提供了收集集群信息的功能。这里提供一些收集失败后的排查方法及常见场景。收集失败后，首先排查日志，看是否为已知场景。          收集信息的进程日志：/opt/SysChecker/Output/SysCheckerRestLog.txt          FusionCare后台进程日志：/home/omm/FusionCare/tomcat/hct-*.log下面是常见的一些收集失败的场景：1、FusionInsight Manager 上 ，集群名称带 '_'， 收集失败。      现象：查看/home/omm/FusionCare/tomcat/hct-*.log日志中，有报错信息：get nodeInfo Fail. by the officeName:test.(实际集群名字，应该为test_xxxx_xxx)      根因：FusionCare在页面上会传递给后台officeName字段，officeName会被前台根据'_'截取。再与后台的数据库中environment字段进行判断，两者不相等，则不会输出集群信息。      规避方法：在浏览器中按F12；临时更改红框中js脚本，改为具体的集群名称；ctrl + s ; 点击下载集群信息。（此处一定不能F5或刷新页面）2、由于集群安装时，多次重装，导致集群ID不为1，收集失败。      现象：查看/opt/SysChecker/Output/SysCheckerRestLog.txt， 明显的python错误：do get fails. Exception:xxxx. KeyError: 'name'.      问题根因：多次重装后，集群ID不为1。 而FusionCare使用1去调用接口，此时接口访问结果为空，python获取结果中的key报错。      规避方法：根据FIM首页-> 集群> 集群属性> 集群ID。获取到集群ID。卸载Syschecker命令:  sh /opt/SysChecker/setup -u ；解压syschecker 命令:   cd /opt/; unzip DWS_SysChecker_8.0.8.zip;修改脚本中的ID，将 2 改为具体的集群ID ：vi /opt/SysChecker/SysCheck/Lib/base_process.py；重装syschecker：sh /opt/SysChecker/setup -i重新点击下载集群信息即可。

【问题影响】单节点os重启，dws集群界面显示低性能【定位过程】1.分析message日志。os重启直接原因为CPU死锁，产生soft lockup，触发panic2.在panic之前，massage日志中存在大量oom日志，oom多次杀掉python和gaussdb进程后，最后一次杀掉了 jemalloc_bg_thd进程后，触发了死锁。3.分析oom信息与进程内存信息，发现gaussdb进程占内存仅4G，但是python进程service-agent进程占内存会到400G4.分析该python进程为管控面获取监控数据的agent-service进程，属于常驻进程，但是每次获取监控数据后内存未及时释放，导致进程内存会快速上涨；【问题根因】1.DWS管控面获取监控数据的agent-service进程内存未及时释放，导致内存快速上涨，频繁触发oom；2.操作系统oom每次杀掉score最高的进程，在频繁oom过程中，不断杀掉python进程和gaussdb进程，直到jemalloc_bt_thd进程变为score最高进程后，jemalloc_bt_thd进程被杀掉；3.jemalloc_bt_thd进程为负责回收内存的进程，oom杀掉进程后释放内存需要回收，此时回收内存进程被杀掉，触发了CPU核间等待死锁，触发panic。【规避方案】1.每小时杀掉一次agent-service进程，防止agent-service进程内存持续上涨频繁触发oom；ps ux |grep agent_service.py|grep -v grep|awk '{print $2}'|xargs -r kill -92.此规避措施不影响管控面升级，但是影响租户面升级，下一次租户面升级之前需要停掉此规避方案。DWS 8.1.3版本已修复agent-service进程内存不释放问题。

背景：数据库 GaussDB(DWS)；当前版本 8.1.1，后续会升级至8.2.1；数据处理加工脚本使用存储过程。问题：1.存储过程中每次对表进行数据处理后，建议使用analyze/ vacuum analyze/ vacuum full analyze 哪种方式？    8.1.1版本不支持在存储过程中调用vacuum，在8.2.1版本是否支持？2.对于数仓来说，需要存储大量的历史分区数据，分区个数是否会影响 收集统计信息的效率？    我测试了单个表在不同分区个数下的analyze耗时，    单分区（共57w行，81Mb）需 4s，43个分区（共2千百万行，3485Mb）需 7s，400个分区（共2.3亿行，32Gb）需 29s。从结果上看，分区个数会影响收集统计信息的效率。对于数仓来说，需要保留所有历史日期分区数据，为了保证日批效率，需要如何处理？3.DWS数据库服务器物理机上初始搭建服务时，想要扩展数据存储空间。对于每台服务器来说，扩展的磁盘大小，有什么要求么？ 最大支持扩展多少？    物理机为鲲鹏服务器，操作系统为麒麟V10

DWS 中是否有函数匹配某个值出现的次数？

同GaussDB(DWS)、Teradata、Oracle保持一致的xor_md5函数，用于验证跨平台间checksum值相同。CREATE OR REPLACE FUNCTION xor_md5(inputString VARCHAR2) RETURN NUMBER IS result NUMBER(38); md5 NUMBER; BEGIN select m1+m2-BITAND(m1, m2) * 2 into md5 from ( select n1+n2-BITAND(n1, n2) * 2 as m1, n3+n4-BITAND(n3, n4) * 2 as m2 from ( select to_number(substr(md5,1,8),'xxxxxxxx') n1, to_number(substr(md5,9,8),'xxxxxxxx') n2, to_number(substr(md5,17,8),'xxxxxxxx') n3, to_number(substr(md5,25,8),'xxxxxxxx') n4 from ( select standard_hash(inputString, 'MD5') as md5 from dual )a ) b) c; RETURN md5; END xor_md5;/用法：select sum(xor_md5(校验字段)) from 业务表;

同GaussDB(DWS)、Teradata、Oracle保持一致的xor_md5函数，用于验证跨平台间checksum值相同。CREATE FUNCTION hex_to_dec(param1 char(8))returns bigintlanguage sqlbegin atomic declare num bigint; declare i int; declare s varchar(1); set num = 0; set i = 1; while i <= 8 do set s = substr(param1,i,1); set num = num + power(16,8-i) * (case s when 'A' then 10 when 'B' then 11 when 'C' then 12 when 'D' then 13 when 'E' then 14 when 'F' then 15 else to_number(s) end); set i = i + 1; end while; return num;end@CREATE FUNCTION xor_md5(param1 varchar(32000))returns bigintlanguage sqlbegin atomic declare hash_value varchar(32); declare num bigint; set hash_value = hex(sysibm.hash(param1,0)); set num = hex_to_dec(substr(hash_value,1,8)) ^ hex_to_dec(substr(hash_value,9,8)) ^ hex_to_dec(substr(hash_value,17,8)) ^ hex_to_dec(substr(hash_value,25,8)); return num;end@注意，创建函数方式：db2 -td@ "创建函数SQL"

我的DWS服务端开启了SSL认证，我通过官网的命令，生成了客户端keystore与truststore文件我参考官网文档 设置keystore 开启ssl = true 去连接发现我的文件正确与否 都能连接成功于是我又设置 sslmode = "verify-ca"此时用文件链接报错 但根本没有这个目录 并且我的客户端密钥文件并非在此目录大佬们我该如何通过jdbc的方式进行ssl连接？