HDUO Lab

标签： 分布式存储

  • 深入 Apache Pulsar 跨机房雪崩排查：Geo-Replication 断连引发的 Cursor 堆积与 BookKeeper GC 死亡螺旋实战

    某次跨地域容灾演练引发断网，Pulsar 集群 P99 写入延迟飙升至 5s。核心结论：Geo-Replication 复制链路断开导致 Replicator Cursor 停止推进，底层 BookKeeper Ledger 无法回收，磁盘满载后触发极端激进的 EntryLog Compaction，将 Ledger 盘 IOPS 彻底打满，导致 Write Cache 无法 Flush，最终阻塞写入。解决方案为配置 Backlog Quota 降级策略并隔离 GC IO。

    事故现场与指标异动

    排查过程中，监控大盘发出严重告警。集群（Pulsar 2.10.4, BookKeeper 4.14.7）在地域 A（主）和地域 B（备）配置了 Geo-Replication。地域 B 的专线网络模拟切断 30 分钟后，地域 A 的本地生产者全部收到 ProduceTimeout 异常。

    查看监控指标，发现以下几个异常：

    1. Broker 侧：pulsar_broker_publish_latency P99 从 5ms 突增到 5000ms+。

    2. Broker 侧：pulsar_replication_backlog 持续线性增长，Replicator 处于断开状态。

    3. Bookie 侧：Journal 盘（NVMe SSD）的 iostat 正常，但 Ledger 数据盘（普通 SSD）的 util% 持续 100%。

    4. Bookie 侧：Write Cache 满载，bookkeeper_server_ADD_ENTRY_QUEUE_SIZE 严重积压。

    登录其中一台 Bookie 节点，直接抓取磁盘 IO 现场：

    # iostat -xz 1
Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
nvme0n1 (Journal) 0.00     0.00  120.00  450.00  1536.00  4096.00    19.78     0.12    0.21    0.15    0.23   0.10   5.70
sda (Ledger)      0.00     0.00 4850.00 2100.00 65536.00 28672.00    27.11    34.50   14.20   12.10   19.05   0.14  100.00

    可以看到，负责同步刷盘的 Journal 毫无压力，但负责异步刷盘和冷数据存储的 Ledger 盘 IOPS 被完全打满。查阅 Bookie 日志，满屏的 Compaction 狂暴运作：

    20:15:33.123 [GarbageCollectorThread-1-1] INFO  org.apache.bookkeeper.bookie.GarbageCollectorThread - Suspending compaction, disk usage 92% is above warn threshold 90%.
20:15:33.456 [GarbageCollectorThread-1-1] INFO  org.apache.bookkeeper.bookie.GarbageCollectorThread - Running major compaction on entrylog 14552...

    为什么 Geo-Replication 断连会引发本地写雪崩？

    很多刚接触 Pulsar 计算存储分离架构的人会有个误区：BookKeeper 的 Journal 盘和 Ledger 盘是物理隔离的，只要 Journal 写得快，Pulsar 就能一直维持低延迟。

    但在实际生产的复杂拓扑（尤其是跨机房双活/多活）中，这个防御假设不堪一击。本次故障的底层原理是一场由 Cursor 停滞引发的连环死亡螺旋：

    1. Replication Cursor 卡死：Pulsar 的 Geo-Replication 本质上是 Broker 内部维护的一个特殊的 Subscription（游标）。当专线断开，地域 B 无法接收数据，地域 A 的 Broker 侧 pulsar_replication_backlog 会不断堆积。

    2. ManagedLedger 无法回收：Broker 侧的数据清理完全依赖 ManagedLedger 的 Cursor 推进。由于 Replication Cursor 是全量保留的，Zookeeper 中的 Ledger 元数据无法被标记为 Deleted。

    3. Bookie 磁盘水位告警：未删除的 Ledger 持续占据 Bookie 空间，导致 Ledger 磁盘使用率触碰 diskUsageWarnThreshold（默认 90%）。

    4. 触发 GC 死亡螺旋：BookKeeper Garbage Collector 线程检测到磁盘高水位，企图通过激进的 Major Compaction 腾出空间。但由于 绝大部分 Ledger 仍在存活期，Compaction 需要从旧的 EntryLog 中读取出存活的 Entry，重新写入新的 EntryLog，并更新 RocksDB 索引。这引发了极其庞大的无用读写（Read-Modify-Write）放大。

    5. Write Cache 阻塞：Ledger 盘的 IOPS 被 GC 榨干。由于 Pulsar 写入时不仅写 Journal，还要写入内存的 Memtable（Write Cache）。Memtable 满了后必须 Flush 到 Ledger 盘。Ledger 盘 IO 打满导致 Flush 极慢，最终阻塞整个 Write 链路，甚至引发 Broker 内存爆满和重连。

    核心配置调优与防御性加固

    花里胡哨的跨机房双活，最后往往死在最基础的磁盘保护和背压（Backpressure）机制上。解决此类问题，必须在 Broker 和 Bookie 双侧同时实施防御性配置。

    1. Broker 侧：强制接管 Backlog Quota (破局点)

    绝不能允许一个远端机房的断连拖死本地主干业务。必须对 Namespace 设置基于时间或大小的 Backlog Quota，并采取丢弃策略（Eviction），确保本地磁盘的生存权。

    # 查看当前的 backlog-quota
