【摘要】 DWS集群的基本功能：创建，备份，恢复，删除。一、 GaussDB(DWS) 服务控制台页面：1. 登录华为云官网 : https://www.huaweicloud.com/。2. 在产品->EI企业智能中找到数据仓库服务。3. 点击进入控制台按钮，进入GaussDB(DWS) 服务控制台页面。 二、 GaussDB(DWS) 集群基本功能1. 集群创建：在创建集群动作开始前，首先您需要根据数据量、业务负载以及性能需求，选择能够支撑业务应用的节点数量。刚开始使用GaussDB(DWS) 服务时，您也可以先创建一个规格较小的集群，今后随着数据量和业务负载的变化，再自由调整集群规模和节点规格，自由扩展而不中断业务。您可以点击右上角“购买数据仓库集群”进行集群创建，创建集群需要确定的参数有：①需要部署的Region（区域）以及AZ（可用区） 区  域：选择在哪个区域创建集群。 可用区：可用区表示在公有云的一个数据中心地域下，电力、网络互相隔离的物理区域。可用区之间内网互通，不同可用区之间物理隔离。②集群节点信息，包括集群类型、CPU架构、节点规格、节点数量    创建集群至少需要3个节点。③集群登录信息，包括集群名称、管理员用户、管理员密码、数据库端口   集群创建成功后，客户端连接集群数据库时将使用该管理员用户及其密码。④集群VPC信息，包括VPC选择，子网选择，安全组选择，公网访问      虚拟私有云（VPC）为集群提供网络拓扑，不同集群互相隔离并控制访问。可以选择已有的VPC，也可以自行创建。安全组可以选择自动创建。公网访问选项可方便您从互联网环境使用客户端连接GaussDB(DWS) 数据库。⑤所属的企业项目⑥高级配置，包括配置快照以及数据库加密功能。     点击“立即购买”进入规格确认页面，确认后，单击“提交”开始创建GaussDB(DWS) 集群。集群的创建一般需要十几分钟的等待时间。2. 集群备份功能快照是GaussDB(DWS) 集群在某一时间点的完整备份，记录了这一时刻指定集群的所有配置数据和业务数据，用于还原创建快照时的集群数据。快照依照创建方式分为两种：手动快照和自动快照。手动快照：手动快照可以按照您的需求随时自行创建，其采用全量备份，所以备份时间会比较长。创建的手动快照会一直保存在快照列表中，由您进行恢复操作或者选择删除。手动创建的快照详细信息自动快照：当您创建的集群启用了自动快照功能，GaussDB(DWS) 将按照默认8小时或您设定的时间周期来创建快照。自动快照拥有默认3天，可设置1~10天的保留期，且不支持手动删除，如您不需要创建自动快照，关闭自动快照功能即可。自动创建的快照名称中带有时间戳。自动快照的详细信息3. 集群恢复功能您可以使用手动创建的快照或自动快照来进行集群恢复。恢复过程中使用的集群是新创建的，可以创建原有规格的集群，也可以跨规格恢复。在快照管理页面，选择您想要恢复的快照，点击“恢复”，即可进入规格选择页面，该页面中支持跨规格恢复的规格会被自动显示，您可以按照需求选择新的规格创建集群。4. 集群删除功能当您不需要使用数据仓库服务时，可以删除您创建的集群。原文链接：https://bbs.huaweicloud.com/blogs/198712【推荐阅读】【最新活动汇总】DWS活动火热进行中，互动好礼送不停（持续更新中）  HOT  【博文汇总】GaussDB(DWS)博文汇总1，欢迎大家交流探讨~（持续更新中）【维护宝典汇总】GaussDB(DWS)维护宝典汇总贴1，欢迎大家交流探讨（持续更新中）【项目实践汇总】GaussDB(DWS)项目实践汇总贴，欢迎大家交流探讨（持续更新中）【DevRun直播汇总】GaussDB(DWS)黑科技直播汇总，欢迎大家交流学习（持续更新中）【培训视频汇总】GaussDB(DWS) 培训视频汇总,欢迎大家交流学习（持续更新中）扫码关注我哦，我在这里↓↓↓

GaussDB(DWS) 是 share nothing 架构，使用分布式事务解决数据的一致性问题。当前 GaussDB(DWS) 使用的是两阶段提交（2PC）协议。2PC 协议有两类节点：协调者和参与者。一个事务会涉及一个协调者和多个参与者。当协调者或者参与者出现故障或者节点间出现网络问题时，2PC 事务就面临着失败或者残留的问题。在 GaussDB(DWS) 中，发起事务的 CN 节点就是协调者，其他参与此事务的 CN 或者 DN 节点就是参与者。1.1. 2PC 事务失败/残留的原因1.1.1. 2PC 事务的正常提交流程首先看一下 2PC 事务的正常提交流程，一般情况下，对于一个事务，至少要经过一个 CN（执行 CN )、一个 DN 和 GTM。如果涉及本地，先在本地进行 PREPARE；在远端其他节点进行 PREPARE。如果任一节点失败，则报告错误并进行 ABORT 操作；到这步时，所有涉及的节点都已经 PREPARE 了，可以进行 COMMIT 了：首先通知 GTM 当前事务已经 PREPARED，并提供一个节点列表给GTM；先在本地 COMMIT PREPARED，然后在其他远端节点 COMMIT；返回并做提交动作的收尾工作1.1.2. 故障对于上述流程，在任意执行路径上出错，都可能导致整个分布式事务的状态无法达到终点，最终当前事务整体提交失败。如果事务不能完整结束，那么它所占有的资源就会一直无法释放1.1.3. 故障处理的总体原则当故障发生后，通过全局回滚或者是由 gs_clean 工具进行残留事务清理，以保证事务完整结束。1.1.4. 故障场景在事务运行过程中，或者 prepare 阶段，对于 CN、DN、GTM 实例本身或者网络出现故障，事务都要进行回滚，根据实际情况，执行 CN 没问题的话，CN 提交回滚操作；否则需要由 gs_clean 工具进行清理。在 commit prepared 阶段，CN 向其他 CN 和 DN 发送 commit prepared 命令，并收取返回信息，这时如果实例发生了故障，那么事务会残留，就需要等待 gs_clean 工具清理了。1.2. gs_clean上面的故障情况中，对于执行 CN 不能自动进行回滚的的场景，就需要 gs_clean 工具来协助进行清理了。1.2.1. gs_clean 是干什么的gs_clean 工具是用于清理 GaussDB(DWS) 集群中残留的两阶段事务的组件。1.2.2. 为什么需要 gs_clean由于 GaussDB(DWS) 集群使用多个工作节点一起来支持分布式事务，单个组件的故障会导致分布式事务（2PC）的全局状态产生异常。在某些情况下，异常的事务由于无法判断后续状态进而无法继续下去，这时就需要一个第三方的组件来判断事务状态并将事务圆满的结束。1.2.3. gs_clean 在哪里gs_clean 二进制文件跟随内核包一起部署在 $GAUSSHOME/bin 目录下。1.2.4. 谁来调用 gs_clean每个 CN 中有一个叫做 TwoPhaseCleanerMain 的辅助线程线程，所有的 gs_clean 调用都是由这个线程自动完成的。一般情况下，不需要人工调用 gs_clean。1.2.5. 什么时候调用 gs_clean在 CN 正常运行过程中，每隔 5mins 会调一次 gs_clean 命令，对集群中所有的数据库中的两阶段残留事务进行扫描和清理；如果是进程刚启动，或者上次 gs_clean 调用失败，则 60s 后会再次调用；sync 等待时，如果等待超时，会给这个线程发消息线程调用 gs_clean；如果已经有 gs_clean 进程启动，则不会再调用；1.2.6. gs_clean的结果与日志gs_clean 的所有信息都保存在自己的日志文件中，日志文件路径为：$GAUSSLOG/bin/gs_clean/1.2.7. gs_clean 的主要工作流程连接 CN，做一些前期的信息收集和准备工作：获取要清理的 database 列表连接 CN，设置为维护模式获取自己的 node name 和 所有的 node list扫描两阶段残留信息：去各个节点上执行视图 pg_prepared_xacts获取 prepared 的事务信息，把结果和事务状态记录在链表里遍历链表，查看是否有要进行恢复的 2PC 事务针对每个处于 prepared 阶段的事务，去其他所有节点上查找对应事务是否已经提交，把结果也更新到链表中收集了所有需要的信息后，针对每个 database 中的每一个事务，根据规则判断应该进行提交、回滚还是继续等待，如果需要提交或回滚，那么直接向所有相关节点发起 commit/rollback prepared 动作1.2.8. 残留事务的处理规则如果有一个节点处于 committed 状态，则标记为提交，并最终提交该事务;如果有一个节点处于 aborted 状态，则标记为回滚，并最终回滚该事务;如果所有节点都处于 prepared 状态，则可选择回滚或者提交（参数），默认是回滚；如果有节点连不上，则不提交也不回滚。1.2.9. 实际运行过程中的一些事情GUC 参数 gs_clean_timeout 可以用来控制 CN 调用 gs_clean 的周期间隔。默认为 5min。当 CN 上进行事务 sync 等待时，如果超过 transaction_sync_naptime 参数（默认5s），则会触发 gs_clean。CN 自动触发的 gs_clean 命令为： gs_clean -a -p PORT -v -r        1. -a：清理所有数据库        2. -p：CN 端口        3. -v：打印详细信息，包括数据库信息，残留事务信息等        4. -r：将处于 PREPARED 状态的事务进行回滚        5. 其他 gs_clean 参数可以参考 gs_clean --help原文链接：https://bbs.huaweicloud.com/blogs/201221【推荐阅读】【最新活动汇总】DWS活动火热进行中，互动好礼送不停（持续更新中）  HOT  【博文汇总】GaussDB(DWS)博文汇总1，欢迎大家交流探讨~（持续更新中）【维护宝典汇总】GaussDB(DWS)维护宝典汇总贴1，欢迎大家交流探讨（持续更新中）【项目实践汇总】GaussDB(DWS)项目实践汇总贴，欢迎大家交流探讨（持续更新中）【DevRun直播汇总】GaussDB(DWS)黑科技直播汇总，欢迎大家交流学习（持续更新中）【培训视频汇总】GaussDB(DWS) 培训视频汇总,欢迎大家交流学习（持续更新中）扫码关注我哦，我在这里↓↓↓

