with recursive入门 小试牛刀一创建表 CREATE TABLE xiyouji ( id character varying, pid text, name text ) WITH (orientation=row, compression=no); 插入数据 insert into xiyouji values('001',1,'孙悟空'),('002',1,'猪八戒'),('003',1,'沙僧'),('1',0,'唐僧'),('007','001','小猴子'); insert into xiyouji values('008','007','小猴子的猴子1'),('009','008','小猴子的猴子1的A'),('010','009','小猴子的猴子1的AB'),('011','010','小猴子的猴子1的ABC'); 查询小猴子所有老大 with recursive xi as ( select pid,name from xiyouji where id='007' union all select b.pid, b.name||'>'||a.name from xi a inner join xiyouji b on a.pid=b.id )select * from xi where pid<>'001'; pid | name -----+-------------------- 0 | 唐僧>孙悟空>小猴子 1 | 孙悟空>小猴子 (2 rows)使用with recursive慢的场景以小试牛刀一来测 当表数据唯一的时候，查询结果集只有7条耗时71毫秒 postgres=# with recursive xi as ( select pid,name from xiyouji where id='011' union all select b.pid, b.name||'>'||a.name from xi a inner join xiyouji b on a.pid=b.id )select * from xi order by pid ; pid | name -----+---------------------------------------------------------------------------------------- 0 | 唐僧>孙悟空>小猴子>小猴子的猴子1>小猴子的猴子1的A>小猴子的猴子1的AB>小猴子的猴子1的ABC 001 | 小猴子>小猴子的猴子1>小猴子的猴子1的A>小猴子的猴子1的AB>小猴子的猴子1的ABC 007 | 小猴子的猴子1>小猴子的猴子1的A>小猴子的猴子1的AB>小猴子的猴子1的ABC 008 | 小猴子的猴子1的A>小猴子的猴子1的AB>小猴子的猴子1的ABC 009 | 小猴子的猴子1的AB>小猴子的猴子1的ABC 010 | 小猴子的猴子1的ABC 1 | 孙悟空>小猴子>小猴子的猴子1>小猴子的猴子1的A>小猴子的猴子1的AB>小猴子的猴子1的ABC (7 rows) Time: 71.841 ms 当表数据存在二次重复时，insert into xiyouji select * from xiyouji; 结果集会突增到254条耗时2880毫秒。 随着数据重复度越高，会导致with recursive执行时间指数级增长。 postgres=# with recursive xi as ( select pid,name from xiyouji where id='011' union all select b.pid, b.name||'>'||a.name from xi a inner join xiyouji b on a.pid=b.id )select * from xi ; pid | name -----+---------------------------------------------------------------------------------------- 0 | 唐僧>孙悟空>小猴子>小猴子的猴子1>小猴子的猴子1的A>小猴子的猴子1的AB>小猴子的猴子1的ABC 0 | 唐僧>孙悟空>小猴子>小猴子的猴子1>小猴子的猴子1的A>小猴子的猴子1的AB>小猴子的猴子1的ABC 0 | 唐僧>孙悟空>小猴子>小猴子的猴子1>小猴子的猴子1的A>小猴子的猴子1的AB>小猴子的猴子1的ABC 0 | 唐僧>孙悟空>小猴子>小猴子的猴子1>小猴子的猴子1的A>小猴子的猴子1的AB>小猴子的猴子1的ABC 0 | 唐僧>孙悟空>小猴子>小猴子的猴子1>小猴子的猴子1的A>小猴子的猴子1的AB>小猴子的猴子1的ABC 0 | 唐僧>孙悟空>小猴子>小猴子的猴子1>小猴子的猴子1的A>小猴子的猴子1的AB>小猴子的猴子1的ABC 0 | 唐僧>孙悟空>小猴子>小猴子的猴子1>小猴子的猴子1的A>小猴子的猴子1的AB>小猴子的猴子1的ABC 0 | 唐僧>孙悟空>小猴子>小猴子的猴子1>小猴子的猴子1的A>小猴子的猴子1的AB>小猴子的猴子1的ABC 0 | 唐僧>孙悟空>小猴子>小猴子的猴子1>小猴子的猴子1的A>小猴子的猴子1的AB>小猴子的猴子1的ABC ..... 1 | 孙悟空>小猴子>小猴子的猴子1>小猴子的猴子1的A>小猴子的猴子1的AB>小猴子的猴子1的ABC (254 rows) Time: 2880.336 ms优化对于表数据存在重 1.业务上可以对数据进行优化，避免存在重复值 2.使用distinct去重或union all改为union。 postgres=# with recursive xi as ( select distinct pid,name from xiyouji where id='011' union all select distinct b.pid, b.name||'>'||a.name from xi a inner join xiyouji b on a.pid=b.id )select * from xi ; pid | name -----+---------------------------------------------------------------------------------------- 001 | 小猴子>小猴子的猴子1>小猴子的猴子1的A>小猴子的猴子1的AB>小猴子的猴子1的ABC 1 | 孙悟空>小猴子>小猴子的猴子1>小猴子的猴子1的A>小猴子的猴子1的AB>小猴子的猴子1的ABC 0 | 唐僧>孙悟空>小猴子>小猴子的猴子1>小猴子的猴子1的A>小猴子的猴子1的AB>小猴子的猴子1的ABC 009 | 小猴子的猴子1的AB>小猴子的猴子1的ABC 007 | 小猴子的猴子1>小猴子的猴子1的A>小猴子的猴子1的AB>小猴子的猴子1的ABC 010 | 小猴子的猴子1的ABC 008 | 小猴子的猴子1的A>小猴子的猴子1的AB>小猴子的猴子1的ABC (7 rows) Time: 134.162 ms

