DIS支持将源数据类型为JSON格式的数据转储至DWS。转储前，需要配置源数据Schema。源数据Schema，即用户的JSON数据样例，用于描述JSON数据格式。DIS可以根据此JSON数据样例生成Avro schema, 将通道内上传的JSON数据转换为Parquet或CarbonData格式。参考创建源数据Schema，创建源数据Schema。如下以添加转储任务时创建源数据Schema为例进行说明。选择源数据类型是Json的通道。在通道详情页面的“转储任务”页签，单击“添加转储任务”。转储服务类型选择DWS，通过导入文件的方式配置源数据Schema。输入源数据样例，单击“转换源数据样例”并提交，生成源数据Schema。配置Schema属性过滤功能。说明： schema过滤功能，只针对源数据schema根节点或一级子节点非array类型，才有效。即管理源数据Schema创建的源数据schema，满足根节点或一级子节点非array类型，界面才呈现此配置。打开Schema过滤开关。在源数据属性名列表中，勾选对应的属性名，完成DWS表中指定列的映射。说明： 源数据属性名列表中的属性由源数据Schema的name字段生成，匹配DWS的列名称。如图2所示，源数据属性名只选择id，即少于对应表的总字段。DWS侧创建集群，并执行如下命令创建表。CREATE TABLE dis_test3(id TEXT,dev TEXT,online BIGINT,module TEXT default 'a',logTime TEXT,appId TEXT,event TEXT);DIS侧转储数据至DWS成功后，登录集群数据库查询dis_test3表格数据，可看到仅id列和module列插入数据，其中module列是默认数据。

一 、GaussDB(for MySQL)简介华为云GaussDB（for mysql）是华为云自主研发的最新一代云原生数据库，采用计算存储分离、日志即数据的架构设计。通过IO卸载、日志压缩合并、批量处理、软硬件垂直整合等技术，使数据库性能方面有了大幅提升。同时存储层采用多副本，多az部署，增强数据可靠性。具备极致可靠、极致性价比、多为扩展、完全可信等诸多特性。    GaussDB（for mysql）采用了计算存储分离、日志即数据的架构，一部分计算能力下推到存储层。存储层需要通过consolidation不断将写入的日志应用到页面上，从而将日志回收掉。另外SQL层从存储层读取页面时，也需要将日志回放到相应的版本从而获得对应版本的页面。如果每次都从磁盘读取页面，IO时延较大，这里将成为整个回放流程的瓶颈。根据数据库一贯的做法，我们需要一个缓存（bufferpool），把经常访问的页面放在缓存中，从而加快页面读取的速度。但是存储层能够分配给bufferpool的资源非常有限，我们需要根据bufferpool的使用特点设计一个高效的缓存策略。二、一些常见的缓存淘汰算法  缓存一般从以下三个特征进行描述：命中率返回正确结果数/请求缓存次数，命中率问题是缓存中的一个非常重要的问题，它是衡量缓存有效性的重要指标。命中率越高，表明缓存的使用率越高。最大元素（或最大空间）缓存中可以存放的最大元素的数量，一旦缓存中元素数量超过这个值（或者缓存数据所占空间超过其最大支持空间），那么将会触发缓存启动清空策略根据不同的场景合理的设置最大元素值往往可以一定程度上提高缓存的命中率，从而更有效的时候缓存。淘汰（替换）策略如上描述，缓存的存储空间有限制，当缓存空间被用满时，如何保证在稳定服务的同时有效提升命中率？这就由淘汰（替换）策略来处理，设计适合自身数据特征的淘汰策略能有效提升命中率。因此，选择一个适合使用场景的淘汰（替换）策略非常重要，能够大大提升缓存命中率，从而加速业务处理。缓存的淘汰（替换）根据访问模式可以分为基于时间或者访问频率两类，下面分别对这两类进行详细描述。    基于访问时间：此类算法按各缓存项的被访问时间来组织缓存队列,决定替换对象，如LRU。    基于访问频率：此类算法用缓存项的被访问频率来组织缓存。如LFU、LRU-2、2Q、LIRS。1.       LRU基本思想：如果数据最近被访问过，那么将来被访问的几率也更高常见实现方法：一般采用unordered_map+list来实现，访问数据时，直接从unordered_map通过key在O(1)时间内获取到所需数据。有新数据时，插入到链表的头部；当缓存命中时，也将数据移动到链表头部；当缓存满时将链表尾部的数据丢弃。命中率分析当存在热点数据时，LRU的效率很好，但偶发性的、周期性的批量操作会导致LRU命中率急剧下降，缓存污染情况比较严重。Mysql对朴素LRU算法的改进：由于朴素的LRU算法会存在缓存污染问题，若直接读取到的页放入到LRU的首部，那么某些SQL操作可能会使缓冲池中的页被刷新出，从而影响缓冲池的效率。常见的这类操作为索引或数据的扫描操作。这类操作需要访问表中的许多页，甚至是全部的页，而这些页通常来说又仅在这次查询操作中需要，并不是活跃的热点数据。如果页被放入LRU列表的首部，那么非常可能将所需要的热点数据页从LRU列表移除，而在下一次需要读取该页时，InnoDB存储引擎需要再次访问磁盘。解决方案：InnoDB存储引擎引入了另一个参数来进一步管理LRU列表，这个参数是Innodb_old_blocks_time，用于表示页读取到mid位置后需要等待多久才会被加入到LRU列表的热端。链表按照5:3的比例分为young区和old区，新加入的数据放在old区，若old区的数据在LRU链表中存在时间超过了1秒，则将其移动到链表头部，如果数据在LRU old区链表中存在的时间少于1秒，则保持位置不变，淘汰时优先淘汰old区的数据。这样可以避免全表扫描对LRU链表的污染，全表扫描的冷数据很快会被淘汰出去。2.       LFU基本思想：如果数据过去被访问多次，那么将来被访问的频率也更高。注意LFU和LRU的区别，LRU的淘汰规则是基于访问时间，而LFU是基于访问次数常见实现方法：与LRU类似，LFU一般也采用unordered_map+list来实现，访问数据时，直接从unordered_map通过key在O(1)时间内获取到所需数据。有新数据时，插入到链表的尾部；  当缓存命中时，增加该key的引用计数，链表按照引用计数排序。为了避免节点在链表中频繁移动，一般会将链表划分为多个区域或者使用多个链表，如果引用计数落入某个范围，将该节点加入到相应的链表中，当引用计数超出阈值时将当前节点移动到上一个区间的链表。当缓存满时将引用计数最小的区域的数据丢弃。  命中率分析LFU命中率要优于LRU，且能够避免周期性或者偶发性的操作导致缓存命中率下降的问题，但LFU需要记录数据的历史访问记录，一旦数据访问模式改变，LFU需要更长时间来适用新的访问模式，即LFU存在历史数据影响将来数据的"缓存污染"问题。3.       LRU-KLRU-K中的K代表最近使用的次数，因此LRU可以认为是LRU-1。LRU-K的主要目的是为了解决LRU算法"缓存污染"的问题，其核心思想是将"最近使用过1次"的判断标准扩展为"最近使用过K次"常用实现如下：数据第一次被访问，加入到访问历史列表；如果数据在访问历史列表里后没有达到K次访问，则按照LRU淘汰；当访问历史队列中的数据访问次数达到K次后，将数据索引从历史队列删除，将数据移到缓存队列中，并缓存此数据，缓存队列重新按照时间排序；缓存数据队列中被再次访问后，重新排序；需要淘汰数据时，淘汰缓存队列中排在末尾的数据，即淘汰"倒数第K次访问离现在最久"的数据。命中率分析：LRU-K具有LRU的优点，同时能够避免LRU的缺点，实际应用中LRU-2是综合各种因素后最优的选择，LRU-3或者更大的K值命中率会高，但适应性差，需要大量的数据访问才能将历史访问记录清除掉。LRU-K降低了"缓存污染"带来的问题，命中率比LRU要高。4.       2Q算法类似于LRU-2，不同点在于2Q将LRU-2算法中的访问历史队列改为一个FIFO队列，即2Q有两个缓存队列：FIFO队列和LRU队列常见实现方法：当数据第一次访问时，2Q算法将数据缓存在FIFO队列里面，当数据第二次被访问时，则将数据从FIFO队列移到LRU队列里面，两个队列各自按照自己的方法淘汰数据。命中率分析：2Q LRU-K类似，都是LRU的改进版，命中率比LRU要高，可以避免LRU污染带来的问题。上面介绍了4个常用的缓存淘汰算法，实现起来也不是很复杂。当然还有一些其他的算法，这里就不再介绍了，感兴趣的朋友可以查找资料学习一下。三、 GaussDB（for mysql）bufferpool的缓存策略GaussDB（for mysql）目前支持两种缓存淘汰策略：LRU和LFU，这两种淘汰算法都是改进过的。1.       改进的LFU算法：LFU在实现上采用unordered_map+list方式实现，访问数据时，直接从unordered_map通过key在O(1)时间内获取到所需数据。为了避免数据在链表中频繁移动，将链表按照引用计数分成多个区间，当缓存命中时，增加引用计数，若引用计数仍落在原来的区间，保持数据在链表中的位置不动，如果引用计数落入新的区间，将数据移动到相应位置。为了避免一些频繁访问的数据后面不再访问，但是引用计数很大，导致不能被淘汰，因此引入“老化”策略，每隔一段时间将引用计数值衰减一下，这样就可以将一些引用计数较大，但是当前不怎么访问的数据淘汰出去。一些被淘汰出去的数据我们还会在历史记录里面保留一段时间其对应的引用计数，下次该数据再次被加入缓存时，可以“投胎转世”，可以在上次的引用计数基础上开始计数。这样可以更精确的反应数据被访问的频率。LFU的缓存命中率较高，但是在“老化”的过程中需要对链表加锁，这样会阻塞其他地方的访问。2.       改进的LRU算法：与mysql的改进LRU算法类似，也是将链表划分为hot和cold两个区，数据第一次被加入时先放入cold区，当再次命中时移入hot区。淘汰时优先淘汰cold区的数据。同时我们引入了一个lockfree的队列，以免在flush page时对链表加锁，增强缓冲操作的并发度。四、下一步的改进虽然我们引入了改进版的LRU和LFU算法，但是在大数据量时，按照一些模拟分析数据，还有一定的改进空间。后面在两个算法的基础上进一步改进，提升缓存的命中率。