【摘要】 在大数据时代，数据的完整和可靠性成为一个数仓最核心的能力之一。对于企业、政府等用户，如果因为硬件故障导致的文件损坏，或是业务操作的误删，导致了数据损坏或丢失，那么损失将是不可估量的。Roach工具是GaussDB(DWS)推出的一款主力的备份恢复工具，包含物理与逻辑备份两种主要能力，本文着重于讲解Roach逻辑备份的实现原理。一、简介在大数据时代，数据的完整和可靠性成为一个数仓最核心的能力之一。GaussDB(DWS)以其出众的分布式计算和存储能力广受用户青睐的同时，也特别着眼于数据备份容灾领域的创新和打磨。数据的可靠性可以说是数仓的“命门”。对于企业、政府等用户，如果因为硬件故障导致的文件损坏，或是业务操作的误删，导致了数据损坏或丢失，那么损失将是不可估量的。GaussDB(DWS)提供的Roach工具，将以其稳定、快速、可靠的备份能力，通过备份恢复数据库或业务表，为客户准备一个可靠的“后悔药”，从而有效地挽回客户损失。二、Roach备份恢复基本框架         GaussDB(DWS)的Roach工具，同时提供物理备份和逻辑备份两种主要形态的备份。物理备份直接通过拷贝文件块，存储于备份介质之上，恢复时使用备份的文件块，重建集群中实例DN与CN的数据目录进行恢复。本文中我们主要着眼于逻辑备份，在当前的GaussDB(DWS)中，相比于物理备份，逻辑备份拥有更好的灵活性，其充分利用了GaussDB(DWS)强大的数据导入导出能力，不同于物理备份的文件整体拷贝，逻辑备份针对数据库的逻辑对象进行抽取和备份，粒度可以做到表级、schema级、database级，根据客户需要进行定制选择；在一个拥有成千上万表的客户数仓中，如果仅想要备份一张表，那么当前逻辑备份是更好的选择。在逻辑备份讲解之前，我们首先讲一下Roach工具的设计架构，这个框架是一切逻辑或者物理备份的实现基础——图1  Roach备份恢复工具框架示意图         GaussDB(DWS)提供的Roach是一个分布式的备份恢复工具，以一个Node1、2、3组成的集群为例，备份的总入口是python进程GaussRoach.py，它将在当前节点拉起一个roach master进程，在集群其他所有节点各拉起一个roach agent进程，是典型的master-slave框架，master进程与所有的agent进程分别建立TCP长连接，并封装报文与各个节点通信，下发备份等任务，在每个节点上，将分布式地为节点上的CN、DN等数据库对象进行备份。三、逻辑备份的原理         下面简述一下逻辑备份的执行过程1）  待备份表定义的导出和备份如果是库级的备份，将逐个schema地进行元数据导出；处理每一个schema时，又将逐个导出所有的表定义，因此，我们下图展示了Roach逻辑备份导出一个表DDL的过程。Roach Master节点接到备份指令后，向一个有CN的节点Roach Agent下发指令，该Agent进程再调用gs_dump，连CN进行表定义DDL的导出。图2  逻辑备份表元数据DDL导出备份示意图2）  创建外表Roach逻辑备份过程，本质是建立外表进行数据导出的过程，类似上一步的表定义导出，Roach Agent接受Master指令后，基于导出的表定义，连CN创建写外表，创建的外表使用gsmpp_server， server的option中，location为roach://{Roach Agent监听端口}，其中，Roach Agent监听端口为参数可配置，将接受该节点上所有DN实例的连接，Roach逻辑备份外表定义类似如下形式，该待备份表仅有一个int类型字段id，图中举例的Roach Agent监听端口为8080，可配置，导出格式为csv。  图3 Roach逻辑备份创建的外表3）  Roach工具与DN的建连及数据导出备份当前GaussDB(DWS)的集中主要数据导入导出外表包括GDS、HDFS、OBS、Roach等四种，Roach外表同其他几种外表类似，都通过FDW（Foreign Data Wrapper）完成，但注册了一系列属于Roach的FDW API接口实现，此外，Roach还实现了Open/Read/Write/Close/ErrorReport等五个主要的底层读写API，实现DN与Roach Agent之间的数据交互。图4 逻辑备份表数据备份流程示意图如图4所示，逻辑备份数据的流程可以用以下phase1 ~ phase5简单描述Phase1： 备份数据的命令被Master下发给所有Agent，连一个CN，连数据库创建外表导出server、创建导出外表，每个节点的Roach Agent同样会创建一个TblServer线程，监听Agent Port端口，等待DN连接；Phase2： 连一个CN执行insert into roachft select * from A；sql查询会被下发到所有DN，通过注册的Roach FDW API，DN调用回调函数，封装一个PGXCNode的消息，以自明instance身份，去尝试连接server url中的本节点Agent Port；Phase3： Roach Agent的TblServer每接收一个DN的连接，会分配一个数据通信的socket槽位，并fork一个子进程为该DN实例的备份服务；Agent会等待该节点上所有的DN都建立连接，创建lengthof（节点所有DN）个子进程，并行进行数据备份。Phase4： 每个备份子进程通过建立的连接，不断读取表数据，待该表所有切分的数据块读取完成，发送一个FINISH_BACKUP消息给Roach Agent，则停止数据传输，从DN读取的数据首先存入Agent子进程的buffer中。Phase5:     每个Agent进程内会创建一个BackupSender线程，负责消费存入buffer的表数据，与备份介质建立连接，流式进行数据的发送；Phase4、5在实际运行中是个异步并行的动作，并非等所有表数据都写入buffer后，才向备份介质发送。四、小结  关于Roach逻辑备份的原理大致就讲解完成了，逻辑备份能够有效地应对单表、schema级等较细粒度的备份，较为灵活和便利。逻辑备份的恢复的过程，与上述备份过程基本是个逆向过程，简而言之即表定义恢复，节点及DN元数据恢复，数据导入的过程，恢复的一大优势是，不会停集群或移动其他数据，对其他库或者表的业务几乎不影响。在后续的博文中，我们可以更详细地解读。原文链接：https://bbs.huaweicloud.com/blogs/198461【推荐阅读】【最新活动汇总】DWS活动火热进行中，互动好礼送不停（持续更新中）  HOT  【博文汇总】GaussDB(DWS)博文汇总1，欢迎大家交流探讨~（持续更新中）【维护宝典汇总】GaussDB(DWS)维护宝典汇总贴1，欢迎大家交流探讨（持续更新中）【项目实践汇总】GaussDB(DWS)项目实践汇总贴，欢迎大家交流探讨（持续更新中）【DevRun直播汇总】GaussDB(DWS)黑科技直播汇总，欢迎大家交流学习（持续更新中）【培训视频汇总】GaussDB(DWS) 培训视频汇总,欢迎大家交流学习（持续更新中）扫码关注我哦，我在这里↓↓↓

【摘要】 冗余会话清理现场通常使用Data Studio进行DWS数据库连接，很多人使用关闭后不关闭窗口，导致数据库连接仍然存在，后台大量堆积Data Studio查询作业，导致DWS集群查询无响应。可以参照以下超长会话清理方式进行操作。1.1 冗余会话清理现场通常使用Data Studio进行DWS数据库连接，很多人使用关闭后不关闭窗口，导致数据库连接仍然存在，后台大量堆积Data Studio查询作业，导致DWS集群查询无响应。可以参照以下超长会话清理方式进行操作。注意：该清理操作，需要在每个CN上都执行。-- 查询持续运行时间超过一天的会话SELECT * FROM PG_STAT_ACTIVITY   WHERE   useName <> 'Ruby' and state   <> 'idle' and current_timestamp -   query_start > interval '1 days';--杀掉会话SELECT   PG_TERMINATE_BACKEND(pid) FROM PG_STAT_ACTIVITY WHERE   useName <> 'Ruby' and state   <> 'idle' and current_timestamp -   query_start > interval '1 days'; Ø  实践建议：建议运维人员定时执行该操作，及时清理垃圾会话，避免不佳使用习惯对数据库造成影响。1.2 磁盘垃圾回收在对表做了大量更新和删除之后，会产生表的膨胀现象，导致全表扫描性能劣化非常严重。在现场发现，垃圾数据多了，会导致全表扫描IO量达到正常值200倍以上，并且select * from {tableName} limit 100; 这样的简单查询，也会受到影响。可以通过如下语句查询数据库内部表的脏页情况，如果发现脏页dirty_page_rate非常高，超过30，建议及时进行VACUUM FULL。SELECT * FROM   PGXC_GET_STAT_ALL_TABLESWHERE schemaName NOT IN('pg_toast', 'pg_catalog', 'information_schema', 'cstore','pmk')ORDER BY dirty_page_rate DESC;   注意：VACUUM FULL会导致当前表进入只读，所以需要选择合适时间执行。VACUUM FULL ANALYZE {tableName}; Ø  实践建议：建议定期对整库进行VACUUM，个别垃圾数据比较频繁的表，可以频率更加频繁一些。1.3  分布键调整当前很多使用场景中建表没有指定分布键，系统默认使用表中的第一列作为分布键，这不仅导致数据倾斜严重，极端情况下，数据可能全部只分布在一个DN中，严重影响查询效率。数据倾斜检查办法如下：SELECT * FROM PGXC_GET_TABLE_SKEWNESS ORDER   BY SKEWRATIO DESC;       PGXC_GET_TABLE_SKEWNESS视图字段信息如下：名称类型描述schemanamename表所在的模式名。tablenamename表名。totalsizenumeric表的总大小，单位Byte。avgsizenumeric(1000,0)表大小平均值(totalsize/DN个数，该值为平均分布的理想情况下，表在各DN占用空间大小)。maxrationumeric(4,3)单DN表大小最大值占比（表在各DN占用空间的最大值/totalsize）。minrationumeric(4,3)单DN表大小最小值占比（表在各DN占用空间的最小值/totalsize）。skewsizebigint表分布倾斜值（单DN表大小最大值 - 单DN表大小最小值）。skewrationumeric(4,3)表分布倾斜率（skewsize/totalsize）。skewstddevnumeric(1000,0)表分布标准方差（在表大小一定的情况下，该值越大表明表的整体分布情况越倾斜）。如果发现数据倾斜，或者在查询过程中，执行计划不合理，产生大量数据重分布，整改操作步骤如下： 1.  创建新表，重新指定分布键，导入数据到新表中 2.  修改原始表名称，并修改新表为正式表名称，然后删除原始旧表。 3.  对新表执行ANALYZE。Ø  实践建议：建议对数据库内部所有表进行倾斜检查，调整分布键。原文链接：https://bbs.huaweicloud.com/blogs/177222【推荐阅读】【最新活动汇总】DWS活动火热进行中，互动好礼送不停（持续更新中）  HOT  【博文汇总】GaussDB(DWS)博文汇总1，欢迎大家交流探讨~（持续更新中）【维护宝典汇总】GaussDB(DWS)维护宝典汇总贴1，欢迎大家交流探讨（持续更新中）【项目实践汇总】GaussDB(DWS)项目实践汇总贴，欢迎大家交流探讨（持续更新中）【DevRun直播汇总】GaussDB(DWS)黑科技直播汇总，欢迎大家交流学习（持续更新中）【培训视频汇总】GaussDB(DWS) 培训视频汇总,欢迎大家交流学习（持续更新中）扫码关注我哦，我在这里↓↓↓

【摘要】 为了保护集群数据的安全，GaussDB(DWS)支持对集群设置三权分立（系统管理员、安全管理员、审计管理员），使用不同类型的用户分别控制不同权限的模式。GaussDB(DWS)创建集群时默认用户是SYSADMIN属性的系统管理员，具备系统最高权限。在实际业务管理中，为了避免系统管理员拥有过度集中的权利带来高风险，可以设置三权分立，将系统管理员的权限分立给安全管理员和审计管理员。三权分立后，系统管理员将不再具有CREATEROLE属性（安全管理员）和AUDITADMIN属性（审计管理员）能力。即不再拥有创建角色和用户的权限，并不再拥有查看和维护数据库审计日志的权限。关于CREATEROLE属性和AUDITADMIN属性的更多信息请参考 CREATE ROLE。默认的用户权限对象名称系统管理员安全管理员审计管理员普通用户表空间对表空间有创建、修改、删除、访问、分配操作的权限。不具有对表空间进行创建、修改、删除、分配的权限，访问需要被赋权。表对所有表有所有的权限。仅对自己的表有所有的权限，对其他用户的表无权限。索引可以在所有的表上建立索引。仅可以在自己的表上建立索引。模式对所有模式有所有的权限。仅对自己的模式有所有的权限，对其他用户的模式无权限。函数对所有的函数有所有的权限。仅对自己的函数有所有的权限，对其他用户放在public这个公共模式下的函数有调用的权限，对其他用户放在其他模式下的函数无权限。自定义视图对所有的视图有所有的权限。仅对自己的视图有所有的权限，对其他用户的视图无权限。系统表和系统视图可以查看所有系统表和视图。只可以查看部分系统表和视图。详细请参见系统表和系统视图。三权分立的权限最小化设置将数据库安全提升一个档次。如何实现三权分立的设置，请看如下：1、在数据仓库服务界面创建集群后，单击集群名称，进入集群详情，在详情页签中点击“安全设置”。2、进入“安全设置”，呈现设置界面。3、打开“三权分立”开关，可进行设置安全管理员及审计管理员用户名及密码（默认系统管理员在创建集群时已设定）。4、设置完成后，对于审计配置建议进行设置，审计也是数据库运行过程的关键日志。   审计保留策略建议“时间优先”，最长可保留730天，再根据实际需要将越权访问、DML、DDL等分别设置，数据仓库服务还提供的审计日志转储OBS的功能，设置转储的OBS桶及路径，在转储周期内将生成审计日志文件，直接放在您的OBS桶中，方便查看。5、设置完后，点击应用，成功后即可连接数据库查看三权分立的效果。审计查询命令是数据库提供的sql函数pg_query_audit，其原型为：pg_query_audit(timestamptz startime,timestamptz endtime,audit_log)参数startime和endtime分别表示审计记录的开始时间和结束时间，audit_log表示所查看的审计日志信息所在的物理文件路径，当不指定audit_log时，默认查看连接当前实例的审计日志信息。通过sql函数pgxc_query_audit可以查询所有CN节点的审计日志，其原型为：pgxc_query_audit(timestamptz startime,timestamptz endtime)说明： startime和endtime的差值代表要查询的时间段，其有效值为从startime日期中的00:00:00开始到endtime日期中的23:59:59之间的任何值。请正确指定这两个参数，否则将查不到需要的审计信息。原文链接：https://bbs.huaweicloud.com/blogs/180975【推荐阅读】【最新活动汇总】DWS活动火热进行中，互动好礼送不停（持续更新中）  HOT  【博文汇总】GaussDB(DWS)博文汇总1，欢迎大家交流探讨~（持续更新中）【维护宝典汇总】GaussDB(DWS)维护宝典汇总贴1，欢迎大家交流探讨（持续更新中）【项目实践汇总】GaussDB(DWS)项目实践汇总贴，欢迎大家交流探讨（持续更新中）【DevRun直播汇总】GaussDB(DWS)黑科技直播汇总，欢迎大家交流学习（持续更新中）【培训视频汇总】GaussDB(DWS) 培训视频汇总,欢迎大家交流学习（持续更新中）扫码关注我哦，我在这里↓↓↓