spark支持读取hive事务表么,3.1.1版本

索引失效一般分为以下几种常见场景1.条件列进行隐式转换，比如查询的带索引的列类型为int，条件为text类型 2.条件列使用函数 3.条件列进行计算 4.没有analyze导致引擎误认为不走索引代价更小 5.条件使用or1.条件列进行隐式转换，比如查询的带索引的列类型为int，条件为text类型eg:语句条件存在where id='1'的场景，如果列id类型为int，进行查询时id列类型会被隐式转换成text类型，导致id列上索引失效，语句进行全表扫描，性能裂化。2.条件列使用函数eg:语句存在条件lower(scope)=‘A’的场景，scope列上的索引会失效导致条件过滤不走索引。 建议把lower(scope)=‘A’ 等价改写为scope=lower(‘A’)可走索引3.条件列进行计算eg：当id列上创建索引时 语句条件存在where id+1=3;不走索引 可等价改写为where id=3+1;4.没有analyze导致引擎误认为不走索引代价更小没有对表进行统计信息收集，会导致引擎误认为结果集很大或者表数据量很小，不走索引代价更小5.条件使用orwhere id=1 or id=2;此场景不走索引，可以等价改写为union all方式

巡检未做analyze的表select 'analyze '||schemaname||' '||relname from pg_stat_all_tables where schemaname in ('业务schema名称') and last_analyze is null ;巡检脏页率高的表select a.schemaname,a.relname, pg_size_pretty(pg_table_size(a.schemaname||'.'||a.relname::regclass)) as tablesize,a.dead_tup,a.live_tup,a.dead_tup/(a.dead_tup+a.live_tup) as drate from( select schemaname,relname,sum(n_dead_tup) as dead_tup,sum(n_live_tup) as live_tup from pg_catalog.pgxc_stat_dirty_tables(10,50) group by 1,2 ) a where (drate>0.3 or a.dead_tup>1000) order by 6 desc;巡检表倾斜情况select schemaname,tablename, (100-100*avg(dnsize)/nullif(max(dnsize),0))::numeric(5,2) "New_Skew(%)" ,max(dnsize)*count(1)-sum(dnsize) "WastedPerm(B)" from table_distribution() a where schemaname='schemaname' and tablename='tablename' group by 1,2;列存表统计select n.nspname as schemaname,cl.relname as tablename,reloptions[1] from pg_class cl left join pg_namespace n on n.oid=cl.relnamespace where schemaname='指定schema名称' and relkind = 'r' and cl.oid > 16384 and reloptions[1] ='orientation=column';行存表统计select n.nspname as schemaname,cl.relname as tablename,reloptions[1] from pg_class cl left join pg_namespace n on n.oid=cl.relnamespace where schemaname='指定schema名称' and relkind = 'r' and cl.oid > 16384 and reloptions[1] ='orientation=row';schema大小统计（速度快，前提对应版本存在这个视图）select pg_size_pretty(sum(usedspace)) from pgxc_total_schema_info where schemaname in (业务schemaname);*schema大小统计（稍微慢些，如果版本无pgxc_total_schema_info视图）select n.nspname, pg_size_pretty(sum(pg_table_size(c.oid))) from pg_class c LEFT JOIN pg_namespace n ON n.oid = c.relnamespace where c.relkind = 'r' and n.nspname in ('','','') group by n.nspname;--不包含索引 select n.nspname, pg_size_pretty(sum(pg_table_size(c.oid))) from pg_class c LEFT JOIN pg_namespace n ON n.oid = c.relnamespace where n.nspname in ('','','') group by n.nspname;--包含索引占用