GaussDB(for MySQL)数据库在写入性能上，在业界同类产品中是最好的，这主要得益于GaussDB(for MySQL)在MySQL内核方面的诸多优化。其中有一项从“送快递”得来灵感的优化——事务异步提交，值得我们分析。背景我们先来看看MySQL 8.0的事务提交的大致流程图1 MySQL 8.0事务执行流程以上流程，是MySQL8.0对WAL原则的一种实现，这个流程意味着，任何一个事务的提交，一定要完成write buffer和flush to disk流程。然而那么这个流程中，有一个问题：每个服务器的CPU是有限的，服务器能处理的Thread也是有上限的，那么当我们的业务的并发数量，远远大于我们服务器能并行处理的数量时，那么后来的事务，只能等待前面的事务提交后才能被处理。在这之前，他们什么也做不了。因此，在大并发场景下，如何进一步提升线程的使用率，是大并发事物写入的一个关键。灵感来源于生活一个优化，并不是凭空想象出来的，有时候，往往来源于现实生活。下面，我们先来看看我们身边，和事务提交流程非常类似的一个例子：快递。现在的快递配送，一般一个快递员会负责一片区域，快递刚开始兴起时，数量不多，那么一个快递员基本上可以在规定时间内完成配送。图2 过去的快递配送但是，随着快递数量越来越多，一个快递员要在一个小区配送很长的时间，才能到下一个小区，常常导致了快递员无法准时的配送。在这个问题的催动下，随后，一个新的行业开始出现 – 快递驿站。图3 现在的快递配送快递的优化原理接下来，让我们来看下，快递驿站究竟解决了什么问题。快递的配送过程中，最耗时的，不是装货，不是卸货，而是电话和等待。配送一个小区的时间，取决于这个最后一个来取快递的人的时间，在最后一个人取完快递钱，快递员除了打电话，做不了其他任何事情（也没有办法通知下一个小区的人，因为最后一个人来取得时间是无法确定的）。那么这个等待的时间，对于快递员来说，就是一种浪费。快递驿站可以很大程度解决这个问题，快递员到了以后，只需要将快递卸货，即可前往下一个小区，剩下的事情，就可以由驿站的人员来完成，大大提升了快递员的配送效率。分析回过头来，我们看看数据库，如果把Transaction线程看做快递员，存储上的文件看做取快递的人，那么我们会发现两者有非常大的相似性。那么我们可以像快递配送优化那样去优化事务的处理流程吗？答案是可以的。图4 事务处理和快读配送非常类似根据快递驿站的优化原理，我们知道，快递驿站帮快递员免去了等待客户取货的时间，那么事务处理过程中，有没有等待的过程呢？答案是有的，存储的IO就是一个较长的等待。数据库使用经验丰富的开发人员来都知道，等待redo日志写入存储的磁盘IO性能，很大程度上决定了数据库的写入性能。对于现代数据库来说，尤其对于GaussDB(for MySQL)这样计算于存储分离的数据库，存储的IO耗时，在事务处理的总耗时中，占据了不小的比例，虽然有log buffer的合并写入，提升并发情况下的整体吞吐，但是如果在等待IO的这段时间中，这些线程能够去做别的事情（例如处理等待中的其他事务）。那么将会有进一步的性能提升。GaussDB(for MySQL)的优化既然找到了等待的点，那么我们就可以像快递配送的优化方法，为数据库，也创造一个“快递驿站”，让“快递驿站”来做等待的事情，而事务线程就可以去处理其他等待中的事务，让CPU不会“闲下来”。图5 GaussDB(for MySQL)的“快递驿站”如图5所示，GaussDB(for MySQL)当redo日志的flush to disk动作完成后，即可进行事务提交，但是此时并不应答客户端，而是直接处理下一个事务。同时使用少量”post comit worker线程”，来批量等待日志写入完成（等待的过程其实并不占用CPU），并应答客户端，这就可以让“等待”和“下一个事务的处理”并行化，让CPU“闲不下来”。实际测试图6 Sysbench write only 模型下写入性能测试根据实际测试，在标准的sysbench写入模型下，没有使用Post Commit时，极限性能是35万QPS左右，而使用Post commit后，可以到大42万以上的QPS，提升了20%的写入性能。

7月20日，华为云在TechWave技术峰会上正式发布了GaussDB系列新品，数据库战略全面升级，进一步满足政企客户业务需求，持续加速客户数字化转型进程。华为云数据库业务总裁苏光牛表示：“华为将持续战略投入数据库，布局全球7大区域囊括1000+数据库专家与人才。此次战略升级是华为云数据库积极构建高安全、高可靠、高性能的全场景云服务，拥抱开源生态的具体举措，华为云GaussDB数据库会持续打造多元生态服务，全方位满足客户的需求，加速政企客户数字化创新发展。”华为云数据库战略全面升级苏光牛表示，数据库是信息产业三个核心控制点和基础研究之一（硬件芯片、软件数据库与操作系统），也是华为鲲鹏计算产业与华为云的重要组成部分，同时也是支持华为内部业务正常运作并持续服务全球客户的数据底座不可或缺的关键组成。华为将继续战略投入，打造世界级数据库，保障业务连续性并为客户持续提供数据库服务。基于打造更好更丰富的数据库服务，华为云数据库在品牌和业务方面也进行了全面升级，华为云GaussDB重点打造涵盖关系型与非关系型在内的GaussDB系列全场景云服务，依托华为云与华为云Stack，以云服务方式持续为客户服务，提升交付与运维效率，帮助客户聚焦核心业务创新，快速提供创新技术和新服务。 华为云GaussDB系列新品商用发布华为云GaussDB是华为基于在电信、政企市场深耕10年+的数据库内核研发优化能力、对客户高可靠高性能诉求的理解，结合云的技术倾力打造的企业级分布式数据库。GaussDB将陆续推出兼容主流开放生态如MySQL等数据库服务和基于华为openGauss开源生态的GaussDB（openGauss）商业版本，满足政企客户高性能、高可靠、高安全的全场景数据库服务，开启数据库极速融合时代，加速政企智能升级。发布会上，华为云重磅推出了关系型数据库GaussDB（for MySQL）和非关系型数据库GaussDB NoSQL系列两大云原生数据库新品。GaussDB(for MySQL)基于华为最新一代DFV分布式存储，采用计算存储分离架构，支持1写15读的只读节点的极速扩展，最高支持128TB的海量存储，可实现超百万级QPS吞吐，单节点相比原生MySQL性能提升7倍，业界第一。GaussDB NoSQL拥有极强的多模数据管理能力，在并发读写能力、扩容时间缩、故障重构时间、备份效率、恢复效率等方面也都实现业界领先。华为云数据库还提供统一管控平台和接口，实现多业务数据融合，支撑多样化的应用服务。 华为云GaussDB系列数据库产品涵盖关系型和非关系型数据库场景，广泛应用于金融，泛政府、电信、能源、交通、医疗、物流、电商等行业，能满足客户对智能时代高并发事务实时处理、海量数据高效分析等全方位需求，持续加速客户数字化转型进程。目前GaussDB(for MySQL)、GaussDB(for Mongo)、GaussDB(for Cassandra)3款自研黑科技，现在体验优惠价6.7折起噢！活动链接：https://activity.huaweicloud.com/gaussdb.html