GaussDB(DWS)中的时区分为后台集群时区和客户端时区。后台集群时区默认使用UTC时区，可以通过控制台的集群参数修改页面进行调整。通常情况下集群时区不需要进行修改，设置客户端时区可以对SQL执行产生影响。查询客户端时区和当前时间。 客户端时区为UTC时区，now()函数返回当前时间。建立如下数据表CREATE TABLE timezone_test (id int, t1 timestamp, t2 timestamptz) DISTRIBUTE BY HASH (id);其中timestamp，timestamptz是常用的时间类型。timestamp不保存时区，timestamptz保存时区。              向timezone_test表插入当前时间。         查询timezone_test表         t1 (timestamp类型)在保存数据时丢弃了时区信息，t2(timestamptz类型)保存了时区信息。         把客户端时区设置为东8区（UTC-8），再次查询timezone_test表。         t1的查询结果没有变化。而t2根据客户端时区做了调整，显示为东8区时间“2020-06-13 15:32:39.207232+08”。 t2保存的数据没有发现变化只是按东8区的方式显示出来。         继续插入当前时间到timezone_test表，并查询。         这时t1新插入的值是用的东8区时间。         客户端设置为UTC时区，再次查询。         客户端时区切换t1查询结果保持不变，t2根据客户端时区对查询结果进行转换。总结：      timestamp类型只受数据在插入时的时区影响，查询结果不受客户端时区影响。timestamptz类型在数据插入时记录了时区信息，查询时会根据客户端时区做转换，以客户端时区显示数据。原文链接：https://bbs.huaweicloud.com/blogs/175143【推荐阅读】【最新活动汇总】DWS活动火热进行中，互动好礼送不停（持续更新中）  HOT  【博文汇总】GaussDB(DWS)博文汇总1，欢迎大家交流探讨~（持续更新中）【维护宝典汇总】GaussDB(DWS)维护宝典汇总贴1，欢迎大家交流探讨（持续更新中）【项目实践汇总】GaussDB(DWS)项目实践汇总贴，欢迎大家交流探讨（持续更新中）【DevRun直播汇总】GaussDB(DWS)黑科技直播汇总，欢迎大家交流学习（持续更新中）【培训视频汇总】GaussDB(DWS) 培训视频汇总,欢迎大家交流学习（持续更新中）扫码关注我哦，我在这里↓↓↓

【摘要】 本文介绍了GaussDB(DWS)透明加密及基基本原理，特性介绍。1 特性介绍透明加密功能是GaussDB(DWS)的高级特性，是对存在硬盘上的用户数据加密存储。目前支持行存和列存文件的加密存储，支持到集群级别的透明加密配置。透明加密对客户是无感知的，仅需要创建DWS集群时配置透明加密。定义透明加密：数据在文件落盘时加密，对用户及上层使用SQL的应用不感知。价值保障用户数据安全。范围透明加密核心是算法和密钥，算法支持AES。密钥管理使用华为公有云KMS服务管理。2 应用场景数据库使用客户，对存储在GaussDB(DWS)中的业务数据有很高机密性要求。需要消减因更换磁盘磁盘流出或运维待非法通过直接读取磁盘文件而绕过数据库认证及审计及数据丢换的风险时，建议使用透明加密特性。需注意加解密有较小的性能开销，实际的影响依赖硬件CPU处理相应加密算法的效率。3系统影响系统容量影响无。加密模式选用CTR，CTR流加密可以保证明文和密文长度相等。不会导致加密后数据量大于不加密。性能影响使用透明加密对数据导入，以及读算子开销较大的SQL查询业务有较大。使用TPCDS测试模型评估的性能影响有如下参考值（不同硬件，不同测试模型）：AES: 性能下降小于4%业务影响无。透明加密对应用层业务不感知。可靠性影响因GaussDB(DWS)进程重启时，需要访问KMS，故KMS服务及网络可靠性会影响GaussDB(DWS)可靠性。需强力保证根密钥的管理，一旦密钥丢失，GaussDB(DWS)中的数据将不可解密。4相关特性依赖特性华为公有云KMS服务互斥特性无影响特性无5 原理5.1 概述站在管理面视角：❶ 租户管理员登录华为公有云后，在DWS Console上申请创建加密集群；❷ DWS Service接收到创建加密集群请求后，向KMS Service申请主密钥和集群密钥，并生成数据库密钥下发给GaussDB内核；❸ GaussDB在集群初始化时加载密钥，并加密保存；站在数据面视角：❶ SQL Client下发SQL请求到GaussDB的CN，CN解析SQL请求后下发给DN；❷ DN处理SQL请求触发写IO操作时，若向磁盘中写入数据，则内存数据加密写入磁盘；若从磁盘中读入数据，则磁盘数据解密后加载到内存；5.2 密钥管理5.2.1 KMS密钥管理当选择KMS（密钥管理服务）对DWS进行密钥管理时，加密密钥层次结构有三层。按层次结构顺序排列，这些密钥为主密钥（CMK）、集群加密密钥 (CEK)、数据库加密密钥 (DEK)。主密钥用于给CEK加密，保存在KMS中。CEK用于加密DEK，CEK明文保存在DWS集群内存中，密文保存在DWS服务中。DEK用于加密数据库中的数据，DEK明文保存在DWS集群内存中，密文保存在DWS服务中。密钥使用流程如下：1. 用户选择主密钥。2. DWS随机生成CEK和DEK明文。3. KMS使用用户所选的主密钥加密CEK明文并将加密后的CEK密文导入到DWS服务中。4. DWS使用CEK明文加密DEK明文并将加密后的DEK密文保存到DWS服务中。5. DWS将DEK明文传递到集群中并加载到集群内存中。当该集群重启时，集群会自动通过API向DWS请求DEK明文，DWS将CEK、DEK密文加载到集群内存中，再调用KMS使用主密钥CMK来解密CEK，并加载到集群内存中，最后用CEK明文解密DEK，并加载到集群内存中，返回给集群。加密密钥轮转加密密钥轮转是指更新保存在DWS服务的密文。在DWS中，您可以轮转已加密集群的加密密钥CEK。5.2.2 密钥轮转流程如下：DWS集群启动密钥轮转。DWS根据集群的主密钥来解密保存在DWS服务中的CEK密文，获取CEK明文。用获取到的CEK明文解密保存在DWS服务中的DEK密文，获取DEK明文。DWS重新生成新的CEK明文。DWS用新的CEK明文加密DEK并将DEK密文保存在DWS服务中。用主密钥加密新的CEK明文并将CEK密文保存在DWS服务中。您可以根据业务需求和数据类型计划多久轮转一次加密密钥。为了提高数据的安全性，建议用户定期执行轮转密钥以避免密钥被破解的风险。一旦您发现密钥可能已泄露，请及时轮转密钥。5.2.3 GaussDB内核密钥管理创建密钥：初次安装启动时，DWS Service接收到创建加密集群请求后，向KMS Service申请主密钥和集群密钥，并生成数据库密钥(DEK)下发给GaussDB内核。并分发到GaussDB各节点。该DEK一次生成，终身使用，不可变更，不可轮转。在快照（即备份）恢复时，同样需要使用此前的DEK。获取密钥：数据库CN、DN在启动时，会通过向一个url，传入AK/SK，及当前集群所在的区域（Region）信息，从管控面那里获取到DEK。在这里每一个集群的URL都不同（包含了当前集群的ClusterID）；同一租户的AK/SK相同；Region根据集群部署的区域（例如华北、华东）不同而可能不同。5.2.4 相关可靠性设计扩容，集群备份与恢复已实现密钥密文记录文件及相关配置文件的同步操作。DWS保存的DEK密文分布在所有管控节点及GAUSSDB内核各节点上有较高的可靠性。6 实施6.1 配置前提条件已有华为云租户帐号安装步骤1.       进入华为公有云购买数据仓库集群页面。2.       如下图高级配置选择自定义，打开加密数据库。3.       创建委托选择是。4.       点击立即购买，再点击提交即可。6.2 验证查看视图：pg_tde_info视图，用于查看tde功能是否开启，以及使用的哪种加密算法。列名字段含义is_encryptf/t是否加密集群g_tde_algoAES-CTR-128加密算法remainRemain保留字段 用例编号测试名称透明加密功能验证测试目的使用透明加密后的数据文件是否可以分析，加密是否成功预置条件1，  Gauss   200透明加密集群和非透明加密集群已安装，状态正常。2，  pg_filedump（需要glibc-2.14或以上版本才能运行）测试步骤1、    查询pg_tde_info视图非透明加密集群：透明加密集群：2、    分别在透明加密集群和非透明加密集群创建如下表，并插入数据。source   ${BIGDATA_HOME}/mppdb/.mppdbgs_profilegsql   -d postgres -p 25308 –arcreate   table test(c1 int, c2 int, date timestamp) distribute by hash(c1);insert   into test select generate_series(1,10000), generate_series(1,10000), sysdate;3、 在透明加密和非透明加密集群CN上执行checkpoint或者重启集群保证数据下盘。gsql -d postgres -p 25308 –archeckpoint;4、 到非透明加密集群和透明加密集群一个DN上查询test表对应的数据文件并传到pg_filedump服务器。postgres=# select   pg_relation_filepath('test'); pg_relation_filepath---------------------- base/14548/16464\qscp /srv/BigData/mppdb/data1/master1/base/14548/16464   10.185.180.55:/opt/filedump/pg_filedump-masterpostgres=# select   pg_relation_filepath('test'); pg_relation_filepath---------------------- base/14548/18019\qscp   /srv/BigData/mppdb/data1/master1/base/14548/18019   10.185.180.55:/opt/filedump/pg_filedump-master5、使用pg_filedump分析数据文件非透明加密集群数据文件分析，-D后面要加上表的字段数据类型./pg_filedump -D int,int,timestamp   18019 | more每一个COPY对应的行为真实数据。透明加密集群数据文件分析./pg_filedump -D int,int,timestamp   16464 | more数据文件解析报错：Error: Item contents   extend beyond block.测试脚本预期结果1，步骤1查询pg_tde_info非透明加密集群is_encrypt为f,透明加密集群is_encrypt为t，g_tde_algo字段为加密算法。2，步骤5非透明加密集群使用pg_filedump可以解析出数据，透明加密集群使用pg_filedump不能解析数据。实测结果备注使用透明加密对数据导入，以及读算子开销较大的SQL查询业务有较大。使用TPCDS测试模型评估的性能影响有如下参考值（不同硬件，不同测试模型）：  AES: 性能下降小于10% （无AES硬件加速）  SM4：单并发性能劣化48%，5并发劣化25%（有ARM硬件SM4加速）测试方签字测试审核员签字 原文链接：https://bbs.huaweicloud.com/blogs/176371【推荐阅读】【最新活动汇总】DWS活动火热进行中，互动好礼送不停（持续更新中）  HOT  【博文汇总】GaussDB(DWS)博文汇总1，欢迎大家交流探讨~（持续更新中）【维护宝典汇总】GaussDB(DWS)维护宝典汇总贴1，欢迎大家交流探讨（持续更新中）【项目实践汇总】GaussDB(DWS)项目实践汇总贴，欢迎大家交流探讨（持续更新中）【DevRun直播汇总】GaussDB(DWS)黑科技直播汇总，欢迎大家交流学习（持续更新中）【培训视频汇总】GaussDB(DWS) 培训视频汇总,欢迎大家交流学习（持续更新中）扫码关注我哦，我在这里↓↓↓

