GaussDB(DWS) DMS在性能监控时，有聚合数据的需求，JDK自带的SummaryStatistics类自带求和、最大值、最小值、平均值等聚合算法，要实现均值、方差、峰值、偏度等数据聚合方式，需要一个继承SummaryStatistics子类，并在子类中实现相关的算法。代码示例如下：import java.util.DoubleSummaryStatistics;/**  * @Description: Double流统计算法  */public class AggregationDoubleStatistics extends DoubleSummaryStatistics {     private double m1;     private double m2;     private double m3;     private double m4;     @Override     public void accept(double x) {         super.accept(x);         long n = getCount();         //δ         double delta = x - m1;         //δ / n         double deltaN = delta / n;         //δ^2 / n         double delta2N = delta * deltaN;         //δ^2 / n^2         double delta2N2 = deltaN * deltaN;         //δ^3 / n^2         double delta3N2 = delta2N * deltaN;         //δ^4 / n^3         double delta4N3 = delta3N2 * deltaN;         m4 += (n - 1) * (n * n - 3 * n + 3) * delta4N3                + 6 * m2 * delta2N2                - 4 * m3 * deltaN;         m3 += (n - 1) * (n - 2) * delta3N2                - 3 * m2 * deltaN;         m2 += (n - 1) * delta2N;         m1 += deltaN;     }     @Override     public void combine(DoubleSummaryStatistics other) {         throw new UnsupportedOperationException(                 "Can't combine a standard DoubleSummaryStatistics with this class");     }     public void combine(MoreDoubleStatistics other) {         MoreDoubleStatistics s1 = this;         MoreDoubleStatistics s2 = other;         long n1 = s1.n();         long n2 = s2.n();         long n = n1 + n2;         //δ         double delta = s2.m1 - s1.m1;         //δ / n         double deltaN = delta / n;         //δ^2 / n         double delta2N = delta * deltaN;         //δ^2 / n^2         double delta2N2 = deltaN * deltaN;         //δ^3 / n^2         double delta3N2 = delta2N * deltaN;         //δ^4 / n^3         double delta4N3 = delta3N2 * deltaN;         this.m4 = s1.m4 + s2.m4 + n1 * n2 * (n1 * n1 - n1 * n2 + n2 * n2) * delta4N3                + 6.0 * (n1 * n1 * s2.m2 + n2 * n2 * s1.m2) * delta2N2                + 4.0 * (n1 * s2.m3 - n2 * s1.m3) * deltaN;         this.m3 = s1.m3 + s2.m3 + n1 * n2 * (n1 - n2) * delta3N2                + 3.0 * (n1 * s2.m2 - n2 * s1.m2) * deltaN;         this.m2 = s1.m2 + s2.m2 + n1 * n2 * delta2N;         this.m1 = s1.m1 + n2 * delta;         super.combine(other);     }     private long n() {         return getCount();     }     /**      * 计算流的方差      * @return      */     public double getVariance() {         return n() <= 1 ? 0 : m2 / (n() - 1);     }     /**      * 计算流的标准差      * @return      */     public double getStdDev() {         return Math.sqrt(getVariance());     }     /**      * 计算流的偏度      * @return      */     public double getSkewness() {         return m2 == 0 ? 0 : Math.sqrt(n()) * m3 / Math.pow(m2, 1.5);     }     /**      * 计算流的峰度      * @return      */     public double getKurtosis() {         return m2 == 0 ? 0 : n() * m4 / (m2 * m2) - 3.0;     }}使用示例：private void getAggregatedData(List<Double> list) {     MoreDoubleStatistics doubleStatistics =  list            .stream()             .mapToDouble(t -> t)             .collect(MoreDoubleStatistics::new, MoreDoubleStatistics::accept, MoreDoubleStatistics::combine);     double maxAggregatedData = doubleStatistics.getMax();     double minAggregatedData = doubleStatistics.getMin();     double avgAggregatedData = doubleStatistics.getAverage();     double sumAggregatedData =  doubleStatistics.getSum();     double varAggregatedData =  doubleStatistics.getVariance();}原文链接：https://bbs.huaweicloud.com/blogs/237976【推荐阅读】【最新活动汇总】DWS活动火热进行中，互动好礼送不停（持续更新中）  HOT  【博文汇总】GaussDB(DWS)博文汇总1，欢迎大家交流探讨~（持续更新中）【维护宝典汇总】GaussDB(DWS)维护宝典汇总贴1，欢迎大家交流探讨（持续更新中）【项目实践汇总】GaussDB(DWS)项目实践汇总贴，欢迎大家交流探讨（持续更新中）【DevRun直播汇总】GaussDB(DWS)黑科技直播汇总，欢迎大家交流学习（持续更新中）【培训视频汇总】GaussDB(DWS) 培训视频汇总,欢迎大家交流学习（持续更新中）扫码关注我哦，我在这里↓↓↓

【摘要】 GDS是GaussDB(DWS)提供的一个数据导入导出工具，可在支持多种场景下的数据迁移业务，如异型数据库之间、两个集群之间等。GDS性能较高，单核处理能力上限约400MB/s，相比copy、\COPY工具性能更优、运行更稳定、容错性更强。1. GDS定位GDS是GaussDB(DWS)提供的一个数据导入导出工具，可在支持多种场景下的数据迁移业务，如异型数据库之间、两个集群之间等。GDS性能较高，单核处理能力上限约400MB/s，相比COPY、\COPY工具性能更优、运行更稳定、容错性更强。2. GDS根基GDS基于FDW，全称是Foreign Data Wrapper（外部数据包装器）。这个功能是PostgreSQL 9.1首次引入的，实现了部分SQL/MED的特性。 2.1 什么是FDW顾名思义，这个功能与数据库外部的数据有关系，对于外数据的具体描述是通过外部表来定义的。以GDS外部表创建语句为例说明外部表的结构：CREATE FOREIGN TABLE [ IF NOT EXISTS ] table_name( [ { column_name type_name POSITION(offset,length) | LIKE source_table } [, ...] ] )SERVER gsmpp_server OPTIONS ( { option_name ' value ' } [, ...] )[ { WRITE ONLY | READ ONLY }][ WITH error_table_name | LOG INTO error_table_name][REMOTE LOG 'name'][PER NODE REJECT LIMIT 'value'][ TO { GROUP groupname | NODE ( nodename [, ... ] ) } ];可以看出，外部表可以分为三部分：字段定义、server定义、options定义。其中：（1）字段属性定义与本地表定义方式类似，甚至可以使用like L_TBL等语法进行定义；（2）server定义，需要使用CREATE SERVER xxx_server创建；（3）options选项，由与该外表相关的FDW实现决定。在GDS使用过程中，安装自定义FDW、创建server等配置都是在initdb阶段执行，无须用户额外设置。Postgres现在有很多FDW扩展，其中postgres_fdw、file_fdw是由官方全球开发组维护，postgres_fdw可用于访问远程PostgreSQL服务器。下图展示了FDW的执行过程[1]。① 查询分析模块为输入的SQL创建一棵查询树；② 计划器（或执行器）连接到远程服务器；③ 执行EXPLAIN命令以估算计划路径的代价；④ 计划器按照计划树创建出纯文本SQL语句；⑤ 执行器将纯文本SQL语句发送到远程服务器并接收结果。2.2 GDS自定义FDW根据导入导出场景，GaussDB(DWS)实现了自定义的FDW扩展——dist_fdw。dist_fdw运行于GaussDB内核之中，在initdb时进行安装，所以一般情况下对用户是透明的。3. 多角度缔造高性能3.1 多线程工作模式GDS使用多线程模式，由主线程负责接收请求，然后分配给工作线程进行具体的业务处理，可以并发处理导入导出业务。主线程与工作线程通过UnixSocket进行通信，通信内容包括：分派新任务、停止工作线程、工作线程状态上报等。每个线程可承载多个导入导出业务，通过与事件消息驱动机制相结合，实现高速网络通信，确保业务执行高性能、高并发。3.2 事件消息驱动机制GDS采用事件驱动模型，选择当前系统可支持的最高效的多路复用机制（epoll、poll、select等）。3.3 大文件导入优化对于超大文件的导入，如果仍然与普通文件一样，继续采用串行方式导入，必然会成为业务瓶颈，导致数据迁移、备份等过程的无限延长，无法充分发挥多核机器、GDS多线程架构的优势。针对该场景，GDS引入分片导入机制，实现并行导入，充分发挥软硬件性能，减少业务阻塞，减少数据迁移耗时。该功能针对本地文件的导入场景，需通过外表file_sequence参数进行相应设置。该参数格式为file_sequence '文件被拆分的总数-当前分片' 。例如：file_sequence '3-1' 表示导入的文件在逻辑上被拆分成3份，当前外表导入的数据为第一个分片上的数据。file_sequence '3-2' 表示导入的文件在逻辑上被拆分成3份，当前外表导入的数据为第二个分片上的数据。file_sequence '3-3' 表示导入的文件在逻辑上被拆分成3份，当前外表导入的数据为第三个分片上的数据。这里给出一个使用示例：-- step1. 创建目标表CREATE TABLE gds_widetb_1 (city integer, tel_num varchar(16), card_code varchar(15), phone_code vcreate table pipegds_widetb_3 (city integer, tel_num varchar(16), card_code varchar(15), phone_code varchar(16), region_code varchar(6), station_id varchar(10), tmsi varchar(20), rec_date integer(6), rec_time integer(6), rec_type numeric(2), switch_id varchar(15), attach_city varchar(6), opc varchar(20), dpc varchar(20));--step2. 创建带有file_sequence字段的外表。CREATE FOREIGN TABLE gds_csv_r_1( like gds_widetb_1) SERVER gsmpp_server OPTIONS (LOCATION 'gsfs://127.0.0.1:8781/wide_tb.txt', FORMAT 'text', DELIMITER E'|+|', NULL '', file_sequence '3-1');CREATE FOREIGN TABLE gds_csv_r_2( like gds_widetb_1) SERVER gsmpp_server OPTIONS (LOCATION 'gsfs://127.0.0.1:8781/wide_tb.txt', FORMAT 'text', DELIMITER E'|+|', NULL '', file_sequence '3-2');CREATE FOREIGN TABLE gds_csv_r_3( like gds_widetb_1) SERVER gsmpp_server OPTIONS (LOCATION 'gsfs://127.0.0.1:8781/wide_tb.txt', FORMAT 'text', DELIMITER E'|+|', NULL '', file_sequence '3-3');--step3. 将wide_tb.txt并发导入到gds_widetb_1。\parallel onINSERT INTO gds_widetb_1 SELECT * FROM gds_csv_r_1;INSERT INTO gds_widetb_1 SELECT * FROM gds_csv_r_2;INSERT INTO gds_widetb_1 SELECT * FROM gds_csv_r_3;\parallel off3.4 SMP特性支持导入场景SMP特性通过算子并行来提升性能，本质上是一种利用富余资源来换取时间的方案，计划并行之后会占用更多的系统资源，包括CPU、内存、网络、I/O等等。在合适的场景以及资源充足的情况下，能够起到较好的性能提升效果。SMP支持自适应特性，该特性会根据当前资源和查询特征，动态选取最优的并行度。SMP特性支持支持GDS导入的外表扫描并行，当集群资源充足时，可以发挥各节点性能，加速导入执行效率。4. 全方位丰富功能4.1 容错机制提供了强大的容错机制，包括错误默认处理、错误表、错误日志等多种方式，减少数据导入导出异常中止的情况，方便用户事后查询分析。4.2 编码解析支持多种类型的字符编码，包括UTF-8、GBK、ASCII、LATIN1等。4.3 多字符字段/换行分割符对于外表属性，分隔符delimiter、行分隔符eol，既兼容原有的逗号、\n等默认方式，还支持用户自定义多字符分隔符，最多可支持10个字节。在场景复杂、噪声较多、数据量很大的场景下，单字符分隔符很容易与数据本身冲突，而使用多字符分隔符，可以减少这种冲突，且可以轻容兼容异构数据库，方便用户进行数据处理。4.4 数据不落地此前GDS只支持本地文件的导入导出，因此无论是数据加工清洗或者是远端数据的导入导出都需要在GDS本地生成一份中间数据，这对用户来说不仅消耗磁盘空间并且很不方便。据此，开发人员对不落地导入导出特性进行了规划和实现，提供了另外一种导入导出方式，不仅节省了用户的磁盘空间而且让GDS的使用变得更加灵活多变。具体使用方式参见用户手册。5. 展望随着数据仓库业务的发展，GDS使用场景日益增多，这就要求GDS仍要不断迭代，充分深入挖掘用户需求，提高产品化程度。继往开来，GDS一批新特性已展开规划，如自动化工具、过程监控工具、云化等等。未来可期，作为GaussDB(DWS)的强有力数据迁移工具，GDS会继续强化，丰富产品生态。【参考文献】[1] [日]铃木启修.PostgreSQL指南——内幕探索[M].电子工业出版社:北京,2019:85-86.原文链接：https://bbs.huaweicloud.com/blogs/237973【推荐阅读】【最新活动汇总】DWS活动火热进行中，互动好礼送不停（持续更新中）  HOT  【博文汇总】GaussDB(DWS)博文汇总1，欢迎大家交流探讨~（持续更新中）【维护宝典汇总】GaussDB(DWS)维护宝典汇总贴1，欢迎大家交流探讨（持续更新中）【项目实践汇总】GaussDB(DWS)项目实践汇总贴，欢迎大家交流探讨（持续更新中）【DevRun直播汇总】GaussDB(DWS)黑科技直播汇总，欢迎大家交流学习（持续更新中）【培训视频汇总】GaussDB(DWS) 培训视频汇总,欢迎大家交流学习（持续更新中）扫码关注我哦，我在这里↓↓↓

【摘要】 什么是逻辑集群，有哪些能力，可以应用在哪些场景，本文将给你答案。GaussDB(DWS)为什么要支持逻辑集群传统的基于MPP的分布式数据仓库采用的是全对等架构，每个表数据平均分布到所有节点中，这样能保证足够的并发度以及节点间协同，保证性能SLA。只要保证数据在所有节点上是均衡的，数据查询会将计算平均分配到所有节点上，结构简单，扩展性好 。                                      随着业务越来越大，这种简单的数据分布方式可能会带来一些问题。具体表现为：用户不断把各种业务数据集成到一个数仓中，不同业务逻辑访问同一个数仓，这减少了维护多个数仓的成本，运维方便。但也会导致数仓的数据规模越来越大，表越来越多。不同业务访问数仓过程中会带来资源的竞争，比如CPU、内存、磁盘IO、网络的竞争。虽然通过配置资源池可以一定程度解决资源竞争，但所有业务执行逻辑仍然同时在每个节点上执行，无法做到资源完全隔离。事实上，同一业务的不同作业总是倾向访问本业务相关的表，对其他业务的表访问较少，如果能做到业务内数据“高内聚”，业务间“低耦合”无疑是更好的选择。数据库表无论大小都被切分到所有节点，对小表来说，数据过于分散。当节点规模达到一定程度后，通过增加更多节点，提高查询并行度的方式可能就无法带来理想的扩展性了。如果为了避免集群变大，将不同业务数据拆分成独立集群，集群间数据互访就需要从应用层解决，或者需要跨集群导数。   逻辑集群实现了一个大集群按节点拆分，将大集群中所有节点分组，每个节点组构建一个逻辑集群，可以很好的解决上面所述的问题。   企业可以根据不同业务的数据规模为其创建不同节点数的逻辑集群，由于不同节点属于不同的逻辑集群，这样可以做到不同业务之间物理资源彻底隔离。在一个逻辑集群内部，所有节点是对等的，数据保持均衡，确保逻辑集群内部作业高效运行。同时，由于所有业务仍然在一个统一的大集群内，有统一的元数据管理和节点管理，跨逻辑集群数据互访非常容易和高效，这样就可以做到高内聚，低耦合。 逻辑集群的能力逻辑集群实现了三种隔离：数据隔离：不同业务的表创建在不同逻辑集群上，表数据物理上隔离；资源隔离：不同逻辑集群的CPU，内存，IO资源是隔离的；跨逻辑集群数据访问的资源是受控的；同一逻辑集群内部还可以通过负载队列进行作业资源管控；权限隔离：访问其他逻辑集群的表和数据库对象需要授权；逻辑集群支持弹性计算，一个逻辑集群的作业可以利用其他逻辑集群计算资源。逻辑集群间可以异构部署，一个逻辑集群内部节点间配置应该是完全相同的，不同逻辑集群间节点配置可以不同（包括CPU、内存、IO等硬件配置，但操作系统配置需要相同）。每个逻辑集群可以独立扩缩容，业务迁移后不用的逻辑集群可以删除，释放的节点可以用于创建新的逻辑集群。逻辑集群典型场景多子业务拆分：将一个大业务拆分为多个子业务，每个子业务创建一个独立逻辑集群；子业务之间资源隔离，同时也可以方便地进行跨子业务查询。 数据加工和数据查询作业分离：将数据加工和灵活查询作业分开到两个逻辑集群，数据加工结果写入灵活查询逻辑集群中，保证两类作业资源隔离，且可以根据需要独立扩容。原文链接：https://bbs.huaweicloud.com/blogs/237716【推荐阅读】【最新活动汇总】DWS活动火热进行中，互动好礼送不停（持续更新中）  HOT  【博文汇总】GaussDB(DWS)博文汇总1，欢迎大家交流探讨~（持续更新中）【维护宝典汇总】GaussDB(DWS)维护宝典汇总贴1，欢迎大家交流探讨（持续更新中）【项目实践汇总】GaussDB(DWS)项目实践汇总贴，欢迎大家交流探讨（持续更新中）【DevRun直播汇总】GaussDB(DWS)黑科技直播汇总，欢迎大家交流学习（持续更新中）【培训视频汇总】GaussDB(DWS) 培训视频汇总,欢迎大家交流学习（持续更新中）扫码关注我哦，我在这里↓↓↓

【摘要】 GaussDB(DWS)SQL On Anywhere特性可以实现与其他大数据组件和数据库互联互通，扩大了其数据分析的应用场景，并且可以实现冷热数据分离，分别存储在不同成本的介质上，从而降低用户成本。本文着重介绍了GaussDB（DWS）SQL On Anywhere的内部三种实现方式FDW、ELK和EC+ODBC技术，并对比其优缺点，及其整个特性的未来规划。1. 什么是SQL On Anywhere？查询分析是大数据要解决的核心问题之一，虽然大数据相关的处理引擎组件种类繁多，并提供了丰富的接口供用户使用，但相对传统数据库用户来说，SQL语言依然是使用最简单、最广泛和方便的一种接口。如果能在一个客户端中使用SQL语句操作不同的大数据组件，将极大提升使用各种大数据组件的效率。GaussDB(DWS)的SQL On Anywhere，主要指对大数据的文件系统和与其他异构数据库的访问和交互，构筑起统一的大数据计算平台。大数据文件系统主要包括HDFS和OBS，其他异构数据库主要包括Oracle、Spark和Other GaussDB(DWS)。2. GaussDB(DWS)SQL On Anywhere的作用及其应用场景通过SQL On Anywhere特性可以实现与其他大数据组件和数据库互联互通访问，可以直接同时处理本地和HDFS/OBS上的数据集，甚至其他异构数据库的数据，而无需导入导出数据，将其分析能力从本地存储扩展到数据湖中，扩大GaussDB DWS的大数据分析的应用场景；通过该特性可以帮助客户实现冷热数据分离，将使用频度更高的热数据存储在本地，而使用频度更低的冷数据存储在成本更低廉的共享存储HDFS或者DWS上，降低用户成本。从应用场景来看，可以满足如下业务需求：针对多数据源需要构建虚拟的统一数据仓库，实现多数据源联邦查询，跨数据仓库热数据和HDFS/OBS冷数据的复杂混合查询，需要提供一致的、熟悉的数据仓库操作体验。满足低频的业务全数据的低成本低延迟即席查询。3. GaussDB(DWS)SQL On Anywhere的实现方式GaussDB(DWS)SQL On Anywhere针对大数据的文件系统的访问主要通过FDW或ELK机制实现的，而跨数据库的访问主要通过EC+ODBC的方式实现的。   3.1 利用FDW访问HDFS/OBS数据GaussDB(DWS)对存储在HDFS上的Hadoop或者OBS原生数据的访问，采用FDW（Foreign Data Wrapper）机制，也称外表机制。首先通过创建Foreign Data Server来定义对HDFS数据源或同构其他集群的连接信息；之后创建Foreign Table，用于在GaussDB A数据库内部系统表中，定义对应的HDFS数据源上Hadoop原生结构化数据表的结构或对应同构其他集群结构化数据表的结构。例如读取hdfs上的数据，其流程如下：    1）建立一个hdfs_server，其中hdfs_fdw为数据库中存在的foreign data wrapper。--创建hdfs_server。postgres=# CREATE SERVER hdfs_server FOREIGN DATA WRAPPER HDFS_FDW OPTIONS     (address '10.146.187.231:8000,10.180.157.130:8000' ,     hdfscfgpath '/opt/hadoop_client/HDFS/hadoop/etc/hadoop',      type 'HDFS') ;    2）创建一个hdfs外表读取hdfs上的数据CREATE FOREIGN TABLE region (    R_REGIONKEY INT4,    R_NAME TEXT,    R_COMMENT TEXT )SERVER  hdfs_server OPTIONS(     FORMAT 'orc',     FOLDERNAME '/user/hive/warehouse/mppdb.db/region_orc11_64stripe/')DISTRIBUTE BY roundrobin;      3）查询HDFS外表，例如：select * from region limit 10;目前外表支持与普通表进行关联查询，并支持多种文件存储格式，其支持的文件格式如下：文件系统读支持的文件格式写支持的文件格式HDFSORC、Parquet、TEXT、CSVORC、TEXT、CSVOBSORC、Carbondata、TEXT、CSVORC、TEXT、3.2 通过ELK访问HDFSELK的方式类似于HAWQ，它是通过建立表空间为HDFS表空间，直接将数据存储和访问HDFS文件系统，目前只支持访问HDFS文件系统，而不支持访问OBS上的数据。首先通过创建HDFS表空间，然后会创建一个HDFS表，在创建时指定表空间为HDFS表空间，最后对HDFS表的操作如同普通表的操作，可进行插入修改删除数据。以GaussDB数据库数据推到HDFS中    1）在数据库中创建HDFS表空间CREATE TABLESPACE hdfs_table RELATIVE LOCATION ‘tmp/hdtest’With (filesystem=’hdfs’, address=’28.4.136.221:9000’, cfgpath=’/opt/Huawei/bigdata/mppdb/hdfs_conf/zhndnrop/omm@HADOOP.COM/’, storepath=’/tmp/test’);    2）数据库中创建HDFS表CREATE TABLE abc( zjxxlh char(20), nbbsh char(20), khwybh char(20), zjlx char(20))WITH (orientation=orc) TABLESPACE tables_hdfs;    3）向表中插入数据insert into abc select * from region10;3.3基于EC+ODBC的跨集群访问数据GaussDB(DWS)支持通过 EC(全称Extension Connector)+ODBC统一访问其它大数据组件——将SQL发给其它大数据组件并接收执行结果，实现跨集群访问数据。目前EC+ODBC为用户提供了三种功能： SQL on Oracle、SQL on Spark和SQL on other GaussDB，分别用于连接Oracle数据库、Spark集群和其他GaussDB集群。EC+ODBC的基本工作原理是：用户首先构建Data Source对象（其中包含目标库的一些连接信息和字符编码方式），然后用户获取该Data Source的使用权限，最后通过标准ODBC API连接目标库，发送SQL语句并获取执行结果。为了方便使用，EC+ODBC为用户提供了统一的连接函数exec_on_extension(text, text)。其中，第一个参数为Data Source名称，第二个参数为发送的SQL语句，例如：postgres=# SELECT * FROM exec_on_extension('ds_spark', 'select * from a;') AS (c1 int);4 . GaussDB(DWS) SQL On Anywhere的实现方式优缺点对比方式数据源优势劣势EC+ODBCORACLESparkMPPDB1.使用灵活2.可以下推很复杂的查询到其他数据库3.支持和本地多表join1.查询得到的数据和本地join须通过stream，存在较大网络开销，查询操作执行的节点存在单点瓶颈2.配置繁琐，依赖odbc驱动，兼容性问题较多FDWHDFSOBS1.支持多DN并发查询2.支持和本地多表join等复杂查询3.支持analyze收集统计信息4.格式支持丰富，易扩展1. 无法在一张外表，同时支持读和写2. 不支持增量写，只支持覆盖写，不支持update和delete3. 不支持和本地表join的复杂查询结果直接写入外表ELKHDFS1.   支持多DN并发查询2.   支持和本地多表join查询和写入3.   支持analyze收集统计信息4.   节点本地化效率相对比较高5.   支持增量写，支持update和delete1. HDFS表空间方式要求HDFS集群与MPPDB集群有强依赖关系，不易于扩展2. 格式支持有限，目前只支持ORC格式，并且只支持访问HDFS文件系统3. 有可能会产生大量小文件5. GaussDB(DWS)未来规划GaussDB(DWS)未来规划主要仍然围绕互联互通和数据冷热存储开展，主要扩实现自动的冷热数据管理机制和扩展外表的功能：实现冷热数据的自动管理；同一个外表同时支持读写功能；外表支持更多的文件格式；外表支持将复杂查询的查询结果直接写入外表；外表支持增量写。原文链接：https://bbs.huaweicloud.com/blogs/237721【推荐阅读】【最新活动汇总】DWS活动火热进行中，互动好礼送不停（持续更新中）  HOT  【博文汇总】GaussDB(DWS)博文汇总1，欢迎大家交流探讨~（持续更新中）【维护宝典汇总】GaussDB(DWS)维护宝典汇总贴1，欢迎大家交流探讨（持续更新中）【项目实践汇总】GaussDB(DWS)项目实践汇总贴，欢迎大家交流探讨（持续更新中）【DevRun直播汇总】GaussDB(DWS)黑科技直播汇总，欢迎大家交流学习（持续更新中）【培训视频汇总】GaussDB(DWS) 培训视频汇总,欢迎大家交流学习（持续更新中）扫码关注我哦，我在这里↓↓↓

【摘要】 GaussDB(DWS)提供了灵活的数据入库方式，可以将多种数据源的数据导入到GaussDB(DWS)中，如图1所示。各导入方式具有不同的特点，如表1所示，用户可以根据其特点自行选择。建议用户配合云数据迁移（Cloud Data Migration，简称CDM）、数据接入服务（Data Ingestion Service，简称DIS）和数据湖工厂（Data Lake Factory，简称DLF）。概述        云数据迁移服务（Cloud Data Migration，简称CDM），可以将其他数据源（例如MySQL）的数据迁移到GaussDB(DWS) 集群的数据库中。       GaussDB(DWS)提供了灵活的数据入库方式，可以将多种数据源的数据导入到GaussDB(DWS)中，如图1所示。各导入方式具有不同的特点，如表1所示，用户可以根据其特点自行选择。建议用户配合云数据迁移（Cloud Data Migration，简称CDM）、数据接入服务（Data Ingestion Service，简称DIS）和数据湖工厂（Data Lake Factory，简称DLF）一起使用，CDM用于批量数据迁移，DIS用于流数据接入，DLF可以对整个ETL过程进行编排调度，同时提供可视化的开发环境。导入方式：数据导入方式说明：数据导入方式数据源说明优势从OBS并行导入数据OBS支持将存储在OBS上的TXT、CSV、ORC及CARBONDATA格式的数据并行导入到GaussDB(DWS)，支持导入后查询数据，也支持远程读OBS上的数据。GaussDB(DWS)优先推荐的导入方式。并行拉取方式，性能好，横向扩展。使用GDS从远端服务器导入数据Servers（即远端服务器）使用GaussDB(DWS)提供的GDS工具，利用多DN并行的方式，将数据从远端服务器导入到GaussDB(DWS)。这种方式导入效率高，适用于大批量数据入库。从MRS导入数据到集群MRS（HDFS）配置一个GaussDB(DWS)集群连接到一个MRS集群，然后将数据从MRS的HDFS中读取到GaussDB(DWS)。并行拉取方式，性能好，横向扩展。使用CDM迁移数据到GaussDB(DWS)数据库、NoSQL、文件系统、大数据平台CDM提供同构/异构数据源之间批量数据迁移的功能，帮助您实现从多种类型的数据源迁移数据到GaussDB(DWS)。CDM在迁移数据到GaussDB(DWS)时，采用的是Copy方式和GDS并行导入方式。数据源丰富，操作简单。从DIS导入流式数据到GaussDB(DWS)流数据可以将流式数据从DIS通道周期性导入到GaussDB(DWS)集群的数据库中。导入GaussDB(DWS)前数据临时存储在OBS，待转储GaussDB(DWS)完成后删除OBS上的临时存储数据。准实时入库。第三方ETL工具数据库、NoSQL、文件系统、大数据平台请参考第三方ETL工具的相关文档。GaussDB(DWS)提供了DSC工具，可以将Teradata/Oracle脚本迁移到GaussDB(DWS)。·         使用DSC工具迁移SQL脚本·         使用Schema Convertor Tool将MySQL迁移到DWS通过OBS中转，数据源丰富，数据转换能力强。通过INSERT语句直接写入数据-使用SQL客户端工具或JDBC/ODBC驱动连接GaussDB(DWS)数据库时，执行INSERT语句插入一行或多行数据，以及从指定表插入数据。INSERT是最简单的一种数据写入方式，适合数据写入量不大，并发度不高的场景。使用COPY FROM STDIN导入数据其他文件或数据库使用Java语言开发应用程序时，通过调用JDBC驱动的CopyManager接口，从文件或其他数据库向GaussDB(DWS)写入数据。从其他数据库直接写入GaussDB(DWS)的方式，具有业务数据无需落地成文件的优势。使用gsql元命令\copy导入数据本地文件与直接使用SQL语句COPY不同，该命令读取/写入的文件只能是gsql客户端所在机器上的本地文件。操作简单，适用于小批量数据入库。 场景介绍本节介绍云数据迁移（Cloud Data Migration，以下简称CDM）的基础使用方法，通过使用CDM迁移本地MySQL数据库中的表，写入到数据仓库服务DWS的具体操作，帮助您了解、熟悉CDM服务，具体场景如图。CDM的基本使用流程如下：创建CDM集群创建连接创建并执行作业查看作业运行结果以完成数据迁移创建集群操作场景用户首先需要创建CDM集群，来执行MySQL数据同步到DWS的任务。前提条件已获取DWS所在的区域、VPC、子网、安全组。操作步骤1. 登录CDM管理控制台。2. 单击“购买云数据迁移服务”，进入创建CDM集群的界面，集群配置样例如下：当前区域：选择CDM集群的区域，不同区域的资源之间内网不互通，这里必须选择与DWS所在区域一致。可用区：指在同一区域下，电力、网络隔离的物理区域，可用区之内内网互通，不同可用区之间物理隔离。这里选择“可用区2”。集群名称：集群名称在4位到64位之间，必须以字母开头，可以包含字母、数字、中划线或者下划线，不能包含其他的特殊字符，例如：“cdm-aff1”。版本：默认即可。实例类型：用户按实际业务数据量选择实例规格，这里选择“cdm.medium”即可，适用大部分迁移场景。large：8核CPU、16G内存的虚拟机，最大带宽/基准带宽为3/0.8Gbps，能够并发执行的作业个数为20，适合单张表规模≥1000万条的场景。xlarge：16核CPU、32G内存的虚拟机，最大带宽/基准带宽为10/4Gbps，能够并发执行的作业个数为100，适合使用10GE高速带宽进行TB以上的数据量迁移。4xlarge：64核CPU、128G内存的虚拟机，最大带宽/基准带宽为30/30Gbps，能够并发执行的作业个数为300。虚拟私有云：即VPC（Virtual Private Cloud），这里必须选择与DWS相同的VPC。子网：推荐与DWS的子网一致。安全组：推荐与DWS的安全组一致。这里所配置的子网、安全组也可以与DWS不一致，但是需要配置安全组规则，允许CDM集群能正常访问DWS。其它参数保持默认即可。3. 查看当前配置，确认无误后单击“立即购买”进入规格确认界面。说明：集群创建好以后不支持修改规格，如果需要使用更高规格，需要重新创建。4. 单击“提交申请”，系统开始自动创建CDM集群，在“集群管理”界面可查看创建进度。说明：创建集群需要10～20分钟时间，如果您是首次创建CDM集群，只需要一分钟即可。创建连接连接说明迁移本地MySQL数据库到数据仓库服务DWS前，需要创建2个连接：MySQL连接：CDM连接本地MySQL数据库。DWS连接：CDM连接DWS数据库。由于CDM需要访问本地数据源，所以创建连接前，需先为CDM集群绑定弹性IP，CDM通过弹性IP访问MySQL数据库。前提条件用户本地的MySQL数据库已允许通过公网IP访问。用户已拥有EIP配额。已获取连接MySQL数据库的IP地址、端口、数据库名称、用户名、密码，且该用户拥有MySQL数据库的读、写和删除权限。用户已经拥有了DWS实例，已获取连接DWS数据库的IP地址、端口、数据库名称、用户名、密码，且该用户拥有DWS数据库的读、写和删除权限。创建MySQL连接1. 登录CDM管理控制台。2. 单击左侧导航上的“集群管理”，找到步骤1：创建集群章节创建的集群“cdm-aff1”。3. 单击该集群后的“绑定弹性IP”，选择并绑定弹性公网IP。图1 绑定EIP说明：如果用户对本地数据源的访问通道做了SSL加密，则CDM无法通过弹性IP连接数据源。4. 单击CDM集群后的“作业管理”，进入作业管理界面，再选择“连接管理> 新建连接”，进入选择连接器类型的界面，如图2所示。图2 选择连接器类型5. 选择“MySQL”后单击“下一步”，配置MySQL连接的参数。图3 创建MySQL连接单击“显示高级属性”可查看更多可选参数，具体请参见配置关系数据库连接。这里保持默认，必填参数如表1所示。参数名说明取值样例名称输入便于记忆和区分的连接名称。mysqllink数据库服务器MySQL数据库的IP地址或域名。192.168.0.1端口MySQL数据库的端口。3306数据库名称MySQL数据库的名称。sqoop用户名拥有MySQL数据库的读、写和删除权限的用户。admin密码用户的密码。-使用Agent是否选择通过Agent从源端提取数据。是Agent单击“选择”，选择连接Agent中已创建的Agent。-6. 单击“保存”回到连接管理界面。说明：如果保存时出错，一般是由于MySQL数据库的安全设置问题，需要设置允许CDM集群的EIP访问MySQL数据库。创建DWS连接1. 在“连接管理”界面单击“新建连接”，连接器类型选择“数据仓库服务（DWS）”。2. 单击“下一步”配置DWS连接参数，必填参数如表2所示，可选参数保持默认即可。参数名说明取值样例名称输入便于记忆和区分的连接名称。dwslink数据库服务器DWS数据库的IP地址或域名。192.168.0.3端口DWS数据库的端口。8000数据库名称DWS数据库的名称。db_demo用户名拥有DWS数据库的读、写和删除权限的用户。dbadmin密码用户的密码。-使用Agent是否选择通过Agent从源端提取数据。是Agent单击“选择”，选择连接Agent中已创建的Agent。-导入模式COPY模式：将源数据经过DWS管理节点后拷贝到数据节点。如果需要通过Internet访问DWS，只能使用COPY模式。COPY3. 单击“保存”完成创建连接。创建并执行作业操作场景    创建CDM迁移数据表的作业，执行从本地MySQL数据库复制表到DWS的任务。操作步骤1. 在集群管理界面，找到步骤1：创建集群章节创建的集群“cdm-aff1”。2. 单击该CDM集群后的“作业管理”，进入作业管理界面。3. 选择“表/文件迁移> 新建作业”，配置作业基本信息。图1 新建作业作业名称：输入便于记忆、区分的作业名称，例如：“mysql2dws”。源端作业配置源连接名称：选择步骤2：创建连接章节中创建的MySQL连接“mysqllink”。使用SQL语句：选择“否”。模式或表空间：选择从MySQL的哪个数据库导出表。表名：选择导出哪张表。其它可选参数保持默认即可，详细说明可参见配置关系数据库源端参数。目的端作业配置目的连接名称：选择步骤2：创建连接章节中创建的DWS连接“dwslink”。模式或表空间：选择导入到DWS的哪个数据库。自动创表：这里选择“不存在时创建”，当下面“表名”参数中配置的表不存在时，CDM会自动在DWS数据库中创建该表。表名：选择导入到DWS数据库的哪张表。其他可选参数保持默认即可，详细说明可参见配置关系数据库目的端参数。4. 单击“下一步”进入字段映射界面，CDM会自动匹配源端和目的端的数据表字段，需用户检查字段映射关系是否正确。如果字段映射关系不正确，用户单击字段所在行选中后，按住鼠标左键可拖拽字段来调整映射关系。导入到DWS时需要手动选择DWS的分布列，建议按如下顺序选取：有主键可以使用主键作为分布列。多个数据段联合做主键的场景，建议设置所有主键作为分布列。在没有主键的场景下，如果没有选择分布列，DWS会默认第一列作为分布列，可能会有数据倾斜风险。如果需要转换源端字段内容，可在该步骤配置，具体操作请参见字段转换，这里选择不进行字段转换。图2 字段映射5. 单击“下一步”配置任务参数，一般情况下全部保持默认即可。该步骤用户可以配置如下可选功能：作业失败重试：如果作业执行失败，可选择是否自动重试，这里保持默认值“不重试”。作业分组：选择作业所属的分组，默认分组为“DEFAULT”。在CDM“作业管理”界面，支持作业分组显示、按组批量启动作业、按分组导出作业等操作。是否定时执行：如果需要配置作业定时自动执行，请参见配置定时任务。这里保持默认值“否”。抽取并发数：设置同时执行的抽取任务数。这里保持默认值“1”。是否写入脏数据：如果需要将作业执行过程中处理失败的数据、或者被清洗过滤掉的数据写入OBS中，以便后面查看，可通过该参数配置，写入脏数据前需要先配置好OBS连接。这里保持默认值“否”即可，不记录脏数据。作业运行完是否删除：这里保持默认值“不删除”。6. 单击“保存并运行”，CDM立即开始执行作业。说明：如果运行作业失败，日志提示如下错误：SQL语句无法执行。ERROR: value too long for type character varying(7) Where: COPY dws_city, line 1, column name: "广州市"。原因：DWS表的字符字段长度不够。这是因为MySQL和华为云DWS存储中文时编码不一样，所需的长度也不一样，一个中文字符在UTF-8编码下可能要占3个字节。解决方法：在3新建作业时选择自动创表，高级属性参数“扩大字符字段长度”选择“是”，再重新执行作业。这样CDM在DWS中自动创表时，会将字符类型的字段长度设置为原表的3倍。查看作业运行结果操作场景作业完成后，可以查看作业执行结果及最近90天内的历史信息，包括写入行数、读取行数、写入字节、写入文件数和日志等信息。操作步骤1. 在集群管理界面，找到步骤1：创建集群章节创建的集群“cdm-aff1”。2. 单击该CDM集群后的“作业管理”，进入作业管理界面。3. 找到步骤3：创建并执行作业章节创建的作业“mysql_dws”，查看该作业的执行状态。说明：作业状态有New，Pending，Booting，Running，Failed，Succeeded。其中“Pending”表示正在等待系统调度该作业，“Booting”表示正在分析待迁移的数据。4. 单击作业后面的“历史记录”，可查看作业的写入行数、读取行数、写入字节或写入文件数。图1 查看历史记录5. 在历史记录界面，再单击“日志”可查看作业执行的日志信息。也可以在作业列表界面，选择“更多 > 日志”来查看该作业最近的一次日志。图2 查看作业日志原文链接：https://bbs.huaweicloud.com/blogs/237368【推荐阅读】【最新活动汇总】DWS活动火热进行中，互动好礼送不停（持续更新中）  HOT  【博文汇总】GaussDB(DWS)博文汇总1，欢迎大家交流探讨~（持续更新中）【维护宝典汇总】GaussDB(DWS)维护宝典汇总贴1，欢迎大家交流探讨（持续更新中）【项目实践汇总】GaussDB(DWS)项目实践汇总贴，欢迎大家交流探讨（持续更新中）【DevRun直播汇总】GaussDB(DWS)黑科技直播汇总，欢迎大家交流学习（持续更新中）【培训视频汇总】GaussDB(DWS) 培训视频汇总,欢迎大家交流学习（持续更新中）扫码关注我哦，我在这里↓↓↓

1.GaussDB AZ内单点故障RTO（Recovery Time Objective,RTO)恢复时间目标，指在故障或灾难发生之后业务恢复时间，主要指的是所能容忍的应用停止服务的最长时间，也就是从灾难发生到业务系统恢复服务功能所需要的最短时间周期；GaussDB(DWS) AZ内的单实例和单节点故障情况下，RTO=0，是通过单点故障自恢复和SQL语句出错自动重试实现的。1）单点故障自恢复GaussDB(DWS)高可用架构采用主备从架构，之前已经有很多博文对该架构进行了详细的介绍，这里简单进行普及：集群正常情况下，主机和备机之间通过日志复制和数据页复制强同步，主机和从备之间只保持连接，不同步数据，当备机发生故障时，主机自动感知，主机与从备开始进行日志和数据页的强同步；如果是主机发生故障，通过集群管理感知，并仲裁备生主，新主与从备进行日志和数据页的强同步；因此，同环内发生单点故障的情况下，仍然时刻保证了数据的2个副本强同步，不会影响服务的可用性；2）CN Retry功能GaussDB(DWS)支持在SQL语句执行出错时的自动重试功能（下文简称CN Retry）。对于来自gsql客户端、JDBC、ODBC驱动的SQL语句，在SQL语句执行失败时，CN端能够自动识别语句执行过程中的报错，并重新下发任务进行自动重试。CN Retry功能是默认开启的，由GUC参数max_query_retry_times进行控制，支持范围是0-20，默认为6，代表可语句出错时会自动重试6次，0代表关闭该功能，GaussDB(DWS)绝大部分错误类型都支持CN Retry功能，比如主机单点故障，业务断连的情况。GaussDB(DWS) 主要是通过以上2个特性来保证单点故障业务不中断，当某个DN主机故障时，通过集群管理和高可用的单点故障自恢复，自动备机升主，此时客户业务虽然实际产生短暂的断连，通过CN Retry功能对业务在后台进行重新下发执行，客户除了感知到短暂业务缓慢，不会影响业务执行。2.GaussDB(DWS)单点故障实测我们通过以下步骤对该功能进行简单测试：1）准备压测程序模拟用户业务，探测程序方便观察业务情况；压测程序可以任意选定，模拟一定的业务压力即可。探测程序，大概如下，观测较方便：dbname=rep_hangport=28308for((i=1;i<=10000000;i++))doecho "########## current times: $i ##########"echo `date`gsql -p $port $dbname -c "insert into test_row select nextval('seq_test_001'),now() returning *;"done启动业务后的压力情况：top - 21:53:56 up 63 days, 19:11,  2 users,  load average: 47.09, 23.51, 9.65Tasks: 1258 total,   2 running, 754 sleeping,   0 stopped,   0 zombie%Cpu(s): 37.6 us,  9.3 sy,  0.0 ni, 50.6 id,  1.8 wa,  0.0 hi,  0.8 si,  0.0 stKiB Mem : 40132032+total, 36850240 free, 19214592 used, 34525548+buff/cacheKiB Swap:  4194240 total,  4194240 free,        0 used. 28847993+avail Mem   PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                                                                                                                              54439 mpp651    20   0   82.6g   4.3g   1.9g S  1914  1.1 212:44.01 gaussdb                                                                                                                              54427 mpp651    20   0   78.3g   4.4g   1.9g S  1540  1.1 200:15.33 gaussdb                                                                                                                              54382 mpp651    20   0   56.5g   1.8g   1.0g S 371.1  0.5 686:57.20 gaussdb                                                                                                                              54404 mpp651    20   0   54.4g   1.6g   1.2g S 172.4  0.4  89:12.34 gaussdb                                                                                                                              54421 mpp651    20   0   55.0g   1.6g   1.2g S 167.1  0.4  93:04.60 gaussdb 2）对单个主机节点注入网络故障ifconfig enp131s0 down3) 观察探测程序########## current times: 150 ##########Sun Jan 10 22:43:01 CST 2021  id   |           time1            -------+---------------------------- 95026 | 2021-01-10 22:43:01.052801(1 row)INSERT 0 1########## current times: 151 ##########Sun Jan 10 22:43:01 CST 2021  id   |           time1            -------+---------------------------- 95028 | 2021-01-10 22:43:01.081416(1 row)INSERT 0 1########## current times: 152 ##########Sun Jan 10 22:43:01 CST 2021  id   |           time1            -------+---------------------------- 95031 | 2021-01-10 22:44:05.251098(1 row)INSERT 0 1########## current times: 153 ##########Sun Jan 10 22:43:32 CST 2021  id   |           time1            -------+---------------------------- 95032 | 2021-01-10 22:44:05.288718(1 row)可以观测到，业务未发生断连，短暂的卡住了一分钟后继续快速执行。 卡住的时间主要和当时集群的业务压力，以及作业类型，和正在执行的语句执行到了什么阶段相关，这里业务压力比较大。结论：GaussDB(DWS) AZ内的单实例和单节点故障情况下，业务不中断。原文链接：https://bbs.huaweicloud.com/blogs/236561【推荐阅读】【最新活动汇总】DWS活动火热进行中，互动好礼送不停（持续更新中）  HOT  【博文汇总】GaussDB(DWS)博文汇总1，欢迎大家交流探讨~（持续更新中）【维护宝典汇总】GaussDB(DWS)维护宝典汇总贴1，欢迎大家交流探讨（持续更新中）【项目实践汇总】GaussDB(DWS)项目实践汇总贴，欢迎大家交流探讨（持续更新中）【DevRun直播汇总】GaussDB(DWS)黑科技直播汇总，欢迎大家交流学习（持续更新中）【培训视频汇总】GaussDB(DWS) 培训视频汇总,欢迎大家交流学习（持续更新中）扫码关注我哦，我在这里↓↓↓

【摘要】 本文介绍了集群管理组件CM启停集群的原理、流程和关键日志，CM_CTL模块通过启动、停止命令删除或生成启停文件，CM_AGENT模块通过循环检查启停文件是否存在以及其他启动条件执行实例的拉起或停止操作。CM启停集群功能介绍一 CM_CTL模块cm_ctl是GaussDB(DWS)提供的用来控制集群服务的工具。启动集群和停止集群是cm_ctl的重要功能，其功能的实现主要通过启停文件实现：集群启停文件 cluster_manual_start实例启停文件 instance_manual_start_X(X是实例编号，例如instance_manual_start_6001)       当启动集群、节点、实例时，会删除启停文件，当停止集群、节点、实例时，会生成启停文件。通过cm_ctl生成的启停文件中有三行信息，每行为一个数字，第一个字段保留，第二、三个字段分别记录了停止模式和停止等级。启停文件位于$GAUSSHOME/bin下。其中，GAUSSHOME为环境变量。行数字段取值范围说明1保留字段0-2停止模式0:smart发送SIGTERM信号1: fast发送SIGINT信号2: immediate发送SIGKILL信号3停止等级0单实例停止，对应实例级启停文件1单节点停止，对应集群级启停文件2集群级停止，对应集群级启停文件 cm_agent组件不区分停止单节点和停止集群，因此启停文件均为集群级；停止等级仅用于内部识别，不影响实际的停止流程；停止cm_server进程与具体停止模式无关，均发送SIGKILL信号；如果启停文件内容为空，则根据名称判断启停文件级别，并执行默认的停止流程，默认的停止模式为smart;目前不支持通过cm_ctl停止单个cm_server进程，可通过手动生成实例级启停文件的方式控制；以smart方式停止节点或集群时，DN环的停止顺序为先停止备DN，再停止主DN； cm_ctl启停命令：启动集群cm_ctl start启动节点cm_ctl start –n nodeid启动实例cm_ctl start –n nodeid –D datapath停止集群cm_ctl stop停止节点cm_ctl stop –n nodeid停止实例cm_ctl stop –n nodeid –D datapath         以下图中实例6001为例，其启动命令为cm_ctl start –n 1 –D /home/mpp/data/dnP1     具体的启动停止操作将交由cm_agent执行。二、CM_AGENT模块cm_agent是GaussDB(DWS)提供的部署在集群各主机上用来启停和监控各数据库实例进程的集群管理组件，拉起和停止本主机上部署的实例进程是cm_agent的一个重要功能。该功能由常驻的启停线程来完成，根据检测到的启动、停止条件去相应地启动、停止集群，下面对cm_agent的启停流程进行介绍：1. CM Agent启停流程cm_agent的停止实例进程流程如图1所示：                                                             图1cm_agent启动实例进程的流程如图2所示：                                                             图2CM Agent整体的启停流程大致如图1和图2所示，对于不同类型的实例，其启停流程上会有一些差别，下面对不同实例启停的差别进行描述：（1）CM Server: 只有在检查到启停文件存在时才会杀死cm_server进程，而在磁盘、网卡有故障时并不会杀死cm_server进程。（2）CN：对于已经被剔除的CN，不会再对其启动。（3）DN：拉起DN时进行build进程的检查       a. build进程pid>0并且running(正在进行build)       b. build进程pid>0并且not running(即build失败)，重新进行build       c. build进程pid<0，重新进行build       d.build进程pid=0, 且DN进程不存在，(build已经完成)拉起DN 2. 关键日志举例日志类型关键字段举例启动日志GTM磁盘或网卡故障disk damged/ nic downstop the gtm instance 1001 due to disk damged or nic downGTM进程不存在但满足启动条件GTM START systemgtm(/home/mpp/data/gtm) is not running,now start, try 0 ! !GTM START system(command:…)CN磁盘故障、网卡故障或CN被剔除disk fault/ nic fault/ droppedkill CN because disk fault or nic fault or be droppedCN无法重启Do not start cnDo not start cn because cn on current node has been manually stopped.CN进程不存在但满足启动条件CN START systemcoordinate(/home/mpp/data/cn) is not running, now start, try 0 times!CN START system(command:…)DN启停文件存在manually stoppedDatanode 6001 is manually stopped. Do not perform start check.cm_server因端口或磁盘原因无法重启would not be startedCM Server 1 would not be started due to port conflict. cm_server启停文件存在无法重启Do not start cm serverDo not start cm server because cm server on current instance has been manually stopped.拉起cm_serverCM_SERVER START systemCM_SERVER START system(command:…).停止日志检测到集群启停文件cluster manual start fileFound the cluster manual start file, set the shutdown flag.所有实例正常停止all the instancesall the instances have stopped!仍存在实例进程Stopping checkall the instances原文链接：https://bbs.huaweicloud.com/blogs/233442【推荐阅读】【最新活动汇总】DWS活动火热进行中，互动好礼送不停（持续更新中）  HOT  【博文汇总】GaussDB(DWS)博文汇总1，欢迎大家交流探讨~（持续更新中）【维护宝典汇总】GaussDB(DWS)维护宝典汇总贴1，欢迎大家交流探讨（持续更新中）【项目实践汇总】GaussDB(DWS)项目实践汇总贴，欢迎大家交流探讨（持续更新中）【DevRun直播汇总】GaussDB(DWS)黑科技直播汇总，欢迎大家交流学习（持续更新中）【培训视频汇总】GaussDB(DWS) 培训视频汇总,欢迎大家交流学习（持续更新中）扫码关注我哦，我在这里↓↓↓

【摘要】 对数据进行压缩能够有效地减少磁盘IO、网络IO以及数据存储成本，但对数据的压缩和解压操作也会消耗额外的CPU资源、影响数据的访问与存储性能。所以需要根据业务需求在压缩率与解压缩速率之间进行权衡，来选择一个较优的压缩算法。简介对数据进行压缩能够有效地减少磁盘IO、网络IO以及数据存储成本，但对数据的压缩和解压操作也会消耗额外的CPU资源、影响数据的访问与存储性能。所以需要根据业务需求在压缩率与解压缩速率之间进行权衡，来选择一个较优的压缩算法。Gaussdb的行列存引擎在对数据进行压缩处理过程中，会根据数据特征自适应选择较优的压缩算法。行存压缩对于行存压缩表，以页为单位进行压缩处理。给行存表开启压缩：create table row_tbl (att1 type1, att2 type2) with ( orientation = row, compression = yes);1. Delta 差分压缩又称差分编码/增量编码，只存储数据间的差异diff，适用于数据改变很小的场景。对于要压缩的每一页，差分压缩采用以下步骤：    1. 对于每一列，确定最大值MaxVal和最小值MinVal，其中MinVal将用作差分的基准。同时由MaxVal和MinVal可以确定存储diff所需的最小字节数bytes。     2. 列中的值将会被原值与MinVal的差值diff替换，且需确保diff非负，diff的字节数小于bytes。2. Prefix 前缀压缩     前缀压缩首先会检查同一列内的数据，得到同一列内所有数据的共同前缀preFixStr并保存到元信息结构体中。列中每个数据只保存除了前缀外的部分，前缀指向唯一一个共同的前缀preFixStr。3. Dict 字典压缩    字典压缩首先会检查同一列内的重复值，如果某一值出现的次数达到要求则将其加入字典。列中的值将会直接指向字典中与其重复的值。列存压缩    对于Gaussdb中的列存压缩表，相对于行存以页为单元进行压缩，列存以CU为单元具有天然的压缩优势，并且以列为单位扫描能进一步减小磁盘IO提高查询速度。指定的压缩等级越高，则数据的压缩率越高。create table col_tbl (att1 type1, att2 type2) with ( orientation = column, compression = high);    列存压缩除了支持差分压缩以及字典压缩外，还支持RLE压缩、zlib压缩与lz4。1. RLE 压缩又称游程编码(Run-Length Encoding)，当数据存在大量连续的相同值时，会采用RLE压缩把重复的数据存储为一个数据值和计数。2. lz4 与 zlibzlib 压缩能使数据有更高的压缩率，但压缩/解压缩速度很慢，当压缩等级为high时可能采用；lz4 压缩在压缩/解压缩速度方面表现很好，压缩率低于zlib, 当压缩等级为middle时可能采用；两者的对比测试：压缩算法压缩率压缩速度解压速度zlib 2.74390 MB/s400 MB/slz42.101740 MB/s4530 MB/s友商的压缩实现1. GreenPulm2. SQL serverSql server的页压缩同样支持前缀压缩与字典压缩：前缀压缩（支持前缀的不完全匹配）：字典压缩（支持整页的字典）：3. leveldbLeveldb中以块为压缩单位，使用google开源的数据压缩库Snappy进行压缩。4. OracleOracle支持字典压缩，以及ZLIB、LZ0等压缩算法。5. TeradataTeradata 支持字典压缩以及ZLIB。原文链接：https://bbs.huaweicloud.com/blogs/233430【推荐阅读】【最新活动汇总】DWS活动火热进行中，互动好礼送不停（持续更新中）  HOT  【博文汇总】GaussDB(DWS)博文汇总1，欢迎大家交流探讨~（持续更新中）【维护宝典汇总】GaussDB(DWS)维护宝典汇总贴1，欢迎大家交流探讨（持续更新中）【项目实践汇总】GaussDB(DWS)项目实践汇总贴，欢迎大家交流探讨（持续更新中）【DevRun直播汇总】GaussDB(DWS)黑科技直播汇总，欢迎大家交流学习（持续更新中）【培训视频汇总】GaussDB(DWS) 培训视频汇总,欢迎大家交流学习（持续更新中）扫码关注我哦，我在这里↓↓↓

【摘要】 GaussDB(DWS) 数据库加密是DWS服务与KMS（密钥管理服务）服务的无缝对接，DWS服务通过KMS对GaussDB(DWS)进行密钥管理，起到了保护DWS数据库的作用。GuassDB(DWS) 为集群启用数据库加密，保护静态数据。当为集群启用加密时，该集群机器快照的数据都会得到加密。加密是集群一项可选且不可变的设置，要从未加密的集群更改为加密集群，必须从现有集群导出数据，然后在已启用数据库加密的新集群中重新导入这些数据，数据库加密是GaussDB（DWS）写入数据时对数据进行加密，而在用户查询数据时，DWS将数据自动进行解密后再将结果返回给用户。一、GaussDB(DWS) 服务控制台数据库加密页面：1、进入GaussDB(DWS) 服务 “购买数据仓库集群” 页面。2、在上图的页面中找到“高级配置”，并点击“自定义”。  3、打开加密数据库按钮，并选择填入密钥。4、如果没有可用的密钥，在点击“创建密钥”。5、在创建密钥的页面中填入别名和描述，点击“确定”按钮，密钥创建完成。6、创建完成后，选择使用得到的密钥去创建DWS集群。二、KMS服务加密GaussDB(DWS) 数据库     当选择KMS（密钥管理服务）对GaussDB(DWS) 进行密钥管理时，加密密钥层次结构有三层。按层次结构顺序排列，这些密钥为主密钥（CMK）、集群加密密钥 (CEK)、数据库加密密钥 (DEK)。主密钥用于给CEK加密，保存在KMS中。CEK用于加密DEK，CEK明文保存在GaussDB(DWS) 集群内存中，密文保存在GaussDB(DWS) 服务中。DEK用于加密数据库中的数据，DEK明文保存在GaussDB(DWS) 集群内存中，密文保存在GaussDB(DWS) 服务中。密钥使用流程如下：用户选择主密钥。GaussDB(DWS) 随机生成CEK和DEK明文。KMS使用用户所选的主密钥加密CEK明文并将加密后的CEK密文导入到GaussDB(DWS) 服务中。GaussDB(DWS) 使用CEK明文加密DEK明文并将加密后的DEK密文保存到GaussDB(DWS) 服务中。GaussDB(DWS) 将DEK明文传递到集群中并加载到集群内存中。当该集群重启时，集群会自动通过API向GaussDB(DWS) 请求DEK明文，GaussDB(DWS) 将CEK、DEK密文加载到集群内存中，再调用KMS使用主密钥CMK来解密CEK，并加载到集群内存中，最后用CEK明文解密DEK，并加载到集群内存中，返回给集群。三、加密密钥轮转    加密密钥轮转是指更新保存在GaussDB(DWS) 服务的密文。在GaussDB(DWS) 中，您可以轮转已加密集群的加密密钥CEK。密钥轮转流程如下：GaussDB(DWS) 集群启动密钥轮转。GaussDB(DWS) 根据集群的主密钥来解密保存在GaussDB(DWS) 服务中的CEK密文，获取CEK明文。用获取到的CEK明文解密保存在GaussDB(DWS) 服务中的DEK密文，获取DEK明文。GaussDB(DWS) 重新生成新的CEK明文。GaussDB(DWS) 用新的CEK明文加密DEK并将DEK密文保存在GaussDB(DWS) 服务中。用主密钥加密新的CEK明文并将CEK密文保存在GaussDB(DWS) 服务中。     根据业务需求和数据类型计划多久轮转一次加密密钥。为了提高数据的安全性，建议用户定期执行轮转密钥以避免密钥被破解的风险。一旦密钥可能已泄露，需要及时轮转密钥。原文链接：https://bbs.huaweicloud.com/blogs/233111【推荐阅读】【最新活动汇总】DWS活动火热进行中，互动好礼送不停（持续更新中）  HOT  【博文汇总】GaussDB(DWS)博文汇总1，欢迎大家交流探讨~（持续更新中）【维护宝典汇总】GaussDB(DWS)维护宝典汇总贴1，欢迎大家交流探讨（持续更新中）【项目实践汇总】GaussDB(DWS)项目实践汇总贴，欢迎大家交流探讨（持续更新中）【DevRun直播汇总】GaussDB(DWS)黑科技直播汇总，欢迎大家交流学习（持续更新中）【培训视频汇总】GaussDB(DWS) 培训视频汇总,欢迎大家交流学习（持续更新中）扫码关注我哦，我在这里↓↓↓

【摘要】 本帖简单介绍GaussDB(DWS)的锁等待场景。一般数据库事务管理中所指的锁是指表级锁，GaussDB(DWS)中支持的锁模式有8种，按排他级别分别为1-8。每种锁模式都有与之相冲突的锁模式，由锁冲突表定义相关的信息，锁冲突表如下：编号名称用途冲突关系1AccessShareLockSELECT 82RowShareLockSELECT FOR UPDATE/FOR SHARE 7 | 83RowExclusiveLockINSERT/UPDATE/DELETE 5 | 6 | 7 | 84ShareUpdateExclusiveLockVACUUM 4 | 5 | 6 | 7 | 85ShareLockCREATE INDEX 3 | 4 | 6 | 7 | 86ShareRowExclusiveLockROW SELECT...FOR UPDATE 3 | 4 | 5 |  6 | 7 | 87ExclusiveLockBLOCK ROW SHARE/SELECT...FOR UPDATE 2 | 3 | 4 | 5 |  6 | 7 | 88AccessExclusiveLockDROP CLASS/VACUUM FULL 1 | 2 | 3 | 4 | 5 |  6 | 7 | 8当两个事务的锁产生冲突时，未拿到锁的线程会等锁，等锁时间超过系统设置参数lockwait_timeout（默认20分钟）并且达到cn retry的次数（max_query_retry_times，默认6），就会出现报错。报错信息会将持锁语句打印出来，例如：postgres=# select * from t1;ERROR:  Lock wait timeout: thread 140722372077312 on node coordinator1 waiting for AccessShareLock on relation 16430 of database 14699 after 2000.158 msLINE 1: select * from t1;                       ^DETAIL:  blocked by hold lock thread 140722329605888, statement <truncate t1;>, hold lockmode AccessExclusiveLock.上述查询报错的原因是因为等锁超时，持锁语句为truncate t1。接下来简单介绍下快速找到持锁语句的几种方法，首先构造锁等待场景：第一步：在第一个session中执行:begin;truncate table t1;第二步：在第二个session中执行select语句，执行卡主：select * from t1;接下来介绍两种常用的快速找到持锁语句的方法：方法一：通过pg_locks查找1. 打开一个新的session，找到该语句对应的pid，可参考GaussDB(DWS)查看后台活跃SQL和执行状态，waiting为t表示语句正在等待执行。postgres=# select * from pgxc_stat_activity where query like 'select * from t1%';    coorname   | datid | datname  |       pid       | usesysid | usename | application_name | client_addr | client_hostname | client_port |         backend_start         |          xact_start          |          query_start          |         state_change          | waiting | enqueue | state  | resource_pool | query_id |       query       |                                                              connection_info                                                               --------------+-------+----------+-----------------+----------+---------+------------------+-------------+-----------------+-------------+-------------------------------+------------------------------+-------------------------------+-------------------------------+---------+---------+--------+---------------+----------+-------------------+-------------------------------------------------------------------------------------------------------------------------------------------  coordinator1 | 14699 | postgres | 140722372077312 |       10 | lkp     | gsql             |             |                 |          -1 | 2020-12-30 21:26:41.044308+08 | 2020-12-30 21:26:44.72377+08 | 2020-12-30 21:26:44.723725+08 | 2020-12-30 21:26:44.723727+08 | t       |         | active | default_pool  |        0 | select * from t1; | {"driver_name":"libpq","driver_version":"(GaussDB 8.0.0 build 7ced6a83) compiled at 2020-12-18 17:38:55 commit 7768 last mr 13325 debug"}(1 row)2. 根据该语句的pid查看该节点（coordinator1 ）的等待视图：postgres=# execute direct on(coordinator1) 'select * from pgxc_thread_wait_status where tid = 140722372077312';   node_name   | db_name  | thread_name | query_id |       tid       | lwtid  | ptid | tlevel | smpid | wait_status  | wait_event  --------------+----------+-------------+----------+-----------------+--------+------+--------+-------+--------------+------------  coordinator1 | postgres | gsql        |        0 | 140722372077312 | 214228 |      |      0 |     0 | acquire lock | relation(1 row)3. 根据该表在pg_class上的oid查看pg_locks：postgres=# select oid,relname from pg_class where relname = 't1';   oid  | relname  -------+---------  16430 | t1(1 row)postgres=#  postgres=# select * from pg_locks where relation = 16430;  locktype | database | relation | page | tuple | virtualxid | transactionid | classid | objid | objsubid | virtualtransaction |       pid       |        mode         | granted | fastpath  ----------+----------+----------+------+-------+------------+---------------+---------+-------+----------+--------------------+-----------------+---------------------+---------+----------  relation |    14699 |    16430 |      |       |            |               |         |       |          | 12/214             | 140722372077312 | AccessShareLock     | f       | f  relation |    14699 |    16430 |      |       |            |               |         |       |          | 11/1109            | 140722329605888 | AccessExclusiveLock | t       | f(2 rows)4. pg_locks中granted为t表示持锁语句，pid为持锁语句在该节点上的query对应的pid，可在pgxc_stat_activity中查看持锁语句：postgres=# select * from pgxc_stat_activity where pid = 140722329605888;    coorname   | datid | datname  |       pid       | usesysid | usename | application_name | client_addr | client_hostname | client_port |         backend_start         |          xact_start           |         query_start          |         state_change          | waiting | enqueue |        state        | resource_pool | query_id |       query        |                                                              connection_info                                                               --------------+-------+----------+-----------------+----------+---------+------------------+-------------+-----------------+-------------+-------------------------------+-------------------------------+------------------------------+-------------------------------+---------+---------+---------------------+---------------+----------+--------------------+-------------------------------------------------------------------------------------------------------------------------------------------  coordinator1 | 14699 | postgres | 140722329605888 |       10 | lkp     | gsql             |             |                 |          -1 | 2020-12-30 21:39:34.030827+08 | 2020-12-30 21:39:37.251805+08 | 2020-12-30 21:39:52.15638+08 | 2020-12-30 21:39:52.175311+08 | f       |         | idle in transaction | default_pool  |        0 | truncate table t1; | {"driver_name":"libpq","driver_version":"(GaussDB 8.0.0 build 7ced6a83) compiled at 2020-12-18 17:38:55 commit 7768 last mr 13325 debug"}(1 row)可以看到，持锁语句为truncate语句，该语句的状态为idle in transaction状态，表示事务等待提交。方法二：缩短锁等待报错时间前面介绍过，锁等待时间与lockwait_timeout和max_query_retry_times有关，可以调小这两个参数，根据报错提示快速找到持锁语句：set lockwait_timeout = 5;set max_query_retry_times = 0;select * from t1;解决方法：1. 业务上避免锁冲突的并发场景；2. 通过pg_terminate_backend函数去对应的节点上杀掉持锁语句原文链接：https://bbs.huaweicloud.com/blogs/233114【推荐阅读】【最新活动汇总】DWS活动火热进行中，互动好礼送不停（持续更新中）  HOT  【博文汇总】GaussDB(DWS)博文汇总1，欢迎大家交流探讨~（持续更新中）【维护宝典汇总】GaussDB(DWS)维护宝典汇总贴1，欢迎大家交流探讨（持续更新中）【项目实践汇总】GaussDB(DWS)项目实践汇总贴，欢迎大家交流探讨（持续更新中）【DevRun直播汇总】GaussDB(DWS)黑科技直播汇总，欢迎大家交流学习（持续更新中）【培训视频汇总】GaussDB(DWS) 培训视频汇总,欢迎大家交流学习（持续更新中）扫码关注我哦，我在这里↓↓↓

information_schema下的视图在数据库中对象较多时返回结果很慢，可以通过以下sql快速查询到一张或几张表的列信息：select /*+ nestloop(a c)*/ c.column_name, c.data_type, c.ordinal_position, pgd.description, pp.partkey, c.is_nullable, c.column_default, c.character_maximum_length, c.numeric_precision, c.numeric_scale, c.datetime_precision, c.interval_type, c.udt_namefrom information_schema.columns as c left join pg_namespace sp on sp.nspname = c.table_schema left join pg_class cla on cla.relname = c.table_name and cla.relnamespace = sp.oid left join pg_catalog.pg_partition pp on (pp.parentid = cla.oid and pp.parttype = 'r') left join pg_catalog.pg_description pgd on (pgd.objoid=cla.oid and pgd.objsubid = c.ordinal_position)where c.table_name in ('t1') and c.table_schema = 'public';使用时可以将table_name和table_schema替换成需要查询的模式名和表名。查询结果如下： column_name | data_type | ordinal_position |  description  | partkey | is_nullable | column_default | character_maximum_length | numeric_precision | numeric_scale | datetime_precision | interval_type | udt_name  -------------+-----------+------------------+---------------+---------+-------------+----------------+--------------------------+-------------------+---------------+--------------------+---------------+----------  b           | integer   |                2 | second column |         | YES         |                |                          |                32 |             0 |                    |               | int4  a           | integer   |                1 | first column  |         | YES         |                |                          |                32 |             0 |                    |               | int4(2 rows)原文链接：https://bbs.huaweicloud.com/blogs/233115【推荐阅读】【最新活动汇总】DWS活动火热进行中，互动好礼送不停（持续更新中）  HOT  【博文汇总】GaussDB(DWS)博文汇总1，欢迎大家交流探讨~（持续更新中）【维护宝典汇总】GaussDB(DWS)维护宝典汇总贴1，欢迎大家交流探讨（持续更新中）【项目实践汇总】GaussDB(DWS)项目实践汇总贴，欢迎大家交流探讨（持续更新中）【DevRun直播汇总】GaussDB(DWS)黑科技直播汇总，欢迎大家交流学习（持续更新中）【培训视频汇总】GaussDB(DWS) 培训视频汇总,欢迎大家交流学习（持续更新中）扫码关注我哦，我在这里↓↓↓

【摘要】 本帖简单介绍了审计日志的功能和查看审计日志的方法。数据库安全对数据库系统来说至关重要。GaussDB(DWS)将用户对数据库的所有操作写入审计日志。数据库安全管理员可以利用这些日志信息，重现导致数据库现状的一系列事件，找出非法操作的用户、时间和内容等。设置数据库审计可参考产品文档中设置数据库审计日志章节。建议用户在使用时合理配置审计项，对于一些数据敏感的业务和场景，强烈建议打开对表的DDL和DML审计。说明：本帖中涉及的数据和用户信息均为测试环境信息。1. 审计日志保存和转储目前，常用的审计日志保存方式为记录到表中和记录到OS文件中两种方式。但是表是数据库对象，如果采用记录到表中的方式，容易出现用户非法操作审计表的情况，审计记录的准确性难以保证，因此，从数据库安全角度出发，GaussDB(DWS)采用记录到OS文件的方式来保存审计结果，保证了审计结果的可靠性。由于审计日志会占用一定磁盘空间，为了防止本地文件过大，GaussDB(DWS)支持审计日志转储，具体方法可参考转储数据库审计日志章节。审计日志有两种保存策略，由参数audit_resource_policy控制：● on表示采用空间优先策略，最多存储audit_space_limit大小的日志。● off表示采用时间优先策略，最少存储audit_file_remain_time长度时间的日志。2. 审计日志查看首先要确保当前审计总开关audit_enabled和对应的审计项开关均已开启（表的DML操作审计由audit_dml_state控制，默认关闭，如需查看表上的dml操作，需提前打开该开关，同时，建议审计日志保留策略audit_resource_policy设置为on）。只有拥有AUDITADMIN属性的用户才可以查看审计记录，审计日志需通过数据库接口pg_query_audit和pgxc_query_audit查看。pg_query_audit可以查看当前CN的审计日志，pgxc_query_audit可以查看所有CN的审计日志，使用时一般用pgxc_query_audit接口查看审计。二者函数原型为：pg_query_audit(timestamptz startime,timestamptz endtime, audit_log)pgxc_query_audit(timestamptz startime,timestamptz endtime)其中，startime和endtime表示查看审计记录的开始时间和结束时间，满足审计条件的记录为startime ≤ 审计记录时间 < endtime；audit_log表示所查看的审计日志信息所在的物理文件路径，当不指定audit_log时，默认查看连接当前实例的审计日志信息。函数返回的字段如下：用户可以根据type类型或object_name对审计结果进行过滤，根据需要查看。常见的审计操作类型为：unknownlogin_successlogin_faileduser_logoutsystem_startsystem_stopsystem_recoversystem_switchlock_userunlock_usergrant_rolerevoke_roleuser_violationddl_databaseddl_directoryddl_tablespaceddl_schemaddl_userddl_tableddl_indexddl_viewddl_triggerddl_functionddl_resourcepoolddl_workloadddl_serverforhadoopddl_datasourceddl_nodegroupddl_rowlevelsecurityddl_synonymddl_typeddl_textsearchdml_actiondml_action_selectinternal_eventfunction_execcopy_tocopy_fromset_parameter3. 审计日志使用示例示例1：用户被锁，报错：FATAL:  The account has been locked，如何查看用户被锁的原因：postgres=# select * from pgxc_query_audit('20201230 18:00:00',current_timestamp) where type = 'login_failed';           time          |     type     | result | username | database |     client_conninfo      | object_name |                          detail_info                          |  node_name   |            thread_id            | local_port | remote_port  ------------------------+--------------+--------+----------+----------+--------------------------+-------------+---------------------------------------------------------------+--------------+---------------------------------+------------+-------------  2020-12-30 18:59:07+08 | login_failed | failed | doubi    | postgres | [unknown]@10.144.118.217 | postgres    | login db(postgres)failed,authentication for user(doubi)failed | coordinator1 | 140508124395264@662641147918967 | 32000      | 49687  2020-12-30 18:59:11+08 | login_failed | failed | doubi    | postgres | [unknown]@10.144.118.217 | postgres    | login db(postgres)failed,authentication for user(doubi)failed | coordinator1 | 140508124395264@662641151174956 | 32000      | 49689  2020-12-30 18:59:13+08 | login_failed | failed | doubi    | postgres | [unknown]@10.144.118.217 | postgres    | login db(postgres)failed,authentication for user(doubi)failed | coordinator1 | 140508124395264@662641153871953 | 32000      | 49691  2020-12-30 18:59:16+08 | login_failed | failed | doubi    | postgres | [unknown]@10.144.118.217 | postgres    | login db(postgres)failed,authentication for user(doubi)failed | coordinator1 | 140508124395264@662641156887905 | 32000      | 49692  2020-12-30 18:59:20+08 | login_failed | failed | doubi    | postgres | [unknown]@10.144.118.217 | postgres    | login db(postgres)failed,authentication for user(doubi)failed | coordinator1 | 140508124395264@662641160061866 | 32000      | 49696  2020-12-30 18:59:23+08 | login_failed | failed | doubi    | postgres | [unknown]@10.144.118.217 | postgres    | login db(postgres)failed,authentication for user(doubi)failed | coordinator1 | 140508124395264@662641163187840 | 32000      | 49698  2020-12-30 18:59:25+08 | login_failed | failed | doubi    | postgres | [unknown]@10.144.118.217 | postgres    | login db(postgres)failed,authentication for user(doubi)failed | coordinator1 | 140508124395264@662641165671562 | 32000      | 49699  2020-12-30 18:59:28+08 | login_failed | failed | doubi    | postgres | [unknown]@10.144.118.217 | postgres    | login db(postgres)failed,authentication for user(doubi)failed | coordinator1 | 140508124395264@662641168137151 | 32000      | 49700  2020-12-30 18:59:31+08 | login_failed | failed | doubi    | postgres | [unknown]@10.144.118.217 | postgres    | login db(postgres)failed,authentication for user(doubi)failed | coordinator1 | 140508124395264@662641171124971 | 32000      | 49702  2020-12-30 18:59:33+08 | login_failed | failed | doubi    | postgres | [unknown]@10.144.118.217 | postgres    | login db(postgres)failed,authentication for user(doubi)failed | coordinator1 | 140508124395264@662641173650325 | 32000      | 49858  2020-12-30 18:59:36+08 | login_failed | failed | doubi    | postgres | [unknown]@10.144.118.217 | postgres    | login db(postgres)failed,the account(doubi)has been locked    | coordinator1 | 140508124395264@662641176080044 | 32000      | 51402(11 rows)根据审计结果可以看到，IP为10.144.118.217的用户连续输入密码错误超过10次，导致doubi账户被锁。示例2：某张表数据为空，通过审计日志查看在该表上的操作（前提：已打开表的DML和DDL审计）：postgres=# select * from pgxc_query_audit('20201230 19:15:00',current_timestamp) where object_name = 't1';           time          |    type    | result | username | database |      client_conninfo       | object_name |                   detail_info                   |  node_name   |            thread_id            | local_port | remote_port  ------------------------+------------+--------+----------+----------+----------------------------+-------------+-------------------------------------------------+--------------+---------------------------------+------------+-------------  2020-12-30 19:16:40+08 | dml_action | ok     | dbadmin  | postgres | Data Studio@10.144.118.217 | t1          | insert into t1 values (1,2)                     | coordinator1 | 140722584413952@662642200541821 | 32000      | 50437  2020-12-30 19:17:01+08 | dml_action | ok     | dbadmin  | postgres | Data Studio@10.144.118.217 | t1          | insert into t1 values (generate_series(1,10),2) | coordinator1 | 140722584413952@662642200541821 | 32000      | 50437  2020-12-30 19:17:11+08 | dml_action | ok     | dbadmin  | postgres | Data Studio@10.144.118.217 | t1          | delete from t1                                  | coordinator1 | 140722584413952@662642200541821 | 32000      | 50437(3 rows)通过审计日志可以看到，19:17:01 时刻，IP为10.144.118.217的用户通过Data Studio客户端向t1表中插入了数据，19:17:11 时该用户又对该表执行了delete操作导致数据为空。原文链接：https://bbs.huaweicloud.com/blogs/233104【推荐阅读】【最新活动汇总】DWS活动火热进行中，互动好礼送不停（持续更新中）  HOT  【博文汇总】GaussDB(DWS)博文汇总1，欢迎大家交流探讨~（持续更新中）【维护宝典汇总】GaussDB(DWS)维护宝典汇总贴1，欢迎大家交流探讨（持续更新中）【项目实践汇总】GaussDB(DWS)项目实践汇总贴，欢迎大家交流探讨（持续更新中）【DevRun直播汇总】GaussDB(DWS)黑科技直播汇总，欢迎大家交流学习（持续更新中）【培训视频汇总】GaussDB(DWS) 培训视频汇总,欢迎大家交流学习（持续更新中）扫码关注我哦，我在这里↓↓↓

【摘要】 数据仓库拉链表模型在GaussDB(DWS)中的实践。在数据仓库的数据模型设计过程中，经常会遇到这样的需求： 数据量比较大;表中的部分字段会被update,如用户的地址，产品的描述信息，订单的状态等等;需要查看某一个时间点或者时间段的历史快照信息，比如，查看某一个订单在历史某一个时间点的状态，比如，查看某一个订单在过去某一段时间内，更新过几次等等;通过拉链表模型，可以满足反应数据的历史状态的需求。GaussDB(DWS)中如何使用拉链表，我们来以一个实例来进行一下对比：首先我们来看下普通表的业务模型：普通的订单表只有创建时间和状态create table orders(order_id int,create_date date,status text);2018-07-01, 创建三个订单insert into orders values(1,'2018-07-01','created');insert into orders values(2,'2018-07-01','created');insert into orders values(3,'2018-07-01','created');select * from orders order by order_id;order_id |     create_date     | status----------+---------------------+---------         1 | 2018-07-01 00:00:00 | created        2 | 2018-07-01 00:00:00 | created        3 | 2018-07-01 00:00:00 | created(3 rows)2018-07-02, 更新两个老订单，插入两个新订单update orders set status='paid' where order_id=1;update orders set status='paid' where order_id=2;insert into orders values(4,'2018-07-02','created');insert into orders values(5,'2018-07-02','created');select * from orders order by order_id;order_id |     create_date     | status----------+---------------------+---------         1 | 2018-07-01 00:00:00 | paid        2 | 2018-07-01 00:00:00 | paid        3 | 2018-07-01 00:00:00 | created        4 | 2018-07-02 00:00:00 | created        5 | 2018-07-02 00:00:00 | created(5 rows)2018-07-03, 更新四个老订单，插入一个新订单update orders set status='delivered' where order_id=1;update orders set status='delivered' where order_id=2;update orders set status='paid' where order_id=3;update orders set status='paid' where order_id=4;insert into orders values(6,'2018-07-02','created');select * from orders order by order_id;order_id |     create_date     |  status----------+---------------------+-----------         1 | 2018-07-01 00:00:00 | delivered        2 | 2018-07-01 00:00:00 | delivered        3 | 2018-07-01 00:00:00 | paid        4 | 2018-07-02 00:00:00 | paid        5 | 2018-07-02 00:00:00 | created        6 | 2018-07-02 00:00:00 | created(6 rows)综上，普通的订单表，单个订单只能查询到当前状态，无法追踪历史版本的状态信息。拉链表的模型，每个订单每次状态变化都会记录一条数据，还有状态的起始时间，可以回溯历史数据create table orders_history(order_id int,create_date date,status text,status_begin date,status_end date);同样的订单变化过程，我们来看一下拉链表的变化2018-07-01, 创建三个订单insert into orders_history values(1,'2018-07-01','created','2018-07-01','9999-12-31');insert into orders_history values(2,'2018-07-01','created','2018-07-01','9999-12-31');insert into orders_history values(3,'2018-07-01','created','2018-07-01','9999-12-31');select * from orders_history order by order_id;order_id |     create_date     | status  |    status_begin     |     status_end----------+---------------------+---------+---------------------+---------------------         1 | 2018-07-01 00:00:00 | created | 2018-07-01 00:00:00 | 9999-12-31 00:00:00         2 | 2018-07-01 00:00:00 | created | 2018-07-01 00:00:00 | 9999-12-31 00:00:00         3 | 2018-07-01 00:00:00 | created | 2018-07-01 00:00:00 | 9999-12-31 00:00:00(3 rows)2018-07-02, 插入两个老订单的新状态，同步修改两个老订单旧状态的有效期，插入两个新订单insert into orders_history values(1,'2018-07-01','paid','2018-07-02','9999-12-31');insert into orders_history values(2,'2018-07-01','paid','2018-07-02','9999-12-31');update orders_history set status_end='2018-07-02' where order_id=1 and status_begin<'2018-07-02' and status_end='9999-12-31';update orders_history set status_end='2018-07-02' where order_id=2 and status_begin<'2018-07-02' and status_end='9999-12-31';insert into orders_history values(4,'2018-07-02','created','2018-07-02','9999-12-31');insert into orders_history values(5,'2018-07-02','created','2018-07-02','9999-12-31');select * from orders_history order by order_id;order_id |     create_date     | status  |    status_begin     |     status_end----------+---------------------+---------+---------------------+---------------------         1 | 2018-07-01 00:00:00 | paid    | 2018-07-02 00:00:00 | 9999-12-31 00:00:00         1 | 2018-07-01 00:00:00 | created | 2018-07-01 00:00:00 | 2018-07-02 00:00:00         2 | 2018-07-01 00:00:00 | paid    | 2018-07-02 00:00:00 | 9999-12-31 00:00:00         2 | 2018-07-01 00:00:00 | created | 2018-07-01 00:00:00 | 2018-07-02 00:00:00         3 | 2018-07-01 00:00:00 | created | 2018-07-01 00:00:00 | 9999-12-31 00:00:00         4 | 2018-07-02 00:00:00 | created | 2018-07-02 00:00:00 | 9999-12-31 00:00:00         5 | 2018-07-02 00:00:00 | created | 2018-07-02 00:00:00 | 9999-12-31 00:00:00(7 rows)2018-07-03, 插入四个老订单的新状态，同步修改四个老订单旧状态的有效期，插入一个新订单insert into orders_history values(1,'2018-07-01','delivered','2018-07-03','9999-12-31');insert into orders_history values(2,'2018-07-01','delivered','2018-07-03','9999-12-31');insert into orders_history values(3,'2018-07-01','paid','2018-07-03','9999-12-31');insert into orders_history values(4,'2018-07-02','paid','2018-07-03','9999-12-31');update orders_history set status_end='2018-07-03' where order_id=1 and status_begin<'2018-07-03' and status_end='9999-12-31';update orders_history set status_end='2018-07-03' where order_id=2 and status_begin<'2018-07-03' and status_end='9999-12-31';update orders_history set status_end='2018-07-03' where order_id=3 and status_begin<'2018-07-03' and status_end='9999-12-31';update orders_history set status_end='2018-07-03' where order_id=4 and status_begin<'2018-07-03' and status_end='9999-12-31';insert into orders_history values(6,'2018-07-02','created','2018-07-03','9999-12-31');select * from orders_history order by order_id;order_id |     create_date     |  status   |    status_begin     |     status_end----------+---------------------+-----------+---------------------+---------------------         1 | 2018-07-01 00:00:00 | delivered | 2018-07-03 00:00:00 | 9999-12-31 00:00:00         1 | 2018-07-01 00:00:00 | created   | 2018-07-01 00:00:00 | 2018-07-02 00:00:00         1 | 2018-07-01 00:00:00 | paid      | 2018-07-02 00:00:00 | 2018-07-03 00:00:00         2 | 2018-07-01 00:00:00 | paid      | 2018-07-02 00:00:00 | 2018-07-03 00:00:00         2 | 2018-07-01 00:00:00 | delivered | 2018-07-03 00:00:00 | 9999-12-31 00:00:00         2 | 2018-07-01 00:00:00 | created   | 2018-07-01 00:00:00 | 2018-07-02 00:00:00         3 | 2018-07-01 00:00:00 | paid      | 2018-07-03 00:00:00 | 9999-12-31 00:00:00         3 | 2018-07-01 00:00:00 | created   | 2018-07-01 00:00:00 | 2018-07-03 00:00:00         4 | 2018-07-02 00:00:00 | paid      | 2018-07-03 00:00:00 | 9999-12-31 00:00:00         4 | 2018-07-02 00:00:00 | created   | 2018-07-02 00:00:00 | 2018-07-03 00:00:00         5 | 2018-07-02 00:00:00 | created   | 2018-07-02 00:00:00 | 9999-12-31 00:00:00         6 | 2018-07-02 00:00:00 | created   | 2018-07-03 00:00:00 | 9999-12-31 00:00:00(12 rows)如果需要查看以前版本的数据7月1号的数据版本select * from orders_history where status_begin <= '2018-07-01' and status_end >= '2018-07-01' order by order_id;order_id |     create_date     | status  |    status_begin     |     status_end----------+---------------------+---------+---------------------+---------------------         1 | 2018-07-01 00:00:00 | created | 2018-07-01 00:00:00 | 2018-07-02 00:00:00         2 | 2018-07-01 00:00:00 | created | 2018-07-01 00:00:00 | 2018-07-02 00:00:00         3 | 2018-07-01 00:00:00 | created | 2018-07-01 00:00:00 | 2018-07-03 00:00:00(3 rows)7月2号的数据版本select * from orders_history where status_begin <= '2018-07-02' and status_end >= '2018-07-02' order by order_id;order_id |     create_date     | status  |    status_begin     |     status_end----------+---------------------+---------+---------------------+---------------------         1 | 2018-07-01 00:00:00 | created | 2018-07-01 00:00:00 | 2018-07-02 00:00:00         1 | 2018-07-01 00:00:00 | paid    | 2018-07-02 00:00:00 | 2018-07-03 00:00:00         2 | 2018-07-01 00:00:00 | created | 2018-07-01 00:00:00 | 2018-07-02 00:00:00         2 | 2018-07-01 00:00:00 | paid    | 2018-07-02 00:00:00 | 2018-07-03 00:00:00         3 | 2018-07-01 00:00:00 | created | 2018-07-01 00:00:00 | 2018-07-03 00:00:00         4 | 2018-07-02 00:00:00 | created | 2018-07-02 00:00:00 | 2018-07-03 00:00:00         5 | 2018-07-02 00:00:00 | created | 2018-07-02 00:00:00 | 9999-12-31 00:00:00(7 rows)如上只是举一个例子，具体的拉链表更新业务比上面复杂的多，一般是由三种表组成，订单表、增量表、历史表，拉链表更新过程会从订单表抽取要更新的数据，导入到增量表，更新处理后导入到历史表，即可实现数仓拉链表更新业务。原文链接：https://bbs.huaweicloud.com/blogs/233079【推荐阅读】【最新活动汇总】DWS活动火热进行中，互动好礼送不停（持续更新中）  HOT  【博文汇总】GaussDB(DWS)博文汇总1，欢迎大家交流探讨~（持续更新中）【维护宝典汇总】GaussDB(DWS)维护宝典汇总贴1，欢迎大家交流探讨（持续更新中）【项目实践汇总】GaussDB(DWS)项目实践汇总贴，欢迎大家交流探讨（持续更新中）【DevRun直播汇总】GaussDB(DWS)黑科技直播汇总，欢迎大家交流学习（持续更新中）【培训视频汇总】GaussDB(DWS) 培训视频汇总,欢迎大家交流学习（持续更新中）扫码关注我哦，我在这里↓↓↓

【摘要】 本帖通过简单示例介绍UDF进程异常的排查和处理方式。背景：使用UDF出现报错，后台查看集群UDF进程发现进程异常。本帖通过简单示例介绍UDF进程异常的排查和处理方式，示例中用到的数据、路径配置、主机名等信息均为测试环境信息。首先，通过以下命令查看集群UDF进程状态：cm_ctl query -CvF结果如下：[  Fenced UDF State   ]node         state--------------------1  ASG003    Down2  host17967 Down3  host17995 Down发现UDF进程处于异常状态，查看cm_agent日志（在$GAUSSLOG/cm/cm_agent目录下）发现如下内容：StartAndStop LOG: process (secbox) is not running, path is xxxx, have_found is 0该日志说明secbox.conf的配置存在问题，进入$GAUSSHOME/secbox路径下，查看secbox.conf配置：# read/write src_path [dst_path][mount_path]            read    /dev[mount_path]            read    /sys[mount_path]            read    /bin[mount_path]            read    /sbin[mount_path]            read    /usr/bin[mount_path]            read    /lib[mount_path]            read    /lib64[mount_path]            read    /usr/lib[mount_path]            read    /usr/lib64[mount_path]            read    /usr/local[mount_path]            read    /usr/share[mount_path]            read    /etc[mount_path]            read    /var[mount_path]            read    /var/log[mount_path]            read    /var/lkp发现该配置中/var/lkp路径不存在，导致UDF进程拉起失败，注释或删除此条配置，几秒后观察本节点UDF进程恢复为Normal状态：[  Fenced UDF State   ]node         state--------------------1  ASG003    Down2  host17967 Normal3  host17995 Down说明配置已生效，按照同样的方法对其他节点修改secbox.conf文件，问题解决。[  Fenced UDF State   ]node         state--------------------1  ASG003    Normal2  host17967 Normal3  host17995 Normal原文链接：https://bbs.huaweicloud.com/blogs/233075【推荐阅读】【最新活动汇总】DWS活动火热进行中，互动好礼送不停（持续更新中）  HOT  【博文汇总】GaussDB(DWS)博文汇总1，欢迎大家交流探讨~（持续更新中）【维护宝典汇总】GaussDB(DWS)维护宝典汇总贴1，欢迎大家交流探讨（持续更新中）【项目实践汇总】GaussDB(DWS)项目实践汇总贴，欢迎大家交流探讨（持续更新中）【DevRun直播汇总】GaussDB(DWS)黑科技直播汇总，欢迎大家交流学习（持续更新中）【培训视频汇总】GaussDB(DWS) 培训视频汇总,欢迎大家交流学习（持续更新中）扫码关注我哦，我在这里↓↓↓

【问题现象】     集群管理-->集群名下钻-->集群信息报异常DWS.0005 访问资源不存在或状态异常【分析过程】     发现在查询规格的接口报错，所以查看对应的表中是否有相应规格记录-- 1.查询实例表select specId,status from rds_instance t where t.clusterId='323578df-602a-492f-a1fe-0cb401bc0bb9';-- 2. 查看规格实例关系表 入参为1的结果中specId值select cluster_spec_id from rds_cluster_instance_resspec t where instance_spec_id='f04f994c-81ae-4669-99dc-8392d6ad9c60';-- 3.查看集群规格表中是否有记录 入参为2结果中cluster_spec_id值select * from rds_cluster_spec  t  where id='ba6574f7-fcbf-3189-9d9a-0d2b011176ce';-- 4. 查看对应的region表中是否有记录  入参为3结果中 id值select * from rds_spec_region where cluster_spec_id='ba6574f7-fcbf-3189-9d9a-0d2b011176ce';如果没有则需要往表中添加对应规格的信息【解决方案】    下面以dws.ds2.4xlarge为例，具体参数根据实际情况进行调整：INSERT INTO rds_cluster_spec (id,code,topo,mount,ori_node,min_node,max_node,classify,scenario,serialno,version) VALUES ('7da53a4a-15fa-3212-8427-a6e2ba0304f2','dws.ds2.4xlarge','ONE_AZ_ONE_PRIMARY_ONE_STANDBY_ONE_DUMMY','DN_BIND_VOLUME',3,3,32,'dws','test',24,'v1.0');INSERT INTO rds_cluster_instance_resspec (id,cluster_spec_id,instance_spec_id,instance_type,instance_capacity,instance_tag) VALUES ('bf4f5fc3-7f37-30f9-b7b0-f85298a97238','7da53a4a-15fa-3212-8427-a6e2ba0304f2','4d73661d-ce48-4b2d-8571-c70a2a81afad','UNDEFINED','5029',NULL);insert into rds_spec_region (id,cluster_spec_id,region,`zone`,status)(uuid(),'bf4f5fc3-7f37-30f9-b7b0-f85298a97238','cn-east-3','cn-east-3a','enable');