【直播时间】DevRun开发者沙龙直播时间：2020年8月14日 20:00~21:00【活动介绍】本期DevRun开发者沙龙，将由华为云数据库研发专家  GoldenJohn，为你揭秘GaussDB(for Mongo) 秒级水平扩展独家秘籍。凡报名参加线上直播或在本主题帖中留言的用户均可参与抽奖，奖品若干！ 【报名入口】点击下面链接或扫描微信二维码报名参加直播。报名链接：https://bbs.huaweicloud.com/signup/fa23d72deee34848ba261282a1648839报名二维码：【直播地址】1.微吼直播间：http://live.vhall.com/1823184392.华为云B站：http://live.bilibili.com/219454223.华为云斗鱼：https://www.douyu.com/huaweiyun4.华为云虎牙：https://www.huya.com/huaweiyun 【互动送好礼】满足下面的一个条件即可参与抽奖：1、报名参加直播。2、在本主题帖中跟帖，留言“GaussDB(for Mongo) 秒级水平扩展真牛”。3、在本主题帖中跟帖，留言“提问：xxx”、“建议：xxx”或“反馈：xxx”等。 【获奖规则】1、幸运奖：海纳斯小风扇，从报名入口完成报名的直播用户和本主题留言用户中，随机抽取若干名。2、互动奖：毕亚兹运动臂包，在本主题的留言中，选取最优秀的回帖若干名。3、同一个用户只有一个礼品。4、为保证公平公正，抽奖结果将在活动结束后7个工作日内本主题帖中发布，请报名和留言的伙伴关注社区内容。【礼品展示】【获奖用户】幸运奖：海纳斯小风扇Youhoo帕加尼风之子8866Jazzup小果果user_beifengwolfkdyhw59398218CHAOYING互动奖：毕亚兹运动臂包CharlesE孙小北hw46018172问道linghz666恭喜以上用户获得本期DevRun开发者沙龙直播社群互动奖，我们已私信您填写收件信息的链接，请您注意查看，我们会尽快发出奖品。如您未在8月27日之前提交获奖信息，视为您自动放弃。望周知。

目录：                  GaussDB Roach逻辑备份恢复原理gs_dump逻辑备份恢复工具roach逻辑备份恢复GaussDB Roach逻辑备份恢复实践                逻辑备份恢复支持、规格及约束         续备份、续恢复         逻辑备份删除         存储介质         容错支持         特殊表名         并行处理         最佳实践FAQ GaussDB Roach逻辑备份恢复原理：            1.  gs_dump逻辑备份恢复: 可以设置事务隔离级别。 gs_dump一致性备份：在单个database内保持一致，不同database之间无法保持一致，因为不同database之间需要切换connection，不能在不同database之间共享snapshot，因此只能在同一个database内保持一致性。 如果不保持一致。一个database数据量非常大，gs_dump备份时间会比较长，将会持有锁比较长的时间，对于一些需要ddl操作的database实例来说无法忍受。 解决方案：细粒度备份，而不要备份整个database，一次只备份一个table，调用gs_dump多次。如果多个表之间有关联，将这些表放入一个gs_dump操作中，用-t tablename来操作。但是这个-t其实是解决了依赖关系，本质上还是按照依赖顺序串行导出。一个单表数据量非常大，考虑分区表，也就是将数据进行了分片。否则这些表的ddl将会增加gs_dump之间的冲突。对于数据量非常大的databse实例，推荐使用PITR物理增量备份。 gs_dump并行备份: gs_dump版本>=9.3，server版本>=9.2，需要支持pg_export snapshot                                     n+1个连接，-j n是并行度，1是主节点的连接                                     对于版本<9.2，需要并行度和数据库一致性，在备份的时候不能做dml操作。             2.  roach逻辑备份恢复： GaussDB是一个分布式数据库，数据自动分片存储。GaussDB roach采用了基于单表粒度的备份恢复来实现逻辑备份，即一次只备份一个table，每次通过gs_dump导出table的ddl语句，并通过单独的外表方法（roach外表方法）来导出数据（不同表之间不保证数据一致性）。  GaussDB Roach逻辑备份恢复实践： 1. 逻辑备份恢复： 支持单表、多表（可以是不同schema的表）、schema、database级别逻辑备份。schema、database都默认转为多表逻辑执行（基于单表的串行实现），备份出schema、database内包含的所有表数据。可以从多表、schema、或者database逻辑备份中恢复出任意单张表或者多张表。 规格约束：不支持private table，nodegroup table， replication table，table has trigger/sequence表的备份恢复。                      对于表之间依赖关系，trigger，sequence，index等没有进行导出，只备份恢复数据。 单表： --tablename table  其中tablename可以是schema.table； schema默认为public，database默认为postgres单表备份：python $GPHOME/script/GaussRoach.py --master-port 9500 --agent-port 9600 --media-destination media_path  --metadata-destination metadata_path  --media-type DISK  --logging --logging-level INFO -t backup --tablename table [--schemaname schema] [--dbname database]              单表恢复：python $GPHOME/script/GaussRoach.py --master-port 9500 --agent-port 9600 --media-destination media_path  --metadata-destination metadata_path  --media-type DISK  --logging --logging-level INFO -t restore --tablename table [--schemaname schema] [--dbname database]  --backup-key bkpkey [--clean]/[--create] 多表： --table-list       --table-list选项与--tablename以及--schemaname不兼容；可以是不同schema中的表  tablelist文件内容示例：public.t1gauss.testT2Public."Temp"汉字表名cc.1a 多表备份：python $GPHOME/script/GaussRoach.py --master-port port_no --agent-port port_no --media-destination media_path  --metadata-destination metadata_path  --media-type DISK  --logging --logging-level INFO -t backup --table-list tablelist [--schemaname schema] [--dbname database]              多表恢复：python $GPHOME/script/GaussRoach.py --master-port 9500 --agent-port 9600 --media-destination media_path  --metadata-destination metadata_path  --media-type DISK  --logging --logging-level INFO -t restore --tablelist tablelist  [--dbname database]  --backup-key bkpkey [--clean]/[--create]  Schema： --schemaname  Schema规格约束： 其中系统级schema "dbms_job", "dbms_lob", "dbms_om", "dbms_output", "dbms_random", "dbms_redact", "dbms_sql", "sys", "utl_file", "utl_raw", "cstore"不支持备份恢复，都会报错退出。 Schema备份：python $GPHOME/script/GaussRoach.py --master-port port_no  --agent-port port_no --media-destination media_path  --metadata-destination metadata_path  --media-type DISK  --logging --logging-level INFO -t backup --schemaname schema [--dbname database]              Schema恢复：python $GPHOME/script/GaussRoach.py --master-port port_no --agent-port port_no --media-destination media_path  --metadata-destination metadata_path  --media-type DISK  --logging --logging-level INFO -t restore --schemaname schema  [--dbname database]  --backup-key bkpkey [--clean]/[--create] 其中-t restore --schemaname schema  --dbname database --backup-key bkpkey 可以从database级别逻辑备份中恢复出指定的schema Database：   --dbname        Database规格约束：其中系统级schema "dbms_job", "dbms_lob", "dbms_om", "dbms_output", "dbms_random", "dbms_redact", "dbms_sql", "sys", "utl_file", "utl_raw", "cstore"不支持备份恢复，都会被默认过滤掉。 Database备份：python $GPHOME/script/GaussRoach.py --master-port port_no --agent-port port_no --media-destination media_path  --metadata-destination metadata_path  --media-type DISK  --logging --logging-level INFO -t backup --dbname database             Database恢复：python $GPHOME/script/GaussRoach.py --master-port port_no --agent-port port_no --media-destination media_path  --metadata-destination metadata_path  --media-type DISK  --logging --logging-level INFO -t restore --dbname database  --backup-key bkpkey [--clean]/[--create]  2. 逻辑续备份、续恢复： 逻辑备份续备份、续恢复。其中续备份对于已经进行过校验的表名不会继续校验，以提升效率。如果在续备份时某些表已经被过滤掉，没有实际备份，而用户又对表对象属性进行了修改，希望能够得到备份，则考虑重新进行单表、多表重新备份，或者等待下次备份即可。 多表、schema、database等均支持续备份、续恢复，仅在备份、恢复失败之后才需要做。 续备份： --resume-backup --backup-key bkpkeypython $GPHOME/script/GaussRoach.py --master-port port_no --agent-port port_no --media-destination media_path  --metadata-destination metadata_path  --media-type DISK  --logging --logging-level INFO -t backup --schemaname schema [--dbname database] --resume-backup  --backup-key bkpkey 续恢复： --resume-restore--backup-key bkpkeypython $GPHOME/script/GaussRoach.py --master-port port_no --agent-port port_no --media-destination media_path  --metadata-destination metadata_path  --media-type DISK  --logging --logging-level INFO -t restore --schemaname schema  [--dbname database]  --backup-key bkpkey [--clean]/[--create] --resume-restore  3. 逻辑备份删除： 通过指定backupkey来删除，cascade是将所有backupkey全部删除。 python $GPHOME/script/GaussRoach.py --master-port port_no --media-destination /home/dulong/backup/media  --metadata-destination /home/dulong/backup/metadata  --media-type DISK  --logging --logging-level INFO -t delete --cascade  --backup-key bkpkey  4. 存储介质：一般指定DISK，兼容NBU、OBS等多种存储方式  5. 容错支持：对于不支持的表会进行过滤，不会影响其他表的正常备份恢复。 恢复到新集群：默认备份恢复database是postgres，可以指定其他database。恢复到新集群需要加--create；而恢复到老集群则最好加--clean，会将原有数据清理删除再恢复已防止数据冗余；不加则直接恢复数据，可能会导致冲突或者数据冗余。 同样的，如果一个数据库中某些表已经被drop掉，恢复时这些表需要--create，而其他表需要--clean。用--clean时恢复时另一部分需要--create的表会被过滤掉，反之亦然。  6. 特殊表名： 汉字表名不需要加双引号 大写表名，大小写表名，首字母为数字，含有$, . 等特殊字符在对象中等都为特殊对象名。其中除了含大写字符的不能自动识别外，其余均可自动识别并加上双引号。表名含有. 时，默认. 前为schema名称，如果该.就是表名的一部分，则需要加两侧加双引号，以保证可以识别正确。 特殊对象名称需要加双引号，例如schema名为 a.b，表名为 'public.'，传入必须加双引号，如‘“a.b”’，‘“public.”’,双引号外侧再加单引号是为了保证正确传入了对象名，如果传入“public.”，内部传入其实为'public.'；如果对象名内有大写字符，也需要加双引号，否则内核会默认转为小写。 PS: 尽量不要数据库对象内加各种特殊符号。  7. 并行处理： Gauss数据库为分布式数据库，默认进行了分片处理。每个数据库节点上有一个或多个datanode，一般一个datanode对应一个磁盘，而我们每个节点推荐>=2个datanode保证高可用等。数据落盘为每个datanode同时向磁盘写数据，不同datanode并行的向磁盘写入数据。 每个datanode内为串行的处理表数据，一个表数据处理完之后再处理下一个表（8.1）。在8.1及8.2后续版本中，将实现单个datanode的多个表并行的处理数据（自定义并发度）。  8. 最佳实践： 设置常规作业，利用多表逻辑备份业务中比较重要的表，schema及database备份往往将所有表备份，重要程度不高的表备份恢复仍然有较高开销。对常规作业设置优先级，按优先级进行不同时间间隔的备份与恢复。Database级别逻辑备份将备份整库数据，如果database实例内表数量大且规模大，性能会比较差（单个datanode内串行备份恢复）；推荐使用PITR物理增量备份来替代Database逻辑备份。如果逻辑备份恢复中途失败，尽可能使用续备份、续恢复以完成作业。续备份只备份未备份成功的表，且对已经校验过的表将不会进行二次校验，而现行的校验为串行校验，表数量比较大的时候开销仍然较大；续恢复将恢复未恢复成功的表。在8.1以及8.2后续版本中，将实现更为细粒度的续备份、续恢复，备份效率将更为提高。合理设置压缩算法和压缩率  FAQ：     1. Why not gs_dumpall?The  gs_dumpall program exports all databases, one after another, into a single script file, which prevents you from performing the parallel restore. If you back up all      databases this way, the restore process will take more time.The processing of dumping all databases takes longer than each individual one so you do not know which dump of each database relates to a specific point in time.              If you have a good reason to use the gs_dump all to backup all databases, the following is the command:          gs_dumpall -U postgres > c:\gsbackup\all.sql         2. Why not gs_dump?        gs_dump虽然灵活，但是数据导出按照sql或者二进制，仅支持在单节点导出。数据量较大的情况下性能往往较差，且不易扩展。      3.一致性？   数据的一致性要求在备份恢复过程中要求并不一定很高，而对于性能，扩展性，灵活性等均有一定要求。因此牺牲一定一致性来换取更好的性能，易用性等，对于实际场景往往可以接受。    

