openGauss 资源池化架构简介本文系统讲解 openGauss 资源池化（DataPod）架构，涵盖多节点共享存储、日志按需回放、多机并行查询（SPQ）以及基于存储复制的同城双集群容灾（RPO=0）。一、整体定位：为什么要做资源池化 1.1 传统主备架构的"不可能三角" openGauss 传统主备（Shared-Nothing）架构中，每个副本各存一份数据，在"可靠性、性能、成本"三者之间存在天然矛盾：维度传统主备架构痛点可靠性备机需回放大量 WAL 日志，故障恢复（RTO）慢存储成本每个副本存一份数据，N 副本 = N 倍存储资源利用率备机 CPU 闲置、IO 闲置，资源利用率低一致性读备机读存在延迟，不是"实时一致性读" 1.2 资源池化的解法资源池化（DataPod）自 openGauss 3.1.0 版本引入，本质是存算分离（Shared-Storage）架构——多个计算节点共享一份存储，通过 DMS（TCP 或 RDMA 互连）共享内存实现"一写多读 + 实时一致性读"。其核心价值： ●存储成本下降：一份数据多节点共享，存储利用率提升 50%+ ●故障恢复提速：共享存储使备机无需实时回放 WAL，主机故障备机秒级接管 ●计算利用率提升：多节点并行查询，OLAP 性能成倍提升 ●实时一致性读：备机读到的数据与主机已提交数据一致，无延迟二、专业名词速查表在深入学习前，先熟悉文档中出现的专业术语。这是理解架构的基础。术语全称通俗解释 DataPod Data Pod openGauss 对资源池化架构的品牌命名，强调"数据即资源池" DSS Distributed Storage Service 分布式存储服务。负责跨节点管理共享存储上的文件、卷、锁 DMS Distributed Memory Service 分布式内存服务。基于 RDMA 实现跨节点内存共享，是"实时一致性读"的基础 CM Cluster Manager 集群管理组件。监测节点状态、故障检测、自动主备切换 WAL / XLog Write-Ahead Log / Transaction Log 预写式日志 / 事务日志。记录所有数据变更，用于故障恢复 RDMA Remote Direct Memory Access 远程直接内存访问。绕过 CPU 和操作系统，网卡直接读写远端内存，延迟极低 Buffer Pool Shared Buffer Pool 数据库内存中的数据页缓存。资源池化下多节点共享此缓存 SCSI-3 PR SCSI-3 Persistent Reservation SCSI 第三代持久化预留协议。多节点对共享存储的互斥访问机制 CAW Compare And Write 原子比较并写操作。用于多节点写同一存储区域的并发控制 NoF / NoF+ NVMe over Fabric NVMe over Fabric 协议。比 SCSI 更高效的存储访问协议 NDP Near Data Processing 近数据处理。把数据库算子下推到存储设备执行，减少数据搬运 SPQ Shared-Everything Parallel Query 全共享并行查询框架。资源池化下的多机并行查询能力 ORCA Optimizer Runtime for Commercial Applications Greenplum 开源的分布式查询优化器，被 SPQ 适配 QC / QE Query Coordinator / Query Executor 查询协调者 / 查询执行者。SPQ 中的两类逻辑角色 RPO Recovery Point Objective 恢复点目标。故障时允许丢失的数据量，RPO=0 即"零数据丢失" RTO Recovery Time Objective 恢复时间目标。从故障到业务恢复的时间 REDO GAP REDO Gap 待回放日志量。主机最新日志位置与检查点 REDO 点的差值极致 RTO Extreme RTO openGauss 的一种快速恢复模式，数据块级并行回放按需回放 On-Demand Replay 极致 RTO 的增强版本，先构建回放信息再按需回放，故障时秒级升主实时构建 Realtime Build 按需回放的进一步增强，非故障状态下也实时构建回放信息，进一步压缩 RTO Dorado Dorado 华为企业级全闪存存储产品，用于资源池化的共享存储 OLTP / OLAP Online Transaction / Analytical Processing 联机事务处理 / 联机分析处理 HTAP Hybrid Transactional/Analytical Processing 混合事务分析处理，同时满足 TP 和 AP 能力 TPC-H / TPC-C - TPC 组织制定的 OLAP / OLTP 标准测试基准 DRC Distributed Resource Cache 分布式资源缓存。DMS 中管理页面/锁等资源的全局元数据，记录每个页面的 master、owner、copy、EDP 等信息 EDP Early Dirty Page 早期脏页。页面 owner 转移时，原节点仍持有的旧版本脏页，用于保证多节点页面一致性 Reform - 集群成员变更流程。节点加入/退出集群、failover、switchover 时 DMS 层的重新组网过程 MES Message Exchange Service 消息交换服务。DMS 底层的节点间通信层，支持 TCP、RDMA、SHM 三种传输模式 CLOG / CSNLOG Commit Log / Commit Sequence Number Log 事务提交日志 / 事务提交序列号日志。用于事务状态判断与 MVCC 可见性判断 MVCC Multi-Version Concurrency Control 多版本并发控制。通过数据多版本实现读写不阻塞 OldestXmin - 集群中最老的活动事务 XID，决定全局可见性边界与 vacuum 清理边界灵衢 UB Unified Bus（超节点互连总线）华为灵衢超节点协议。提供跨节点共享内存语义，是 SHM 传输模式与 HTAP 行列融合的硬件基础 OCK Open Computing Kit 基于 RDMA 的轻量级 RPC 框架，替代 TCP/IP 消息传输，需 CX5 网卡 CU Column Unit 列存储单元。行列融合特性中，行存数据转换为列存后的基本存储单元 LUN Logical Unit Number 逻辑单元号。存储阵列划分出的逻辑磁盘，资源池化所需的 data/xlog/votingDisk/shareDisk 均以 LUN 提供 votingDisk Voting Disk 投票盘。共享存储上一块专用盘，用于集群仲裁，防止脑裂 shareDiskDir Shared Disk Directory 共享目录盘。存放集群共享文件（如 CM 配置）的专用盘 Ustore / Astore - openGauss 两种行存引擎：Ustore 原位更新（undo 链），Astore 追加更新（MVCC 多版本）段页式存储 Segment-Page Storage openGauss 的存储管理方式，文件按段/页组织，便于共享存储上多节点管理三、架构详解：多节点共享存储 3.1 三层池化架构资源池化由三个核心组件协同实现"存储池化 + 内存池化 + 计算池化"的三层架构：应用客户端 │ ┌────────────┼────────────┐ ▼ ▼ ▼ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ DN 主节点 │ │ DN 备节点 │ │ DN 备节点 │ ← 计算节点（一写多读） │ (可写) │ │ (实时读) │ │ (实时读) │ └────┬────┘ └────┬────┘ └────┬────┘ │ DMS: 跨节点共享 Buffer Pool（RDMA） │ ├────────────┼────────────┤ │ DSS: 共享存储访问 + 分布式文件锁 │ ▼ ▼ ▼ ┌─────────────────────────────────┐ │ 共享存储（Dorado 磁阵） │ ← 一份数据，所有节点可见 └─────────────────────────────────┘ CM（集群管理）: 状态监测、故障检测、自动主备切换 3.2 架构要点 ●读写节点和只读节点共享一份底层存储。 ●读写节点和只读节点之间通过TCP 或 RDMA 协议使用 DMS 组件共享 Shared Buffer Pool 中的热数据页。 ●读写节点和只读节点通过DSS API 和 DSS Server 的协同访问底层共享存储中的持久化的数据。 3.3 DSS（分布式存储服务）—— 存储池化层 DSS 是资源池化的存储底座，负责跨节点管理共享存储。核心职责： 1.共享存储管理：跨节点管理共享存储上的文件、目录、卷（Volume）和卷组（VG）及元数据 2.用户态 IO 栈：绕过 OS 页缓存直接访问磁阵，减少上下文切换开销 3.分布式文件锁：基于持久化 IO 实现，保证多节点对同一数据卷的互斥访问 4.多协议支持： ○SCSI-3 PR + CAW 协议（生产环境，要求磁阵支持持久化预留） ○NoF / NoF+ 协议（openGauss 6.0 引入，比 SCSI 性能更优，TPC-C 提升 10%） 5.算子卸载（NDP）：对接分布式存储，把数据库算子下推到存储设备执行，TPC-H 性能提升 40% 6.线程池模式：支持大并发处理 7.黑匣子诊断：提升运维能力 NDP 算子卸载详解： ●支持算子：Agg、SeqScan、Filter、Projection 四类逻辑可在存储节点运行，将过滤/投影/聚合后的结果传回计算节点，业务无感知 ●计算侧（内核插件 ndpplugin）：构造算子卸载上下文（snapshot、clog、csnlog、expr、表 schema 等）发送到存储侧 libsmartscan 进程；仅对不在 Buffer Pool（读节点及写节点）中的 PAGE/BLOCK进行 NDP 处理，否则走原内核流程 ●存储侧（libsmartscan 进程）：以存储语义只读本地数据，解析并判断可见性；无法判断可见性或无法获取对应版本数据（Ustore 场景）的页交回计算侧原始流程 ●实现方式：通过存储引擎接口 hook 实现，不改变执行计划与算子信息，屏蔽执行引擎对卸载的感知 ●特性约束：仅资源池化部署；仅 sharedpreloadlibraries 加载；暂不支持 Toast 表、Ustore、synchronize_seqscans 协议选型对比：协议引入版本优势典型场景 SCSI-3 PR + CAW 资源池化首发成熟稳定传统集中式存储 NoF / NoF+ 6.0.0 IO 性能更优，TPC-C 提升 10% 新型分布式存储 3.4 DMS（分布式内存服务）—— 内存池化层 DMS 实现计算节点间的跨节点内存互联（TCP 或 RDMA），是"实时一致性读"的技术基础。核心机制： 1.Shared Buffer Pool 共享：备机读数据页时，若主机内存中有最新版本，直接通过 DMS 从持有该页的节点内存抓取，而不必去磁盘读 + 回放 WAL 2.页面三角色管理（DRC 机制）：每个页面在集群中由 DRC（分布式资源缓存）统一管理，涉及三种角色： ○master：页面的管理节点，负责仲裁该页的锁请求 ○owner：页面当前持有者，持有最新版本的脏页 ○copy：持有页面副本的节点（共享读） 3.EDP（早期脏页）机制：当节点以 X 锁请求页面、原 owner 转移页面且该页仍是脏页时，原节点本地保留的旧脏页即 EDP。EDP 保证了页面转移过程中的多版本一致性（可通过ss_buffer_ctrl()函数观测is_edp、is_remote_dirty等标记） 4.分布式锁服务：全局数据结构的一致读写（S 锁/X 锁模式记录在 DRC 中） 5.全局事务协调：全局死锁检测、全局 oldestxmin 推进等 MES 通信层（DMS 底座）：传输模式说明 TCP 默认模式，无特殊硬件要求 RDMA 依赖 CX5 网卡与 OCK RDMA 动态库，us 级时延 SHM 灵衢超节点 UB 共享内存模式（详见第七章），零拷贝消息收发相关参数：ss_interconnect_type（TCP/RDMA/SHM）、ss_interconnect_channel_count（通道数 1~32，默认 16）、ss_work_thread_count（MES 工作线程 16~128，默认 32）、ss_work_thread_pool_attr（MES 线程池，推荐 '64'）为什么"实时一致性读"成立？传统主备架构下，备机读到的数据是异步回放后的"滞后版本"。而资源池化下： ●主备共享同一份磁盘数据 ●备机若读到一页，该页的 owner 节点内存版本若更新，直接通过 DMS 取走 ●备机读到的版本与主机已提交版本一致，无回放延迟 3.5 Reform：集群成员变更协议 Reform 是 DMS 层的集群重新组网流程，任何节点加入/退出、角色变化都会触发。可通过 query_node_reform_info() 观测： Reform 类型触发场景 Normal reform 节点正常加入（join in）/退出（kick off）集群 Failover 主节点故障，备节点升主 Switchover 计划内主备切换 Reform 过程包含 flush_copy（刷盘标记页）、页面访问恢复、bitmap 组网等多个步骤（27 项状态可通过 query_node_reform_info_from_dms() 查看），保证故障后剩余节点快速形成新的稳定集群。 3.6 CM（集群管理）—— 高可用层 CM 负责整个集群的高可用管理： ●监测数据库状态、网络故障、文件系统故障 ●故障后自动主备切换 ●因为存储共享，切换无需数据重建，RTO 极短 ●支持两节点部署、自定义资源监测、VIP 管理 3.7 硬件与部署要求生产环境最低配置：项要求计算节点 ≥2 台物理机（x86 或鲲鹏）网络物理机之间建议 RDMA（RoCE 或 InfiniBand）存储集中式存储（如 Dorado），支持 iSCSI-3 + SCSI-3 PR + CAW 光交换光交换机或以太互连多路径软件生产环境需安装 ultrapath 多路径软件共享存储 LUN 规划（4 块盘）： LUN 用途典型盘符说明 data /dev/sda 数据卷组（dssvginfo 中的 data 卷） xlog /dev/sdb 日志卷（双集群容灾时作为存储复制 LUN） votingDiskPath /dev/sdc 投票盘，集群仲裁防脑裂 shareDiskDir /dev/sdd 共享目录盘注意：同一 LUN 在集群内多台机器上的盘符需一致，不一致时通过软链接对齐（ln -s /dev/sdX /dev/data）。社区开发者环境： ●单台物理机即可 ●用dd命令模拟块设备 ●编译带libdms.so/libdssapi.so的版本 ●可搭建两节点模拟集群（仅用于学习调试，不可用于生产） 3.8 资源池化观测函数汇总 openGauss 提供一套系统观测函数（详见官方《资源池化函数》参考），是理解内部机制、排查问题的窗口：函数观测内容关键字段/说明 ss_buffer_ctrl() Buffer 页面控制信息 is_remote_dirty、is_edp（早期脏页标记）、lock_mode 等 query_page_distribution_info() 页面在集群中的分布 is_master/is_owner/is_copy 三角色、lock_mode、mem_lsn/disk_lsn、is_dirty query_all_drc_info() DRC 全局资源信息 RESOURCE_ID、MASTER_ID、COPY_INSTS、CLAIMED_OWNER、EDP_MAP query_node_reform_info() 本节点 Reform 信息改革类型、步骤、进度 query_node_reform_info_from_dms() DMS 视角 Reform 详情 27 项 NAME 状态（flush_copy、bitmap 组网等） ss_txnstatus_cache_stat() 事务状态缓存统计事务状态查询命中率等 dss_io_stat() DSS IO 统计共享存储读写 IO 分布 ondemand_recovery_status() 按需回放状态见 4.5 节详解 realtime_build_log_ctrl_status() 实时构建流控状态主机查看各备机预估恢复时间、构建速率等四、日志按需回放：实现秒级 RTO 4.1 为什么资源池化下回放机制不同传统主备架构下，备机需要实时接收主机 XLog 并回放，故障时备机已回放到接近主机位置。资源池化下：由于底层采用共享存储，备机无需接收来自主机的预写式日志，也无需对以上日志进行重演。当故障发生后，备机根据主机控制文件中的 REDO 点开始恢复，直到恢复到主机的最后一条日志为止。因此，资源池化下的 RTO 时间 = 待回放日志量（REDO GAP）决定的回放时间。 4.2 REDO GAP：衡量 RTO 的核心指标 REDO GAP = 主机最新日志位置 - 检查点 REDO 点位置。openGauss 提供官方 SQL 查询：-- 前置：创建查询函数与视图 CREATE OR REPLACE FUNCTION hex_to_int(hexval varchar) RETURNS BIGINT AS $$ DECLARE result bigint; BEGIN EXECUTE 'SELECT x' || quote_literal(hexval) || '::bigint' INTO result; RETURN result; END; $$ LANGUAGE plpgsql IMMUTABLE STRICT; create view query_redo_gap as select b.node_name, (hex_to_int(substring(b.current_xlog_insert_lsn, 1, b.curr_pos - 1)) * 4 * 1024 * 1024 * 1024 + hex_to_int(substring(b.current_xlog_insert_lsn, b.curr_pos + 1))) as curr_redo, (hex_to_int(substring(b.ckpt_redo_point, 1, b.redo_pos - 1)) * 4 * 1024 * 1024 * 1024 + hex_to_int(substring(b.ckpt_redo_point, b.redo_pos + 1))) as ckpt_redo, (curr_redo - ckpt_redo) / 1024 / 1024 as "REDO GAP(MB)" from (select a.*, position('/' IN current_xlog_insert_lsn) as curr_pos, position('/' IN ckpt_redo_point) as redo_pos from local_pagewriter_stat() a) b; -- 查询当前待回放日志量 openGauss=# select * from query_redo_gap; -- 示例结果：REDO GAP = 247.25 MB 运维要点： ●REDO GAP 越大 → 故障后回放时间越长 → RTO 越长 ●REDO GAP 持续增长 → 主机刷脏速度跟不上脏页生成速度 → 需要优化 ●优化手段：降低pagewriter_sleep、增加pagewriter_thread_num、降低incremental_checkpoint_timeout 4.3 五种回放模式对比资源池化提供从慢到快、从低资源消耗到高资源消耗的五种回放模式：回放模式关键参数速度内存消耗适用场景串行回放 recovery_max_workers=1 慢低不推荐并行回放 recovery_max_workers>1, recovery_parse_workers=1 较慢适中不推荐极致 RTO 回放 ss_enable_ondemand_recovery=off, recovery_parse_workers>1, recovery_redo_workers>=1 适中适中 REDO GAP 较大、RTO 不敏感场景极致 RTO 按需回放 ss_enable_ondemand_recovery=on, ss_enable_ondemand_realtime_build=off, recovery_parse_workers>1, recovery_redo_workers>=1 较快较高 RTO 敏感场景，需控制 REDO GAP 不能过大极致 RTO 按需回放实时构建 ss_enable_ondemand_recovery=on, ss_enable_ondemand_realtime_build=on, recovery_parse_workers>1, recovery_redo_workers>=1 最快较高 RTO 敏感、要求极致低 RTO；备机正常运行时也消耗 CPU/IO 关键区分： ●前四种模式：仅在故障后启动回放线程，非故障时不消耗 CPU ●实时构建：非故障状态下也持续构建回放信息，故障时直接使用，进一步压缩 RTO，但持续消耗 CPU 4.4 极致 RTO 按需回放的原理这是资源池化下加速 RTO 的核心特性。理解其工作流程：┌───────────────────────────────────────────────────────────┐ │ 极致 RTO 按需回放工作流程 │ ├───────────────────────────────────────────────────────────┤ │ │ │ 非故障状态（实时构建开启时） │ │ ┌────────────────────────────────────┐ │ │ │ 后台持续解析 XLog │ │ │ │ 构建"页面多版本恢复链" │ │ │ │ 存放在内存中 │ │ │ └────────────────────────────────────┘ │ │ ▼ │ │ 主机故障发生 │ │ ▼ │ │ ┌────────────────────────────────────┐ │ │ │ 1. 读取预构建的"页面恢复链" │ │ │ │ 2. 按需回放必要页面（非全部日志） │ │ │ │ 3. 立即对外提供服务 │ ← 关键：不等全部回放完成 │ │ 4. 后台继续完成剩余回放 │ │ │ └────────────────────────────────────┘ │ │ ▼ │ │ 集群恢复完成 │ │ │ └───────────────────────────────────────────────────────────┘ 核心思路： 1.传统回放需完成全部日志回放后才能对外服务 2.按需回放构建回放信息后立即对外提供服务，降低 RTO 3.对外服务时仍在后台继续回放极致 RTO 的底层机制： ●多级流水线：xlog 日志回放建立多级流水线（recovery_parse_workers个解析线程 + 每个解析线程对应recovery_redo_workers个 PageRedoWorker），提高并发度 ●page 多版本：回放线程维护每一个 page 的日志链，读线程根据指定的 LSN 读取对应版本的 page，从而支持备机读 ●参数取值范围：recovery_max_workers（0~20）、recovery_parse_workers（1~16）、recovery_redo_workers（1~8） ●与传统"并行恢复"的区别：并行恢复是文件级别的并行 REDO；极致 RTO 是数据块级别的并行恢复 ●冲突处理：非资源池化模式下，查询与回放冲突时查询会被取消（报错canceling statement due to conflict with recovery，业务可重试），冲突主要来自删除文件、truncate、drop database、drop tablespace、vacuum 清理五类日志；资源池化模式下，备机的查询和极致 RTO 不存在冲突 "按需回放"与"极致 RTO"的关系：特性适用部署工作时机适用故障类型极致 RTO 资源池化 + 非资源池化故障后回放主机故障重启、备机 failover 极致 RTO 按需回放仅资源池化故障后回放主机故障重启、备机 failover 按需回放实时构建仅资源池化非故障时也构建仅加速备机 failover 重要约束： ●极致 RTO 与备机可读（hot_standby=true）不兼容，但同时配置会报错（CheckExtremeRtoGUCConflicts） ●资源池化下原生支持备机可读，与hot_standby配置无关 ●开启极致 RTO 按需回放后，备机启动阶段会预占大量内存，不推荐内存较小的环境使用 4.5 按需回放状态观测与流控按需回放状态观测：ondemand_recovery_status()openGauss=# select * from ondemand_recovery_status(); 关键字段：字段含义 primarycheckpointredo_lsn 当前节点读取到的主机 redo 点位置 realtimebuildreplayed_lsn 实时构建已完成构建的主机日志位置 hashmapusedblocks / hashmaptotalblocks 已存入/可存入的 block-record 数量 inondemandrecovery 是否处于按需回放中 ondemandrecoverystatus ONDEMANDRECOVERYBUILD（构建中）/ ONDEMANDRECOVERYREDO（已对外服务+后台回放）/ NORMAL realtimebuildstatus DISABLED / BUILDNORMAL / READYTOBUILD / BUILDTODISABLED / BUILDTO_REDO recoverypausestatus 实时构建暂停原因（DDL 日志 / HashMap 满 / 事务日志队列满 / 段页式队列满）运维提示：当 recoverypausestatus 显示暂停状态时会严重影响回放性能，无法保证 RTO 要求，应考虑增大 ss_ondemand_recovery_mem_size，同时提高主机刷盘及 checkpoint 频率。主机日志流控：recovery_time_target ●取值 0~3600 秒，默认 0（不开启流控） ●资源池化单集群的流控只在实时构建场景生效：主机配置recovery_time_target > 0+ 备机配置ss_ondemand_realtime_build = on，主机即基于备机的 xlog 构建速度对业务进行流控 ●与传统主备不同：资源池化场景下该参数为RTO 参考值，主机识别到备机实时构建速度较慢时会适当减缓业务，但不会完全阻塞业务 ●配套观测：主机上执行realtime_build_log_ctrl_status()可查看各备机的预估恢复时间、构建速率、睡眠时间等 4.6 性能指标 ●集群内 RTO：50W TPMC 负载下，RTO < 10 秒，RPO = 0 ●备机性能：sysbench 场景 2 节点性能 6W tps，线性度 1.6 倍（相比优化前提升 50%）五、多机并行查询（SPQ）：让集群具备 AP 能力 5.1 为什么需要 SPQ 资源池化下"一写多读"架构，原本每个备节点都能对外提供读服务，但集群只存在同时一个读节点查询的能力——任一时刻发起的查询只在一个节点执行，其他节点算力未被利用。SPQ 解决的就是这个浪费。 5.2 SPQ 是什么 SPQ（Shared-Everything Parallel Query）是 openGauss 在资源池化场景下引入的多机并行查询框架，核心思想：所有节点都共享集群内的资源，优化器生成多机执行计划，计划分发到各节点执行，再由查询节点汇聚各节点数据，实现所有读节点并行查询，充分发挥集群的 OLAP 能力。 5.3 SPQ 架构与角色┌──────────────────────────────────────────────────┐ │ SPQ 工作集群 │ ├──────────────────────────────────────────────────┤ │ │ │ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ │ │ Node1 │ │ Node2 │ │ Node3 │ │ │ │ QC │ │ QE │ │ QE │ │ │ │ (Coordinator) │ (Executor) │ (Executor) │ │ │ └────┬─────┘ └────┬─────┘ └────┬─────┘ │ │ │ 生成多机计划 │ │ │ │ ├─────分发计划──►│◄────分发计划─┤ │ │ │ │ │ │ │ │◄──汇聚结果────┤◄──汇聚结果──┤ │ │ ▼ ▼ ▼ │ │ 任一节点发起查询均可成为 QC │ │ QE 角色可通过 GUC 参数动态配置 │ │ │ └──────────────────────────────────────────────────┘ ●QC（Query Coordinator）：查询协调者，任一节点发起查询请求均可成为 QC ●QE（Query Executor）：查询执行者，可通过 GUC 参数动态配置 5.4 四大核心子特性 5.4.1 对接分布式优化器 ORCA SPQ 使用 Greenplum 开源社区研发的 GP-ORCA 优化器，对其适配 openGauss 生成多机执行计划。适配后的组件以动态库方式被 openGauss 多机查询调用。适配关键点： ●针对资源池化存储特性，扩展扫描节点生成方案，调整表数据扫描范围 ●在共享存储基础上，匹配相应代价模型，生成分布式扫描计划 5.4.2 多机并行执行框架新增算子适配分布式计划：算子类别算子作用扫描类 SpqSeqScan、SpqIndexScan、SpqIndexOnlyScan、SpqBitmapHeapScan 适配分布式扫描范围计算类 Aggregate 的 FinalAgg、PartialAgg；HashJoin 的 LASJ_NOTIN semi-join 分支分布式聚合计算 Shuffle 类 SpqRemoteQuery、Redistribute、Gather、Broadcast 节点间数据交互与分发自适应扫描机制（消除数据倾斜）：传统分布式数据库通常限定每个 Worker 扫描特定 ID 范围，这会导致数据倾斜。SPQ 设计了请求-响应（Request-Response）模式： ●QC 进程通过特定 RPC 通信告知每个 QE Worker 进程可执行的扫描任务 ●Worker 主动拉取扫描任务，避免某些节点忙、某些节点闲 5.4.3 多机并行 DDL（创建索引） SPQ 加速索引创建的原始数据扫描与排序过程。当前支持： ●多机并行 btree 创建索引 ●多机并行 btree 在线（concurrently）创建索引性能：100G 数据量、一主两备场景下，创建索引性能提升约 2 倍。 5.4.4 多机并行 DML SPQ 加速 DML 的读取阶段（写入仍单线程）： ●支持INSERT ... SELECT、DELETE、UPDATE的多机并行读 ●写入只走单线程（资源池化下一写多读，写仍集中在主节点）性能数据（100G 数据、写线程数 1、每节点读线程 32、一主两备）： DML 类型读远大于写场景读写数据量相同场景 INSERT ... SELECT 最高 2 倍 - UPDATE 最高 10 倍 - DELETE 最高 10 倍 1.7 倍 5.5 特性约束 ●仅支持在资源池化部署下使用 ●暂时仅支持shared_preload_libraries方式加载插件 ●分区表、系统表、伪列、自定义函数、存储过程的查询暂不支持 ●加载 SPQ 的节点所配置的节点名称pgxc_node_name必须互不相同 ●磁盘预留空间不够时，会导致执行语句失败 5.6 启用方式通过 spqplugin 插件使能：# 每个节点配置（node1 示例） port = 12300 pgxc_node_name = 'node1' comm_sctp_port = 12330 comm_control_port = 12340 shared_preload_libraries = 'spqplugin' spqplugin.cluster_map = 'node1|x.x.x.x|12300,node2|x.x.x.x|12300' spqplugin.enable_spq = on 会话级开关：-- 开启 SPQ set spqplugin.enable_spq = on; -- 启用 DML 多机并行 set spqplugin.spq_optimizer_enable_dml = true; -- 启用 INSERT...SELECT set spqplugin.spq_enable_insert_select = on; -- 查看多机计划 explain insert into t2 select * from t1; -- QUERY PLAN -- ---------------------------------------------------------------------------------------- -- Streaming (type: GATHER) (cost=0.00..0.00 rows=0 width=5) -- -> Insert on t2 (cost=0.00..431.01 rows=1 width=5) -- -> SPQ Result (cost=0.00..0.00 rows=0 width=0) -- -> Streaming(type: DML REDISTRIBUTE dop: 1/2) (cost=0.00..431.00 rows=1 width=16) -- -> Spq Seq Scan on t1 (cost=0.00..431.00 rows=1 width=5) 5.7 性能数据测试集数据量部署形态提升倍数 TPC-H（22 条标准语句） 100G 资源池化（一主两备）较单机提升 2.58 倍创建索引 100G 资源池化（一主两备）较单机提升 2 倍 5.8 SPQ 的价值资源池化原本是 OLTP 优化（降低存储成本、加速 RTO），SPQ 让资源池化同时具备较强的 OLAP 能力，实现 HTAP： ●TP 能力：一写多读、实时一致性读 ●AP 能力：多机并行查询、加速索引创建 ●业务隔离：通过虚拟 Node-Group 将 OLTP 业务和 OLAP 业务隔离六、同城双集群容灾：RPO=0 的实现 6.1 为什么需要双集群资源池化解决了单集群内的高可用与性能问题，但单集群机房遭遇断网、停电、火灾等灾害时仍然会全盘失效。金融、银行业对数据安全有极高要求，需要双集群容灾方案。 openGauss 提供两种主备双集群容灾方案：方案引入版本同步方式部署范围 RPO 典型 RTO 基于 Dorado 存储同步复制 5.1.0 存储层同步同城（百公里级） =0 <30s 基于流复制 6.0.0-RC1 WAL 流复制同城或异地 ≈0 - 6.2 基于 Dorado 存储同步复制的容灾方案这是实现 RPO=0 的关键方案，适用于同城双中心容灾场景。前置概念——日志合一：为了支持存储复制容灾，需要将集群内所有节点的 xlog 日志全部存放在一个卷（xlog LUN）上，该 xlog LUN 即作为 Dorado 远程复制 Pair 的复制对象。当前版本在"资源池化本地 xlog 日志和远程同步复制 xlog 日志共存"的实现下部署主备双集群容灾。限制条件：需要两套正常的 Dorado 存储，分别搭建两套资源池化集群（主集群 + 备集群）。原理： ┌──────────────────┐ ┌──────────────────┐ │ 主集群中心（A） │ │ 灾备集群中心（B） │ │ │ │ │ │ ┌────────────┐ │ │ ┌────────────┐ │ │ │ 数据库实例 │ │ │ │ 数据库实例 │ │ │ └─────┬──────┘ │ │ └─────┬──────┘ │ │ │ │ │ │ │ │ ┌─────▼──────┐ │ Dorado 存储 │ ┌─────▼──────┐ │ │ │ Dorado 磁阵 │ │ 同步复制链路 │ │ Dorado 磁阵 │ │ │ │ (Xlog LUN) │◄┼──────────────┼►│ (Xlog LUN) │ │ │ └────────────┘ │ │ └────────────┘ │ └──────────────────┘ └──────────────────┘ Xlog 日志盘通过存储复制 LUN 同步数据库通过一致性回放实现跨集群容灾核心机制： 1.首次全量同步：通过数据库业务网络平面实现跨集群基础数据同步 2.增量日志同步：DSS 日志 LUN 作为存储复制 LUN，数据库通过一致性回放实现跨集群容灾 3.日志直接写入共享存储：日志不通过数据库网络传输，由存储层同步复制为什么 RPO=0： ●Dorado 存储提供存储层同步复制能力 ●主集群的 Xlog 日志盘同步复制到灾备集群 ●同步复制意味着主机提交事务即同步到灾备存储 ●一旦主集群机房故障，灾备集群已有完整日志，RPO=0 两种通道模式：模式描述 RTO 影响单通道主备数据库实例之间一条存储同步链路内核 failover RTO < 30s（备机回放追上、网络正常场景）双通道主备数据库实例之间两条存储同步链路单通道故障可切换为双通道中的另一条，切换时间 < 6s；双通道性能差距 10% 以内双通道的价值：当计算节点与存储节点因网络异常导致 IO 异常时，需要经历 iSCSI session 超时与心跳超时后返回 IO 报错。默认参数下总时长约 130 秒，可通过修改 node.session.timeo.replacement_timeout 调优。 6.3 部署实操要点（关键参数与命令）基于官方手动部署文档，搭建 Dorado 双集群容灾的核心配置项： 1. 容灾参数配置（gs_guc，主/备集群的节点都要配）：# 主集群主节点示例 gs_guc set -N node1 -D /opt/mpp/install/data/dn -c "application_name = 'dn_standby_0'" gs_guc set -N node1 -D /opt/mpp/install/data/dn -c "ss_disaster_mode = dorado" gs_guc set -N node1 -D /opt/mpp/install/data/dn -c "cross_cluster_replconninfo1='localhost=20.0.0.10 localport=25400 remotehost=10.0.0.10 remoteport=25400'" gs_guc set -N node1 -D /opt/mpp/install/data/dn -c "cross_cluster_replconninfo2='localhost=20.0.0.10 localport=25400 remotehost=10.0.0.20 remoteport=25400'" gs_guc set -N node1 -D /opt/mpp/install/data/dn -c "ha_module_debug = off" # pg_hba 需增加对端集群 IP 的接入规则（主备集群互配） gs_guc set -N node1 -D /opt/mpp/install/data/dn -h "host all all 20.0.0.10/32 trust" gs_guc set -N node1 -D /opt/mpp/install/data/dn -h "host all all 20.0.0.20/32 trust" 2. 关键参数速查：参数/配置位置取值说明 ss_disaster_mode GUC（gs_guc） dorado 开启 Dorado 存储容灾模式 cross_cluster_replconninfo1/2 GUC 对端集群节点 IP + 端口跨集群流复制通道（全量同步与状态协商） STORAGE_MODE $DSSHOME/cfg/dssinst.ini SHAREDISK → **CLUSTERRAID** 存储模式改为集群 RAID（容灾形态） CLUSTER_RUN_MODE $DSSHOME/cfg/dssinst.ini clusterprimary / clusterstandby 主/备集群角色标识（备集群所有节点均需修改） ss_double_cluster_mode CM 参数（cm_ctl set） 1（主集群）/ 2（备集群）双集群模式，agent 与 server 均需设置 3. 备集群首备建立（cross_cluster 全量 build）：export DSS_MAINTAIN=TRUE # 打开 dss 手动模式 dssserver -D /opt/huawei/install/dss_home & # 手动拉起 dssserver gs_ctl build -D /opt/huawei/install/data/dn -b cross_cluster_full -q # -q 表示成功后不拉起数据库 dsscmd stopdss # 停止手动模式的 dssserver export DSS_MAINTAIN=FALSE 4. 备集群 CM 参数并拉起：cm_ctl set --param --agent -k ss_double_cluster_mode=2 cm_ctl set --param --server -k ss_double_cluster_mode=2 # dss_inst.ini 增加 CLUSTER_RUN_MODE=cluster_standby（备集群所有节点） cm_ctl start 关键步骤：拉起备集群前，必须登录主集群 DeviceManager，选择数据保护 → LUN → 远程复制 Pair，将之前"分裂"的 Pair 通过操作 → 同步改回同步复制关系。此步骤非常关键。 5. 状态验证： ●备集群cm_ctl query -Cvidp：首备节点状态变为Main Standby Normal（未建容灾关系时是 Primary） ●主集群gs_ctl query：可观察到跨集群流复制信息（peer_role: StandbyCluster_Standby、state: Streaming、sync_percent: 100%） 6.4 远程复制 Pair 操作与主备切换流程搭建期的 Pair 操作（DeviceManager，主集群侧）： 1.服务 → LUN 组 → 创建：创建主集群 LUN 组 2.数据保护 → LUN → 远程复制 Pair → 创建：为 xlog 卷创建远程复制 Pair（对端自动创建同步复制卷） 3.操作 → 分裂：先分裂 Pair，以便分别独立拉起主备集群 4.备集群侧添加 xlog 盘并创建其余 3 个 LUN，然后操作 → 取消从资源保护（使从端可读写） 5.两集群均就绪后，操作 → 同步（恢复同步复制关系）计划内/故障切换主备的流程（第十四步，共 10 步）： 1.停止主集群（无法停止则跳过） 2.DeviceManager 调整同步 Pair：分裂 → 取消从资源保护 → 反转同步方向 3.原备集群所有节点：dsscmd setcfg -n CLUSTER_RUN_MODE -v cluster_primary 4.原备集群首备：cm_ctl set --param --agent/server -k ss_double_cluster_mode=1+cm_ctl reload 5.原备集群首备执行gs_ctl failover升主（原主集群已损坏则至此结束） 6.原主集群全量重建：gs_ctl build -b cross_cluster_full -q（预期内切换可跳过） 7.原主集群所有节点：CLUSTER_RUN_MODE=cluster_standby 8.原主集群主节点：ss_double_cluster_mode=2 9.DeviceManager 调整 Pair：启用从资源保护 → 同步 10.cm_ctl start启动新备集群运维常见问题： ●扩容：数据盘可直接dsscmd adv扩容；xlog 盘扩容需停备集群，新旧 Pair 分裂后主集群在线扩、备集群离线扩，再全部同步 ●容灾解除/重搭：使用gs_ddr工具 ●卸载：主备集群均执行gs_uninstall --delete-data 6.5 集群间极致 RTO 基于 Dorado 同步复制的主备双集群，支持集群间极致 RTO： ●指标：30 万 TPMC 负载下，集群间极致 RTO < 20 秒 ●约束： ○自 6.0.0-RC1 版本引入 ○只适用于资源池化部署的基于 Dorado 存储同步复制的主备双集群 ○只适用于主备集群间切换，不适用于集群内切换 ○开启极致 RTO 的情况下，备集群不支持读业务 ●使用说明： 1.备集群配置极致 RTO 参数，关闭备机可读 2.主集群故障时，备集群升为主集群 3.30 万 TPMC 下，集群间极致 RTO < 20s 6.6 重要约束基于 Dorado 存储同步复制的双集群方案有以下重要约束（来自官方文档）： ●不支持按需回放：双集群方案下不支持按需回放 ●依赖关系：依赖 openGauss 资源池化架构 + Dorado 存储设备 ●不支持与 Dorado 存储复制双集群同时使用：两种容灾方案互斥 6.7 网络双集群与存储复制双集群对比除 Dorado 存储复制双集群外，官方还提供网络双集群部署方案（同一套 Dorado 存储，跨集群走网络同步）：维度存储复制双集群（Dorado 双集群）网络双集群存储要求两套 Dorado 存储（主、备中心各一套）一套 Dorado 存储计算节点两套资源池化集群两套资源池化集群（至少 2+2 计算节点）日志同步方式 xlog LUN 存储层远程复制 Pair（同步复制，RPO=0）数据库网络平面同步（跨集群流复制） LUN 要求需为 xlog 卷创建远程复制 Pair 无需 Pair，常规 4 块 LUN 即可适用场景同城双中心、RPO=0 强诉求共享一套存储的双集群组网两种方案的部署流程（xml 配置、LUN 映射、软链接对齐盘符、容灾参数）高度相似，差异主要在磁阵侧是否创建远程复制 Pair。 6.8 容灾能力总览 openGauss 在不同部署形态下的容灾能力对比：部署形态 RPO RTO 单中心资源池化 0 <10s（极致 RTO 按需回放）同城双中心（Dorado 同步复制） 0 <30s（典型负载）同城双中心 + Dorado 同步复制 + 极致 RTO 0 <20s（30W TPMC）两地三中心 ≈0 分钟级七、进阶特性：备机写转发、灵衢 UB 加速与 HTAP 行列融合 7.1 备机写转发（enableremoteexecute，6.0.0-RC1 引入）资源池化原生是"一写多读"，写集中在主机。开启 enable_remote_execute 后，备机也能承接写业务——备机事务内的写语句透明转发到主机执行。参数说明：项内容参数名 enable_remote_execute GUC 级别 POSTMASTER（启动后不允许修改）默认值 off 行为差异（关键）：场景行为资源池化 + 事务外读语句备机本地执行；写语句/DDL 转发主机执行（支持简单查询与扩展查询协议）资源池化 + 事务内写语句转发主机，读语句仍备机本地执行传统主备 + 事务内事务启动后所有语句（含读）无条件全部转发主机资源池化下的约束（务必注意）： ●事务内不支持 DDL 语句和 LOCK 语句，遇到直接报错 ●事务内包含子事务时，读语句也会转发到主机 ●COPY 类型语句不转发：COPY TO 可在备机执行，COPY FROM 正常报错 ●不支持不在显式事务块内的存储过程/函数/自治事务/Package 调用（须在显式事务块中以call xxx方式使用） ●不支持"主机重启、备机不断业务"和"备机重启、主机不断业务"（写语句依赖跨节点连接） ●外围工具（gsdump/gsprobackup 等）行为不变权限与连接要求： ●执行写业务的用户必须具有SYSADMIN 权限，且具备目标 SQL 的对象权限 ●备机写转发使用当前业务用户向主机建立内部连接，连接参数含replication=standbywrite；主机侧pg_hba.conf必须配置匹配的host replication规则（建议按业务用户+备机 IP 最小范围配置，如host replication /32 sha256） ●使用 sha256 认证时，需在数据库运行用户可读的.pgpass中配置认证凭据（写转发不自动复用客户端密码） ●备机并发连接数超过 50 且报standbywrite could not connect to the remote server时，建议将wal_receiver_connect_timeout调整为 120s 7.2 灵衢 UB 内存语义加速（事务快照直读自 7.0.0 引入）基于华为灵衢超节点（UB）共享内存能力，为资源池化提供两类内存语义加速：能力一：MES SHM 传输模式（与 TCP、RDMA/UBC 并列的第三种互连） ●基于 UBS Memory 服务与 ubdistcomm_queue（ubs-atomic 库）分布式通信队列，在节点间建立共享内存环形缓冲区，实现零拷贝消息收发 ●各节点创建 9 个 ub_queue 队列（优先级 0–7 及 prio6-mirror），优先级 6 的消息在三个队列间轮转以缓解高优先级队列压力 ●相比 URMA，小包高频场景协议开销更低、时延更优；避免协议栈上下文切换与多次内存拷贝能力二：事务快照共享内存直读加速为四类高频事务元数据建立共享内存加速通道，把备机的"消息获取"优化为"共享内存直读"，采用"共享内存优先、DMS 回退"的分层方案：元数据共享内存分区占用加速内容 CLOG 8GB 备机查询事务提交/回滚/进行中状态 CSNLOG 2GB 备机事务可见性判断（读 CSN） Snapshot 128MB（对齐）备机直接读 xmin/xmax/csn 快照 OldestXmin 128MB（对齐）备机定期上报本节点值，主机维护全局 OldestXmin 合计约 11GB 需确保超节点有足够共享内存资源 ●Snapshot 分区采用"version + xmin/xmax/csn + version"双读校验，利用灵衢最高 128 位原子读写能力避免读到半写状态 ●不改变事务可见性语义与磁盘格式；DMS 路径保留为异常兜底参数配置（均为 PGC_POSTMASTER，重启生效）：参数默认值说明 enable_ub off 事务快照共享内存直读加速总开关 ss_init_clog_size 0（kB，0~1048576）主机启动场景 CLOG/CSNLOG 预热窗口上限；越大切换后命中率越高但恢复尾段越耗时 ss_interconnect_type TCP 配置为 SHM 启用灵衢 UB 共享内存互连（与 TCP/RDMA 互斥） ss_shm_ub_comm_cpu_bind ""（空） 9 个队列的 CPU 亲和性，格式 [id,id,...] 或 [lo~hi] ss_mes_elapsed_switch off MES 耗时统计开关（按队列统计 avg/max/min 时延与收发计数，约每 10 秒输出日志）部署要点与约束： ●需配置 UB 动态库路径，如ubs_mem_path = '/usr/local/ubs_mem/lib/libubsmem_sdk.so' ●集群所有节点统一生效，不支持部分节点开启；各节点用户uid 必须相同 ●不推荐使用安装包内附带的 libstdc++.so.6，应使用系统 /usr/lib64/ 下的动态库，否则可能启动失败 ●共享内存退出时不清理，便于下次启动复用；残留未知共享内存可用ubsectl delete memory -t share --name xxx清理 ●共享内存映射对端失败最多重试 60 次（间隔 1 秒），容忍节点启动时序差异 ●主机启动的 SLRU 预热会增加启动耗时（ss_init_clog_size越大开销越高）；在线 failover/switchover 时新主拷贝旧主热缓存避免冷启动，会增加少量 RTO 7.3 资源池化 HTAP 行列融合（7.0.0-RC2 引入）资源池化存算分离场景下，通过主、从节点的行列双格式内存实现 HTAP 一体化：行存表可转换为列存缓存（Column Unit，CU），大幅提升大型复杂 OLAP 分析查询效率。两种内存模式：模式列存数据存放特点本地内存模式主、从节点各自本地内存主、从节点按分片策略各自完成行列转换，各自持有列存分片共享内存模式远端共享内存（灵衢）主节点列存数据存远端共享内存，本地仅存列存元数据并同步从节点，主、从共享同一份列存数据核心机制： 1.行列转换：用户在主节点发起转换请求，批量转换形成基础列存储单元（Column Unit）插入列存内存 2.基于 DMS 的多机列缓存同步：主节点增量表存储增量数据，同步后台线程更新 Column Unit 并广播至从节点，保证所有节点列存数据实时同步 3.多机并行列存扫描：新增SPQCStore scan算子，基于优化器与代价估算生成含多机并行列缓存查询的向量化执行计划使用方式：# 所有列缓存节点配置（本地内存模式） ss_htap_cluster_map = 'node1|x.x.x.x|12300,node2|x.x.x.x|12300' shared_preload_libraries = 'spqplugin' # 共享内存模式（灵衢环境）额外配置 ubs_mem_path = 'libubsm_sdk.so' ss_max_imcs_cache = 10GB-- 共享内存模式：全表转换 / 指定列转换 / 清除列缓存 ALTER TABLE table_name IMCSTORED WITH SHARE_MEMORY; ALTER TABLE table_name IMCSTORED(column_name_list) WITH SHARE_MEMORY; ALTER TABLE table_name UNIMCSTORED; -- 多机并行列存扫描 set spqplugin.enable_spq = on; set enable_imcsscan = on; set spqplugin.cluster_map = 'node1|x.x.x.x|12300,node2|x.x.x.x|12300'; explain select imcstored_columns from table_name; -- 计划中使用 SPQCStoreScan 算子约束： ●仅普通表支持行列转换，不支持分区表（另参考单机/主备行列融合约束） ●依赖资源池化多机并行查询（SPQ）特性 ●共享内存模式依赖灵衢提供共享内存能力，非灵衢环境无法使用八、版本演进路线资源池化特性自 3.1.0 持续演进，关键里程碑：版本关键能力 3.1.0 首次引入资源池化（DMS/DSS 基础框架）、OCK 加速数据传输（RDMA RPC，需 CX5 网卡） 5.0 / 5.1.0 CM 两节点部署、基于 Dorado 存储同步复制的主备双集群容灾、NDP 算子卸载 6.0.0-RC1 SPQ 多机并行查询、极致 RTO 按需回放、备机事务内透明写转发、DSS NoF/NoF+ 协议、基于流复制的主备双集群容灾 6.0.0 LTS 按需回放 REDO 阶段支持 DDL、SPQ 多机并行能力增强 7.0.0 灵衢 UB 内存语义加速：MES SHM 传输模式 + 事务快照共享内存直读（CLOG/CSNLOG/Snapshot/OldestXmin，约 11GB 共享内存） 7.0.0-RC2 资源池化 HTAP 行列融合（Column Unit、本地/共享内存两种模式、SPQCStore scan 算子）九、学习要点总结 9.1 一句话理解资源池化资源池化 = DSS 管存储（共享一份盘）+ DMS 管内存（RDMA 共享热数据页）+ CM 管高可用（秒级切换），用三层池化（存储/内存/计算）打破传统架构"可靠性、性能、成本"三选二的困局。 9.2 三个核心组件的分工组件池化层核心能力 DSS 存储池化跨节点共享存储、分布式文件锁、NDP 算子卸载 DMS 内存池化 RDMA 共享 Buffer Pool、分布式锁、实时一致性读 CM 高可用状态监测、故障检测、自动主备切换 9.3 日志按需回放的核心思想传统回放：全部回放完才能服务按需回放：构建"页面恢复链"后立即服务，后台继续回放实时构建：非故障时也持续构建恢复链，故障时直接使用 9.4 SPQ 的核心思想一写多读原状：集群只有一个读节点能查询，其他节点算力浪费 SPQ：所有节点共享资源，优化器生成多机计划，QC 分发 + QE 执行 + QC 汇聚 9.5 RPO=0 的实现关键存储层同步复制：Xlog 日志盘通过 Dorado 存储复制 LUN 同步，主机提交即同步到灾备存储，灾备集群已有完整日志，故障时 RPO=0 9.6 新特性速记（7.x）备机写转发：写语句转发主机、读语句留在备机，事务内禁 DDL/LOCK 灵衢 UB 加速：跨节点消息与事务元数据从"消息获取"变"共享内存直读"（约 11GB 共享内存布局） HTAP 行列融合：行存表转列存缓存（Column Unit），SPQCStore scan 多机并行列扫描，共享内存模式主从共用一份列存十、参考文档 10.1 官方在线文档 ●资源池化特性说明 ●资源池化高可用系统配置 ●资源池化多机并行 ●spqplugin 概述 ●spqplugin 使用参考 ●资源池化主备双集群容灾 ●openGauss 6.0.0-RC1 版本介绍 ●产品 FAQ ●openGauss 6.0.0-RC1 版本发布公告