各位大佬，信创迁移，应用系统的mysql数据库业务数据迁移到高斯数据库迁移方案有吗，高斯数据库数据迁移接口支持哪些mysql版本？

GaussDB数据库主备架构的基本组件，以及基于华为云底座和轻量化部署TPOPS两种方式的典型高可用部署场景介绍。1、GaussDB数据库组件1.1 GaussDB数据库集中式主备集群基本组件CM由CM Agent、CM Server和OM monitor构成：CM Agent：管理服务组件，由OMM拉起（周期1秒），主要负责CMS、DN进程的保活及启停，仲裁指标采集、仲裁命令执行等。集群的每台主机上均有CM Agent进程。CMA故障可能会导致启停能力丢失、实例故障检测能力丢失。CM Server：管理服务组件，由CMA拉起（周期1秒），根据CM Agent上报的实例状态判定当前状态是否正常，是否需要修复，并下发指令给CM Agent执行。CM Server会将集群的拓扑信息保存在ETCD。OM Monitor：管理服务组件，由crontab定时任务控制拉起（周期1分钟），主要负责OMM、etcd、cm_agent进程的保活及启停DN节点：数据服务组件，由CMA拉起（周期1秒），负责存储业务数据、执行数据查询任务以及返回应用结果。DN主备节点之间采用Quorum复制或Paxos协议复制。ETCD节点：管理服务组件，由OMM自动拉起（周期1秒），主要协助CMS选主、持久化集群仲裁信息、保存集群的拓扑信息等。1.2 区域和可用区在高可用部署架构中区域（Region）和可用区（Available Zone）用来描述数据中心的位置。区域Region：指物理上相对独立的数据中心。每个区域完全独立，这样可以实现最大限度的容错能力和稳定性。在GaussDB数据库中资源创建成功后不能更换区域。可用区AZ：指同一区域内，电力和网络互相隔离的物理区域，比如同一个区域内的两个机房，一个AZ故障不会影响其它AZ。GaussDB数据库中在同一个Region内可以有多个AZ可用区，不同可用区之间物理隔离，但内网互通，既保障了可用区的独立性，又提供了低价、低时延的网络连接。不同Region的划分和多中心的高可用架构有关，比如生产/同城/灾备机房划分为不同的Region，然后在同一个Region内按照机房模块划分为不同的AZ域。也有可能生产和同城划分为同一个Region，灾备作为一个单独的Region，不同Region之间的RPO要求也是不同的。1.3 主备节点数据同步机制1.3.1 WAL日志机制GaussDB数据库为了保证数据在数据库发生故障时候可恢复，引入了Redo机制，也就是WAL日志，其思想是对数据文件的修改在提交之前都需要记录到日志文件中，也就是先写日志后写数据。当事务发生时，相关的操作记录会被组装并写入基于内存的RedoLogBuffer中。当RedoLogBuffer写满或事务没有更多日志记录需要写入时，这些日志记录会被提交给RedoLogHandler，并最终写入到XLog（即WAL日志）中。这样不需要在每次事务提交的时候都把数据页刷回到磁盘，因为出现崩溃的情况下可以用日志REDO来恢复数据库。WAL日志机制在数据库发生故障后可以通过xlog日志文件恢复数据、主备节点也可以通过日志文件进行数据同步、备份恢复时通过WAL日志可以实现PITR恢复。与MySQL中binlog不同之处是WAL日志主要关注于数据的物理修改记录，确保在数据文件修改之前相应的日志已经写入磁盘；而binlog日志则可能更侧重于记录数据的逻辑变化，如SQL语句的执行等。在GaussDB中可以使用逻辑复制的功能将xlog日志转换为类binlog日志格式进行逻辑回放等使用场景。1.3.2 同Region内主备节点复制在一主多备架构中，主机通过WalSender线程向备机同步日志，备机通过WalReceiver线程接受日志，并刷到本地盘，备机读取redo日志，完成主备之间的数据同步。WAL：Write-Ahead Logging，也称为XLog，预写日志系统。实现事务日志的标准方法，是指对数据文件（表和索引的载体）持久化修改之前必须先持久化相应的日志。WAL Receiver：数据库复制时备机创建的一个线程的名称。此线程用于从主机接收数据、命令，并反馈确认信息至主机。一个备机只有一个WALReceiver线程。WAL Sender：数据库复制过程中，主机接受到备机的连接请求后创建的一个线程的名称。此线程用于发送命令、数据到备机，并从备机接收信息。一个主机可能会有多个WAL Sender线程，每一个WAL Sender线程对应一个备机的一个连接请求。WAL Writer：数据库启动时创建的一个写Redo日志的线程，用于将内存中的日志写入到持久性设备中。REDO日志：记录对数据库进行操作的日志，这些日志包含重新执行这些操作所需要的信息。当数据库故障时，可以利用REDO日志将数据库恢复到故障前的状态。GaussDB数据库在同一个Region内1主多备的部署架构下，主备节点间采用Quorum或Paxos一致性复制协议，在事务提交前会进行一致性检测，满足半数以上的多数派响应后才可以提交。因此为了满足多数派选举，日志节点会部署为奇数。同时根据不同的业务可用模式，将日志同步分为不同的模式，有以下几种：最大保护模式：一主多备场景下，如果主机的一个事务必须等到该事务对应的xlog日志在多数派主机上都落盘后才能提交。如果因为网络原因或者多数的备机发生故障，此时主机的事务将无法提交。该模式下，可以保证RPO=0，参数设置synchronous_commit=on最大可用模式：当发现备机不可用时，会自动从最大保护模式切换为最大可用模式，保证在备机不可用时主机的事务能够继续执行。该模式下无法保证RPO=0，参数设置most_avaiable_sync=on最大性能模式：主机的事务在该事务对应的xlog日志在本地落盘之后就可以提交，主机的性能不受备机的影响。该模式下，在主机故障时，可能会有一定的数据丢失，参数配置synchronous_commit=off1.3.3 跨Region流式复制GaussDB跨Region之间的数据同步采用流式复制的方式，一般是在生产和灾备建立两套数据库集群，基于WAL日志建立日志复制关系。跨Region之间的复制不能保证RPO=0。流式复制是使用max_replication_slots（日志复制槽）、max_keep_log_seg（逻辑日志数）等配置来控制复制的速率，防止备机堆积过多日志影响性能。2、华为云GaussDB数据库高可用部署华为云GaussDB数据库有两种部署模式，一种是基于华为云HCS底座的，适合于本身已经建设了华为云IAAS平台，基于现有的云平台底座的运维和管理能力，减少重复建设的成本；另一种是轻量化TPOPS平台，TPOPS不依赖于华为云底座实现对GaussDB数据库实例的运维管理。本文主要介绍集中式架构下的高可用部署。2.1 基于华为云底座的高可用部署集中式主备版本的同城和异地部署的时候有不同的组合，有同Region多AZ部署、跨Region的多AZ部署。这里介绍几种典型的部署方案，其它参考官网材料。1）生产同城单Region部署左图为生产单中心1AZ3副本部署，适用于不要求站点级容灾，但是需要保证单中心故障高可用的场景。DN主备之间采用流复制进行数据同步，至少同步到一台备机，保证RPO=0。DN备节点故障，不中断业务的进行；DN主节点故障，自动进行主备切换。右图为生产同城3AZ4副本同城双活部署，由两个业务AZ和1个仲裁AZ组成，任何AZ故障能够保证RPO=0。AZ1和AZ2对等部署，AZ3作为第三方仲裁节点，不接入业务；AZ3作为仲裁AZ，在1个AZ故障状态下，保证ETCD的存活节点超过多数，从而保证数据的一致性DN主备之间采用流复制进行数据同步，跨AZ存在同步备，数据不会丢失。DN备节点故障，不中断业务的进行；DN主节点故障，自动进行主备切换。AZ1和AZ2之间可以手动切换，切换完成后业务继续运行2）生产同城跨Region部署（保证同城RPO=0）前文已经介绍到GaussDB数据库在不同Region之间划分为不同的集群进行部署，不同集群之间采用流式复制，不能保证RPO=0。基于华为云底座部署的时候，可能因为生产和同城机房在网络部署上划分为不同的网络区域Region，此时如果要保证RPO=0只能采用存储复制的方案。GaussDB数据库结合Dorado存储实现存算分离和存储级别的高可用方案，两个不同Region之间通过存储复制保证RPO=0。每个Region都有一套完整的数据库集群，并有完整的数据；集群内主备节点之间采用共享卷进行数据同步，保证RPO=0DN备节点故障，不中断业务的进行；DN主节点故障，自动进行主备切换跨region容灾需要手工切换闪存存储需要支持远程复制LUN，支持NAS文件系统并且和主机之间的连接使用IP网络连接如果没有要求生产和同城之间RPO=0，采用双Region部署，两个集群之间采用数据库跨Region流式复制的方式实现数据同步。另外有时候考虑到生产和同城的网络带宽及时延限制，主备之间的强一致同步会影响到性能，也会考虑生产同城双Region部署。但其实大多数场景下，生产和同城之间的网络时延在0.5ms左右，已经满足业务访问的时延要求了。对于灾备站点由于物理距离上的限制，网络时延会大很多，所以需要单独划分Region部署，并且不能保证RPO=0。因此，对于不想使用存储复制方案的高可用部署，推荐生产和同城一个Region、灾备站点一个Region的方案。2.2 基于轻量化TPOPS高可用部署GaussDB数据库的TPOPS轻量化部署不依赖于华为云底座，只需要部署TPOPS云数据库管理平台，然后基于TPOPS进行数据库实例的纳管和维护即可。在部署形态上也是支持多种，这里介绍几种典型的部署方案，其它参考官网材料。1）生产同城单Region部署与基于云底座的部署方式相同，DN主备复制支持Quorum和Paxos两种协议，跨AZ存在同步备，数据不会丢失。2）同城3AZ5节点+异地1AZ1节点（同城RPO=0）生产同城双活部署，由两个业务AZ和一个仲裁AZ组成。两个业务AZ之间对等部署，任何一个机房都接入业务；仲裁AZ不接入业务；任何机房故障可保证RPO=0；异地Region支持跨Region的容灾能力。同城和异地跨Region分别部署一套单独的数据库集群；单AZ故障下，保证ETCD存活节点为多数，从而保证数据一致性；DN主备节点之间采用流式复制，至少同步到2台备机，保证RPO=0；同城切换支持跨AZ切换；跨Region容灾需要手动切换相比基于华为云底座的部署，异地Region支持单节点部署，并且生产和同城不需要和云底座的Region网络域捆绑，在部署方式上更为灵活。3、总结华为云GaussDB数据库高可用架构能够保证AZ内RPO=0、同城AZ间RPO=0，异地RPO<10s。另外高可用部署上有灵活的配置满足不同的场景，同时还有以下特性：为保证一致性协议的多数派选举成功，ETCD实例或日志副本等按照奇数部署；集中式架构下管控平台和数据库实例之间解耦，每个数据库集群都有自己的元数据管理节点、故障检测节点，在故障检测、DDL变更等场景下不依赖于集中式的管理节点。而管控平台的作用就是资源的管理、性能指标数据的采集和展示等。缺点就是需要维护的节点增多了，比如每个集群都有自己的ETCD、CMS等。在部署模式上如果没有现成的华为云底座，还是轻量化部署更为合适，数据库也不需要和某一类云厂商捆绑，在实际部署方案上也会更为灵活。GaussDB数据库基于云底座和云管平台实现实例的统一管理、指标采集展示、DBMind智能化运维等功能模块，并且结合DRS等迁移工具和Oracle数据库迁移国产中的兼容性及性能上的优势，在国产数据库的引进中已经具备相当的竞争力。不过吐槽一点是GaussDB数据库在实例部署时候的资源最小限制为8C64G并且在实例纳管时候无法规避，这对于小的应用或开发测试环境来说是相当不友好的。参考资料：https://doc.hcs.huawei.com/db/zh-cn/gaussdbqlh/24.1.30/tg/gaussdb-38-0122.html作者：大唐小少