-- 使用SQL函数简单适配 CREATE OR REPLACE FUNCTION public.to_slngle_byte(str text) RETURNS text AS $$ SELECT translate(str, 'ＡＢＣＤＷＦＧＨＩＪＫＬＭＮＯＰＱＲＳＴＵＶＷＸＴＺａｂｃｄｅｆｇｈｉｊｋｌｍｎｏｐｑｒｓｔｕｖｗｘｙｚ１２３４５４６７８９０＋－＊／．￥',  'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz1234567890+-*/.$') $$ LANGUAGE SQL; -- 如有更高性能需求，需要使用C函数实现。源码可参考开源orafce实现，具体编译方式参见DWS产品文档 -- ---- test case -- select public.to_slngle_byte('ＡＢＣＤＷＦＧＨＩＪＫＬＭＮＯＰＱＲＳＴＵＶＷＸＴＺ'); select public.to_slngle_byte('ａｂｃｄｅｆｇｈｉｊｋｌｍｎｏｐｑｒｓｔｕｖｗｘｙｚ'); select public.to_slngle_byte('１２３４５４６７８９０＋－＊／．￥');

0      引子对Query执行者来说，他们的工作就是在客户端输入Query，然后翻翻报纸、喝杯咖啡就个大蒜，然后偷瞄一下执行结果是否已经返回。有时候，翻完报纸、喝完咖啡，发现数据还没有递交给我们，我们就很着急，就想知道，这家伙到底在私底下（后台）捣鼓啥呢，这么久还没给个信儿~~。于是我们就想了解下，他们到底是怎么工作的，有没有办法帮帮他们，这就需要我们了解SQL引擎和优化器的工作原理了。简单来说优化器的工作机制类似于我们常用的X德导航，定好罗马（执行目标）这个目的地，X德自动规划出N多可行路径（可实现执行目标的Path），通过各种对比计算后X德给我们推荐一条时间最短的路（执行代价最小的）。对于优化器来说执行代价最小是怎么定义的呢，答曰通过代价模型和统计信息。那么什么是统计信息、统计信息记录了什么、为什么要收集统计信息、怎么收集统计信息以及什么时候收集统计信息，且听我娓娓道来1      WHAT：什么是统计信息统计信息是指数据库描述表或数据特征的信息，常见的有表记录条数、页面数等描述表规模的信息，以及描述数据分布特征的MCV(出现频次比较高的值)、HISTOGRAM（值的数据区间分布特征）、CORRELATION（数值存储顺序与数据大小的一致性关系）等信息。本文中通过如下用例来展示统计信息是如何表现表的数据特征的DROP TABLE public.test;CREATE TABLE public.test(a int, b int, c int[]);INSERT INTO public.test VALUES (generate_series(1, 20), generate_series(1, 1200));INSERT INTO public.test VALUES (generate_series(1, 1200), generate_series(1, 1200));UPDATE public.test SET c = ('{' || a || ','|| a || '}')::int[] WHERE b <= 1000;UPDATE public.test SET c = ('{' || a || ','|| b || '}')::int[] WHERE b > 1000;ANALYZE public.test;2     WHY：为什么需要统计信息先我们看下SQL引擎从接收客户端SQL语句到执行SQL语句需要经历的关键步骤，以及各个流程中可能对执行产生影响的因素。1)  词法&语法解析按照约定的SQL语句规则，把输入的SQL语句从字符串转化为格式化结构(Stmt)，如果SQL语句存在语法错误，都会在这个环节报错。2)  语义解析语义解析类似一个翻译器，把外部输入的可视化的对象翻译为数据库内部可识别的对象（比如把Stmt中以字符串记录的表名称转化为数据库内部可识别的oid），如果语句存在语义错误(比如查询的表对象不存在)，数据库会在这个环节报错。3)   查询重写根据规则将“语义解析”的输出等价转化为执行上更为优化的结构，比如把查询语句中的视图逐层展开至最低层的表查询。4)  查询优化数据库确认SQL执行方式、生成执行计划的过程5)  查询执行根据执行计划执行SQL并输出结果的过程 整个执行流程中，优化器决定了查询语句的具体执行方式，对SQL语句的性能起着关键性的作用。数据库查询优化器分为两类：基于规则的优化器(Rule-Based Optimizer，RBO) 和基于代价的优化器(Cost-Based Optimizer，CBO)。RBO是一种基于规则的优化，对于指定的场景采用指定的执行方式，这种优化模型对数据不敏感；SQL的写法往往会影响执行计划，不了解RBO的细则的人员开发的SQL性能不可控，因此RBO逐渐被抛弃，目前GaussDB等数据库厂商的优化器都是CBO模型。CBO模型是根据SQL语句生成一组可能被使用的执行计划，并估算出每种执行计划的代价，最终选择选择一个代价最小的执行方式。数据库执行SQL语句的时候，会把执行拆分为若干步骤，如下SQLselect *from t1 join t2 on t1.a=t2.bwhere t1.b = 2 and t2.a = 3;在具体执行的时候会拆分为表扫描和表关联两个主要查询动作。这两个查询动作都存在多种执行方式，比如表扫描均存在SeqScan、IndexScan、IndexOnlyScan、BitmapScan等多种执行方式、表关联存在NestLoop、HashJoin、MergeJoin三种执行方式，那么在具体的业务场景下什么样的查询动作才是代价最小的执行方式，这就是优化器的核心工作。CBO主要工作原理是通过代价模型(Cost Model)和统计信息估算每种执行方式的代价，然后选择一种执行代价最优的执行方式。这里面代价模型是核心算法逻辑，统计信息是cost计算的数据源，二者配合完成cost计算；如果统计信息缺失，计算时代价模型会使用默认值来计算cost，当然这时cost会跟真实值存在较大偏差，大概率会出现选择非最优执行计划的情况，因此统计信息是CBO模型中 cost计算的数据输入，是CBO最核心的科技之一。3      WHERE：统计信息在哪里3.1      表规模信息系统表pg_class中的reltuples和relpages两个字段能够反映表规模信息信息，其中relpages记录了表数据存储到几个page页里面，主要用于表从存储接口扫描数据的代价计算；reltuples记录了表记录条数，主要用于扫描结果集行数估算。 查询pg_class中的表规模估算信息，显示表为2400行单表全量数据查询，通过explain查看表规模估算，显示表扫描输出行数估算为2400 3.2      单列统计信息单列统计信息是指表的单列的数据特征信息，存储在系统表pg_statistic中。因为pg_statistic会存储一些关键采样值来描述数据特征，因此pg_statistic数据是敏感的，只有超级用户才可以访问pg_statistic。通常我们推荐用户使用查询系统视图pg_stats来查询当前用户有查询权限的表的统计信息，同时pg_stats信息的可读性更强，pg_stats字段信息如下名称描述schemaname统计对象所在的namespace名tablename统计对象名attname统计列的名称inherited如果为真，那么统计分析时采样样本包括继承表数据null_frac该字段NULL值的个数比率avg_width该字段非NULL值的平均字节宽度n_distinct字段中非NULL值的distinct值。如果大于0，则表示实际distinct值个数；如果小于0，则它的绝对值表示distinct值占全部非NULL值个数比例。例如-1表示distinct值的数目与行数相同n_dndistinct第一个DN上该字段非NULL值的distinct值，取值含义与n_distinct一样most_common_vals高频非空值按照出现的频次排序的列表，列表中的值我们一般简称为MCV值most_common_freqs对应每个MCV值出现的频率列表，列表中的每个值表示对应的MCV值出现的次数与表的总记录数(包含NULL值)的比例histogram_bounds去除NULL值和most_common_vals之外的其它值按照’<’操作符排序，然后按照个数等分的边界值。如果此字段的数据类型没有<操作符或取值都在most_common_vals中出现过，则这个字段为NULLcorrelation字段值的物理行序和按照’<’排序的逻辑行序的相关性，我们一般称之为排序相关性，取值范围为-1到+1；数据越按照’<’操作符排序，取值越接近1；数据越按照’>’操作符排序，取值越接近-1。取值越接近于-1或者+1，说明索引扫描时引入的随机IO开销越小，索引扫描的随机IO的cost值也越小。如果字段数据类型没有<操作符，则这个字段为NULL。most_common_elems数组类型的最常用的非空元素的列表，类似most_common_vals，但记录的不是字段值，而是构成数组字段的元素most_common_elem_freqsmost_common_elems中每个元素出现的频次与该字段非NULL值的记录数的比例，同时还在字段尾部依次追加了元素的最小值、最大值、NULL值个数的比例，所以此字段元素的个数总是比most_common_elems元素的个数多3个elem_count_histogram数组类型非NULL distinct值的直方图信息，末尾为平均唯一值个数查询表public.test的a列的数据特征信息如下通过统计新可以看出public.test的a列的NULL值比例为0，存在120个distinct值， 1~20是MCV值，每个出现的概率是0.0254167；21~1200出现在在直方图统计信息中； 以查询语句“SELECT count(1) FROM public.test WHERE a < 44;”为例说明统计信息在优化过程中行数估算场景下的作用a)   所有MCV值均满足a < 44，所有MCV值的比例为0.0254167 * 20 = 0.5083340b)   44为直方图中第三个边界，直方图中满足a < 44的值的比例为(1-0.5083340)/100 *(3-1)= .0098333200那么表中满足a<44的tuples的个数为1243.6015680 ≈1244，通过explain打印执行计划如下 3.3      扩展统计信息扩展统计信息存储在系统表pg_statistic_ext里面，当前只支持多列统计信息这一种扩展统计信息类型。pg_statistic_ext会存储一些关键采样值来描述数据特征，因此pg_statistic_ext数据是敏感的，只有超级用户才可以访问pg_statistic_ext，通常我们推荐用户使用查询系统视图pg_ext_stats来查询当前用户有查询权限的扩展统计信息。名称描述schemaname统计对象所在的namespace名tablename统计对象名attname扩展统计信息涉及列编号的数组inherited如果为真，那么统计分析时采样样本包括继承表数据null_frac该字段组合中所有字段均为NULL值的个数比率avg_width该字段组合的平均字节宽度n_distinct字段中非NULL值的distinct值。大于零的数值是多字段组合的不同值的实际数，小于零是多字段组合的distinct值占全部非NULL值个数比例的负数n_dndistinct第一个DN上的n_distinct值most_common_vals字段组合里最常用数值的列表，此字段要求多列的每个列都不存在NULL值most_common_freqsmost_common_vals中每个值出现的频率列表，列表中的每个元素描述了most_common_vals中对应值出现的次数与表的总记录数(包含NULL值)的比例most_common_vals_null高频非空值按照出现的频次排序的列表，此字段要求多列中的至少1列包含NULL值，但又不全部是NULL值most_common_freqs_nullmost_common_vals_null中每个值出现的频率列表 表的多个列有相关性且查询中有同时基于这些列的过滤条件、关联条件或者分组操作的时候，可尝试收集多列统计信息。扩展统计信息需要手动进行收集(具体收集方法，下个小节会介绍)，如下为test表(a,b)两列的统计信息4      HOW：如何生成统计信息4.1      显式收集统计信息4.1.1 单列统计信息通过如下命令收集单列统计信息：{ ANALYZE | ANALYSE } [ VERBOSE ]  [ table_name [ ( column_name [, ...] ) ] ]; 如语法描述，我们支持对指定列做统计信息，但是实际上我们很难统计实际业务SQL中到底使用了当前哪些表的列进行了代价估算，因此建议通常情况下对全表收集统计信息。4.1.2 扩展统计信息通过如下命令收集多列统计信息：{ANALYZE | ANALYSE} [ VERBOSE ] table_name (( column_1_name, column_2_name [, ...] )); 需要注意的是，当前只支持在百分比采样模式下生成扩展统计信息，因此在收集扩展统计信息之前请确保GUC参数default_statistics_target为负数 4.2      提升统计信息质量analyze是按照随机采样算法从表上采样，根据样本计算表数据特征。采样数可以通过配置参数default_statistics_target进行控制，default_statistics_target取值范围为-100~10000，默认值为100。1） 当default_statistics_target > 0时；采样的样本数为300*default_statistics_target，default_statistics_target取值越大，采样的样本也越大，样本占用的内存空间也越大，统计信息计算耗时也越长2） 当default_statistics_target < 0时，采样的样本数为 (default_statistics_target)/100*表的总行数，default_statistics_target取值越小，采样的样本也越大。但是default_statistics_target < 0时会把采样数据下盘，不存在样本占用的内存空间的问题，但是因为样本过大，计算耗时长的问题同样存在default_statistics_target < 0时，实际采样数是(default_statistics_target)/100*表的总行，所以我们又称之为百分比采样。4.3      自动收集统计信息当配置参数autoanalyze打开时，查询语句走到优化器发现表不存在统计信息，会自动触发统计信息收集，以满足优化器的需求。以文档的case为列 注：只有对统计信息敏感的复杂查询动作(多表关联等操作)的SQL语句执行时才会触发自动收集统计信息；简单查询(比如单点，单表聚合等) 不会触发自动收集统计信息5      WHEN：什么时候收集统计信息5.1      大规模数据变化大规模数据导入/UPDATE/DELETE等操作，会导致表数据行数变化，新增的大量数据也会导致数据特征发生大的变化，此时需要对表重新收集统计信息5.2      查询新增数据常见于业务表新增数据查询场景，这个也是收集业务中最常见、最隐蔽的统计信息没有及时更新的问题，这种场景最主要的特征如下1)       存在一个按照时间增长的业务表2)       业务表每天入库新一天的数据3)       数据入库之后查询新增数据进行数据加工分析 在最后步骤的数据加工分析时，最长的方法就是使用Filter条件从分区表中筛选数据，如passtime > ‘2020-01-19 00:00:00’ AND pastime < ‘2020-01-20 00:00:00’，假如新增数据入库之后没有做analyze，优化器发现Filter条件中的passtime取值范围超过了统计信息中记录的passtime值的上边界，会把估算满足passtime > ‘2020-01-19 00:00:00’ AND pastime < ‘2020-01-20 00:00:00’的tuple个数为1条，导致估算行数验证失真6      WHO：谁来收集统计信息AP场景下业务表数据量一般都很大，单次导入的数据量也比较大，而且经常是数据导入即用，因此建议在业务开发过程中，根据数据变化量和查询特征在需要的地方主动对相关表做analyze。 