建表语句及数据create table cpu2(id int,a text,b text,key text,value text); insert into cpu2 values(1,'a1','b1','mf','12'),(2,'a1','b1','mt',10),(3,'a2','b2','mf',20),(4,'a2','b2','mt',22);需求根据key分类统计value的值 实现语句通过case when方式 select a,b, sum(CASE WHEN key='mf' then VALUE::text else '0' END) as mf, sum(CASE WHEN key='mt' then VALUE::text else '0' END) as mt from cpu2 GROUP BY a,b;

表分区介绍分区功能把物理表分成多个分区，使用分区可以查询业务关注的热数据，避免全表数据查询分区使用1.直接指定分区 2.条件带分区字段 备注分区支持通过between and或者使用> <选择分区 这样也走分区剪枝不走分区场景1.分区列使用表达式 age+1=1984改写为age=1984+1 2.条件存在or or条件使用括号后可以走分区剪枝或者使用union all

升级 ECF.1OUnitied-Access2-MOResource工步报错[问题版本]hcs803-810dws管控面配套升级[问题现象]升级过程中ECF.1OUnitied-Access2-MOResource工步执行失败：注册十统一接入资源包失败faied to register the cloud service adaptation package resource_10UnifiedAccess2MO_ECF_8.1.0.tar.gz, Log in to ManageOne Maintenance Portal, choose System \u003e System Integration \u003e System Access \u003e Cloud Service Access, click \"view log\" to view the directory where the mediation package fails to be pushed.”,"error_msg_en":""1859150, Failed to register ECF service 10UnifiedAccess2MO resource package. [排查方法]接入资源包失败；根据报错中的提示, Log in to ManageOne Maintenance Portal, choose System \u003e System Integration \u003e System Access \u003e Cloud Service Access, click \"view log\" to view the directory where the mediation package fails to be pushed.登录oc面系统管理->系统集成->接入管理->云服务接入查看详情；接入失败时找manageone的同事处理查看接入失败的日志发现log执行失败拉mo的同事定位；此局点没有安装log服务[规避方法]log接入失败，此局点没安装log服务，接入失败只影响log服务，可以跳过此工步，等升级完成安装log服务后重新手动导入。工步，等升级完成安装log服务后重新手动导入。

