技术原理

核心机制

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接近上限后，对于重建的性能提升收益下降，需要根据实际业务资源消耗，选择重建方式。

接口介绍

• 并行Build

  请参见《参考》中“数据库运行参数说明 > GUC参数说明 > 双机复制 > 发送端服务器”章节。

• 异步Build

  请参见《参考》中“数据库运行参数说明 > GUC参数说明 > 双机复制 > 主服务器”章节。

'localhost=Local DN IP localport=Local DN Port+1 remotehost=DN IP remoteport=DN Port+1'