请问各位大大，使用Python3 连接 GaussDB的依赖包在哪里下载呀，如果可以的话，可以再请教一下连接步骤吗？谢谢

1.测试表及测试数据select *  from products ;     2.窗口函数row_number()（1）查询出来的数据按照price排序，并加一列序号，select type,name,price,row_number() over(order by price asc) as idx from products ;      （2）在类别(type)内按照价格(price) 升序排列(就是在类别内做排序)select type,name,price,row_number() over(PARTITION by type order by price asc) as idx from products ;rank() (1)零食类别内的 方便面和汽水价格是一样的，如何将零食和汽水并列第一SELECT type,name,price,rank() over(partition by type order by price asc) from products(2)零食类别中的第三个 辣条 排到第三了，如果这里需要在类别里面能保持序号不重不少(将辣条排名至第二)SELECT type,name,price,dense_rank() over(partition by type order by price asc) from products;

1      变更概述... 1  1.1      目的和需求... 12      变更操作步骤... 1    2.1      停止业务... 2    2.2      停止集群... 2    2.3      升级网卡驱动... 2    2.4      检查LVS配置... 2    2.5      启动集群... 3    2.6      启动业务... 3    2.7      执行gs_check巡检... 3        2.7.1生成hostfile文件... 3        2.7.2 创建工作目录... 3        2.7.3上传收集工具... 4        2.7.4分发收集工具至其他节点... 4        2.7.5执行信息收集... 5        2.7.6 分析巡检报告... 53      测试验证... 54      应急措施... 6    4.1      启停集群失败... 6    4.2      LVS检查失败... 6    4.3      gs_check巡检项未通过... 65      变更后工作... 6 5.1      变更后业务验证（必选）... 61      变更概述1.1      目的和需求保障网卡驱动升级完成后，数据库集群和客户业务稳定运行。2      变更操作步骤确保网卡驱动升级后集群运行状态正常，需按以下步骤做变更。2.1      停止业务停止SDR数据复制链路loader组件，客户操作。2.2      停止集群登录FusionInsight Manager，选择“集群 > 概览 > 停止”，点击停止按钮之后，需要输入FusionInsight Manager的密码。2.3      升级网卡驱动由硬件部门处理。2.4      检查LVS配置升级成功之后检查LVS相关配置。当LVS使用的网卡是双网卡bond时，需要关闭客户端、LVS主备节点和CN的bond网卡和物理网卡的lro、gro 、gso 、tso参数，具体如下所示（假设bond网卡名称为bond0，被bond的两个物理网卡是eth1和eth2）：查看bond网卡使用的物理网卡：ifconfig|grep `ifconfig|grep "bond0"|awk '{print $NF}'`|awk '{print $1}' ethtool -K bond0 lro gro gso tso off ethtool -K eth1 gro lro gso tso off ethtool -K eth2 gro lro gso tso off使用下面命令查看是否关闭：ethtool -k bond0 ethtool -k eth1 ethtool -k eth2显示如下信息表示lro和gro已关闭。tcp-segmentation-offload：off generic-segmentation-offload:off generic-receive-offload: off large-receive-offload: off如果lro、gro、tso、gso不能正常关闭，请联系技术支持工程师提供技术支持。2.5      启动集群检查LVS配置成功之后，启动集群。登录FusionInsight Manager，选择“集群 > 概览 > 启动”。观察集群已正常启动后进行下一步操作。2.6      启动业务启动SDR数据复制链路loader组件，客户操作。2.7      执行gs_check巡检2.7.1生成hostfile文件使用omm用户登录集群第一个CN节点执行：su - omm source     /opt/huawei/Bigdata/mppdb/.mppdbgs_profile cm_ctl query -Cvi|grep     "Primary Normal"|awk '{print$3}'|uniq > /home/omm/hostfile2.7.2 创建工作目录登录该CN节点，用omm用户执行下边命令：清理原有工作目录for i in `cat   /home/omm/hostfile`;do   ssh $i "hostname;rm -rf /home/omm/test_check"   ;done重新创建工作目录for i in `cat     /home/omm/hostfile`;do ssh $i "hostname;mkdir -p     /home/omm/test_check" ;done2.7.3上传收集工具1、确认gs_check路径，若已有gs_check工具，跳过第二步       which gs_check2、gs_check工具下载地址：     https://support.huawei.com/enterprise/zh/cloud-computing/fusioninsight-tool-pid-21624171/software  点击 FusionInsight Tool Prober 6.x.x，下载FI-mrs-syschecker-6.x.x.zip  解压后到以下目录：    SysChecker\SysCheck_C80\ClientScripts\17_MPPDB\Lib，找到gs_check3、将Check包上传至该CN节点的/home/omm/test_check目录下修改test_check目录及目录下文件的属主为ommcd /home/omm/test_check unzip Check_0330.zip chown -R omm:wheel     /home/omm/test_check/Check/ chmod +x -R   /home/omm/test_check/2.7.4分发收集工具至其他节点su - omm source   /opt/huawei/Bigdata/mppdb/.mppdbgs_profile for i in `cat /home/omm/hostfile`;do     scp -r /home/omm/test_check/* $i:/home/omm/test_check/;done2.7.5执行信息收集cd   /home/omm/test_check/Check ./gs_check -e inspect -U   omm -l   ./check.log 等待生成一下巡检结果如下： /home/omm/test_check/Check/inspection/output/CheckReport_***.tar.gz解压CheckReport_***.tar.gz得到巡检报告，如下图：将生成的巡检结果文件尽快反馈至华为工程师，需结合业务场景对巡检报告中“检查结果”列为“NG”列的巡检项进行配置指导。2.7.6 分析巡检报告客户自行分析巡检报告时，重点关注“检查结果”列为“NG”的列，对于不符合配置的，参考巡检报告最后一列“修复建议”进行修复。例如：修复网卡多队列绑定./gs_check -i CheckMultiQueue --set3      测试验证# 查集群状态cm_ctl query   -Cv4      应急措施4.1      启停集群失败分析日志，处理失败原因，重新尝试启停。4.2      LVS检查失败尝试多次检查LVS。4.3      gs_check巡检项未通过将报告及时反馈华为工程师，客户自行分析时参考gs_check巡检报告进行修复，有问题请及时联系华为工程师。5      变更后工作5.1      变更后业务验证（必选）l  集群状态检查       cm_ctl query –Cvl  客户接入业务自行测试。

