# 技术原理 #### 核心机制 1. **一致性快照同步（Establish Snapshot）** 重建开始时，主节点上的WAL Sender线程首先会获取一个当前的一致性点（Checkpoint），并将该点的LSN（Log Sequence Number）和时间线（Timeline）信息发送给备节点。此快照点确保了重建数据的起点是一致的。 2. **全量数据文件流式传输（Streaming Base Backup）** 主节点的Data Sender线程基于之前获取的一致性快照点，读取所有数据文件，并通过TCP连接将其以数据流的形式发送到备节点的Data Receiver线程中，Receiver线程将其写入到本地数据目录的相应位置。 3. **增量日志回放（WAL Redo）** 在数据传输开始之后，主节点的WAL Sender线程会持续将快照点之后产生的WAL日志发送给备节点。备节点先接收并存储这些日志，待全量数据接收完毕后，WAL Redo线程会从快照点开始按顺序回放这些日志，将数据追赶到最新状态。 #### 特性介绍 1. **全量重建（Full Build）** - 特性描述 通过**物理复制**整个主节点数据文件的方式，为故障备节点提供一个全新的、完整的数据副本。并在拷贝数据同步期间，主节点产生的所有WAL日志，通过回放达到数据一致性。 该特性的特征为复制的数据量大，耗时长。 - 适用场景 1. 磁盘损坏、数据文件丢失或损坏。 2. 备节点WAL日志与主节点脱节（回放所需WAL日志已经被主节点清理）。 3. 部分集群管理流程，如：新增节点加入集群。 4. 人为误操作，导致数据被污染。 2. **增量重建（Incremental Build）** - 特性描述 在主备节点出现日志分叉（WAL segment removed）之后，通过对比主备节点本地的WAL日志，寻找到最近分叉点所对应的LSN。将备节点在分叉点之后的数据文件从主节点同步并覆盖，并同步主节点分叉点之后的WAL日志，通过回放达到数据一致性。 仅同步故障期间的数据变更，而非完整的数据集，比全量重建拥有更高的效率。 **当前该模式是集群内HA的默认恢复方式。** - 适用场景 1. 备节点进程异常宕机，但数据目录完好，仅需少量数据即可修复。 2. 集群内failover，原主节点降备后，发生日志分叉。 3. 容灾集群的解除和加回。 3. **并行Build（Parallel Build）** - 特性描述 当前GaussDB全量和增量重建都是通过**单线程** 的方式完成数据传输，在大容量场景下重建速度较慢，不满足客户业务诉求。为提升在大容量场景的重建传输速度，**并行build** 在全量重建和增量重建的基础上，引入**多线程**并行传输数据的机制，充分利用硬件资源，提升重建速度。 - 并行重建 - 多线程并行传输数据，支持线程数参数可配，最大程度利用网络带宽和存储设备I/O。通过设置GUC参数parallel_build_thread_num可以控制并行Build的并行度。 - 压缩重建 - 采用LZ4无损压缩算法, 对传输数据进行压缩，以节省网络带宽。通过设置GUC参数enable_parallel_build_compression可以控制是否在并行重建传输数据的过程中进行压缩。 - 适用场景 TB级以上的数据节点，需要通过全量重建的方式恢复。 - 特性约束 在CPU、存储设备I/O、网络带宽充足的场景下，可以开启本特性提升重建效率；否则，会因为硬件资源受限而无法观察到明显增益。 4. **异步Build（Async Build）** - 特性描述 异步Build的核心目的是在发生大规模节点故障时，**优先保障主节点生产业务的连续性和可用性**，避免其因同步备节点数量不足而挂起或阻塞，同时让故障备节点能以一种"降级"状态快速回归集群参与仲裁。 当触发region级别连续故障时，可能会出现集群内的多个备节点出现异常。此时，由于主机的业务不满足足够的同步备数量，事务无法提交，阻塞客户生产业务的运行。 **异步Build** 在当前全量和增量重建的基础上，将**WAL Receiver**模拟成正常备节点的WAL日志请求线程，替代原来重建流程中同步WAL日志的方案，使得备节点在重建期间，依然可以参与事务提交。 当前异步build模式通过GUC参数async_build控制，默认开启。 - 适用场景 1. Region/AZ级别故障后的业务保活与快速恢复。 2. 避免大规模节点重启时的业务抖动。 - 特性约束 1. 仅支持**Quorum模式**下集群内主节点到备节点的全量和增量重建。 2. 在节点总数大于3，且同步备个数大于2的场景下，至少残留一主一备的正常节点时，该特性才生效。 #### 性能指标 - **测试环境** ： - 硬件配置 - CPU：64核 - 内存：256GB - 磁盘：NVMe SSD RAID组 - 网络：10万兆专用网络（测试网络无带宽传输上限） - 数据模型 - TPC-C基准测试数据 4W仓，规模约 4.5TB。 - 特点：TPC-C模型包含多张宽表、大量索引和关系，其数据文件在磁盘上并非连续紧凑存储。重建过程中会产生大量随机I/O，对磁盘IOPS和延迟有较高要求，**实际有效传输速率会低于理论顺序读写带宽**。 - **基准值** ： - 全量重建耗时：与数据量成正比，在上述环境中，重建速度可达 **300-500 MB/s**（受网络、磁盘I/O、加密压缩等配置影响）。 - 主节点性能影响：重建期间，主节点TPC-C TPMC性能下降约 **5%\~15%**。 - **性能数据对比** ： 表1重建性能数据 | 重建方式 | 并行度 | 是否压缩 | CPU消耗（备节点） | 磁盘I/O消耗（备节点） | 重建完成时间（包含回放时间） | |:---|:---|:---|:---|:---|:---| | 全量重建 | 1 | 否 | 48% | 550MB/s | 04:20:00 | | 全量重建 + 并行 | 2 | 否 | 96% | 1100MB/s | 02:45:00 | | 全量重建 + 并行 | 5 | 否 | 250% | 2600MB/s | 01:45:00 | | 全量重建 + 并行 | 10 | 否 | 500% | 4500MB/s | 01:25:00 | | 全量重建 + 并行 + 压缩 | 2 | 是 | 60% | 700MB/s | 03:10:00 | | 全量重建 + 并行 + 压缩 | 5 | 是 | 140% | 1700MB/s | 02:05:00 | | 全量重建 + 并行 + 压缩 | 10 | 是 | 300% | 3500MB/s | 01:45:00 | 每增加一个并行度，客户端（备节点）CPU会增加50%的计算资源消耗，服务端（主节点）也会同步增加计算资源和存储资源的消耗。随着并行度的提升，磁盘I/O接近上限后，对于重建的性能提升收益下降，需要根据实际业务资源消耗，选择重建方式。 #### 接口介绍 表2GUC参数 | 参数 | 参数说明 | 取值范围 | |:---|:---|:---| | parallel_build_thread_num | 代表并行重建的并行度。当取值为1时表示运行原有单线程重建代码，当取值为n时会建立n条线程完成重建时的数据传输。 | 取值范围：整型（1\~10） 默认值：1 | | enable_parallel_build_compression | 控制是否在并行重建传输数据的过程中进行LZ4压缩，仅在parallel_build_thread_num\>1情况下生效。 | 取值范围：on \| off 默认值：off | | async_build | 控制是否使用异步build流程重建故障DN。开启时采用异步流程重建，在剩余副本数不足多数派时，可优先恢复业务写入能力；关闭时采用同步逻辑重建，剩余副本数不足多数派时需等待数据与日志完全同步方可恢复业务。启用本功能后，若要求重建中的备DN参与多数派提交，需满足被重建的备DN在参数synchronous_standby_names配置的同步列表中，且除被重建DN外至少有一个同步列表中的DN存活 | 取值范围：on \| off 默认值：on | - 并行Build 请参见《参考》中"数据库运行参数说明 \> GUC参数说明 \> 双机复制 \> 发送端服务器"章节。 - 异步Build 请参见《参考》中"数据库运行参数说明 \> GUC参数说明 \> 双机复制 \> 主服务器"章节。 表3Build参数 | 参数 | 参数说明 | 取值范围 | |:---|:---|:---| | -b, --mode=MODE | 指定重建DN备机的模式。 | mode的取值： - full：通过全量镜像的方式重新同步DN主机的数据目录。 - incremental：通过解析Xlog日志获取主备DN差异的数据进行增量修复备DN。 - auto（缺省值）：优先尝试进行增量重建，gs_ctl服务控制工具会根据重建失败后是否可以再增量重建而选择继续增量重建或者全量重建。以下场景，gs_ctl工具会选择全量重建的模式恢复DN实例。 - 主机或备机的差异日志已回收或损坏。 - 主机或备机记录检查点信息的控制文件（即$PGDATA/global/pg_control）丢失或损坏。 - system identifier不一致。 - 增量重建的状态文件（即$PGDATA/global_rewind_info）丢失或损坏。 - standby_full：使用备机重建备机或容灾场景下的首备重建灾备数据库实例内故障的备机。需要数据源备机或首备状态为Normal。 - standby_incremental：使用备机增量重建备机或容灾场景下的首备增量重建灾备数据库实例内故障的备机。需要数据源备机或首备状态为Normal。 - standby_auto：先进行备机增量重建备机，gs_ctl服务控制工具会根据重建失败后是否可以再增量重建而选择继续增量重建或者全量重建。以下场景，gs_ctl工具会选择全量重建的模式恢复DN实例。 - 主机或备机的差异日志已回收或损坏。 - 主机或备机记录检查点信息的控制文件（即$PGDATA/global/pg_control）丢失或损坏。 - system identifier不一致。 - 增量重建的状态文件（即$PGDATA/global_rewind_info）丢失或损坏。 - cross_cluster_full：基于共享存储的同城双中心场景下的跨数据库实例全量build。 - cross_cluster_incremental：基于共享存储的同城双中心场景下的跨数据库实例增量build。 | | -D, --pgdata=DATADIR | 指定数据目录的位置。 | DATADIR的取值必须为有效的数据目录。 | | -Z NODE-TYPE | 指定当前连接数据库的运行模式。 | NODE-TYPE的取值为coordinator或者datanode。 | | -C CONNECTOR | 到源端DN的连接串，通过连接源端DN进行本节点上DN的重建。只支持备机到备机的连接。 | 连接串包含本节点待重建DN的IP和端口和源端DN的IP和端口，格式如下： ``` 'localhost=Local DN IP localport=Local DN Port+1 remotehost=DN IP remoteport=DN Port+1' ``` | | -M | -M后面需要跟SERVERMODE参数，表示在启动时指定数据库的启动模式。 | SERVERMODE的取值范围： - primary：本端以主机模式启动。 - standby：本端以备机模式启动。 - pending：本端处于等待状态，等待提升为主机或者备机。 - hadr_main_standby：本端以首备模式启动。 - cascade_standby：本端以级联备模式启动。 | | -q | build完成后不自动启动，需要调用者启动。 | - | | -r, --recvtimeout=INTERVAL | 指定重建过程中备机日志接收等待主机响应的超时时间。 | - 取值范围：整型 - 默认值：120（秒） | | -t, --timeout=SECS | 等待数据库启动或者关闭完成的最大秒数。 | - 取值范围：整型 - 默认值：60（秒） | | -U USERNAME | 流式容灾备集群首备节点进行跨集群重建时使用的replication用户名。 | - | | -P PASSWORD | 流式容灾备集群首备节点进行跨集群重建时使用的replication用户密码。 | - | | -Q | 在重建完成后进行刷写共享盘操作，仅Dorado容灾集群涉及。 | - copy_from_local：从本地往共享存储上复制。 - copy_from_share：从共享存储往本地存储上复制。 - force_copy_from_local：强制从本地往共享存储上复制。 |