现象：执行升级命令时，提示influxdb is not ok，升级阻塞在提示influxdb is not ok的节点上执行如下步骤步骤1执行 systemctl status influxd.service确认 influxd 状态为running步骤2执行 crontab -e注释掉 * * * * * /usr/bin/python3 /opt/cloud/monitor/monitor.py >> /dev/null 2>&1 & 这个监控进程任务步骤3执行 ps -ef | grep monitor.pykill -9 杀掉监控进程pid步骤4重新执行升级命令，正常升级步骤5升级完成后，执行 crontab -e 打开 * * * * * /usr/bin/python3 /opt/cloud/monitor/monitor.py >> /dev/null 2>&1 & 监控进程任务

GaussDB(DWS)默认就是分布式系统的，和GaussDB的【分布式版】有什么区别吗？

初次接触openGauss或GaussDB数据库的逻辑对象，被其中的表空间、数据库、schema和用户之间的关系，以及授权管理困惑住了，与熟悉的MySQL数据库的逻辑对象又有明显的不同。本文旨在简要梳理下GaussDB数据库逻辑对象之间的关系，以加深理解。1、GaussDB数据库逻辑对象1.1 表空间、Database和表GaussDB数据库中逻辑对象包括表空间、Database和表、索引等，其中Database是数据的集合、表空间是数据在物理上的位置，数据库中的所有对象都存储在表空间中。表空间Tablespace：表空间是一个目录，数据库中可以存在多个表空间，其中存储的是它所包含的数据库的各种物理文件。每个表空间可以对应多个Database。gaussdb中系统默认表空间pg_default，当建表时未指定表空间都使用默认表空间。Database：数据库是逻辑上的抽象，各个database之间相互隔离，同一个database上的数据库对象可以存在多个表空间中。Gaussdb中会默认创建postgres数据库表Table：Table是数据的结构化视图，存储特定类型的数据。每张表只能属于一个数据库，也只能对应到一个Tablespace。每张表对应的数据文件必须在同一个Tablespace中。其中关系如图所示，总结如下：数据库实例中可以定义多个Database和表空间；一个Database中可以包含多个表空间；一个表空间中可以包含多个数据库；一个数据库中可以包含多个表；一个表必须属于一个数据库，并存储在一个表空间中。1.2 用户和SchemaGaussDB数据库中用户user、角色role和schema各自不同的作用：用户是数据库中的实体，用于标识和管理数据库中的各种操作权限和资源使用权限。每个用户都有唯一的用户名，用于登录数据库和执行相关操作。在GaussDB中，用户和用户组在实例范围内是共享的，也就是默认情况下通过单个用户可以连接到任一数据库，但是数据不是共享的，受到权限的管控。角色是一组用户的集合，通过角色可以将权限授予一组用户，而不是单独授予每个用户。角色可以包含其他角色，形成层次结构。通过为角色分配权限，然后将角色授予用户，可以实现权限的快速分配和撤销。Schema是数据库对象的集合，它包含了数据库中的所有表、视图、存储过程、函数等对象。每个数据库可以包含一个或多个Schema，用于将数据库对象组织成逻辑上独立的组。通过Schema，可以允许多个用户使用同一数据库而不相互干扰，将数据库对象组织成易于管理的逻辑组。在数据库创建后，会有一个默认的名为Public的schema。需要注意的是，在GaussDB中，每次创建新用户时，系统会在当前登录的数据库中默认为新用户创建一个同名Schema，此时在当前数据库中创建同名的schema会提示已存在。对于其他数据库，若需要同名Schema，则需要用户手动创建。另外，如果未指定schema访问表时，系统会通过search_path（搜索路径）来判断该表是哪个schema下的表（其中pg_temp和pg_catalog默认会作为搜索路径顺序中的前两位）。search_path（搜索路径）是一个schema名列表，在其中找到的第一个表就是目标表，如果没有找到则报错。在搜索路径中的第一个schema叫做current schema（通过show current_schema可以查看），在没有声明schema名时，新创建的数据库对象会默认存放在该schema下。用户、Database和schema之间关系如图所示，总结如下：每个数据库中可以包含多个用户，用户在实例范围内是共享的；每个数据库中可以定义多个schema，schema之间是互相隔离的，不同数据库之间可以定义相同的schema名；每个schema包含多个数据库对象，但每个数据库对象只能属于一个Schema。用户对不同的Database中不同schema的访问通过设置不同的权限进行管理控制。1.3 不同对象之间权限管理GaussDB数据库中的权限管理沿用了Oracle数据库的权限管理特性，权限层级分为多个级别，包括系统权限和对象权限：系统权限：系统规定用户使用数据库的权限，如登录数据库（LOGIN）、创建数据库（CREATEDB）、创建用户/角色（CREATEROLE）等。对象权限：指在数据库对象（如数据库、模式、表、视图、函数等）上执行特殊动作的权限，如查看（SELECT）、更新（UPDATE）、插入（INSERT）、删除（DELETE）等。在对角色和用户授权时候，主要有以下场景：将系统权限授予角色或用户：比如授予数据库管理员SYSADMIN、MONADMIN权限，监控用户MONADMIN权限；将数据库对象授予角色或用户：将数据库对象的相关权限授予特定的角色或用户，比如对schema的所有权限、schema下表的所有权限。将角色或用户授予其它用户或角色：将一个角色或用户的权限授予其它多个角色，比如创建了一个只读的角色，将该role授予其它用户。将ANY权限授予角色或用户：ANY权限有很多种，比如CREATE ANY、SELECT ANY，当授予SELECT ANY TABLE权限给某个用户后，该用户在当前数据库下既有所有schema的查询权限，对于一些只读的查询用户还是很方便的。GaussDB数据库中的权限管理颗粒度非常细，按照最小授权的原则管理上也相当复杂，因此在实际授权过程中按照schema和schema内的对象维度进行分别授权，全局的只读用户具备SELECT ANY的权限、业务读写用户具备对象级别的增删改查权限、系统视图如pg_catalog和sys等的查询权限。不过需要注意的是：DBE_PREF系统schema访问需要MONADMIN权限，单独授予SELECT权限不生效；Schema内的对象授权时，需要具备schema的usage权限才能正常访问其中的schema；1.4 MySQL数据库中逻辑对象对比在MySQL数据库中，数据库也是存储数据的容器，它包含了表、视图、存储过程、函数、触发器、事件等数据库对象。schema通常与数据库是同义词，指的是数据库结构的集合，创建一个新的数据库时，实际上已经创建了一个新的schema。表也是数据库中最基本的存储单元，它以行和列的形式存储数据。表空间在innodb存储引擎中分为系统表空间和数据表空间，系统表空间包含数据字典、事务信息和undo日志等信息，而打开innodb_file_per_table配置后会为每张表单独创建一个表空间文件，每个表空间文件中存放的是数据、索引和插入缓存等信息。因此，在逻辑结构上MySQL系的数据库中的数据库实例与GaussDB数据库中的database相当，一个数据库中可以创建多个database或schema，每个database中又可以创建不同的表，不同database间共享系统表空间和资源。1.5 总结总结GaussDB数据库的逻辑对象之间的关系，如下图所示：在逻辑层面，GaussDB数据库以不同的database进行逻辑上的区分，一个数据库实例中可以定义多个database，database内可以定义不同的schema、schema内又包含不同的数据库对象。在物理存储层面，表空间对应的是实际的数据存储目录，同一个database可以使用不同的表空间、同一个表空间又可以被不同的database使用。不过在实际使用过程中建议使用默认的表空间。在权限控制上，通过对不同用户或角色授予不同对象的访问权限进行细粒度的权限管控，达到最小化授权的目的。https://doc.hcs.huawei.com/db/zh-cn/gaussdbqlh/24.1.30https://blog.csdn.net/weixin_38623994/article/details/100047552https://bbs.huaweicloud.com/blogs/236381本文作者：大唐小少

我们没有support网站的权限啊

 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日内完成实名认证，否则视为放弃奖励。