GaussDB简介 GaussDB是华为开发的一种分布式关系型数据库管理系统。GaussDB支持主备集群和分片集群两种部署模式，它们在功能和架构上有一些区别。      华为GaussDB相比PostgreSQL做了哪些内核优化？  1. 主备集群 == 集中式 主备集群是传统的数据库高可用架构，包括一个主节点和一个或多个备节点。主节点处理所有的写操作和大部分的读操作，而备节点用于冗余和故障恢复。主备集群的特点包括：  数据一致性：主节点上的写操作会同步到备节点，确保数据一致性。 故障恢复：当主节点发生故障时，备节点可以接管并继续提供服务，实现高可用性。 数据冗余：备节点保存主节点上的数据副本，提供数据冗余和备份。  cm_ctl query -Cvipd  gs_om -t status --detail > a.txt [omm@gaussdb-b0e95ed4-cm-0 ~]$ cat a.txt [  CMServer State   ]  node           node_ip         instance                             state --------------------------------------------------------------------------- 1  245.0.1.49  245.0.1.49      1    /data/cluster/data/cm/cm_server Primary 2  245.0.0.104 245.0.0.104     2    /data/cluster/data/cm/cm_server Standby 3  245.0.1.52  245.0.1.52      3    /data/cluster/data/cm/cm_server Standby  [    ETCD State     ]  node           node_ip         instance                     state ------------------------------------------------------------------------- 1  245.0.1.49  245.0.1.49      7001 /data/cluster/data/etcd StateFollower 2  245.0.0.104 245.0.0.104     7002 /data/cluster/data/etcd StateLeader 3  245.0.1.52  245.0.1.52      7003 /data/cluster/data/etcd StateFollower  [   Cluster State   ]  cluster_state   : Normal redistributing  : No balanced        : No current_az      : AZ_ALL  [  Datanode State   ]  node           node_ip         instance                                          state            | node           node_ip         instance                                          state            |                                                                                                                        node           node_ip         instance                                          state -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------                                                                                                                       ----------------------------------------------------------------------------------------------------- 4  245.0.0.2   245.0.0.2       6001 /data/cluster/data/dn/gaussdb-b0e95ed4-dn0-0 P Standby Normal | 5  245.0.1.135 245.0.1.135     6002 /data/cluster/data/dn/gaussdb-b0e95ed4-dn0-1 S Primary Normal |                                                                                                                        6  245.0.1.61  245.0.1.61      6003 /data/cluster/data/dn/gaussdb-b0e95ed4-dn0-2 S Standby Normal  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 su - omm gsql -d postgres -p 42000 -r  \x select * from pg_stat_replication;  select * from pg_replication_slots; 1 2 3 4 5 6 7   同步模式  两地三中心跨region容灾  2. 分片集群： 分片集群是为了应对大规模数据和高并发负载而设计的解决方案。它将数据分散存储在多个节点上，每个节点称为一个分片，每个分片都是一个独立的数据库实例。分片集群的特点包括：  水平扩展：数据分片存储在多个节点上，可以通过增加节点来实现水平扩展，提高数据库的处理能力和吞吐量。 数据分片：数据被划分为多个分片，每个分片只包含部分数据，减轻了单个节点的负载压力。 查询路由：查询会根据分片规则被路由到相应的分片节点上进行处理，从而实现分布式查询。 GaussDB数据分布策略设计  GaussDB(for openGauss)是分布式架构，数据分布在各个DN上，设计好的数据分布策略是分布式数据库设计中最关键的环节。   cm_ctl query -Cvipd  [  CMServer State   ]  node               node_ip         instance                             state ------------------------------------------------------------------------------- AZ1 1  245.0.1.46  245.0.1.46      1    /data/cluster/data/cm/cm_server Standby AZ1 2  245.0.0.120 245.0.0.120     2    /data/cluster/data/cm/cm_server Standby AZ1 3  245.0.3.43  245.0.3.43      3    /data/cluster/data/cm/cm_server Primary  [    ETCD State     ]  node               node_ip         instance                     state ----------------------------------------------------------------------------- AZ1 1  245.0.1.46  245.0.1.46      7001 /data/cluster/data/etcd StateFollower AZ1 2  245.0.0.120 245.0.0.120     7002 /data/cluster/data/etcd StateFollower AZ1 3  245.0.3.43  245.0.3.43      7003 /data/cluster/data/etcd StateLeader  [   Cluster State   ]  cluster_state   : Normal redistributing  : No balanced        : No current_az      : AZ_ALL  [ Coordinator State ]  node               node_ip         instance                                         state ------------------------------------------------------------------------------------------- AZ1 7  245.0.0.57  245.0.0.57      5001 /data/cluster/data/cn/gaussdb_cadcaebf_cn_0 Normal AZ1 8  245.0.1.6   245.0.1.6       5002 /data/cluster/data/cn/gaussdb_cadcaebf_cn_1 Normal AZ1 9  245.0.3.67  245.0.3.67      5003 /data/cluster/data/cn/gaussdb_cadcaebf_cn_2 Normal  [ Central Coordinator State ]  node               node_ip         instance                                         state ------------------------------------------------------------------------------------------- AZ1 7  245.0.0.57  245.0.0.57      5001 /data/cluster/data/cn/gaussdb_cadcaebf_cn_0 Normal  [     GTM State     ]  node               node_ip         instance                                           state                    sync_state ----------------------------------------------------------------------------------------------------------------------------- AZ1 4  245.0.1.83  245.0.1.83      1001 /data/cluster/data/gtm/gaussdb_cadcaebf_gtm_0 P Standby Connection ok  Sync AZ1 5  245.0.0.102 245.0.0.102     1002 /data/cluster/data/gtm/gaussdb-cadcaebf-gtm-1 S Standby Connection ok  Sync AZ1 6  245.0.3.112 245.0.3.112     1003 /data/cluster/data/gtm/gaussdb-cadcaebf-gtm-2 S Primary Connection ok  Sync  [  Datanode State   ]  node               node_ip         instance                                          state            | node               node_ip         instance                                          state            | node               node_ip         instance                                          state ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ AZ1 10 245.0.1.56  245.0.1.56      6001 /data/cluster/data/dn/gaussdb-cadcaebf-dn0-0 P Standby Normal | AZ1 11 245.0.0.118 245.0.0.118     6002 /data/cluster/data/dn/gaussdb-cadcaebf-dn0-1 S Standby Normal | AZ1 12 245.0.3.90  245.0.3.90      6003 /data/cluster/data/dn/gaussdb-cadcaebf-dn0-2 S Primary Normal AZ1 13 245.0.1.138 245.0.1.138     6004 /data/cluster/data/dn/gaussdb-cadcaebf-dn1-0 P Standby Normal | AZ1 14 245.0.0.59  245.0.0.59      6005 /data/cluster/data/dn/gaussdb-cadcaebf-dn1-1 S Primary Normal | AZ1 15 245.0.3.10  245.0.3.10      6006 /data/cluster/data/dn/gaussdb-cadcaebf-dn1-2 S Standby Normal ~  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 总结来说，主备集群适用于常规的高可用需求，提供数据冗余和故障恢复能力，而分片集群则适用于大规模数据和高并发负载的场景，提供水平扩展和分布式查询的能力。选择适合的架构取决于你的应用需求和规模。  gsql连接 gsql -d postgres -p 42000 --集中式是登录主dn  gsql -d postgres -p 42050 --分布式登录cn，直接登录dn报错  ##GaussDB集中式数据库后台登录  通过终端登录集中式主库 su omm gsql -d postgres -p 42000  ##GaussDB分布式数据库后台登录 通过终端登录CN su omm gsql -d postgres -p 42050  组件介绍 GaussDB  CMServer State（CM服务器状态）：  CMServer（Configuration Management Server）是GaussDB中的配置管理服务器，负责管理数据库集群的配置信息和节点状态。，包括节点的角色（主节点、备节点）、数据库的参数设置等。CMServer状态的正常运行对于集群的配置管理非常重要，如果CMServer状态不正常，可能会导致配置信息无法正确同步和管理。 在提供的输出中，列出了每个CMServer实例的节点、IP地址、实例号、存储路径和状态。例如，AZ1 1节点的CMServer实例1位于/data/cluster/data/cm/cm_server，并且状态为Down。 ETCD State（ETCD状态）：  ETCD是GaussDB集群中的分布式键值存储系统，用于存储数据库集群的元数据和配置信息。ETCD状态的正常运行对于集群的正常运作至关重要，如果ETCD状态不正常，可能会导致集群无法正确启动、配置信息丢失或不一致。 在提供的输出中，列出了每个ETCD实例的节点、IP地址、实例号、存储路径和状态。例如，AZ1 1节点的ETCD实例7001位于/data/cluster/data/etcd，并且状态为Down。 Cluster State（集群状态）：  cluster_state：表示集群的整体状态。在提供的输出中，集群状态为Degraded，表示集群处于降级状态。 redistributing：表示是否正在进行数据重新分配。在提供的输出中，redistributing状态为No，表示当前没有进行数据重新分配。 balanced：表示是否已经实现负载均衡。在提供的输出中，balanced状态为No，表示集群还未实现负载均衡。 current_az：表示当前可用区（Availability Zone）的配置。在提供的输出中，current_az为AZ_ALL，表示所有可用区都被配置为当前可用区。 Coordinator State（协调器状态）：  协调器（Coordinator）是GaussDB集群中的组件，负责协调数据库操作和查询的执行。Coordinator State提供了关于各个协调器实例的状态信息。 在提供的输出中，列出了每个协调器实例的节点、IP地址、实例号、存储路径和状态。例如，AZ1 7节点的协调器实例5001位于/data/cluster/data/cn/gaussdb_cadcaebf_cn_0，并且状态为Normal。 Central Coordinator State（中心协调器状态）：  中心协调器（Central Coordinator）是GaussDB集群中的主要协调器实例，负责全局协调和管理。Central Coordinator State提供了关于中心协调器实例的状态信息。 在提供的输出中，列出了中心协调器实例的节点、IP地址、实例号、存储路径和状态。例如，AZ1 7节点的中心协调器实例5001位于/data/cluster/data/cn/gaussdb_cadcaebf_cn_0，并且状态为Normal。 GTM State（全局事务管理器状态）：  GTM（Global Transaction Manager）是GaussDB集群中的全局事务管理器，负责处理分布式事务。GTM State提供了关于GTM实例的状态信息。 在提供的输出中，列出了每个GTM实例的节点、IP地址、实例号、存储路径、状态和同步状态。例如，AZ1 4节点的GTM实例1001位于/data/cluster/data/gtm/gaussdb_cadcaebf_gtm_0，状态为P（Primary），同步状态为Unknown。 综上所述，ETCD State提供了ETCD实例的状态信息，CMServer State提供了CMServer实例的状态信息，Cluster State提供了集群的整体状态信息，Coordinator State提供了协调器实例的状态信息，Central Coordinator State提供了中心协调器实例的状态信息，而GTM State提供了GTM实例的状态信息。这些状态信息对于了解集群的运行状况和各个组件的状态非常重要。  