一：修改ip总体流程检查集群状态必须是（否则不允许修改）cluster_state   : Normalbalanced        : Yes关闭kerbos：gs_ssh -c "gs_om -t kerberos -m uninstall -U omm"（必须重启集群生效，可能会出现前后台不一致情况）首先进行修改IP前置准备，包括检查环境，导出当前IP配置信息，停止集群硬件侧实施机器物理IP修改；软件侧修改FIM软件中IP信息，首先修改前面导出的IP配置文件，然后执行修改IP的脚本，如果涉及修改主备管理节点管理IP，则还需要更换HA证书；同步配置集群，即调用内核gs_om工具修改mpp数据库内核软件中的IP信息。修改IP几个关键步骤有修改机器物理IP，修改FIM软件IP信息，修改数据库软件IP信息。修改机器物理IP由硬件侧来保证。二：日志路径修改FIM的IP信息：/var/log/Bigdata/controller/modify.log修改mpp数据库内核软件的IP：/var/log/Bigdata/nodeagent/agentlog/agent.log  ，/var/log/Bigdata/mpp/scriptlog/doipchange.log，/var/log/Bigdata/mpp/omm/om/gs_om*.log三：问题定位     目前现网出现已知问题一：     1.问题现象：修改ipmodify脚本执行成功后OMS状态异常（主备oms频繁切换，controller异常，无法登录FI界面，FI界面提示系统繁忙）     2.发生版本（8008版本/FI版本6516）     3.后台oms状态如图       问题定位思路      1.controller异常首先看controller.log日志，日志路径：var/log/Bigdata/controller/controller.log      2.首先重启controller观察是否异常.sh -X /opt/huawei/Bigdata/om-server/om/sbin/restart-controller.sh      问题分析      controller日志提示空指针异常应该是读取配置文件读空      解决方法：      1.登录主oms节点OMS库gsql -p 20015 -U omm -d omm -W ChangeMe@123456      2.分别查看 om_nodes，om_clusters,om_nodes_isolation,om_azs表观察表中字段ip和hostname是否为新ip      3.此处问题om_nodes表如图可知node_id和hostname未修改     4.手动update后重启controller后恢复正常目前现网出现已知问题二：     1.问题现象：修改ip后登录FI界面同步配置失败     2.发生版本（8008版本/FI版本6516）     3.查看gs_om日志/var/log/Bigdata/mpp/omm/om/gs_om*.log    4.日志打印停止集群失败    问题分析： 未做同步配置，集群软件中记录的还是旧ip信息，与当前机器实际物理ip不一致，所以直接启动集群会起不来；同理，此时如果继续补做同步配置，在前置检查中检测到cm_agent进程存在，认为集群未完全停止，会先尝试停止集群，但是由于ip信息不对导致ssh其它节点停集群也报错。    解决方案：    1.分别登录每个节点，执行cm_ctl stop -n nodeid命令停止本节点实例    2.在界面上重新同步配置目前现网出现已知问题三：    1.问题现象：修改ip后登录FI界面同步配置失败    2.发生版本（811版本/FI版本8021）    3.查看gs_om日志/var/log/Bigdata/mpp/omm/om/gs_om*.log，和doipchange.log /var/log/Bigdata/mpp/scriptlog/doipchange.log，查看oms库中ip都是新ip      gs_om日志        doipchange.log      4.日志提示启动集群失败，ip是老的ip             问题分析：修改IP时未观察集群状态，存在build情况             解决方案：            1.执行gs_om -t changeip -X 该操作会拉起集群！界面提示gs_guc:The gs_ctl build is doing now, the gs_guc process should be stopped           2.将master3实例目录下build_completed.start、gs_build.pid两个文件mv改名；           3.修改脚本调长集群启动超时时间，确保master3在启动阶段能完成build；脚本名：/opt/huawei/Bigdata/FusionInsight_MPPDB_8.0.0/install/FusionInsight-MPPDB-8.0.0/package/MPPDB/script/impl/om/OLAP/OmImplOLAP.py           函数名：startCluster注释原有启动命令，新增一行，将启动时间调整为86400：                        4.查看集群状态是否存在build情况（停止实例拉起全量build）          cm_ctl stop -n 2  -D DATA_PATH          gs_ctl build -Z datanode -b full -r 72000 -D  DATA_PATH          cm_ctl start -n 2  -D DATA_PATH          5.再在FI界面上重新同步配置目前现网出现已知问题四：         1.问题现象：修改ip后nodeagent异常重启 2.发生版本（8008版本/FI版本6516）         3.查看nodeagent日志如图        查看nodeagent配置文件是否存在老的ip，以及host.ini文件        /opt/huawei/Bigdata/om-agent_8.0.2.1/nodeagent/etc/agent/nodeagent.properties       /opt/huawei/Bigdata/om-agent/nodeagent/etc/agent/host.ini      /var/log/Bigdata/unreachable     修改完成后重启nodeagent：$CONTROLLER_HOME/inst/restartAllNoes.sh目前现网出现已知问题五：     1.问题现象：修改ip后巡检pgxc_node表ip未更新     2.发生版本（8008版本/FI版本6516）     3. 如何更新pgxc_node系统表在启动集群后还需要更新所有cn中的pgxc_node系统表信息。在每个cn节点构建如下sql语句并更新当前节点cn的pgxc_node系统表update pg_catalog.pgxc_node set (node_host, node_host1, node_port, node_port1)=('%s','%s','%s','%s') where node_name='cn_%s';--除当前cn外每个cn一条update pg_catalog.pgxc_node set (node_host, node_host1, node_port, node_port1)=('%s','%s','%s','%s') where node_name='dn_%s_%s';--每个主dn一条select * from pg_catalog.pgxc_pool_reload()； 