目录【问题描述】【分析过程】【问题根因】【闭环方案】【恢复方案】【问题描述】1、集群FI界面显示以下告警：文件句柄使用率超过阈值、TCP临时端口使用率超过阈值等； 2、业务无法正常执行，连接DataNode5以外节点cn_5001执行作业报dn_6001_6002达到最大连接数；3、连接DataNode5上cn_5005执行作业报临时资源不可用。【分析过程】1、TCP临时端口使用率超过阈值GaussDB A支持随机端口复用，临时端口使用超过65535不会影响业务，因此此告警不会导致问题。 2、文件句柄使用率超过阈值1）查看DataNode5机器的os系统日志，搜kernel关键字，如下：localhost:~ # grep kernel /var/log/messages Jul 12 16:05:01 DataNode5 kernel: VFS: file-max limit 640000 reached Jul 12 16:05:12 DataNode5 kernel: VFS: file-max limit 640000 reached Jul 12 16:05:12 DataNode5 kernel: VFS: file-max limit 640000 reached Jul 12 16:05:12 DataNode5 kernel: VFS: file-max limit 640000 reached Jul 12 16:05:13 DataNode5 kernel: VFS: file-max limit 640000 reached Jul 12 16:05:13 DataNode5 kernel: VFS: file-max limit 640000 reached Jul 12 16:05:13 DataNode5 kernel: VFS: file-max limit 640000 reached Jul 12 16:05:14 DataNode5 kernel: VFS: file-max limit 640000 reached Jul 12 16:05:14 DataNode5 kernel: VFS: file-max limit 640000 reached Jul 13 09:51:46 DataNode5 kernel: VFS: file-max limit 640000 reached omm@localhost:~ #2）查操作系统配置的最大文件句柄数localhost:~ # sysctl -p|grep file-max fs.file-max = 6400003）统计进程使用句柄数情况localhost:~ # lsof -n|awk '{print $2}'|sort|uniq -c|sort -nr|more由于文件句柄较多，统计较慢4）统计gaussdb各进程使用的文件句柄# 查找gaussdb进程 ps ux # 查看某个进程使用的文件句柄数 ls /proc/pid/fd | wc -l# 结果排查，发现cn（此cn为cn_5005）进程所占的文件句柄数最多，如下图，达到57万，略有异常，继续分析。5） 排查cn_5005日志，重点关注7月12号下午16:05的日志信息，如下，“remaining connection slots are reserved for non-replication system admin connections”和“dn_6037_6038: sorry, too many clients already, active/non-active: 5/2995.”均表明当前系统连接数已经达到设置的最大max_connections，不能在建连。继续确认进程启动时间并与客户确认，上一次重启时间为19年12月，8.0之前的版本，客户持续运行7个月以上，连接数可能会一直增大，这时需要用户手动执行clean connection to all for database dbtest;去清理空闲连接，否则继续建连会出现上述报错提示，且也会由于连接数太多占用内存导致执行时报临时资源不可用。疑问：客户集群共部署4个CN节点，且采用LVS负载均衡，正常情况下，LVS会将作业均衡的分发给每个CN节点，但目前只有datanode5节点报文件句柄数达到最大？？6）继续排查其它机器所占用的文件句柄数，如下图只有12万+，怀疑可能是LVS异常。7）与客户对齐发现，客户在使用LVS过程中，跑大量insert语句，刚开始运行时，观察每个cn上都会运行insert语句，运行到10小时之后（20小时才能跑完），LVS只往某两个cn上下发作业，这会导致上述cn_5005连接数远远大于其他节点。【问题根因】连接数太多导致系统业务报错【闭环方案】客户反馈近期会升级到8.0版本，8.0版本已加入自动清理空闲连接操作，不会再出现此类报错。【恢复方案】法一：清理空闲连接：clean connection to all for database dbtest;法二：集群重启后恢复