为什么要进行数据备份？在信息化社会，数据是每个企业最重要的资产，每个好的企业致力于为用户提供稳定可靠的服务，各种客观（自然灾害，网络故障，硬盘故障等）或者主观原因（人为损坏，人为误操作等）会造成数据丢失，影响企业业务，所以数据的备份及恢复显得尤为重要。保护好客户数据，灾难来临，客户数据不丢失，企业业务能够连续进行是数据灾备的目的。数据库灾备能力是评价数据库优劣的重要指标之一。Raoch工具介绍：GaussDB A通过Roach工具提供备份和灾难恢复功能。目前Roach支持的集群形态包括：主备从集群、一主多备集群、小型化集群（单节点部署）。支持物理备份和逻辑备份，并且支持DISK，NBU，OBS(DWS线上使用)，EISOO等备份介质。在备份恢复过程中，集群内每个节点都会运行gs_roach进程，并且会有一个节点以roach master的角色运行roach进程，其余所有节点会以roach agent的角色运行roach进程。roach master控制备份恢复的所有流程和操作，roach agent接收和处理来自于master的命令。应用场景之集群级备份：  集群级备份属于物理备份，GaussDB A根据用户需求提供全量备份和增量备份两种方式，并支持断点续做。集群级全量备份场景：python $GPHOME/script/GaussRoach.py-t <命令类型> 【例如：restore】--master-port <master端口号> 【roach主代理进程执行端口】--media-type <介质类型> 【备份集存放的介质类型，如DISK等】--media-destination <备份文件存放路径>【例如：/home/test/media】--metadata-destination <备份元数据存放路径>【例如：/home/test/meta】集群级增量备份场景：在全量备份基础上加--prior-backup-key参数：--prior-backup-key<指定基于的全量备份的key>【例如：如果该参数的值为20200505_162558，则表示该次备份为增量备份，且本次增量备份基于key为20200505_162558的全量备份进行】集群全量备份断点续做场景：考虑到集群级备份数据量大且备份时间较长，在备份过程中可能受到不可抗力导致备份中断，GaussDB A 提供了断点续做功能，只需要在备份命令添加—resume-backup参数即可。应用场景之集群级恢复：  集群级恢复命令如下：python $GPHOME/script/GaussRoach.py -t restore --master-port 7786 --media-type disk --media-destination /home/test/media --metadata-destination /home/test/meta --clean –backup-key XXXX_XXXX其中：--clean <表示恢复前清除数据库中的数据>--backup-key <参数值为带恢复的备份集的key>应用场景之表级备份：全量备份数据量较大，备份集占用存储空间较大，重复数据重复备份，造成存储空间的浪费。实际应用中，客户数据库中常用的表有限，需要经常的做全量备份，因此，为了节约存储资源，提升客户工作效率，GaussDB A提供了表级备份功能。其中，表级备份分为单表备份和多表备份。单表备份场景：python $GPHOME/script/GaussRoach.py -t backup --master-port <master端口> --media-destination <备份路径> --media-type disk --metadata-destination <元数据备份路径>--tablename <表名称>--agent-port<备份表时Roach与数据库内核之间建立外表所需端口>–dbname <表所在数据库名称>多表备份场景：python $GPHOME/script/GaussRoach.py -t backup --master-port <master端口> --media-destination <备份路径> --media-type disk --metadata-destination <元数据备份路径>--agent-port <agent端口>--table-list <待备份tablelist列表文件，例如：tablist.txt>--dbname <备份表所在数据库名称>--logical <--logical参数表示本次备份为逻辑备份>说明：--table-list的值为tablist.txt，其内容需要备份的表，每张表名一行，格式如下：schema01.tab01schema02.tab02schema01.tab03…应用场景之表级恢复：单表恢复：python $GPHOME/script/GaussRoach.py -t restore --clean --create --master-port 9898 --media-type DISK --media-destination /home/test/media --metadata-destination /home/test/meta --agent-port 7000 --dbname db1 –tablename tab1 --backup-key XXXX_XXXX其中：--create <表示创建表结构>--logging <参数值为true或false，true表示启用日志文件记录功能；false表示禁用日志文件记录功能>多表恢复：python $GPHOME/script/GaussRoach.py -t restore --clean --create --master-port 9898 --media-type DISK --media-destination /home/test/media --metadata-destination /home/test/meta --agent-port 7000 --dbname db1 –table-list tablist.txt --backup-key XXXX_XXXX --logical在执行备份恢复命令时，还提供了以下多种功能参数：--buffersize <缓存大小>--compression-type <压缩算法类型，值为1代表采用zlib压缩算法，值为 2代表采用lz4压缩算法>--compression-level <压缩级别，参数值为0-9，值为0表示快速压缩或无压缩，值为9表示慢速压缩或最大压缩>--filesplit-size <被拆分文件的大小>--log-filecount <日志文件的最大个数>--log-filesize <最大日志文件的大小>--logging-level <日志级别 FATAL ERROR WARNING INFO DEBUG DEBUG2>--parallel-process <roach可使用子进程个数>--retry-wait-time <失败后重试时需等待的时间>…… roach其它功能介绍：stop---用于停止正在进行的备份恢复进程；validate---用于验证所有的备份文件，识别文件有无损坏；Roach工具提供了备份集的两种验证方法，分别是Full(基于CRC校验)和Partial(基于文件大小验证)。delete---用于删除不需要的备份集；show---以列表形式显示可用备份、备份类型、将用于特定backup key恢复的备份，回显信息中包括BACKUP KEY、BKP TYPE、BARRIER TIME、DELETION TIME、VALIDATION TIME、STATUS、TLI、BKP PRIOR KEY、BACKUP LEVEL等关键信息。      除以上应用场景，roach工具还提供了基于schema级别和database数据库级别的备份恢复。GaussDB A提供了管控面管理，可以在管控面进行备份恢复管理。客户可以在管控面，定制自己的备份恢复策略，轻松创建一个备份任务，对备份集进行管理。可视化执行备份恢复任务。除了基本备份恢复，GaussDB A还提供专门容灾工具，在两套主备集群之间实现周期性备份恢复，主集群正常提供业务，进行周期性备份，并将备份集传给备集群，备集群进行周期性恢复，两套集群互不影响，当主集群发生故障，备集群能够迅速替代主集群，提供正常业务。总而言之，GaussDB A提供各种符合客户使用需求的备份恢复，容灾，迁移解决方案，使数据管理变得更加简单，安全和可靠。原文链接：https://bbs.huaweicloud.com/blogs/185928【推荐阅读】【最新活动汇总】DWS活动火热进行中，互动好礼送不停（持续更新中）  HOT  【博文汇总】GaussDB(DWS)博文汇总1，欢迎大家交流探讨~（持续更新中）【维护宝典汇总】GaussDB(DWS)维护宝典汇总贴1，欢迎大家交流探讨（持续更新中）【项目实践汇总】GaussDB(DWS)项目实践汇总贴，欢迎大家交流探讨（持续更新中）【DevRun直播汇总】GaussDB(DWS)黑科技直播汇总，欢迎大家交流学习（持续更新中）【培训视频汇总】GaussDB(DWS) 培训视频汇总,欢迎大家交流学习（持续更新中）扫码关注我哦，我在这里↓↓↓

【摘要】 工作负载管理测试分析比对。工作负载管理测试        该文章从产品的易用性，功能性 ，可测试等几个维度对dws工作负载管理，aws redshift WLM，FIM 多租户进行测试分析比对。DWS负载管理测试        1.首先在该页面创建一个集群：       2.选中该集群选择工作负载管理：       3.选择添加工作负载管理队列,该页面可以设置队列的cpu，内存，存储空间，作业的并发数：            4.关联用户之后就可以使用该用户去运行作业：                     注释：创建队列以及关联用户的后台实现为如下，此处不需要人工干预。               添加工作负载管理队列的后台的操作是创建一个组，创建对应的资源池，组用户，对应队列计算资源的设置是在资源池上，存储资源的设置落在组用户上，之后该队列的关联用户即为组用户的子用户：               例：队列资源配置为：CPU配额20%，内存30%，存储空间102400M，查询并发10，队列名称：queue1               a.)  gs_ssh -c “gs_cgroup -c -S s_queue1 -s 20” //创建class控制组               b.)  create resource pool s_ queue1 with (control_group='s_queue1', active_statements=-1,mem_percent=30); //创建组资源池               c.)  create role s_queue1 resource pool 's_queue1' password  disable perm space  '102400';  //创建组用户               d.)  gs_ssh -c “gs_cgroup -c -S s_queue1 -G queue1 -g 99” //创建workload控制组，100%继承class控制组的资源               e.)  create resource pool queue1 with (control_group='s_queue1:queue1', active_statements=10,mem_percent=100); //创建业务资源池             5.前台页面可以显示作业的运行情况，显示的是运行作业的个数比较清晰：        6.短查询加速：dws短查询配置默认支持短查询可以优先并且内存不受资源池管控，而且可以控制短查询并发个数，该特性保留接口后续会把该特性优化做到短查询内存受资源池内存管控；         查询配置：        查询概览：        后台统计：               注释：此处是短查询加速可以看到对应的用户没有内存占用也就是这里我们短查询加速的时候目前不占用资源池内存。FIM多租户测试       1.需要创建一个父租户，之后再创建一个子租户：       2.添加子租户：Aws redshift工作负载管理测试       1.添加一个队列，并且只能设置内存跟并发：                注释：redshift WLM 根据用户组和查询组向队列分配查询，所以需要自己手动创建用户组，查询组并手动将相应的组关联到队列，比较麻烦。        2.作业运行查询概览，对应的不是作业个数：       3.短查询加速：aws的短查询设置之后内存不受管控，不在队列之内需要预留内存资源，通过预测时间来控制短查询的下发，控制很容易不精确，而且不能控制短查询个数；          select * from STV_WLM_SERVICE_CLASS_CONFIG  测试总结：        通过以上测试分析得到以下结论：       1.dws的工作负载管理作业并发数没有限制，队列只要cpu,内存不超过上限值就可以，下发作业更灵活，而且作业查询概览统计的即为作业个数，查询结果更清晰；aws redshift WLM 最多 8 个队列，每个队列可配置最高 50 的并发级别，所有用户定义的队列（不包括超级用户队列）的最高并发级别总数为 50,导致作业下发个数受限，而且查询个数跟作业个数不一致导致查询结果不够清晰；        2.dws的设置不需要重启集群既可以生效;aws的设置需要重启集群；        3.dws的工作负载管理平均统计时间是5S，误差小 ;aws的异常处理规则是10S 统计一次，导致异常处理误差大；        4.cpu的管控：dws的工作负载队列就能设置，比较容易；aws 的管控需要另外设置异常处理规则比较麻烦；        5.磁盘空间的管控：dws的磁盘空间管控工作负载队列即可设置；aws的只能管控临时下盘空间并且需要设置异常处理规则；        6.dws的短查询加速更灵活多样多种选择，可以选择短查询内存走资源池也可以选择不走资源池，而且可以控制短查询的并发个数；aws的短查询加速只是不走资队列，没有个数的管控，只是通过预测时间来限制是否走短查询加速，不够精确；        7.dws的负载管理页面可以查到用户正在使用的内存大小跟用户的使用空间大小；aws的没有这样细致的统计页面；        8.易用性：dws工作负载队列更容易设置；        综上所述dws的工作负载管理易用性，功能性都是比较好的，而且该模块易于维护更能满足用户进行合理的资源限制，使在可接受的执行时间范围内使用一定的资源执行这些复杂查询，同时划分出部分资源给那些查询消耗没那么大的用户，这样在部分用户执行复杂作业的同时，另一部分用户的作业也不会受到太大影响。原文链接：https://bbs.huaweicloud.com/blogs/180968【推荐阅读】【最新活动汇总】DWS活动火热进行中，互动好礼送不停（持续更新中）  HOT  【博文汇总】GaussDB(DWS)博文汇总1，欢迎大家交流探讨~（持续更新中）【维护宝典汇总】GaussDB(DWS)维护宝典汇总贴1，欢迎大家交流探讨（持续更新中）【项目实践汇总】GaussDB(DWS)项目实践汇总贴，欢迎大家交流探讨（持续更新中）【DevRun直播汇总】GaussDB(DWS)黑科技直播汇总，欢迎大家交流学习（持续更新中）【培训视频汇总】GaussDB(DWS) 培训视频汇总,欢迎大家交流学习（持续更新中）扫码关注我哦，我在这里↓↓↓