在数据库使用过程中脏数据是如何产生的？企业级数据仓库如何优雅进行脏数据的清理？ autovacuum如何使用及调优？11月24日晚19点，华为云数仓研发专家威少带您三步搞定PB级数仓空间回收。同时，我们准备了1元试用GaussDB(DWS)，帮助大家更好地了解和体验华为云数仓GaussDB(DWS)~直播回放入口：https://bbs.huaweicloud.com/live/cloud_live/202211241900.html1元试用申请链接：cid:link_0试用指导手册、讲师PPT见附件哦~参与互动华为手环、鼠标、颈枕、云宝公仔等好礼等您来拿~一、直播看点1. 行列存vacuum和vacuum full的区别，使用背景和使用方法；2. autovacuum的使用和调优；3. vcuum后垃圾空间不回收的排查处理方法。二、参与互动，好礼等您领直播间抽奖：观看直播参与互动抽奖；参与GaussDB(DWS)试用，并在本帖留言使用感受；在GaussDB(DWS)论坛上发帖互动（包括但不限于直播收获、问题求助、博文分享、数仓产品体验感受、产品优化建议等)；以上互动方式参与一种或多种均可~

1 Odbc连接数据库1.1 获取相关使用工具unixODBC-2.3.0.tar.gz  GaussDB-8.1.3-SUSExx-64bit-Odbc.tar.gz   GaussDB-8.1.3-SUSExx-64bit-ClientTools.tar.gz1.2 在客户端执行如下命令安装unixODBC。默认安装到“/usr/local”目录下，生成数据源文件到 “/usr/local/etc”目录下，库文件生成在“/usr/local/lib”目录。tar zxvf unixODBC-2.3.0.tar.gzcd unixODBC-2.3.0#修改configure文件(如果不存在，那么请修改configure.ac)，找到LIB_VERSION#将它的值修改为"1:0:0"，这样将编译出*.so.1的动态库，与psqlodbcw.so的依赖关系相同。vim configure./configure --enable-gui=no #如果要在TaiShan服务器上编译，请追加一个configure参数： --build=aarch64-unknown-linux-gnu make#安装可能需要root权限make install1.3 替换客户端GaussDB(DWS)驱动程序。将GaussDB-8.1.3-SUSExx-64bit-Odbc.tar.gz解压到“/usr/local/lib”目录下。解压会得到“psqlodbcw.la”和“psqlodbcw.so”两个文件。将GaussDB-8.1.3-SUSExx-64bit-ClientTools.tar.gz解压后lib目录中的库拷贝到“/usr/local/lib”目录下。1.4 配置数据源配置ODBC驱动文件。在“/usr/local/etc/odbcinst.ini”文件中追加以下内容。[GaussMPP]Driver64=/usr/local/lib/psqlodbcw.sosetup=/usr/local/lib/psqlodbcw.so1.5 配置数据源文件在“/usr/local/etc/odbc.ini ”文件中追加以下内容。[MPPODBC]Driver=GaussMPPServername=10.10.0.13（数据库Server IP）Database=postgres  （数据库名）Username=omm  （数据库用户名）Password=  （数据库用户密码）Port=25308 （数据库监听端口）Sslmode= disable1.6 配置数据库服务器以操作系统用户omm登录安装有MPPDB服务的任一主机。执行source ${BIGDATA_HOME}/mppdb/.mppdbgs_profile命令启动环境变量。执行如下命令增加对外提供服务的网卡IP或者主机名（英文逗号分隔），其中NodeName为当前节点名称：gs_guc reload -Z coordinator -N NodeName -I all -c "listen_addresses='localhost,192.168.0.100,10.11.12.13'"在DR（Direct Routing，LVS的直接路由DR模式）模式中需要将虚拟IP地址（10.11.12.13）加入到服务器的监听地址列表中。listen_addresses也可以配置为“*”或“0.0.0.0”，此配置下将监听所有网卡，但存在安全风险，不推荐用户使用，推荐用户按照需要配置IP或者主机名，打开监听。执行如下命令在所有的CN配置文件中增加一条认证规则。（这里假设客户端IP地址为10.11.12.13，即远程连接的机器的IP地址）gs_guc reload -Z coordinator -N all -I all -h "host all jack 10.11.12.13/32 sha256"重启集群。gs_om -t stopgs_om -t start1.7 配置环境变量vim ~/.bashrc在配置文件中追加以下内容。export LD_LIBRARY_PATH=/usr/local/lib/:$LD_LIBRARY_PATHexport ODBCSYSINI=/usr/local/etcexport ODBCINI=/usr/local/etc/odbc.ini1.8 执行如下命令使设置生效source ~/.bashrc1.9 测试数据源配置isql –v MPPODBC1.10 执行SQL语句进行测试创建测试表CREATE TABLE if not exists customer_t2(c_customer_sk INTEGER, c_customer_name VARCHAR(32));插入数据INSERT INTO customer_t2 VALUES (1,'table');进行查询select * from customer_t2;将建存储过程create or replace procedure testproc (psv_in1 in integer,psv_in2 in integer,psv_inout in out integer)as begin psv_inout := psv_in1 + psv_in2 + psv_inout; end; drop table IF EXISTS customer_t2;CREATE TABLE customer_t2(c_customer_sk INTEGER, c_customer_name VARCHAR(32));insert into customer_t2 values(25,'li');call  testproc(20,50,70);