概要本篇主要讲解GaussDB使用过程中遇到的“FATAL:  terminating connection due to administrator command”相关报错进行阐述。按报错现象可分为两类场景，一类是在客户端报错的同时，查找cn日志相应时间点的日志，可以找到相关报错日志；另一类是客户端报错，但cn日志在报错时间点未能找到相关报错日志。接下来分别以这两种场景进行以案例的形式进行介绍介绍。（后续有其他场景或案例会持续补充更新）目录【场景一： CN在客户端报错相应时间点有日志记录】【问题描述】【分析过程】【闭环方案】【场景二： CN在客户端报错相应时间点未找到日志记录】【分析及案例】【场景一： CN在客户端报错相应时间点有日志记录】【问题描述】 业务偶现报错“FATAL:  terminating connection due to administrator command”，如下图：    【分析过程】业务报错打印“FATAL: terminating connection due to administrator command”, 经过排查代码只有在收到SIGTERM信号时打印此信息。进一步分析SIGTERM信号只有3个场景会触发：（1）集群停止shutdown；（2）强制清理连接clean connection force；（3）调用终止服务线程函数pg_terminate_backend(pid)三种场景详细分析如下：第一种情况：集群停止shutdown场景，分析全量日志，查看报错时间点是否有任何集群停止命令对应日志，若没有排除集群停止shutdown导致服务线程终止因素。# grep -nr "fast shutdown request" ./第二种情况：强制清理连接clean connection force，通过排查数据库各模块代码，在数据库内没有任何调用此接口的代码，只是一个对外接口，排除数据库内部自行调用clean触发因素。第三种情况：调用终止服务线程函数pg_terminate_backend(pid)，通过排查各模块代码，数据库内部有且仅有cm_agent模块一处调用。        cm_agent在检测磁盘超过阈值（默认90%）场景下，会调用命令“select pg_terminate_backend(pid) from pg_stat_activity where usesysid <> 10”终止当前CN上所有非omm用户的SQL，同时打印调用日志“cancel session ok”，排查cma日志，报错时间点是否出现过cma终止当前cn所有非omm用户sql的打印。并未发现日志打印，说明cma并没有发送终止命令。# grep "pg_terminate_backend" cm/*/*.log·   目前为止遇到的此报错大多数是由于客户端调用pg_terminate_backend和clean connection foece导致，当用户遇到此类问题时，排除集群停止shutdown导致服务线程终止因素，建议排查执行的作业是否包含pg_terminate_backend和clean connection foece关键字，以下通过两个案例简单说明。·   案例详解·         案例一：1、  报错现象：客户跑批时sql被无故杀掉，业务报错打印“FATAL: terminating connection due to administrator command”2、  在日志中查看到，有关于pg_terminate_backend调用的记录(如下图)         3、  另外，CM在检查磁盘空间超过阈值设置只读时，也会下发pg_terminate_backendBDP17189/logfiles/cm/cm_agent/cm_agent-2019-08-06_111323-current.log:2019-10-26 22:12:28.502 tid=127209 LOG: exec: (select pg_terminate_backend(pid) from pg_stat_activity where usesysid <> 10), cancel session ok.  BDP17189/logfiles/cm/cm_agent/cm_agent-2019-08-06_111323-current.log:2019-10-27 20:14:47.912 tid=127209 LOG: exec: (select pg_terminate_backend(pid) from pg_stat_activity where usesysid <> 10), cancel session ok.  BDP17189/logfiles/cm/cm_agent/cm_agent-2019-08-06_111323-current.log:2019-10-29 04:08:51.278 tid=127209 LOG: exec: (select pg_terminate_backend(pid) from pg_stat_activity where usesysid <> 10), cancel session ok.4、  因此从日志来看，业务侧确实有调用pg_terminate_backend杀线程， 另外cm在检查磁盘空间超过阈值设置只读时也下发过几次pg_terminate_backend·         案例二：    1、报错现象：    客户端偶现报错：                2、分析    1）根据上述报错场景分析，排除集群停止shutdown，怀疑可能是调用了clean connection force和pg_terminate_backend，gdb抓现场，设置两个断点断点：pg_terminal_backend和clean_connection force。(gdb) bt #0  CleanConnection (stmt=0x7f62118aa468) at poolutils.cpp:274 #1  0x0000000001875f35 in standard_ProcessUtility (parsetree=0x7f62118aa468, queryString=0x7f62118a9060 "CLEAN CONNECTION TO ALL FORCE FOR DATABASE postgres;", params=0x0, isTopLevel=true,     dest=0x7f62118aa580, sentToRemote=false, completionTag=0x7f61d95648a0 "") at utility.cpp:6498 #2  0x0000000001886098 in pgaudit_ProcessUtility (parsetree=0x7f62118aa468, queryString=0x7f62118a9060 "CLEAN CONNECTION TO ALL FORCE FOR DATABASE postgres;", params=0x0, isTopLevel=true,     dest=0x7f62118aa580, sentToRemote=false, completionTag=0x7f61d95648a0 "") at auditfuncs.cpp:1240 #3  0x000000000186803e in ProcessUtility (parsetree=0x7f62118aa468, queryString=0x7f62118a9060 "CLEAN CONNECTION TO ALL FORCE FOR DATABASE postgres;", params=0x0, isTopLevel=true, dest=0x7f62118aa580,     sentToRemote=false, completionTag=0x7f61d95648a0 "") at utility.cpp:1506 #4  0x00000000018637c9 in PortalRunUtility (portal=0x7f62118af060, utilityStmt=0x7f62118aa468, isTopLevel=true, dest=0x7f62118aa580, completionTag=0x7f61d95648a0 "") at pquery.cpp:1682 #5  0x0000000001863c2c in PortalRunMulti (portal=0x7f62118af060, isTopLevel=true, dest=0x7f62118aa580, altdest=0x7f62118aa580, completionTag=0x7f61d95648a0 "") at pquery.cpp:1842 #6  0x0000000001862522 in PortalRun (portal=0x7f62118af060, count=9223372036854775807, isTopLevel=true, dest=0x7f62118aa580, altdest=0x7f62118aa580, completionTag=0x7f61d95648a0 "") at pquery.cpp:1114 #7  0x000000000184c22b in exec_simple_query (query_string=0x7f62118a9060 "CLEAN CONNECTION TO ALL FORCE FOR DATABASE postgres;", messageType=QUERY_MESSAGE, msg=0x7f61d9564ba0) at postgres.cpp:2777 #8  0x0000000001857110 in PostgresMain (argc=1, argv=0x7f624818f850, dbname=0x7f62437418a8 "database_resource_monitor", username=0x7f6243741840 "user_resource_monitor") at postgres.cpp:8268 #9  0x000000000166bcd3 in BackendRun (port=0x7f61d95661c0) at postmaster.cpp:7063 #10 0x000000000166d743 in SubPostmasterMain (argc=3, argv=0x7f61d9566430) at postmaster.cpp:7810 #11 0x000000000166c8f7 in MainStarterThreadFunc (args=0x7f625ad01bd8) at postmaster.cpp:7250 #12 0x0000000001d67ae6 in ThreadStarterFunc (arg=0x7f625ad01bc0) at gs_thread.cpp:389 #13 0x00007f633bf97806 in start_thread () from /lib64/libpthread.so.0 #14 0x00007f633bcf264d in clone () from /lib64/libc.so.6 #15 0x0000000000000000 in ?? () (gdb) p *MyProcPort $1 = {sock = 212, …, remote_host = 0x7f2e6074aee0 "100.185.178.233", remote_hostname = 0x7f2e6074aee0 "100.185.178.233", remote_hostname_resolv = 0, remote_port = 0x7f2e6074af70 "52563", …}    2）由上知，对端100.185.178.233，端口41684 ，明确对端信息后，登录到对端查看此连接对应的对端进程到底在做什么    3）登录到对端机器100.185.178.233，根据remote_port 52563找到进程，结果如下图：    linux178233:/lvs_kehuduan/script/dml # netstat -anop | grep 52563    tcp        0      0 100.185.178.233:52563   100.185.185.182:6000    ESTABLISHED 229505/gsql         keepalive (1.40/0/0)    linux178233:/lvs_kehuduan/script/dml # ps ux | grep 229505    root     229505  0.7  0.0  53048  3400 pts/1    S    22:07   0:00 gsql -d database_resource_monitor -p 6000 -U user_resource_monitor -W           -h 100.185.185.182 -f dml/test_clean_connection.sql    root     229531  0.0  0.0   5736   816 pts/4    S+   22:08   0:00 grep 229505    linux178233:/lvs_kehuduan/script/dml #        3、结论    最终发现是用户在100.185.178.233 上通过gsql连接到集群，并持续执行test_clean_connection.sql，就是下图一个神奇的脚本，接近无限循环清理连接。。    一直在执行test_clean_connection.sql：--创建jack用户。 CREATE USER jack PASSWORD 'Bigdata123@'; --删除数据库template1在dn1和dn2节点上的连接。 CLEAN CONNECTION TO NODE (dn_6001_6002) FOR DATABASE template1; --删除用户jack在dn1节点上的连接。 CLEAN CONNECTION TO NODE (dn_6001_6002) TO USER jack; --删除在数据库postgres上的所有连接。 CLEAN CONNECTION TO ALL FORCE FOR DATABASE postgres; --删除用户jack。 DROP USER jack;案例三：    1.客户业务从172节点的cn接入    2.用户业务偶现报错打印“FATAL: terminating connection due to administrator command“，重试可成功    2.根据以上报错场景分析，排除shutdown场景，此报错只有两种场景：1）外部调用pg_terminate_backend函数 2）clean connection force    3.排查发现用户自己有杀超时语句的程序，但是在172节点客户程序的日志中未找到该语句被杀的记录，并且语句是刚跑起来就被杀    4.继续排查，在171节点的客户程序日志中找到了该语句被杀的日志    5.经分析，是因为客户杀语句的程序使用了current_time() - backend_start【闭环方案】    排查代码中下发SIGTERM信号场景，后续版本中在调用pg_terminate_backend和clean connection force时，均打印日志，例如：    Send SIGTERM to thread:    send SIGTERM signal to walreceiver thread    use pg_terminate_backend to terminate backend thread,tid【场景二： CN在客户端报错相应时间点未找到日志记录】    【分析及案例】    1、报错现象    Jdbc客户端报错如下：        2、分析    1）CN和DN日志中均未搜到“FATAL: terminating connection …”报错信息。按照场景一种提到的三种方式排查，均为发现异常。    2）查看用户设置的session_timeout为1d，当达到超时时间时，集群会自动关闭此连接，如下图，在11:24时重新执行作业报错，查看日志发现在11:18:54.387因为已经达到超时时间，连接已经被关闭。        3、对于jdbc来说，客户端和cn的之间的连接达到了session_timeout被kill，但是getConnections又从jdbc连接池拿了这个连接所以报的错。

A. 背景：客户在使用DWS时，经常会出现执行一个sql很久不返回结果，导致业务性能低下，从而报障。现象：一个业务sql执行很久不出结果定位方法：DWS在经常变化的表需要定期做统计优化查询，具体场景如下：1 经常变化的表，如果经常insert语句到表中，需要做analyze 表，具体语句为Analyze tablename;2 经常变化的表，如果经常删除delete数据，需要做valcumm full 表，具体语句为Valcumm full tablename 注：执行valcumm full 语句时注意不能有其他任务在跑。 注：定位技巧：查询表大小select * from pg_size_pretty(pg_table_size('tablename'));详情请点击博文链接：https://bbs.huaweicloud.com/blogs/171920

   PostGIS为PostgreSQL提供了空间数据库分析能力，是目前业界主流的地理数据库之一，提供如下空间信息服务功能：空间对象、空间索引、空间操作函数和空间操作符等。在GaussDB 中，目前已支持PostGIS地理数据库扩展，并已广泛应用于国内外安防、农业、安平等政企客户。https://bbs.huaweicloud.com/blogs/190410