【摘要】 DWS日期时间类型支持不同的格式，通过设置DateStyle参数可以修改日期时间数据显示格式，提供了不同格式日期时间类型数据入库方法，以及利用to_char对日期时间类型数据的格式化输出。使用DWS过程中，经常遇到不同格式的时间类型数据入库失败， DWS默认的日期时间显示格式是yyyy-mm-dd hh24:mi:ss.us，其他格式的日期时间数据入库会导致报错， DWS支持不同的日期时间显示风格，需要对数据做格式化处理才能正常入库。对于日期时间类型的显示，需要了解DWS中的配置参数DateStyle。postgres=# show DateStyle;  DateStyle  -----------  ISO, MDY(1 row)DateStyle参数详解DateStyle参数中，分为两部分，一部分是控制日期/时间的输出格式，一部分是控制day/month/year的显示顺序。PostgreSQL官方文档中描述如下：The output format of the date/time types can be set to one of the four styles ISO 8601,SQL(Ingres), traditional POSTGRES (Unix date format), or German. The default is theISOformat. (TheSQLstandard requires the use of the ISO 8601 format. The name of the "SQL" output format is a historical accident.) Table 8-14 shows examples of each output style. The output of the date and time types is generally only the date or time part in accordance with the given examples. However, the POSTGRES style outputs date-only values inISOformat.Table 8-14. Date/Time Output StylesStyle SpecificationDescriptionExampleISOISO   8601, SQL standard1997-12-17 07:37:16-08SQLtraditional   style12/17/1997 07:37:16.00 PSTPostgresoriginal   styleWed Dec 17 07:37:16 1997 PSTGermanregional   style17.12.1997 07:37:16.00 PSTNote: ISO 8601 specifies the use of uppercase letter T to separate the date and time. PostgreSQL accepts that format on input, but on output it uses a space rather than T, as shown above. This is for readability and for consistency with RFC 3339 as well as some other database systems.In theSQLand POSTGRES styles, day appears before month if DMY field ordering has been specified, otherwise month appears before day. (See Section 8.5.1 for how this setting also affects interpretation of input values.) Table 8-15 shows examples.Table 8-15. Date Order Conventionsdatestyle    SettingInput    OrderingExample    OutputSQL, DMYday/month/year17/12/1997 15:37:16.00 CETSQL, MDYmonth/day/year12/17/1997 07:37:16.00 PSTPostgres, DMYday/month/yearWed 17 Dec 07:37:16 1997 PST通过一些探索性的测试验证，发现一些更为细节的东西，比如day/month/year的顺序只能为YMD/DMY/MDY ，month/day的顺序还可以使用European和US来控制。详细情况测试如下：默认DateStyle设置下的行为如下：postgres=# show DateStyle;  DateStyle  -----------  ISO, MDY(1 row)  postgres=# select current_timestamp;         pg_systimestamp         -------------------------------  2020-06-22 20:07:51.148858+08(1 row)ISO格式的day/month/year顺序是不受MDY参数控制，也就是说无论怎么设置，顺序都是yyyy-mm-dd。而同样，在GERMAN格式下，格式始终是dd.mm.yyyy。postgres=# set DateStyle to 'GERMAN, MDY';SETpostgres=# select current_timestamp;         pg_systimestamp          --------------------------------  22.06.2020 20:18:45.135697 CST(1 row)Postgres格式下，不管怎么设置，year始终在最后，只能变换month和day的位置。postgres=# set DateStyle to 'Postgres, DMY';SETpostgres=# select current_timestamp;            pg_systimestamp            -------------------------------------  Mon 22 Jun 20:10:01.270965 2020 CST(1 row)postgres=# set DateStyle to 'Postgres, YMD';SETpostgres=# select current_timestamp;            pg_systimestamp            -------------------------------------  Mon Jun 22 20:14:13.967454 2020 CST(1 row)  postgres=# set DateStyle to 'Postgres, MDY';SETpostgres=# select current_timestamp;            pg_systimestamp            -------------------------------------  Mon Jun 22 20:29:37.870996 2020 CST(1 row)对于SQL格式来说，跟Postgres格式类似，不管怎么设置，year始终在最后，只能变换month和day的位置。postgres=# set DateStyle to 'SQL, YMD';SETpostgres=# select current_timestamp;         pg_systimestamp          --------------------------------  06/22/2020 20:26:01.411167 CST(1 row)  postgres=# set DateStyle to 'SQL, DMY';SETpostgres=# select current_timestamp;         pg_systimestamp          --------------------------------  22/06/2020 20:26:11.314706 CST(1 row)  postgres=# set DateStyle to 'SQL, MDY';SETpostgres=# select current_timestamp;         pg_systimestamp          --------------------------------  06/22/2020 20:27:23.056398 CST(1 row)而SQL和Postgres格式下，可以通过设置European和US来设置month和day的位置，European代表day/month，US代表month/day。postgres=# set DateStyle to 'SQL, European';SETpostgres=# select current_timestamp;         pg_systimestamp          --------------------------------  22/06/2020 20:31:06.073123 CST(1 row)  postgres=# set DateStyle to 'SQL, US';SETpostgres=# select current_timestamp;         pg_systimestamp          --------------------------------  06/22/2020 20:31:12.113224 CST(1 row)  postgres=# set DateStyle to 'Postgres, US';SETpostgres=# select current_timestamp;           pg_systimestamp            ------------------------------------  Mon Jun 22 20:31:34.13653 2020 CST(1 row)  postgres=# set DateStyle to 'Postgres, European';SETpostgres=# select current_timestamp;            pg_systimestamp            -------------------------------------  Mon 22 Jun 20:31:40.816756 2020 CST(1 row)另外，NonEuropean与US一致，还可以用NonEuro和Euro缩写来进行设置。不同格式时间数据入库假如有时间类型数据无法入库，例如cat test.dat22/06/2020 20:57:20导入时报错postgres=# copy test from '/home/jack/test.dat';ERROR:  date/time field value out of range: "22/06/2020 20:57:20"HINT:  Perhaps you need a different "datestyle" setting.CONTEXT:  COPY test, line 1, column time: "22/06/2020 20:57:20"第一种方案可以在session中临时修改DateStyle，然后再执行入库：postgres=# set DateStyle to 'SQL, European';SETpostgres=# copy test from '/home/jack/test.dat';COPY 1postgres=# select * from test;         time          ---------------------  22/06/2020 20:57:20(1 row)还有一种方案，需要借助于copy以及GDS/OBS导入外表的参数DATE_FORMAT|TIME_FORMAT|TIMESTAMP_FORMAT| SMALLDATETIME_FORMAT，例如timestamp类型的列，通过指定TIMESTAMP_FORMAT格式，执行入库。postgres=# copy test from '/home/jack/test.dat' with(timestamp_format 'DD/MM/YYYY HH24:MI:SS');COPY 1postgres=# select * from test;         time          ---------------------  2020-06-22 20:57:20(1 row)时间数据类型格式化在不更改DateStyle参数的情况下，如果需要调整日期时间显示格式，可以借助于to_char格式化命令。postgres=# select to_char(sysdate,'Dy DD Mon YYYY HH24:MI:SS');          to_char           --------------------------  Mon 22 Jun 2020 20:56:07(1 row)  postgres=# select to_char(sysdate,'DD.MM.YYYY HH24:MI:SS');        to_char        ---------------------  22.06.2020 20:57:00(1 row)  postgres=# select to_char(sysdate,'DD/MM/YYYY HH24:MI:SS');        to_char        ---------------------  22/06/2020 20:57:20(1 row)对于需要带微秒、时区、十二小时制的时间格式化来说，举例如下：postgres=# select to_char(current_timestamp, 'Dy DD Mon YYYY HH:MI:SS.US TZ AM');                 to_char                  ----------------------------------------  Mon 22 Jun 2020 09:45:36.404909 CST PM(1 row)【注意】由于DWS默认时区为UTC，与国内的东八区有差异，建议在使用时间类型数据时关注时区，尤其是时间类型数据作为分区表的分区字段的场景，DWS支持的时间类型支持timestamp with time zone(timestamptz)，可以避免客户端服务端不同时区导致的数据差异。PostgreSQL官方文档中，to_char支持的格式化Patterns很多，有兴趣可以研究一下：In a to_char output template string, there are certain patterns that are recognized and replaced with appropriately-formatted data based on the given value. Any text that is not a template pattern is simply copied verbatim. Similarly, in an input template string (for the other functions), template patterns identify the values to be supplied by the input data string.Table 9-22 shows the template patterns available for formatting date and time values.Table 9-22. Template Patterns for Date/Time FormattingPatternDescriptionHHhour   of day (01-12)HH12hour   of day (01-12)HH24hour   of day (00-23)MIminute   (00-59)SSsecond   (00-59)MSmillisecond   (000-999)USmicrosecond   (000000-999999)SSSSseconds   past midnight (0-86399)AM, am, PM   or pmmeridiem   indicator (without periods)A.M., a.m., P.M.   or p.m.meridiem   indicator (with periods)Y,YYYyear   (4 or more digits) with commaYYYYyear   (4 or more digits)YYYlast   3 digits of yearYYlast   2 digits of yearYlast   digit of yearIYYYISO   8601 week-numbering year (4 or more digits)IYYlast   3 digits of ISO 8601 week-numbering yearIYlast   2 digits of ISO 8601 week-numbering yearIlast   digit of ISO 8601 week-numbering yearBC, bc, AD   or adera   indicator (without periods)B.C., b.c., A.D.   or a.d.era   indicator (with periods)MONTHfull   upper case month name (blank-padded to 9 chars)Monthfull   capitalized month name (blank-padded to 9 chars)monthfull   lower case month name (blank-padded to 9 chars)MONabbreviated   upper case month name (3 chars in English, localized lengths vary)Monabbreviated   capitalized month name (3 chars in English, localized lengths vary)monabbreviated   lower case month name (3 chars in English, localized lengths vary)MMmonth   number (01-12)DAYfull   upper case day name (blank-padded to 9 chars)Dayfull   capitalized day name (blank-padded to 9 chars)dayfull   lower case day name (blank-padded to 9 chars)DYabbreviated   upper case day name (3 chars in English, localized lengths vary)Dyabbreviated   capitalized day name (3 chars in English, localized lengths vary)dyabbreviated   lower case day name (3 chars in English, localized lengths vary)DDDday   of year (001-366)IDDDday   of ISO 8601 week-numbering year (001-371; day 1 of the year is Monday of the   first ISO week)DDday   of month (01-31)Dday   of the week, Sunday (1) to Saturday (7)IDISO   8601 day of the week, Monday (1) to Sunday (7)Wweek   of month (1-5) (the first week starts on the first day of the month)WWweek   number of year (1-53) (the first week starts on the first day of the year)IWweek   number of ISO 8601 week-numbering year (01-53; the first Thursday of the year   is in week 1)CCcentury   (2 digits) (the twenty-first century starts on 2001-01-01)JJulian   Day (integer days since November 24, 4714 BC at midnight UTC)Qquarter   (ignored by to_date and to_timestamp)RMmonth   in upper case Roman numerals (I-XII; I=January)rmmonth   in lower case Roman numerals (i-xii; i=January)TZupper   case time-zone abbreviation (only supported in to_char)tzlower   case time-zone abbreviation (only supported in to_char)OFtime-zone   offset from UTC (only supported in to_char)对于时间类型格式化这块，DWS保持了PostgreSQL的兼容性，更详细的格式化Patterns以及使用方法，可以参考PostgreSQL文档。原文链接：https://bbs.huaweicloud.com/blogs/178389【推荐阅读】【最新活动汇总】DWS活动火热进行中，互动好礼送不停（持续更新中）  HOT  【博文汇总】GaussDB(DWS)博文汇总1，欢迎大家交流探讨~（持续更新中）【维护宝典汇总】GaussDB(DWS)维护宝典汇总贴1，欢迎大家交流探讨（持续更新中）【项目实践汇总】GaussDB(DWS)项目实践汇总贴，欢迎大家交流探讨（持续更新中）【DevRun直播汇总】GaussDB(DWS)黑科技直播汇总，欢迎大家交流学习（持续更新中）【培训视频汇总】GaussDB(DWS) 培训视频汇总,欢迎大家交流学习（持续更新中）扫码关注我哦，我在这里↓↓↓

