GaussDB (DWS)时序数仓对接Grafana 方案【摘要】 本方案指导用户配置Grafana,实时展示GaussDB(DWS)实时数仓中的数据，方案中采用存储过程构造模拟数据，真实场景下请接入真实数据。一、Grafana 软件部署(windows版)Grafana下载地址：https://grafana.com/grafana/download?platform=windows下载完成后，在windows路径下解压文件grafana-7.4.3.windows-amd64.rar：进入bin目录双击grafana-server启动服务Grafana登录地址：http://localhost:3000 默认用户名及密码：admin/admin,第一次登陆会提示修改密码，登陆后页面如下：二、GaussDB(DWS)对接Grafana，展示实时数据       1.Data Studio登录GaussDB(DWS)集群，创建用户、数据库及测试表--创建用户create user <USER> password '********';--创建数据库create database <DATABASE> owner <USER> encoding='utf-8' TEMPLATE template0;--赋予用户<USER> 模式public权限GRANT ALL PRIVILEGES ON SCHEMA public TO <USER>;备注：命令中用户、数据库等信息根据真实场景替换2.创建测试表，构造时序数据1）创建测试表Data Studio上使用新建的<USER>用户登录<DATABASE>数据库创建测试表，并构造时序数据创建测试表：drop table if exists public.test;create  table if not exists public.test(,tag_column      text  TSTag,Field_column    double precision  TSField,time        timestamp without time zone  TSTime)with (TTL='7 days', PERIOD = '1 day', orientation=TIMESERIES);语法介绍：TSTag：维度属性字段TSField：指标属性字段TSTime：时间属性字段TTL：数据生命周期，此表数据生命周期为7天PERIOD：自动创建分区间隔，此表分区按照1天间隔创建Orientation：表属性，TIMESERIES说明是时间序列表 1）创建造数程序创建存储过程insert_data()，模拟时序数据入库CREATE OR REPLACE PROCEDURE insert_data(v_number bigint)ASDECLARE  v_insert_test_string VARCHAR2(4000);  var_count               bigint;BEGIN  var_count               :=   0;  v_insert_test_string :=             'insert into public.test(                                            ,tag_column                                            ,Field_column                                            ,time                                          )                                            values(                                          ,''fioawhefawief''                                            ,random()                                            ,clock_timestamp()                                          );';  while var_count <   v_number loop    EXECUTE IMMEDIATE   v_insert_test_string;    var_count :=   var_count+1;    pg_sleep(5);    commit;  end loop;END;/执行存储过程，执行数据插入1000次，每5s插入一次call insert_data(1000);  2.Grafana配置Grafana中配置DWS数据源àData Sources点击 Add data source选择PostgreSQL数据源配置DWS集群信息Save&Test保存Database Connection OK 说明连通性测试成功3)         配置时序图标展示数据点击+Add new panel配置数据源，选择$DWS配置区配置要展示的时序数据，如下图：可切换为SQL模式配置完成后点击apply应用此配置页面可以选择时序数据展示的时间区间及刷新频率 

【摘要】 pooler连接池介绍。一、pooler连接池是什么？pooler连接池是GaussDB CN进程内保存与其他GaussDB进程数据连接的数据结构，主要作用是连接复用，节省建连、认证、对端线程启动初始化开销。如上图所示，CN的pooler连接池中会保存与其他CN/DN的连接，每一个连接在对端会对应一个postgres工作线程。postgres工作线程是带状态属性的，如database，所以可以认为pooler连接池中的连接也是带属性的。不同属性间的连接是不能复用的，如上图所示，按不同属性切分为pool A/B/C等连接池。每个连接池中会存有连接往不同节点的空闲连接的数组，提供接口给外部使用或放入连接。CN上的postgres工作线程在需要连接其他节点时，会创建一个本地agent，尝试从pooler连接池取跟本线程相同属性的空闲连接，pooler如果没有空闲连接，就会新建一个连接。连接交给agent后，可以视为线程私有。在线程退出时，agent才会将连接还给pooler。注意：enable_stateless_pooler_reuse为on时，连接只按database区分连接池；enable_stateless_pooler_reuse为off时，连接按database+user+option区分连接池。二、怎么查看pooler连接池可以连接CN后通过pg_pooler_status查看，如下图：一般pooler连接池中的连接会非常多，可以按不同字段group by查看某个db pool池中的连接情况，或连往某个node的连接情况，如：select database,user_name,node_name,in_use,count(*) from pg_pooler_status group by 1, 2, 3 ,4 order by 5 desc limit 50;三、pooler连接池相关问题定位1，空闲连接太多导致DN线程超过max_connectionsDN上报错误信息：FATAL :dn_6011_6012 :[FATAL] Already too many clients. active/non-active: 998/1069/3 表明DN上2000个线程用满了，但有1069个空闲线程，此时可以通过在各个CN上查询pooler视图，统计连接此DN的空闲连接，确认问题。并通过手动clean connection清理空闲连接。CLEAN CONNECTION TO ALL FORCE FOR DATABASE postgres;GaussDB内核8.0.0版本已支持自动清理空闲连接功能。2，查询性能慢，查看CN pg_thread_wait_status视图显示大量建连状态"pooler create conn"大量pooler建连状态，说明空闲连接不够用。需要先确认当前的空闲连接状态：select in_use,count(*) from pg_pooler_status group by 1 order by 2 desc where database='XXX' and node_name='XXX';如果空闲连接和非空闲连接都很少，说明连接用完即销毁了。需要确认pooler连接池开关参数cache_connection=on，并确认CN日志没有报错。如果非空闲连接很多，空闲连接很少，说明并发太大，连接都在使用中，需要降低并发，或调大max_pool_size。原文链接：https://bbs.huaweicloud.com/blogs/200909【推荐阅读】【最新活动汇总】DWS活动火热进行中，互动好礼送不停（持续更新中）  HOT  【博文汇总】GaussDB(DWS)博文汇总1，欢迎大家交流探讨~（持续更新中）【维护宝典汇总】GaussDB(DWS)维护宝典汇总贴1，欢迎大家交流探讨（持续更新中）【项目实践汇总】GaussDB(DWS)项目实践汇总贴，欢迎大家交流探讨（持续更新中）【DevRun直播汇总】GaussDB(DWS)黑科技直播汇总，欢迎大家交流学习（持续更新中）【培训视频汇总】GaussDB(DWS) 培训视频汇总,欢迎大家交流学习（持续更新中）扫码关注我哦，我在这里↓↓↓

【摘要】 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) 培训视频汇总,欢迎大家交流学习（持续更新中）扫码关注我哦，我在这里↓↓↓