书接上文GaussDB关键技术原理：高弹性（一）从CBI索引方面对hashbucket进行了解读，本篇将从优化器剪枝、执行器两方面继续介绍hashbucket。2.3 优化器剪枝  优化器是一个数据库管理系统中的重要组件，用于优化SQL查询语句的执行计划，从而提高查询性能。优化器的任务是找到最优的执行计划，使得查询结果能够以最快的速度返回。剪枝是一种优化技术，可以根据查询的语义和数据类型，选择最优的执行计划，避免不必要的计算和 IO 操作，提高查询效率。GaussDB中hash分片计划生成流程如图1所示，关键思想是在优化器阶段根据剪枝结果确定要扫描的buckets分片。图1  hash分片计划生成流程2.3.1 hash分片剪枝hash分片剪枝分为静态剪枝和动态剪枝，静态剪枝是在优化器阶段根据表达式的过滤条件进行剪枝，动态剪枝是在执行器阶段根据运行时数据进行剪枝。在当前系统中，GaussDB只支持单分布键剪枝。下面以静态剪枝为例介绍优化器剪枝原理。涉及到hash分片剪枝的表达式有两类：集合运算表达式：AND OR比较运算表达式：= 、!=剪枝的过程就是集合运算的过程。先把基表上有关分布列的过滤条件抽取出来并转换为c1 op const AND c2 op const OR c3 op const ...的形式，然后针对每个表达式部分求解剪枝结果并进行集合运算(AND:INTERSECT, OR:UNION)，剪枝结果用集合进行表示，保存在结构体BucketInfo中。剪枝过程如下：    （1）确定能参与剪枝的条件。非分布列的条件不能剪枝（结果为全集）。（2）以OR条件进行分组，对每个分布列 op const求出部分剪枝结果。（3）进行集合运算求出整体剪枝结果。算法入参为基表的表达式树如下图2，剪枝算法需要遍历表达式树，并对每个节点采取相应动作：图2  表达式树示意图AND表达式：获取两边剪枝结果，求交集。OR表达式：获取两边剪枝结果，求并集。=表达式，分情况处理：var = const时，若var是分布列，对const求hashbucketid，返回[bucketid]剪枝结果，若var是非分布列，返回全集；var = non-const，返回全集。!=表达式，分情况处理：var是分布列，对const求hashbucketid，返回不包含bucketid的剪枝结果；var是非分布列，返回全集；var = non-const 返回全集。其他表达式无法处理：返回全集。EXPLAIN是一个用于分析查询语句执行计划的命令，通过分析一条简单SQL语句“select * from t1 where a = 3 and b !=3;”语句的执行计划来了解hashbucket优化器剪枝对生成执行计划的影响。执行计划的显示格式为“算子（算子修饰符）（算子估算代价 结果集行数 结果集宽度）”。语句的执行计划如下：gaussdb=# explain verbose select * from t1 where a = 3 and b !=3; QUERY PLAN----------------------------------------------------------------- Streaming (type: GATHER) (cost=0.06..1.25 rows=2 width=12) Output: a, b, c Node/s: datanode4 -> Seq Scan on gaussdb.t1 (cost=0.00..1.03 rows=2 width=12) Output: a, b, c Distribute Key: a Filter: ((t1.b <> 3) AND (t1.a = 3)) Selected Buckets 1 of 1024 : 642(8 rows)第一层执行计划是用stream算子（网络数据传输算子）把DN4的数据汇总到CN；第二层是SeqScan顺序扫描算子根据表达式“a=3 and b!= 3”剪枝得到剪枝结果。在表达式中b不是分布列，所以“b!=3”不参与剪枝，由条件“a=3”得到元组所在bucketid为642。在执行此查询语句时就只需要扫描bucketid为642的bucket分片包含的数据元组。优化器剪枝结果保存在关键数据结构BucketInfo中，BucketInfo设计如下：typedef struct BucketInfo { NodeTag type; List *buckets; /* 对应父表要扫描的bucket分片，DN只扫描自己的bucketid。如果剪枝状态不等于BUCKET_EMPTY，buckets为NULL那么表示扫描所有的分区 */ HBucketPruningStatus status; /* 表示剪枝结果的状态 */ Expr *expr;} BucketInfo;其中，buckets表示剪枝得到的要扫描的bucket分片，status表示剪枝结果状态，分为：BUCKETS_UNINITIED：还未剪枝，结果未知。BUCKETS_FULL：生成包含所有bucket的bitmapset。BUCKETS_EMPTY：生成不包含bucket的剪枝结果。BUCKETS_PRUNED：不允许剪枝。BucketInfo包含DN要扫描的分片信息，由CN下发给DN执行。在执行时，Scan算子通过剪枝结果状态和buckets列表获取到实际要扫描的bucketid，并通过系统表打开对应bucket的relation。注意下发的bucketids是全局的，DN通过bucketmap来判断哪些bucketid是本机的，只扫描本机的bucketid。动态剪枝从DN上获取的表定位信息保存在关键数据结构DistqryRelationLocInfo中，设计如下：typedef struct { Oid relid; /* 表OID */ char locatorType; /* 定位器类型，LOCATOR_TYPE_HASH */ List* partAttrNum; /* 分布列属性 */ List* node_list; /* 数据所在的节点索引 */ ListCell* roundRobinNode; /* 要使用的下一个节点的索引 */ NameData gname; uint2* buckets_ptr; /* 指向本地bucket-node映射的指针 */ bool isbucket;} DistqryRelationLocInfo;其中，partAttrNum表示分布列属性，relid表示表的oid，locatorType表示定位器类型，在hashbucket动态剪枝场景中默认设为LOCATOR_TYPE_HASH。2.4 执行器  执行器是GaussDB数据库核心组件之一，负责执行优化器生成的执行计划，将查询结果返回给用户。在执行过程中，执行器会根据执行计划的不同节点进行相应的操作，如扫描、聚合、排序等。以堆表索引扫描为例介绍执行器的工作。执行器会根据优化器生成的扫描计划，先初始化扫描相关的数据结构，创建扫描键，指定初始化扫描目标；在索引中查询满足条件的索引元组，并获取该元组内记录的bucketid以及tid（元组id），获取相应的bucket分片（文件），从而缩小目标元组的扫描范围；最后执行器根据之前获取的tid读取上述锁定bucket分片中的block，获取目标元组并返回给客户端。    2.4.1 hash分片执行器扫描GaussDB支持普通表和分区表扫描，其中分区表扫描是基于普通表来实现的，主要区别是普通表仅扫描一个数据文件，分区表可以理解为扫描多个数据文件。hashbucket表为了更均匀的切分数据文件，把数据按照hash进行分片，支持两种hash方案，即在普通表上支持hash分片，和在分区表上支持hash分片。2.4.1.1 hash分片扫描流程当前GaussDB涉及到hash分片扫描的执行算子有：SeqScan（顺序扫描算子）、IndexScan（索引扫描算子）、IndexOnlyScan（仅索引扫描算子）、TidScan（Tuple ID扫描算子）、BitmapIndexScan（位图索引扫描算子）等。每一个算子都可能经过初始化、执行、重置、结束四个阶段。以顺序扫描表的初始化为例，下图3展示增加hash分区后的初始化流程图。其中红色分支是为hash分区表新增的路径。对于其他扫描方式的处理方式类似。图3  顺序扫描初始化流程图（1）判断扫描表是否为hash分区表上图中比较重要的一步是如何区分待扫描的对象是否存在hash分片。在元数据设计中，一个表是否存在hash分片由字段relbucket标识。因此，在扫描对象时，我们仅需要读取这个字段来判断是否存在hash分片。（2）获取普通表的hash分片的文件号执行计划中给出了要扫描的对象和表的hash分片号，需要根据这两个信息来获取分片对应的数据文件编号。Relation中保存了每个bucketid对应的文件编号, 可以直接读取。（3）hashbucket表扫描普通堆表仅管理一个物理数据文件，hashbucket表需要管理若干个bucket，每个bucket相当于一个普通堆表。对于普通堆表，在初始化阶段生成扫描描述符，用于记录扫描状态；在扫描阶段从数据库文件中读取数据；在扫描结束阶段释放占有的资源。扫描hashbucket表时，需要扫描其所有的bucket，在操作单个bucket时，借助普通堆表的访问接口，复用普通堆表的执行器框架。2.4.1.2 hash分片表访问接口用户视角不关注hashbucket表和普通堆表的存储和读取方式，因此我们在堆表和hashbucket表上封装一层通用扫描处理程序，在执行器框架中调用通用接口。普通堆表又抽象出一层TableAM层区分astore表和ustore表，由抽象接口根据表类型动态绑定具体的调用接口，目前hashbucket表仅支持astore存储，所以TableAM层不在此描述。在表扫描开始时会创建堆表或hashbucket表的扫描描述器，表访问接口会判断当前表是否是hashbucket表，根据表是否是hashbucket表执行相应的访问接口。hashbucket表复用普通堆表的访问接口，由于hashbucket表底层管理了多个堆表，当一个bucket分片扫描完成时，即当前bucket分片中没有数据可读，会切换到下一个bucket进行读取，如此循环直到所有bucket都被读取。    hashbucket表的扫描描述符HBktTblScanDescData 数据结构定义为：typedef struct HBktTblScanDescData { Relation rs_rd; /* 哈希分片表的Relation */ struct ScanOperator * scan_state; oidvector* h_bkt_list; /* bucket列表，用于管理待扫描的bucket */ int curr_slot; /* 记录当前正在扫描的bucket编号 */ Relation curr_bkt_rel; /* 当前扫描bucket的堆表结构 */ TableScanDesc * curr_bkt_scan; /* 当前bucket的TableScan算子 */} HBktTblScanDescData;typedef struct HBktTblScanDescData { Relation rs_rd; /* 哈希分片表的Relation */ struct ScanOperator * scan_state; oidvector* h_bkt_list; /* bucket列表，用于管理待扫描的bucket */ int curr_slot; /* 记录当前正在扫描的bucket编号 */ Relation curr_bkt_rel; /* 当前扫描bucket的堆表结构 */ TableScanDesc * curr_bkt_scan; /* 当前bucket的TableScan算子 */} HBktTblScanDescData;创建hashbucket表扫描描述符HBktTblScanDesc流程如下：从BucketInfo中加载待扫描的buckets。创建并初始化扫描描述符HBktTblScanDesc。打开第一个待扫描的bucket。为当前扫描的bucket开启一个Heap表扫描描述符HeapScanDesc。对应 SamplingScan、BitmapHeapScan、TidScan等方式的描述符创建流程类似，仅需要为当前处理的bucket创建相应的heap扫描方式。对于其他访问接口类似，即借助堆表的接口操作每一个bucket。当一个bucket访问完成时，需要切换到下一个bucket，具体实现不再详述。2.4.1.3 hash分片索引访问接口索引的访问接口抽象和表接口的抽象类似。封装hashbucket表和非hashbucket表索引扫描的通用接口，在执行器框架中调用通用接口，在TableAm层区分astore和ustore绑定不同接口。hashbucket表的索引访问接口也同样是使用普通堆表的接口，扫描完一个分片之后，切换到下一个分片，具体实现不再赘述。以上内容从优化器剪枝、执行器两方面对hashbucket进行了解读，下篇将从段页式方面继续介绍GaussDB高弹性技术，敬请期待！   