pulsar-admin namespaces get-backlog-quotas my-tenant/my-ns

# 强制配置 backlog-quota：超过 50GB 直接开始按最旧数据丢弃
pulsar-admin namespaces set-backlog-quota my-tenant/my-ns \
  --limit 50G \
  --policy consumer_backlog_eviction

    在 broker.conf 中，针对 Replication 场景开启默认强制容忍限制（重要）：

    # 如果订阅方掉线，最多保留多久的数据（分钟）
managedLedgerDefaultMarkDeleteRateLimit=1.0
backlogQuotaDefaultLimitGB=50
backlogQuotaDefaultRetentionPolicy=consumer_backlog_eviction

    2. Bookie 侧：GC 隔离与限速 (防爆点)

    Bookie 的默认 GC 策略过于理想化，在极端容量下，GC 必须被限速，否则它自己就会成为压垮 IO 的最后一根稻草。修改 bookkeeper.conf：

    # 磁盘使用率达到 90% 时触发告警，达到 95% 时 Bookie 直接变为 Read-Only（拒绝新写入，保命）
diskUsageWarnThreshold=0.90
diskUsageThreshold=0.95

# 严格限制 GC 线程的 IO 速率，避免 Compaction 打满磁盘
# 每秒最多重写 1000 个 Entry 或 10MB 数据
compactionRateByEntries=1000
compactionRateByBytes=10485760

# 开启 GC EntryLog 元数据缓存，减少 GC 时的随机读盘
gcEntryLogMetadataCacheEnabled=true

# 调小 Minor/Major Compaction 的阈值，平摊日常 GC 压力，防止堆积
minorCompactionThreshold=0.2
majorCompactionThreshold=0.8

    3. DbLedgerStorage 读写隔离 (底层优化)

    Pulsar 默认使用 DbLedgerStorage（基于 RocksDB）。在高并发落盘时，必须确保 RocksDB 的 Write Buffer 和 Block Cache 合理分配。在 bookkeeper.conf 调整分配策略：

    # 使用直接 IO，绕过 PageCache，防止 Catch-up 读或 GC 污染 PageCache，挤占 Flush 性能
dbStorage_directIOEntryLogger=true

# 为 RocksDB 设置合理的 BlockCache 大小（假设节点内存较大）
dbStorage_rockdbBlockCacheSize=2147483648
dbStorage_rockdbWriteBufferSizeMB=64

    常见问题

    Q: Broker 侧开启了 TTL（Time To Live），为什么断网后 Bookie 磁盘空间还是没有释放？ A: 这是 Pulsar 最常见的认知误区。TTL 默认只对 没有 Cursor 引用 的数据有效。如果你的 Replication Cursor（或者任何下游 Consumer Cursor）卡住了，数据会被标记为 Retained。此时 TTL 是无效的。如果想要 TTL 强制覆盖 Cursor，必须配合设置 ttlDurationDefault 并且使用 Namespace 级别的强制 Retention 策略，但这会导致复制链路丢失数据，需业务层评估接受度。

    Q: Bookie 日志盘 (Journal) 和数据盘 (Ledger) 已经分离，为什么 Ledger 盘高 IO 还是会影响实时写延迟？ A: 因为 BookKeeper 的写入模型中，数据除了追加到 Journal 盘（负责 WAL 可靠性），同时还会写入内存中的 Write Cache（Memtable）。Write Cache 满了需要 flush 到 Ledger 数据盘。如果 Ledger 盘因为 GC/大批量 Catch-up 读导致 IOPS 耗尽，Write Cache 无法被清理，此时新的写入请求就会被阻塞在内存池外，最终导致客户端超时。

    Q: 跨机房同步场景下，如何监控并提前预警这种问题？ A: 必须强监控 Broker 端的三个关键指标：

    1. pulsar_replication_backlog：复制延迟超过阈值必须立即告警，不能放任。

    2. pulsar_storage_backlog_quota_evictions：一旦触发丢弃，说明集群已经进入自保降级状态。

    3. bookkeeper_server_GC_ACTIVE_THREADS 和 Ledger 磁盘 util%：在正常运行期如果这两个指标飙升，说明你的节点容量或者负载规划已经严重不足。