1      数据库主要对象的理解1.1      数据库对象TABLESPACE:操作系统文件结构中的具体文件空间在集群内的定义。说白点就是集群要占用哪些操作系统文件系统空间。DATABASE：数据库物理隔离单位，一个集群内可以有多个DATABASE，多个DATABASE在数据库概念上是物理隔离的。用户一次只能登陆一个DATABASE，防问其中的数据。定义DATABASE时，即创建了从数据库逻辑到操作系统文件空间的对应关系。SCHEMA：DATABASE内进行逻辑隔离的作用。这样不同用户和应用可以重用表名空间。数据库管理时使用schemaname.tablename则可以唯一操作具体的表。TABLE:这个就是用户具本存数据的最小单元了，大家都理解。2      ORACLE/PG/DWS的SCHEMA设计比较2.1      差异总结PG和DWS的模式（SCHEMA）是DATABASE内的概念，为了提供用户在DATABASE内再进行逻辑划分用的。ORACLE的DATABASE是用户层面的概念，即一个用户在新DATABASE内创建对象时，固定要创建一个同名SCHEMA，并将对像创建在SCHEMA下。2.2      实现差异自动创建同名SCHEMA可独立创建SCHEMA不同DATABASE处理Oracle是否一致PG否是一致DWS是是不一致，创建用户的库有同名SCHEMA，其它库需手动创建2.3      优缺点自动创建同名SCHEMA：优点：不同用户默认创建表时，不会发生表名冲突的情况。因为默认都创建在各自的同名SCHEMA下。缺点：用户名与SCHEMA间存在了约束关系。例如user1,如创建了user2的schema，刚无法创建名为user2的用户，因为schema名冲突。可新增普通SCHEMA：优点：用户内可对数据库对象分组，按组赋权给其它用户缺点：USER和SCHEMA共用名空间，一个是管理员行为一个是一般用户行为，会出现行为冲突。3      DWS与PG对比测试情况3.1      PG不会因为其它用户存在A 模式而不能创建A用户3.2      DWS因为其它用户存在A模式，而不能创建A用户dws=# create user u1 password 'Gauss_234';CREATE ROLEdws=# create schema schema2 authorization u1;CREATE SCHEMAdws=# create user schema2 password 'Gauss_234';ERROR:  schema "schema2" already exists3.2.1        DWS不同库可以有同名模式原文链接：https://bbs.huaweicloud.com/blogs/174598【推荐阅读】【最新活动汇总】DWS活动火热进行中，互动好礼送不停（持续更新中）  HOT  【博文汇总】GaussDB(DWS)博文汇总1，欢迎大家交流探讨~（持续更新中）【维护宝典汇总】GaussDB(DWS)维护宝典汇总贴1，欢迎大家交流探讨（持续更新中）【项目实践汇总】GaussDB(DWS)项目实践汇总贴，欢迎大家交流探讨（持续更新中）【DevRun直播汇总】GaussDB(DWS)黑科技直播汇总，欢迎大家交流学习（持续更新中）【培训视频汇总】GaussDB(DWS) 培训视频汇总,欢迎大家交流学习（持续更新中）扫码关注我哦，我在这里↓↓↓

【摘要】 运维管理模块是任何软件产品最基础和重要的一部分。是软件产品的门户，也是用户接触和使用软件产品的和前提和基础。如安装部署能让用户快速上手使用，升级能让产品平滑更新，扩容能让产品扩充能力，故障修复能让产品快速恢复，监控告警能让产品提前预知或及时排除故障。其在可用性，易用性，可靠性，可维护性、在线运维方面都有较高的要求。本文将详细介绍GaussDB(DWS)重要运维管理功能“升级”的原理和使用。前言不断更新和演进是软件的一个重要行为，升级是软件更新的重要保证。伴随着新特性不断推出和历史问题修复，软件升级和打补丁显得格外重要。升级和打补丁需要满足如下要求：软件版本的无缝、平滑过渡。业务中断时间尽量少，以至于在线。用户体验前向兼容。而数据库升级比其他软件升级更为复杂，不光是软件本身的更新，还要支持其管理的数据的升级。数据库升级需要考虑如下因素： 软件升级，即软件本身的更新。元数据升级，即软件管理数据的方式的更新。业务数据升级，即软件管理的数据的升级。随着数据库版本的快速演进，升级愈显重要，其可靠性、性能、业务中断、易用性急需改善。升级演进GaussDB(DWS)升级经过多个版本的演进，其性能，可靠性逐步提升。并提供了不同场景的各种升级方式。如下是演进过程：大版本全量升级：新版本重建数据库，元数据导入导出，业务数据全量mv方式。依赖于数据库对象个数和业务数据量大小、业务数据表文件数。已在V1R8停用。就地升级：原地替换二进制，修改系统表方式。依赖于系统表的逻辑大小（数据对象个数）和物理大小（系统表脏页）及数据库个数。小版本离线升级：停机，替换二进制，启动集群。业务中断时间是一次集群的重启时间。小版本滚动升级：保留老二进制文件，新目录安装新二进制，按照组件（om_monitor，cm_agent，ETCD，CN，dummy DN，standby DN/GTM/CM，master DN/GTM/CM）滚动切换到新二进制，然后主备切换。整个升级过程中涉及两次switchover，业务中断时间依赖于在线switchover和CN retry能力。小版本闪断升级：基于小版本滚动升级基础，保留老二进制文件，新目录安装新二进制，先切换管理组件（om_monitor、cm_agent、ETCD、cm_server），再一次性切换业务组件（GTM、CN、DN），只闪断一次业务。目前DWS已使用。就地升级原理介绍目前8.0主要使用的升级方式是就地升级。其已经支撑现网线下和公有云多套集群成功升级到新版本。1、公有云升级流程DWS服务升级主要分2部分，管控面升级和租户面升级：各个region的管控面升级回滚主要通过CDK平台完成，升级后组件自行功能验证。升级实例的信息：租户面升级在ServiceCM平台由SRE操作，操作可分为DWS Guest升级和数据库内核升级：主要流程如下所示：2、线下updatetool升级通过登录UpdateService操作界面，创建升级工程，进行一键式升级。3、数据库内核升级流程数据库内核升级是通过替换二进制+更新元数据的方式进行升级。包括初始阶段，准入检查，环境准备，停机，备份，升级，update catalog，提交8个阶段。升级性能目标版本业务中断升级时间窗8.0版本升级小于60分钟建议4小时8.0版本补丁10分钟建议2小时8.1版本升级小于30分钟建议2小时8.1版本补丁秒级闪断建议30分钟8.x版本升级灰度滚动升级在线升级8.x版本补丁函数注册，无闪断在线补丁升级问题定位升级过程日志概览见下表：流程日志目录日志记录信息说明创建升级工程${BIGDATA_LOG_HOME}/update-service/scriptLog/创建工程脚本执行${BIGDATA_LOG_HOME}/controller/scriptlog/restore_package.log升级包瘦身还原${BIGDATA_LOG_HOME}/controller/scriptlog/installPack.log部署新版本组件包${BIGDATA_LOG_HOME}/update-service/runLog/update-manager.log集群信息与工程初始化${BIGDATA_LOG_HOME}/upgrade/prepare.log升级信息准备分发软件包${BIGDATA_LOG_HOME}/update-service/runLog/update-manager.log包分发-工具侧${BIGDATA_LOG_HOME}/controller/controller.log包分发-controller侧${BIGDATA_LOG_HOME}/update-service/runLog/omm_upd_agent.log原子包部署${BIGDATA_LOG_HOME}/update-service/scriptLog/distribute_deploy_adapter.log升级适配包部署升级Manager${BIGDATA_LOG_HOME}/upgrade/upgrade.log升级Manager过程中脚本执行${BIGDATA_LOG_HOME}/controller/scriptlog/installPack.log注册新版本部件升级集群前准备${BIGDATA_LOG_HOME}/upgrade/upgrade.log适配components适配adapter${BIGDATA_LOG_HOME}/controller/controller_client.log进入、退出agent更新模式${BIGDATA_LOG_HOME}/update-service/runLog/update-manager.log进入、退出agent更新模式安装新版本部件配置生成组件账户信息升级Postinstall处理${BIGDATA_LOG_HOME}/controller/controller.log安装新部件配置生成组件账户信息升级Postinstall处理升级集群${BIGDATA_LOG_HOME}/update-service/runLog/update-manager.log停止服务备份服务升级前处理启动新服务${BIGDATA_LOG_HOME}/ controller/controller.log停止服务启动新服务提交确认${BIGDATA_LOG_HOME}/upgrade/commit.log旧版本部件删除oms升级确认agent升级确认${BIGDATA_LOG_HOME}/update-service/runLog/update-manager.log新服务提交确认旧版本部件卸载${BIGDATA_LOG_HOME}/controller/controller.log组件账户信息确认旧版本部件卸载${BIGDATA_LOG_HOME}/update-service/scriptLog/删除升级软件包脚本执行回滚${BIGDATA_LOG_HOME}/upgrade/rollback.log回退JDK回退Adapter适配回退component适配卸载新版本部件agent回退oms回退${BIGDATA_LOG_HOME}/update-service/runLog/update-manager.log激活旧版本部件配置刷新停止服务组件服务回退启动旧版本服务部件回退进入与退出Agent更新模式${BIGDATA_LOG_HOME}/controller/controller.log激活旧版本部件配置刷新停止服务启动旧版本服务组件账户信息回退部件回退${BIGDATA_LOG_HOME}/update-service/scriptLog/删除升级软件包脚本执行UpdateService的日志分为审计日志和调试日志，位置见下表：文件目录日志类别日志说明/var/log/Bigdata/audit/upgrade审计日志记录UpdateService接收到的命令及其执行结果${BIGDATA_LOG_HOME}/update-service/catalina${BIGDATA_LOG_HOME}/update-service/core${BIGDATA_LOG_HOME}/update-service/runLog${BIGDATA_LOG_HOME}/update-service/scriptLog运行日志安装运行过程中产生的日志结语在数据仓库产品使用过程中，升级和打补丁是使用频率较高的功能。本文中仅仅介绍了GaussDB(DWS)升级的大致流程和基本原理，及性能目标。如果现网变更中遇到升级相关问题，还需联系相关技术支持。原文链接：https://bbs.huaweicloud.com/blogs/198213【推荐阅读】【最新活动汇总】DWS活动火热进行中，互动好礼送不停（持续更新中）  HOT  【博文汇总】GaussDB(DWS)博文汇总1，欢迎大家交流探讨~（持续更新中）【维护宝典汇总】GaussDB(DWS)维护宝典汇总贴1，欢迎大家交流探讨（持续更新中）【项目实践汇总】GaussDB(DWS)项目实践汇总贴，欢迎大家交流探讨（持续更新中）【DevRun直播汇总】GaussDB(DWS)黑科技直播汇总，欢迎大家交流学习（持续更新中）【培训视频汇总】GaussDB(DWS) 培训视频汇总,欢迎大家交流学习（持续更新中）扫码关注我哦，我在这里↓↓↓