一、版本：线下811二、问题背景1.259节点的data4磁盘满，258、260节点的一块盘也是90%多，这三个节点下的实例有些在同一个安全环。2.3028、3038两个从备实例也是down状态。3.集群不可用。三、处理过程1.259节点的data4满盘，data4对应6055和6076实例，停止6076实例，挪走xlog，腾出部分空间后，6055变为normal，集群降级。2.258节点的data1使用率从95逐渐上涨，应该是6056在和6055做数据同步，有数据落盘，导致该盘容量上涨，最终达到100%3.停掉258节点data1下的6056，移走xlog，腾出空间，让6056不再redo，避免磁盘进一步上涨。4.排查259节点data4的哪个目录占空间大，结果是，master/base/44610，并找到一张大表5.连上对应的6055，根据找到的大表，查找到对应的表名，大小为993G6.连上cn查下该表大小也为993G，连其他dn查下该表，只有8kb；应该是倾斜导致，删除掉这张大表7.移回6056的xlog，启动6056实例，状态变为catchup，但对应的data1磁盘使用又逐渐上涨8.此时6056catchup，环上对应3029变为Down；6059、6060均异常，集群不可用；9.后面6056和3029这一对环出问题，集群不可用，3029之前是normal；3029实例对应的盘使用率达95%10.查看3029日志，起不来是因为，（811版本机制）磁盘使用率已经超过阈值了，enable_transaction_read_only参数如果为on，不会拉从备，如果为off，会尝试拉起从备；之前看的其他节点的cm.conf里的enable_transaction_read_only为off；但不知为何没有拉起从备。重新使用gs_guc reload 将磁盘只读检测关闭；查看3029，变为normal11.将第1步的6076的xlog文件移回，并启动6076实例；此时259的data4磁盘使用率为72%（第6步清理过倾斜的大表）12.258节点的data1使用率达100%，停止对应的6041实例，拉起全量build13.此时260节点的data2满盘，查看对应实例如下：观察6050是否能正常启动14.一段时间后，6050正常启动，但对应260节点的data2可用空间降至18G；查看data2下的从备实例占用为413G，将从备日志删除 rm -rf 00*15.将上一步的从备xlog删除后，data2使用率降至95%，对应的3029实例normal，环上的主6055normal、备6056Need repair（disconnected），之前是Need repair（normal）16.一段时间后6056变为normal17.一段时间后，260节点的data2使用率降至60%18.最后在查下集群状态，只有6041在全量build，等待完成即可