书接上文GaussDB关键技术原理：高弹性（二）从优化器剪枝、执行器两方面对hashbucket进行了解读，本篇将从段页式技术方面继续介绍GaussDB高弹性技术。3 段页式3.1 段页式存储根据前文的介绍，hashbucket需要对文件进行分片，如果直接对单文件管理的数据文件进行切片，将会产生表数量*1024个文件，在表数量较多的场景下，产生的小文件数量多，导致文件管理系统的压力较大，因此，引入段页式管理，属于一个库表空间下的所有表共同使用一组段页式文件，防止bucket化拆分后小文件多的问题。图1是存储引擎架构示意图，从整个数据库的组成架构看，段页式在其中是存储引擎中最底层的一种文件管理方式，和单文件管理相并列，通过一组段页式文件管理所有用户表，减少单文件数量，从而降低文件系统的压力。段页式管理和单文件管理通过smgr层（介质管理器）对上层提供相同的接口，实现和缓冲区的读写交互，上层业务不感知底层存储方式发生的变化。​为了向SQL层提供一套接口，段页式表引入了逻辑block的概念，逻辑block是连续页号的page，上层逻辑访问段页式表使用的是逻辑block。每个段页式表都有一个对应的SegmentHeader，SegmentHeader维护了段页式表使用的逻辑block到实际的段页式物理block的映射关系。SegmentHeader管理了一个用户表的所有元数据信息，尤为重要，设计如下：typedef struct SegmentHead { uint64 magic; XLogRecPtr lsn; uint32 nblocks; // block number reported to upper layer uint32 total_blocks; // total blocks can be allocated to table (exclude metadata pages) uint64 reserved; BlockNumber level0_slots[bmt_header_level0_slots]; BlockNumber level1_slots[bmt_header_level1_slots]; BlockNumber fork_head[segment_max_forknum + 1];} SegmentHead;其中，比较重要的有：nblocks指的是上层看到的最大逻辑页号，和页式存储中的文件大小的概念是一样的，smgrnblocks的返回值。total_blocks指的是分配的所有extent，数据块的个数总和，当申请的extent的pages全部用完时，会再申请一个extent。level0_slots和level1_slots存放的是逻辑block到物理block的映射关系，对于序号靠前的extent，起始位置直接存储在 level0_slots中。level0_slots存满之后，会使用level1_slots中存放的level0_slots页面记录。fork_head指的是所有fork的segment head，也以数组的形式存储在main fork的segment head中。每个segment head中的 fork_head[0] 一定等于自己。hashbucket表采用了段页式存储的方式。在段页式存储管理下，表空间和数据文件采用段（Segment）、区（Extent）以及页（Page/Block）作为逻辑组织，进行存储的分配和管理。具体来说，一个database在其所存在的每个表空间中，都拥有一组独立的段页式文件，如下图2所示：某个库下的一个表空间的段页式文件由1-5号文件组成。图2 段页式物理结构示意图由于属于一个表空间下的所有段页式表的数据都会写到这几个段页式文件中，所以这几个文件会膨胀到TB量级，段页式文件仍然沿用GaussDB页式文件的切分方式，按照1GB进行切分，将一个物理文件称为一个slice，使用2.1, 3.1来表示。拥有相同前缀的一组slice组成一个段页式文件管理系统（SegLogicFile）。SQL层将每个SegLogicFile看作一个无限大的物理文件。每个SegLogicFile称为一个ExtentGroup，文件组织格式如下图3。图3 段页式逻辑文件组织格式MapHeader：用来存放管理BitMap page的元信息；BitMapPages：Bitmap页面，用来管理DataPages的extent使用情况，页面中的一个bit位表示代表1个extent，0表示空闲，1表示已使用。每个ExtentGroup中extent大小不一样，所以1个bit位表示的extent大小也不一样；ReversePointerPages：reversepointer页面，用来管理DataPages的extent的属主信息，即属于哪个SegmentHeader管理。DataPages：数据表记录存放区域，不同文件按照不同数量的block组成extent。GaussDB中有fork的概念，用于管理每个表的数据和元数据信息，如表数据存的文件称作MAIN FORK，空闲页面信息称为FSM FORK，visibility map称为VM FORK。这些fork存储在各自的物理文件中，文件用后缀来区分，1_fsm, 1_vm，MAIN FORK不带后缀。所以，对于GaussDB单文件存储来说，只需要知道relfilenode和fork number，就能拼出物理文件名。 为了前向兼容，段页式保留了fork的概念，一个fork使用一组segment，依然用“relfilenode + fork number +逻辑页号”来访问数据。把MAIN FORK的SegmentHeader，作为该表的relfilenode，存储在系统表pg_class中；其它fork的SegmentHeader存储在MAIN FORK的SegmentHeader中。数据访问的流程如下图4所示：其中，表t1在pg_class中的relfilenode是4157，通过访问段页式1号文件的4157页面可以访问到其SegmentHeader，根据上层传入的逻辑页面号0可以通过Block Map Tree找到物理页面的位置（2号文件的4157页面）。通过fork header中的fsm页面4160可以访问到fsm的segmentheader所在的物理信息（1_fsm文件的4160页面）。由上可知，段页式表通过唯一的Segment Header进行表示，而段页式表中的数据则是存放在若干个Extent中，每个Extent都是由固定数量的Page组成的。所有Extent由1-5号文件组成段空间，所有表都从该段空间中分配数据。因此表的个数和实际物理文件个数无关。每个表有一个逻辑segment，该表所有的数据都存在该segment上。每个segment会挂载多个extent，每个extent是一块连续的物理页面。 在表或者分区数量较多的场景下， 段页式存储相比于页式存储生成的文件数量会大大减少，从而降低对文件系统的规格要求，减轻对操作系统IO栈产生的压力，提升数据库的吞吐能力。hashbucket表对数据文件进行切片，如果不采用段页式存储可能会产生大量的小文件，在进行CHECKPOINT这种IO重度操作的时候，需要对大量文件进行sync操作，此时很有可能造成长时间的IO等待，影响数据库的整体性能。段页式目前支持五种大小的Extent，分别是8K/64K/1M/8M/32M，对应五种不同Extent大小的段页式文件（文件名1/2/3/4/5），称之为段页式文件组，这一组文件中1号文件用来管理段页式表元数据，2到5号文件用来存储用户表数据。对于一个segment来说，每一次扩展的Extent的大小是固定的。前16个extent大小为64K，第17到第143个extent大小为1MB，依次类推。具体参数如下表1所示。初始时表比较小，分配的Extent粒度较小，当表变得比较大的时候，分配的粒度较大。这样做的好处是可以在空间利用率和分配频率之间做一个很好的平衡。3.2 hashbucket段页式 hashbucket位于段页式的下层，将段页式的文件组bucket化分片，如下图6所示hashbucket表的bucket桶个数固定为1024个。每个DN分片拥有的bucket数量为1024/DN分片数量个。将上一章节介绍的段页式文件（1-5号）进行切片，拥有相同hash值的数据存在一组bucket段页式文件中，命名方式为文件编号_bucketid_[vm/fsm]，其中1号小bucket段页式文件仍然存储元数据信息，主要是SegmentHeader，管理属于bucket 0的数据Extent；2号小bucket段页式文件存储真正的用户数据。因此以tablespace为粒度，每个库的每个tablespace拥有1024组1-5号bucket段页式文件。 hashbucket表与段页式的寻址方式类似，在系统表pg_class的relfilenode表示1号段页式文件中的一个页面号，表示最上层的元数据管理页面，通过如下结构体实现：typedef struct BktMainHead { uint64 magic; XLogRecPtr lsn; BlockNumber bkt_main_head_map[BUCKETMAPLEN];} SegmentHead;其中，bkt_main_head_map是4字节*1024的数组，下标表示hashbucket桶的编号，内容表示小段页式文件中SegmentHeader所在的页面号。以创建一张hashbucket表t1为例，寻址过程如下图7所示：P1：通过pg_class的relfilenode能够访问到段页式1号文件中的BktMainHead页面4157。 P2：从BktMainHead的内容找到对应bucket 0 SegmentHeader所在的页面号，访问对应bucket 0的1号文件1_b0的页面65。P3：通过页面1_b0的页面65的SegmentHeader记录的Extent位置信息存入对应的数据，或者根据传入的逻辑页面号翻译出要访问的物理页面位置。P4：根据要访问的物理页面信息访问对应的bucket段页式文件2_b0。hashbucket的元数据管理采用上述方式主要为了后续扩容考虑，为了实现物理文件搬迁，我们需要直接把某个DN分片的bucket文件搬迁到新节点，为了保证文件搬迁后仍然可以寻址成功，需要在新DN build完元数据之后进行BktMainHead的更新，将即将搬迁至新节点的所有bucket 1号文件中的SegmentHeader所在的页面号更新到段页式1号文件的BktMainHead中。hashbucket表的反向指针在bucket 1号文件中，SegmentHeader页面对应的反向指针存储的是1号段页式文件BktMainHead页面所在的页面号，因此需要在扩容期间基线数据搬迁完成时更新搬迁至新节点所有bucket 1号文件的SegmentHeader的反向指针。3.3 TOAST TOAST是GaussDB中一种存储大数据的机制。TOAST表是否创建是根据原表列类型决定的，数据是否存到TOAST表中是根据数据大小决定的。创建原表时如果包含变长类型（text类型等）的列就会自动创建并关联TOAST表一张TOAST表负责行外存储，如下图8所示。GaussDB不允许一行数据跨页存储，当单个元组大小超过2K时，会自动触发TOAST机制，对数据进行压缩和切片，将实际数据存储到TOAST表。TOAST表不支持用户手动创建，随原表一起创建和删除。TOAST表和索引的存储类型和原表保持一致，原表和TOAST表通过OID关联，pg_class中原表会记录reltoastrelid（与原表关联的TOAST表的OID，如果没有则为0），在pg_class中通过OID可以找到TOAST表。 图8 hashbucket TOAST表元数据3.3.1 hashbucket TOAST数据管理方式 由于hashbucket扩容会将属于老节点的文件直接搬迁至新节点，此时如果TOAST指针中记录了老节点的OID信息，由于OID是本地维护的，搬迁到新节点可能出现访问不到数据的问题。因此，hashbucket表TOAST数据管理方式是由产生TOAST的列存储TOAST指针，存储小段页式1号文件的relfilenode。对TOAST表操作时通过小段页式1号文件SegmentHead页面的反向指针查询到当前hashbucket表大段页式1号文件的页面号，再通过反向指针获取到所属TOAST表的OID，如下图9所示： 图9 hashbucket TOAST表寻址示意图数据插入时会先对可压缩的列执行压缩，然后判断元组长度是否能触发TOAST以及类型是否可以执行外部存储，多数情况下压缩后的元组长度不满足2K的阈值所以不会触发TOAST机制。访问数据时需要访问TOAST表中的压缩数据，对该数据解压。关键数据结构TOAST指针varatt_external，存储获取行外存储数据所需的信息，数据结构设计如下：typedef struct varatt_external { int32 va_rawsize; /* 原始数据大小（包括header） */ int32 va_extsize; /* 外部保存大小（不包括header） */ Oid va_valueid; /* TOAST表中值的唯一id */ Oid va_toastrelid; /* toast表id */} varatt_external;其中va_extsize表示外部数据大小，va_rawsize表示原始未压缩数据大小，当且仅当va_extsize小于va_rawsize减var header大小时，数据会被压缩。以上内容从段页式技术方面对GaussDB高弹性能力进行了解读，下篇将从hashbucket扩容方面继续介绍GaussDB高弹性技术，敬请期待！

数据库管理服务器维护整个数据库各个组件的状态信息，提供对外的查询接口，提供如下组件状态信息查询：数据库整体健康状态监测：Normal（数据库正常），Degraded（数据库可用），Unavailable（数据库不可用）。CM状态监测：Primary（主角色，负责数据库仲裁），Standby（备角色），Down（实例停止），Pending（启动后，CMS主备待仲裁）。ETCD状态监测：StateLeader（ETCD主角色，负责处理客户端请求），StateFollower（ETCD备角色，负责响应主节点请求），Down（ETCD故障）。DN状态监测：Primary（DN主角色），Standby（DN备角色），Pending（DN主备待仲裁），Unknown（DN主备角色未知），Normal（DN正常），Need repair（DN需要修复），Starting（DN正在启动），Wait promoting（DN等待升主），Demoting（DN正在降备），Promoting（DN正在升主），Building（正在重建备实例），Manually stopped（DN被手工停止），Disk damage（磁盘损坏），Port conflicting（端口冲突），Build failed（重建备实例失败），Catchup（主备机追赶），CoreDump（DN coredump），ReadOnly（DN只读），Down（DN故障）。6.2 数据库实例健康检测支持对QPS/TPS，IOPS，IO吞吐量，buffer命中率，日志写次数，日志写响应时间，数据块读写次数，数据块读写响应时间，实例时间分布等进行监测，涉及到如下分类：OS，Instance，Memory，File，Object，Workload，Session/Thread，Transaction，Query，Cache/IO，Communication，Utility，Lock，Wait Events，Configuration。6.3 用户负载健康检测支持workload，session和query三个维度的用户负载健康检测，帮助用户发现负载性能和功能故障：Workload: 负载DDL，DML，DCL构成关系，DML中 Select，Update，Insert，Delete构成关系，以及事务特性指标；比如：检测数据库内workload上的SQL数量分布，可执行：select * from DBE_PERF.summary_workload_sql_count;检测数据库内汇聚的负载事务信息，可执行：select * from DBE_PERF.summary_workload_transaction;详细关于Workload的负载健康检测视图，见《开发者指南》中“DBE_PERF Schema > Workload”章节。Session: 用户会话多维度统计信息，包括session基本描述信息，sesison当前活动，session当前等待事件；比如：检测数据库内各节点上正在运行的线程相关的信息，可执行：select * from DBE_PERF.global_session_stat_activity;检测所有节点上工作线程以及辅助线程的阻塞等待情况，可执行：select * from DBE_PERF.global_thread_wait_status;详细关于Session的负载健康检测视图，见《开发者指南》中“DBE_PERF Schema > Session/Thread”章节。Query: 用户慢查询信息，包括query完整的性能指标，执行计划等信息。比如：检测所有节点上已经转储的慢查询信息，可执行：select * from DBE_PERF.global_slow_query_info;详细关于Query的负载健康检测视图，见《开发者指南》中“DBE_PERF Schema > Query”章节。6.4 数据库健康告警支持多维度的告警信息上报：数据库HA：数据库各组件非正常状态告警。数据库关键事件：数据库各组件异常，数据库主备关系变化，磁盘故障，备机重建，分片只读，备机强制升主等。数据库实例关键事件：RTO告警，流控告警，TPS/latancy，P95异常，活跃session异常，节点连接池利用率异常，登入登出次数异常等。

SELECT XMLELEMENT( MSG,  XMLELEMENT(MSGCAP, '交易明细'),             XMLELEMENT(INFO,                XMLELEMENT(FD,XMLATTRIBUTES( '中文被转码' AS NAME), '对手信息' )             )          )

我看官方文档上分为主备版和分布式版，又有文档分为集中式和分布式，请问主备版就是集中式的意思吗？

前提:我们其中一个节点服务器做了raid5磁盘阵列重建, 之后用gs_replace -t config -h  xxx  和gs_replace -t start -h做了集群恢复.目前集群恢复至Normal状态.现象:       业务方反馈说, 做完操作后,使用kettle连接数据库经常断连, 有时成功有时失败,  且写失败次数大于读失败次数       已排除网络问题, 且业务方如果手动执行SQL正常,但大,长SQL无法正常执行这种情况怎么处理?

8月22~24日，由IT168联合旗下ITPUB、ChinaUnix两大技术社区主办的第15届中国数据库技术大会（DTCC2024）在北京召开。大会以“自研创新 数智未来”为主题，邀请上百位数据库领域顶尖专家和学者，一起交流数据库先进技术和实践案例，畅想数据库未来发展前景。华为云数据库各个专家分别带来了精彩的演讲，获取现场演讲资讯，cid:link_0

华为云开发者日·上海站来啦！参加“使用GaussDB(for MySQL)挑战数据业务汇报任务”体验项目提出你的建议或使用体验有机会获得开发者盲盒礼包惊喜不容错过，快叫上小伙伴一起来参加吧~【体验项目】使用GaussDB(for MySQL)挑战数据业务汇报任务【活动时间】2024年8月30日-9月6日【参与方式】直接在此活动帖下方回帖提建议/提建议即可比如对产品功能的改进建议、对活动流程的感想、对现场活动的感悟等等PS：不要少于30字哦~【获奖规则】奖项设置有效回复楼层评选条件获奖名额激励礼品优质建议奖20对产品功能有改进价值的建议1名开发者盲盒礼品价值50-100元积极反馈奖20优质建议奖轮空的情况下进行抽取抽取1名开发者盲盒礼品价值50元【活动规则】1、本帖的回帖建议不少于30字，仅限于对“使用GaussDB(for MySQL)挑战数据业务汇报任务”体验项目，其他项目建议不参与此次活动，否则将视为无效内容。2、本次活动将根据实际参与情况发放奖励，包括但不限于用户百分之百中奖或奖项轮空的情况；以上奖品均为实物奖品，具体发放视出库情况而定；3、活动预计于结束后七天内完成奖项公示，并于结束后15个工作日内完成邮寄。【温馨提示】1、请务必使用个人实名账号参与活动（IAM、企业账号等账号参与无效）。如一个实名认证对应多个账号，只有一个账号可领取奖励，若同一账号填写多个不同收件人或不同账号填写同一收件人，均不予发放奖励。2、所有获得奖品的获奖用户，请于获奖后3日内完成实名认证，否则视为放弃奖励。

GaussDB数据库中的MERGE INTO介绍一、前言随着数据量的爆炸性增长，数据库管理系统（DBMS）的功能和性能要求也在不断提升。GaussDB 作为一款先进的关系型数据库管理系统，其 MERGE INTO 语句在数据整合、更新操作中发挥了重要作用。MERGE INTO 语句允许用户在单次操作中执行插入和更新操作，大大提高了数据处理效率。本文将举例为大家讲述 GaussDB 中 MERGE INTO 语句的使用。二、GaussDB MERGE INTO 语句的原理概述1、MERGE INTO 语句原理GaussDB 的 MERGE INTO 语句是基于 SQL 标准的，通过单个SQL语句实现了数据的UPDATE和INSERT操作。该语句在执行时，会根据指定的条件比较源表和目标表的数据。当源表和目标表中数据针对关联条件可以匹配上时，则进行UPDATE操作；当源表和目标表中数据针对关联条件无法匹配时，则进行INSERT操作。这种操作方式减少了数据传输的开销，避免多次执行，提高了数据处理的效率。2、MERGE INTO 的语法MERGE [/*+ plan_hint */] INTO table_name [ partition_clause ] [ [ AS ] alias ]USING { { table_name | view_name } | subquery } [ [ AS ] alias ]ON ( condition )[WHEN MATCHED THENUPDATE SET { column_name = { expression | subquery | DEFAULT } |( column_name [, ...] ) = ( { expression | subquery | DEFAULT } [, ...] ) } [, ...][ WHERE condition ]][WHEN NOT MATCHED THENINSERT { DEFAULT VALUES |[ ( column_name [, ...] ) ] VALUES ( { expression | subquery | DEFAULT } [, ...] ) [, ...] [ WHERE condition ] }];where partition_clause can be:PARTITION { ( partition_name ) | FOR ( partition_value [, ...] ) } |SUBPARTITION { ( subpartition_name ) | FOR ( subpartition_value [, ...] ) }NOTICE: 'partition_clause' is only avaliable in CENTRALIZED mode!NOTICE: 'subquery' in the UPDATE and INSERT clauses are only avaliable in CENTRALIZED mode!3、语法解释权限：进行MERGE INTO操作的用户需要同时拥有目标表的UPDATE和INSERT权限，以及源表的SELECT权限。plan_hint子句：可选，以/*+ */的形式在MERGE关键字后，用于对MERGE对应的语句块生成的计划进行hint调优INTO talbe_name：指定正在更新或插入的目标表。USING子句：指定源表，源表可以为表、视图或子查询。ON子句：关联条件，用于指定目标表和源表的关联条件。不支持更新关联条件中的字段。WHEN MATCHED / WHEN NOT MATCHED子句：不支持INSERT子句中包含多个VALUES。WHEN MATCHED和WHEN NOT MATCHED子句顺序可以交换，可以缺省其中一个，但不能同时缺省，不支持同时指定两个WHEN MATCHED或WHEN NOT MATCHED子句。DEFAULT：用对应字段的缺省值填充该字段。如果没有缺省值，则为NULL。WHERE condition：UPDATE子句和INSERT子句的条件，只有在条件满足时才进行更新操作，可缺省。不支持WHERE条件中引用系统列。三、GaussDB MERGE INTO 语句的应用场景MERGE INTO 语句在多种场景中都有广泛的应用。例如，在数据迁移过程中，可以使用 MERGE INTO 语句将源数据库中的数据迁移到目标数据库，同时保证数据的完整性和一致性。此外，在数据整合、ETL过程、实时数据处理等场景中，MERGE INTO 语句都能发挥其高效的数据处理能力。四、GaussDB MERGE INTO 语句的示例1、示例场景举例假设我们有两个表：source_table 和 target_table。source_table 包含最新的销售数据，而 target_table 存储历史销售数据。我们的目标是更新 target_table 中的销售数据，并插入新的销售记录。2、示例实现过程以下是使用 GaussDB MERGE INTO 语句的实现示例1）创建两个实验表，并初始化测试数据--创建测试表target_table,存储历史销售数据CREATE TABLE public.target_table(product_id VARCHAR(20),product_name VARCHAR(20),sales_sum_number INT,sales_sum_amount MONEY,create_date VARCHAR(8),update_date VARCHAR(8));--插入测试数据INSERT INTO public.target_table(product_id,product_name,sales_sum_number,sales_sum_amount,create_date,update_date) VALUES('P1001','books',100,1000,'20240101','30001231');INSERT INTO public.target_table(product_id,product_name,sales_sum_number,sales_sum_amount,create_date,update_date) VALUES('P1002','pens',200,400,'20240102','30001231');--创建测试表source_table,包含最新的销售数据CREATE TABLE public.source_table(product_id VARCHAR(20),product_name VARCHAR(20),sales_sum_number INT,sales_sum_amount MONEY,create_date VARCHAR(8));--插入测试数据INSERT INTO public.source_table(product_id,product_name,sales_sum_number,sales_sum_amount,create_date) VALUES('P1001','books',50,500,'20240103');INSERT INTO public.source_table(product_id,product_name,sales_sum_number,sales_sum_amount,create_date) VALUES('P1003','toys',100,1000,'20240103');--查看结果SELECT * FROM public.target_table;SELECT * FROM public.source_table;2）更新 target_table 中的销售数据，并插入新的销售记录。--更新 target_table 中的销售数据，并插入新的销售记录。MERGE INTO target_table AS tUSING source_table AS sON (t.product_id = s.product_id)WHEN MATCHED THENUPDATE SET t.sales_sum_number=t.sales_sum_number + s.sales_sum_number,t.sales_sum_amount = t.sales_sum_amount + s.sales_sum_amount,t.update_date = s.create_dateWHEN NOT MATCHED THENINSERT (product_id,product_name,sales_sum_number,sales_sum_amount,create_date,update_date) VALUES (s.product_id,s.product_name,s.sales_sum_number,s.sales_sum_amount,s.create_date,'30001231');--查看执行结果SELECT * FROM public.target_table;3）查看并比对执行结果更新之前的目标表target_table：源表source_table:更新之后的目标表target_table：上述示例中，我们通过 MERGE INTO 语句将 source_table 中的销售数据与 target_table 中的数据进行匹配。在目标中，产品“P1001”销售数量增加了50，销售金额增加了500，更新日期更新为源表中的创建日期。产品“P1002”的销售数据没有变化。产品“P1003”作为一条新的销售数据插入到了历史表（目标表）中。这样，我们就轻松地将最新的销售数据整合到 target_table 中，同时保持数据的完整性和一致性。特别说明：在实际业务操作时，需要提前做好规划，确保执行的准确定、数据的准确性以及数据的安全性，同时做好各个环节的备份等操作。五、小结MERGE INTO 语句在GaussDB数据库中是一个非常好用、方便的SQL工具。同时，在数据处理工作中起着非常重要的作用，它能够提高数据处理效率，简化数据处理流程，满足各种数据处理需求。本文通过在GaussDB数据库中模拟了一则简单的示例为大家进行了讲解，希望可以帮助读者更好的理解与使用。——结束

[omm@node01 ~]$ cm_ctl query -Cvipd[ CMServer State ]node node_ip instance state--------------------------------------------------------------------------------1 192.168.30.51 192.168.30.51 1 /gaussdb/cluster/data/cm/cm_server Primary2 192.168.30.52 192.168.30.52 2 /gaussdb/cluster/data/cm/cm_server Standby3 192.168.30.53 192.168.30.53 3 /gaussdb/cluster/data/cm/cm_server Standby[ ETCD State ]node node_ip instance state------------------------------------------------------------------------------1 192.168.30.51 192.168.30.51 7001 /gaussdb/cluster/data/etcd StateFollower2 192.168.30.52 192.168.30.52 7002 /gaussdb/cluster/data/etcd StateFollower3 192.168.30.53 192.168.30.53 7003 /gaussdb/cluster/data/etcd StateLeader[ Cluster State ]cluster_state : Degradedredistributing : Nobalanced : Nocurrent_az : AZ_ALL[ Coordinator State ]node node_ip instance state----------------------------------------------------------------------1 192.168.30.51 192.168.30.51 5001 8000 /gaussdb/cluster/data/cn Deleted2 192.168.30.52 192.168.30.52 5002 8000 /gaussdb/cluster/data/cn Normal3 192.168.30.53 192.168.30.53 5003 8000 /gaussdb/cluster/data/cn Deleted[ Central Coordinator State ]node node_ip instance state----------------------------------------------------------------------2 192.168.30.52 192.168.30.52 5002 /gaussdb/cluster/data/cn Normal[ GTM State ]node node_ip instance state sync_state-------------------------------------------------------------------------------------------------------1 192.168.30.51 192.168.30.51 1001 /gaussdb/cluster/data/gtm P Primary Connection ok Sync2 192.168.30.52 192.168.30.52 1002 /gaussdb/cluster/data/gtm S Standby Connection ok Sync3 192.168.30.53 192.168.30.53 1003 /gaussdb/cluster/data/gtm S Standby Connection ok Sync[ Datanode State ]node node_ip instance state | node node_ip instance state | node node_ip instancestate---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------1 192.168.30.51 192.168.30.51 6001 33100 /gaussdb/cluster/data/dn/dn_6001 P Primary Normal | 2 192.168.30.52 192.168.30.52 6002 33100 /gaussdb/cluster/data/dn/dn_6002 S Standby Normal | 3 192.168.30.53 192.168.30.53 6003 33100 /gaussdb/cluster/data/dn/dn_6003S Standby Normal2 192.168.30.52 192.168.30.52 6004 33120 /gaussdb/cluster/data/dn/dn_6004 P Standby Normal | 1 192.168.30.51 192.168.30.51 6005 33120 /gaussdb/cluster/data/dn/dn_6005 S Primary Normal | 3 192.168.30.53 192.168.30.53 6006 33120 /gaussdb/cluster/data/dn/dn_6006S Standby Normal3 192.168.30.53 192.168.30.53 6007 33140 /gaussdb/cluster/data/dn/dn_6007 P Primary Normal | 2 192.168.30.52 192.168.30.52 6008 33140 /gaussdb/cluster/data/dn/dn_6008 S Standby Normal | 1 192.168.30.51 192.168.30.51 6009 33140 /gaussdb/cluster/data/dn/dn_6009S Standby Normal[omm@noGaussdb分布式 集群状态为degraded，其中2个节点显示为delete，如何让集群状态回归正常？

 --登录数据库 su - omm gsql -d postgres -h 192.168.30.51 -U root -p 8000  --创建用户 CREATE USER tpcds WITH PASSWORD 'Zdxjyyds.!';  --创建数据库 CREATE DATABASE dxj ENCODING='UTF8';  --更改数据库dxj归属用户tpcds alter database dxj owner to tpcds;  --赋予权限 grant usage on schema public to tpcds; grant  all  privileges  on schema public to tpcds;  --切换用户和数据库 \c dxj tpcds CREATE TABLE customer_address ( ca_address_sk integer NOT NULL , ca_address_id character(16) NOT NULL , ca_street_number character(10) , ca_street_name character varying(60) , ca_street_type character(15) , ca_suite_number character(10) , ca_city character varying(60) , ca_county character varying(30) , ca_state character(2) , ca_zip character(10) , ca_country character varying(20) , ca_gmt_offset numeric(5,2) , ca_location_type character(20) ) DISTRIBUTE BY HASH (ca_address_sk) PARTITION BY RANGE (ca_address_sk) ( PARTITION P1 VALUES LESS THAN(5000), PARTITION P2 VALUES LESS THAN(10000), PARTITION P3 VALUES LESS THAN(15000), PARTITION P4 VALUES LESS THAN(20000), PARTITION P5 VALUES LESS THAN(25000), PARTITION P6 VALUES LESS THAN(30000), PARTITION P7 VALUES LESS THAN(40000), PARTITION P8 VALUES LESS THAN(MAXVALUE) ) ENABLE ROW MOVEMENT;提示如下报错：--问题描述 ERROR:  permission denied for schema public DETAIL:  N/A

--问题描述 创建自定义表空间报错gaussdb=> CREATE TABLESPACE test RELATIVE LOCATION '/gaussdb/test/'; ERROR:  relative location can only be formed of 'a~z', 'A~Z', '0~9', '-', '_' and two level directory at most 

请问在那个数据库执的SQL语句，在gs_log日志不记录吗？应该在哪里查看？

官网也搜不到相关的信息！！！！！！！这是配置信息tpops元库信息