技术背景随着客户业务对数据可靠性和服务可用性要求的提高，主备架构在OLAP系统中也已被广泛使用。而分析型数据库往往数据量大，节点数多，分布式系统下发生硬件故障已成为常态。对于传统两副本系统（一主一备最大可用HA模式），单节点故障后，为了服务可用性，一般都会选择让另一个正常节点继续提供服务，在故障节点恢复前数据只有单副本运行。而由于数据量大，往往故障节点修复时间和数据重建时间都很长，此时一旦正常主机再次发生故障，将造成数据丢失的严重后果。另外，根据分布式CAP原理，两副本系统一旦采用最大可用策略，将损失分区容错性（即脑裂双主，下文详述）。尽管三副本通过多数派复制策略可以解决上述问题，但三副本带来了更多的存储成本开销，在OLAP数据库中无法成为主流解决方案。因此，GaussDB(DWS)创新性的在数据节点（DN）引入从备概念，使得集群在任意单点故障时仍保持两副本可用，相比传统三副本节约了三分之一的存储空间，但数据可靠性基本持平。技术原理如上图所示，GaussDB(DWS)引入备机和从备的概念，正常情况下主机和备机通过日志流复制和数据页流复制进行强同步，主机与从备仅保持连接并不发送日志和数据，因此从备不占用额外存储资源。当备机发生故障时，主机自动感知，将未完成同步的日志和数据发送给从备，并保持主从强同步。主备同步向主从同步的切换在内核底层HA实现，事务层并不感知，因此不会造成任何报错和不一致。同理，当主机发生故障时，由集群管理感知并仲裁备机升主，升主后的备机连接从备进行主从强同步。因此，在一组DN内发生单点故障后，不会影响服务可用性，同时数据仍然有两份副本的可靠性保障。日志分叉与脑裂尽管GaussDB(DWS)主备间是强同步，但各自落盘顺序总有先后。与绝大多数数据库一样，GaussDB(DWS)的物理日志总是先写主机后写备机。如上图所示，主机崩溃前可能有一部分日志未同步给备机（红色部分未同步，蓝色部分已同步），备机升主后会提供服务，会写入新的日志（绿色部分）。由于物理日志按照lsn顺序递增，主机的红色日志与备机的绿色日志占用了相同的一段lsn，形成冲突，即日志分叉。日志分叉可能带来严重问题，例如一旦分叉后发生集群重启，传统两副本方式可能无法通过日志长度判断应该选谁成为新主，选错将造成数据丢失（应选包含绿色日志的节点为主，因为其可能包含已提交事务；而红色段日志一定不存在已提交事务，可以丢弃）。在引入从备后，主机故障备机升主，升主后将与从备进行强同步，因此从备上的日志一定与新主保持一致。在上述场景中，DN响应升主命令时可以额外判断从备日志，通过校验CRC来判断日志是否分叉，与从备日志一致的才能升主成功，从而保证了仲裁的正确性和数据的一致性。此外，在极限断网、进程僵死、集群管理失效等场景下，有可能在主机存活时错误的将备机升主，形成双主脑裂。传统的两副本HA机制无法识别此类场景，只能通过外部加固手段减少脑裂发生的概率。而在主备从架构下，从备可临时作为仲裁者，类似三副本多数派机制。DN响应升主时与从备建连并进行日志校验，只有与从备形成多数派的主机才实际有效，而另外的主机因无法与从备强同步而自动失效，从而解决了脑裂的问题。数据可靠性对于服务可用性，主备从HA与三副本多数派复制和两副本最大可用HA相同，都能够容忍单副本故障。对于数据可靠性，主备从HA提供了强于两副本、接近三副本的能力。以上图所示场景为例，备机故障一段时间后恢复。从时间轴上看，可以分为P1主备同步、P2主从同步、P3备机追赶和P4主备同步四个阶段。P1/P4：主备同步，数据拥有两副本可靠性，数据可靠性与传统两副本相同。P2：发生单节点故障，主从同步，数据仍然具有两副本可靠性，优于传统两副本。此时如果主机磁盘损坏无法恢复，由于从备仍有一份数据，当备机恢复后即可提供服务，而传统两副本则必须等待主机恢复才能提供服务，否则会数据丢失。P3：备机恢复后追赶P2阶段生成的日志和数据，此时主机仍然与从备强同步并正常服务。追赶阶段一旦发生主机故障，备机升主时可以连接从备补齐日志和数据并提供服务；而传统两副本则因备机没有追赶完成而无法恢复服务，否则会数据丢失。以上，主备从HA在P2、P3阶段相比两副本有额外的可靠性优势。而相比三副本，只有在主备两节点都发生磁盘损坏且不可恢复的场景下，可靠性方面具有劣势。总结综上所述，主备从HA在保持了两副本存储成本的前提下，解决了传统两副本最大可用HA模式中因日志分叉造成的数据一致性问题和脑裂问题，同时提供了接近三副本的更高数据可靠性。原文链接：https://bbs.huaweicloud.com/blogs/175249【推荐阅读】【最新活动汇总】DWS活动火热进行中，互动好礼送不停（持续更新中）  HOT  【博文汇总】GaussDB(DWS)博文汇总1，欢迎大家交流探讨~（持续更新中）【维护宝典汇总】GaussDB(DWS)维护宝典汇总贴1，欢迎大家交流探讨（持续更新中）【项目实践汇总】GaussDB(DWS)项目实践汇总贴，欢迎大家交流探讨（持续更新中）【DevRun直播汇总】GaussDB(DWS)黑科技直播汇总，欢迎大家交流学习（持续更新中）【培训视频汇总】GaussDB(DWS) 培训视频汇总,欢迎大家交流学习（持续更新中）扫码关注我哦，我在这里↓↓↓