一、问题版本：线下811二处理过程：1.在扩容过程中，页面显示重分布失败，查看详细信息，可得知还剩多少张表没有重分布2.后台查看redis进程，若进程存在，表示重分布仍在继续执行3.查看gs_redis-xxxx.log（第一个CN节点），未发现有报错，进程也存在，等待即可4.后台重分布完成，页面重分布状态仍然显示失败，重分布进度未正常同步到FIM界面5.登录OMS数据库，更新MPP_LOGIC_CLUSTER_REDISTRIBUTION_TASK表的TASKID字段后，刷新FIM界面，重分布状态刷新为已重分布

An I/O error occurred while sending to the backend Caused by：Read time out【问题现象】cdm侧抽数到dws作业失败，报错An I/O error occurred while sending to the backend Caused by：Read time out【问题分析】根据报错时间点查看cn日志，多个任务报错时间cdm侧下发的truncate table任务锁等待超时，排查排查与之锁冲突的语句，发现有个存储过程在调用该表【问题规避】避免在作业运行时有其他业务调用该表，防止锁冲突导致作业失败

gs_replace修复实例报错【问题现象】1、在拉起cn阶段超时报错，查看gs_replace日志报错cn退出失败2、查看执行修复命令的该cn日志，日志报错两阶段事务清理失败：clean up 2pc transactions failed3、在两阶段事务清理时告警发送失败，cn退出卡住。可暂时屏蔽告警，去/opt/huawei/snas/bin目录下重命名告警二进制文件snas_cm_cmd，gs_ssh -c 'mv /opt/huawei/snas/bin/snas_cm_cmd /opt/huawei/snas/bin/snas_cm_cmd_bak'执行后重试gs_replace4、实例修复成功后需恢复告警二进制文件:gs_ssh -c 'mv /opt/huawei/snas/bin/snas_cm_cmd_bak /opt/huawei/snas/bin/snas_cm_cmd'

情况一：虚拟机无法登录（定界标准虚拟机无法登录或登录上之后很快就掉）可以询问是否网络测做过变更操作，IP冲突，联系网络测同事排查。情况二：无法进入DWS相关服务容器（定界标准POD拉起时间过长后无法拉起）kubectl describe pod XXX -n dws 查看容器详情其中有Fail信息或err信息，联系CDK测同事排查。情况三：DWS创建集群失败的网络问题（定界标准以下几种情况均需VPC网络测排查）登录RMS数据库之后,查询集群下发失败环节1、RdsPingInstanceManagerIpTask(界面错误码DWS.6016\DWS.6000)1.1通过BMC登录到节点之后ping CDK master节点，或者在CDK master节点ping BMS机器（BMS的管理IP可以在dws instance表中查找。）管理IP查询方法:select manageIp from rds_instance  where name like '%集群名称%';1.2vlan有Ip而bond0无Ip场景，且发单台裸机bond0无ip，查看网络是否有问题，可能原因（机器入云前发放过裸机，交换机内部配置未手动清理）1.3ps -ef|grep rpc或查看/home/Ruby/log/下是否有channel日志，确保rpc进程已启动注意要是分不清网络从哪到哪看这个:http://3ms.huawei.com/km/blogs/details/93118772、RdsDownloadPackageTask2.1OBS域名不通，网段未放通3、RdsCreatePortTask3.1 BMS机型组bond错误，重新组bond。注意DWS是两个网卡，四网口，跨网卡组一个bond即可。4、RdsInitInstanceTask4.1创建互信失败，集群内不同节点相互ping，检查网络是否互通，如果不互通，则找网络放开对应vlan。情况四：DWS创建集群失败的BMS相关问题 （定界标准以下几种情况均需BMS测排查） 登录RMS数据库之后,查询集群下发失败环节 1、dsCreateInstanceTask 1.1根据日志查看具体原因，日志中找到BMS.0042类似这样的错误码和错误提示信息，或 glance image-show 查看镜像注册是否有问题（如公共镜像桶OBS端口号，管理镜像or公共镜像等） 2、StartupServerTask 2.1启动BMS失败 3、错误码 3.1BMS.0042(规格无法匹配到裸机服务器\裸机资源被占用，未释放\下发裸机的IP不足\下发裸机的vlan不足) 3.2BMS.3037(创建BMS集群  资源不可用) 3.3BMS.3033(创建BMS volume type错误) 4、BMS创建规格页面添加标签按照文档无法校验通过