文章目录1. 负载管理简介2. 资源监视功能介绍负载管理(WLM)简介对于任何一个分布式数据库而言，无论数据库集群规模有多大，其计算资源（CPU、内存）与存储资源（磁盘空间、网络、IO）总归是有上限的。对于数据仓库应用而言，随着业务规模的逐日累积，当数据量或者查询作业达到一定的规模，不同组织、不同用户之前的必然会出现计算、存储资源的争抢，在无人干预的情况下，数据库系统通常会“笨”的想着把你的所有业务都尽可能快的执行完，通常会导致所有的业务执行速度都变慢了。GaussDB 负载管理（WLM）存在的目的就是为了让资源的分配合理化，重要的作业优先运行，次要的作业在资源不足情况下避免争抢他人资源。当然，如何能用好GaussDB 负载管理（WLM）的配置功能，不是一件一蹴而就的事情，业务是复杂的，一个组织/用户的运行作业是计算密集型还是存储密集型，往往通过猜得到的结果是背道而驰的。这也是本文存在的意义，希望读者能够通过GaussDB所提供的资源监视功能，将资源监视功能作为有效的度量工具，来衡量各组织/用户的资源争抢情况，进而通过负载管理功能做好计算/存储资源的划分，让你的数据库“聪明”起来。资源监视功能介绍对于用户而言，数据库负载不高的情况下，通常不会在意数据库里面跑了什么作业，通常当用户察觉到作业变慢的时候，才会开始琢磨作业为什么慢了，是不是数据库里面有别的作业影响到我了。此时，用户将会找到管理员，要求解决性能劣化的问题。而用户给管理员提供的信息会非常简单，在什么时间执行了一个什么语句，以前这个语句几分钟能够运行结束，现在要多长时间才能跑完。并且，劣化作业有可能因业务原因，不能随意执行，无法让管理员去复现定位。管理员只能等到数据库系统中，依据这简单的信息，期望能发现一些线索。GaussDB提供了完善的资源监视功能，能够帮助管理员在这两个信息的基础上分析历史某个时间点发生的问题。总结一下，管理员现在拿到的信息：1) 作业执行起始时间；2) 用户名; 3) 作业的SQL语句。下面，请跟随我以管理员的视角，在有限信息的情况下，来逐层递进分析，找到作业“慢”在哪。功能一：历史TopSQLGaussDB 提供了记录所有在数据库中执行SQL语句的功能，管理员可以通过打开enable_resource_track开关来启用这个功能，并且可以调整resource_track_duration参数来过滤掉执行时间较短的作业，着重于分析执行时长较长的作业。GaussDB 提供记录历史TopSQL这一功能的目的，就是为了方便用户做性能调优，TopSQL的数据表pgxc_wlm_session_history中详细记录了作业的执行时间、内存消耗、下盘量、CPU消耗、IO占用等信息，在业务变更、作业变更前后，可通过对比来分析SQL是否出现劣化。数据表pgxc_wlm_session_history提供的关键信息简述如表格，管理员能够分析的可能现象也在表格中：字段名称字段描述分析出可能的现象block_time语句执行前的阻塞时间，包含：语句解析、语句优化时间，以及作业排队时间。A1: block_time较大，而duration值并无明显变化，说明用户作业受其它作业影响，在真正开始执行前进行了较长时间的排队，下一步需要接着查看本数据表，统计起始时间小于start_time、结束时间大于finish_time的作业数量。A2: block_time较小，而duration值较大，说明用户作业执行时间增加较大原因是自己导致，需要继续分析数据量的变化情况、各DN的执行时间变化。start_time语句开始执行时间戳。finish_time语句执行结束时间戳。duration语句执行时间长度。status语句执行的结束状态，正常为finished，异常为aborted。可以查看作业是否正常结束，如果异常，还会有异常原因。abort_info语句执行结束状态为aborted时显示异常信息。min_peak_memory语句在所有DN上的最小内存峰值，单位MB。B1: 对于同一个查询，可对比前后几次的内存消耗情况，内存消耗平均值能够反映出数据表的数据量是否有变化，memory_skew_percent值能够侧面反映出相关数据表在各DN上的数据分布是否有倾斜。并且，query_plan能够直接显示作业的执行计划，对比执行计划是否有变化。max_peak_memory语句在所有DN上的最大内存峰值，单位MB。average_peak_memory语句执行过程中的内存使用平均值，单位MB。memory_skew_percent语句各DN间的内存使用倾斜率。min_spill_size若发生下盘，所有DN上下盘的最小数据量，单位MB。C1: 对有大量下盘的查询有显著帮助信息，当下盘量剧增的时候，通常是表数据量有大幅增加，或者是执行计划有问题导致的，结合query_plan能进一步分析，spill_skew_percent可以查看作业是否有严重数据倾斜。max_spill_size若发生下盘，所有DN上下盘的最大数据量，单位MB。average_spill_siz若发生下盘，所有DN上下盘的平均数据量，单位MB。spill_skew_percent若发生下盘，DN间下盘倾斜率。min_dn_time语句在所有DN上的最小执行时间，单位ms。D1: DN上的执行时间，结合duration数据，如果一个查询的DN执行时间有严重倾斜，那就需要考虑数据表的分区、分布列是否设置合适；不合理的分区、分布列，可能会导致本应分散到多个DN的执行任务被集中到个别DN上执行，执行时间必然大大增加。max_dn_time语句在所有DN上的最大执行时间，单位ms。average_dn_time语句在所有DN上的平均执行时间，单位ms。dntime_skew_percent语句在各DN间的执行时间倾斜率。min_cpu_time语句在所有DN上的最小CPU时间，单位ms。E1: CPU执行时间是分配给改作业的实际执行时间，当duration有明显增加，而平均CPU执行时间无明显变化时，很可能的一个原因是作业执行期间，有多个其它计算密集型作业同时段执行，因CPU抢占的原因，拉长了该作业的执行时长。max_cpu_time语句在所有DN上的最大CPU时间，单位ms。total_cpu_time语句在所有DN上的CPU总时间，单位ms。cpu_skew_percent语句在DN间的CPU时间倾斜率。min_peak_iops语句在所有DN上的每秒最小IO峰值。F1: IO是变化最莫测的一个资源，一个作业在数据量不变、内存消耗无变化、CPU执行时间无变化、下盘量无变化的情况下，偏偏duration增加了，那最可能的原因是IO的原因。IO有点独特的是，往往IOPS变小反而反应了作业受其它作业影响，IO跑步起来，拖长了作业执行时间；其它属性通常相反，如：内存、CPU、下盘量，这些值变小通常意味着作业执行变快了。max_peak_iops语句在所有DN上的每秒最大IO峰值。average_peak_iops语句在所有DN上的每秒平均IO峰值。iops_skew_percent语句在DN间的IO倾斜率。query_plan语句的执行计划。G1: 作业执行计划是否有变化。总结一下：因数据量变化，导致作业执行时间增加，可以分析A2/B1/D1/G1，进而确认作业查询的数据表是否有明显的数据量增加；因其它并发作业抢占，导致作业排队，从而导致作业执行时间增加，可以分析A1/B1/D1，进而查看作业执行的同时期是否有大量并发作业在执行；因其它作业而产生的CPU抢占，导致作业执行时间增加，可以分析A2/D1/E1，进而查看作业执行的同时期是否有大量并发作业在执行；因其它作业而产生的IO抢占，导致作业执行时间增加，可以分析A2/F1，进而查看作业执行的同时期是否有大量并发作业在执行；值得注意的是，发生资源争抢时，可能会出现并发症，即CPU、IO抢占，作业排队现象都会发生，针对并发症问题，可以逐步分析解决，比如：第一步，调整作业执行顺序，减少并发作业数量，减少阻塞时间；第二步，定位出同时段执行的典型计算密集型、存储密集型作业，先移动到其它时间段执行，减少对本作业的影响；第三步，在无其他作业明显干预的情况下，做进一步分析，功能二：历史用户资源占用如果无其它作业影响，TopSQL一张数据表基本已经能够分析出性能劣化缘由；但如果分析出受其它作业影响，那么接下来就是查找可能造成影响的作业。除了在TopSQL中查询执行周期内的作业信息之外，还可以借助历史用户资源占用系统表GS_WLM_USER_RESOURCE_HISTORY，来搜索“可疑”用户。“可疑”用户通常对数据库性能优化没有太多理解，往往会出现“select *”查询，或者一次提交大批量作业。GS_WLM_USER_RESOURCE_HISTORY系统表记录了所有用户的历史资源占有情况，结合反馈性能劣化的用户名以及作业执行时间段，从历史用户资源占用表中或许可以分析出是否有“可疑”用户影响。数据表GS_WLM_USER_RESOURCE_HISTORY提供的关键信息简述如表格，管理员能够分析的可能现象也在表格中：字段名称字段描述分析出可能的现象username用户名。timestamp监控时间戳。used_memory该用户正在使用的内存大小，单位MB。A: 是否有其它用户占用大量内存，结合运行作业数量分析，是一个大查询还是多个小查询。used_cpu该用户正在使用的CPU核数。B: 是否有其它用户占用大量CPU。used_space该用户已使用的存储空间大小，单位KB。C: 查看各用户的磁盘占用情况，结合负载管理(WLM)中的空间管控能力，可疑避免差SQL一次将磁盘占满的情况。used_temp_space该用户已使用的临时存储空间大小，单位KB。used_spill_space该用户已使用的算子落盘存储空间大小，单位KB。read_kbytes监控周期内，读操作的字节流量，单位KB。D: 是否有其它用户占用了大量IO资源。write_kbytes监控周期内，写操作的字节流量，单位KB。read_speed监控周期内，读操作的字节速率，单位KB/s。write_speed监控周期内，写操作的字节速率，单位KB/s。历史用户资源占用数据表能够非常直观的看出哪个用户占用了资源，而且是占用了哪类资源，管理员可疑进一步分析这些资源占用是否合理，进而通过资源管理(WLM)的管控能力，做合理的用户资源划分。功能三：历史实例资源监视在TopSQL、用户资源占用的数据表的基础上，基本能够分析出劣化原因，从而能做出相应的措施。此外，有一类问题比较独特，危害较大，DN负载不均衡或者DN劣化(硬件缘由)，在数据表分布不均的情况下，可能会导致一系列SQL都会出现执行倾斜的情况，变相拉长所有作业的执行时间，TopSQL中相关SQL的倾斜值较大。针对此类问题，如果没有用户提出作业变慢的情况下，管理员如何能够提前预防呢？GaussDB 提供了记录CN、DN资源使用量的能力，该类数据会保存到GS_WLM_INSTANCE_HISTORY数据表中，包含：CPU、内存、IO等信息。如下列表所示：字段名称字段描述分析出可能的现象instancename实例名称。timestamp时间戳。used_cpu实际使用的CPU。A: 可能有个别DN长时间占用大量CPU，明显的数据倾斜特征。used_mem实际使用的内存大小。io_await实例所使用磁盘的io_wait值（10秒均值）。B1: io_util&io_await能够反应出磁盘的繁忙程度，disk_read&disk_write是发生的实际IO流量值，如果磁盘很繁忙，但实际IO流量值不高，可以进一步分析磁盘是否有坏道，是否有硬件故障。B2: 如果磁盘很繁忙，实际IO流量也很高，但是process_read&process_write却较低，说明造成磁盘繁忙的原因并不是该GaussDB实例，可能是备机catchup或者其它运行在该磁盘上的程序消耗了大量IO，可做进一步定位。B3: 通常情况下，logical_read/logical_write远大于process_read/process_write，这是因为磁盘预读+较好的缓存命中率导致的；如果两者相近，说明缓存命中率很低，进而分析是否需要vacuum或者数据表的定义是否符合查询的就近原则。io_util实例所使用磁盘的io_util值（10秒均值）。disk_read实例所使用磁盘的读速率（10秒均值），单位KB/s。disk_write实例所使用磁盘的写速率（10秒均值），单位KB/s。process_read实例对应进程从磁盘读数据的读速率(不包括从磁盘pagecache中读取的字节数，10秒均值)，单位KB/s。process_write实例对应进程向磁盘写数据的写速率(不包括向磁盘pagecache中写入的字节数，10秒均值)，单位KB/s。logical_read该实例在本次统计间隙（10秒）内逻辑读字节速率，单位KB/s。logical_write该实例在本次统计间隙（10秒）内逻辑写字节速率，单位KB/s。总结：本文从用户提出作业变慢这一问题作为出发点，从管理员视角，对已经发生的问题做定位定界，GaussDB 具备将瞬息万变的负载情况记录下来，提供回看数据库系统内部资源负载情况的能力。本文的管理员从作业、用户、DN三个层次，自上而下的顺序层层分析性能劣化的缘由。当然，读者可以从任意视角、以任意顺序去分析系统负载情况。本文重点是介绍了GaussDB 负载管理(WLM)提供的资源监视能力，结合所提供的监控项，能够分析出一些有趣的资源争抢现象，便于读者理解监控项的含义，方便读者对监控项的二次利用。那么，下一篇将会接着介绍负载管理(WLM)所提供的其它能力，如：存储空间管理、计算资源管理等，敬请期待，谢谢。原文链接：https://bbs.huaweicloud.com/blogs/177679【推荐阅读】【最新活动汇总】DWS活动火热进行中，互动好礼送不停（持续更新中）  HOT  【博文汇总】GaussDB(DWS)博文汇总1，欢迎大家交流探讨~（持续更新中）【维护宝典汇总】GaussDB(DWS)维护宝典汇总贴1，欢迎大家交流探讨（持续更新中）【项目实践汇总】GaussDB(DWS)项目实践汇总贴，欢迎大家交流探讨（持续更新中）【DevRun直播汇总】GaussDB(DWS)黑科技直播汇总，欢迎大家交流学习（持续更新中）【培训视频汇总】GaussDB(DWS) 培训视频汇总,欢迎大家交流学习（持续更新中）扫码关注我哦，我在这里↓↓↓

【摘要】 负载管理功能概述及全景介绍。DWS工作负载管理概述        在实际的业务场景中，使用DWS的客户可能会同时使用多个用户同时运行查询作业，这其中有些查询可能会非常复杂，此时如果对数据库资源未做控制，这些复杂作业的查询容易占用大部分的集群资源并长时间运行，从而影响其他查询的性能，使其不得不等待哪些复杂作业执行完成。                                      其实在上述场景中，我们完全可以对这些执行复杂作业的用户进行分组，对这些用户进行合理的资源限制，使在可接受的执行时间范围内使用一定的资源执行这些复杂查询，同时划分出部分资源给那些查询消耗没那么大的用户，这样在部分用户执行复杂作业的同时，另一部分用户的作业也不会受到太大影响。                                                               这就是DWS工作负载管理多队列资源管控的思想模型，客户可以根据自己的业务特点预先创建好多个工作负载队列，对每个队列配置好可以使用的资源上限，然后为每种业务创建好数据库用户并添加到对应的队列中，这样每次这些不同的用户在提交作业的时候都会被分配到对应的队列中，只能使用该队列中拥有的资源执行作业，队列资源不足时，该查询将在该队列中排队等待执行，各个队列之间资源个各自隔离，各不冲突，这样当一些数据库用户在自己队列中执行一些非常耗时的查询作业时，其他用户在各自的队列同时在执行一些简单或者有自己业务特点的作业，这些作业互不干扰。                                                                工作负载管理功能以队列为资源承载点，目前可以配置队列的CPU时间片占比、内存占比、并发（复杂查询并发数）以及磁盘空间大小（永久表空间）等资源。        CPU资源配比为队列可使用的最小时间片占比，当某个队列A的CPU负载超限并且有某个队列B恰好空闲时，队列A可以暂时使用空闲队列B的CPU资源，但是一旦空闲队列B开始对CPU资源有诉求时，将会收回“出借”给队列A的CPU资源。这种CPU控制方式我们称之为CPU配额控制，即可以保证至少有配比的资源可用。        DWS在创建集群时会根据集群中的节点规格为每个DN计算好可用的内存大小max_process_memory，DN在启动时会一次性申请max_process_memory大小的内存，DWS会在此基础上，根据每个队列的内存配比，对作业使用的内存进行限制。队列中所有数据库用户共享队列内存，并且执行作业可消耗的内存资源不超过队列的内存配比。        DWS目前只支持永久表空间的存储资源限制，队列中所有数据库用户共享队列的存储资源，并且可使用的永久表空间大小不超过队列配置的存储资源大小。        队列的并发数指的是队列内多有数据库用户可同时执行的作业数，作业数达到并发数限制之后，再提交的作业会在队列中排队等待执行。DWS负载管理页面介绍页面概览        DWS负载管理页面主要包括工作负载管理配置区域、工作负载队列列表区域以及工作负载队列详情展示区域，工作负载管理配置用来管理工作负载功能的全局配置，包括工作负载开关和全局最大并发数的配置（每个CN的最大并发数）；工作负载队列列表区域显示所有已创建的工作队列，可以在这里添加队列；队列详情区域包括队列的短查询配置、资源配置、异常规则配置以及队列中数据库用户的管理。添加队列        添加一个工作负载队列并配置相应的资源      修改队列        修改一个队列资源配比        向队列中添加数据库用户        向队列中添加数据库用户，以限制该用户执行作业时消耗的资源占比        从队列中移除数据库用户        从队列中将已添加的某个数据库用户移除，每个数据库用户只能添加到一个队列中，从队列中移除之后可再添加至其他队列中                作为工作负载管理系列的开端，以上就是DWS工作负载管理的基本使用场景介绍以及基础功能概览，后续我们会陆续推出对CPU、内存、并发、磁盘等单项资源管控机制深度解密的系列博文，敬请关注。原文链接：https://bbs.huaweicloud.com/blogs/174999【推荐阅读】【最新活动汇总】DWS活动火热进行中，互动好礼送不停（持续更新中）  HOT  【博文汇总】GaussDB(DWS)博文汇总1，欢迎大家交流探讨~（持续更新中）【维护宝典汇总】GaussDB(DWS)维护宝典汇总贴1，欢迎大家交流探讨（持续更新中）【项目实践汇总】GaussDB(DWS)项目实践汇总贴，欢迎大家交流探讨（持续更新中）【DevRun直播汇总】GaussDB(DWS)黑科技直播汇总，欢迎大家交流学习（持续更新中）【培训视频汇总】GaussDB(DWS) 培训视频汇总,欢迎大家交流学习（持续更新中）扫码关注我哦，我在这里↓↓↓