RocksDB Resumable Remote Compaction 详解基于 Checkpoint 的可恢复远程压缩机制【免费下载链接】rocksdbA library that provides an embeddable, persistent key-value store for fast storage.项目地址: https://gitcode.com/gh_mirrors/ro/rocksdb导读RocksDB 通过CompactionServiceAPI 将压缩compaction任务卸载到远程 worker让主实例的 CPU 与 I/O 专注于读写服务但远程压缩任务动辄处理上百 GB 输入一旦 worker 崩溃、被抢占或超时整次压缩必须从头重来浪费全部已产出结果。Resumable Remote Compaction 引入检查点 恢复checkpoint-and-resume机制worker 在压缩过程中定期把进度持久化到output_directory中断后再次调用DB::OpenAndCompact()即可从最后一个检查点续跑。读完本文你将掌握该特性的完整工作流程、核心 API 与配置方式、进度文件与 delta 编码原理、跳过检查点的安全边界以及统计指标的使用方法。Background远程压缩的收益与痛点RocksDB 的远程压缩Remote Compaction模型基于CompactionServiceAPI主 RocksDB 实例primary负责挑选输入文件把序列化后的CompactionServiceInput发送给 worker远程 worker运行DB::OpenAndCompact()完成压缩将输出的 SST 写入output_directory再返回序列化的CompactionServiceResult主实例把返回的结果安装进自己的 LSM 树中。这套架构让运维人员可以用无状态statelessworker 横向扩展压缩吞吐同时把主实例的 CPU 与 I/O 留给读写路径。相关类型与函数在 include/rocksdb/db.h 与 include/rocksdb/options.h 中均有完整声明。但远程压缩任务可能运行很长时间有时处理数百 GB 输入。当 worker 崩溃、被抢占或超时时整个压缩必须从头重启之前产出的所有输出全部作废并让主实例背上不断累积的压缩债务compaction debt。这正是 Resumable Remote Compaction 要解决的问题。Resumable Remote Compaction 的工作原理Resumable Remote Compaction 引入了检查点与恢复机制压缩过程中worker 周期性地把进度保存到output_directory如果压缩被中断后续以相同输出目录再次调用OpenAndCompact()即可从最后一个检查点继续而不是从头开始。检查点Checkpointing每完成一个输出 SST 文件后worker 就会向输出目录output_directory中的**压缩进度文件compaction progress file**持久化一个进度检查点记录恢复时需要从哪个internal key继续所有已完成输出文件的元数据。进度记录采用delta 编码delta encoding——每条记录只包含自上一个检查点以来新完成的文件从而保证序列化开销随进度线性增长而不是随整个任务累计增长。该进度文件是 RocksDB 中一类全新的文件类型在 include/rocksdb/types.h 的FileType枚举中新增了kCompactionProgressFile在 file/filename.cc 中定义了CompactionProgressFileName()与TempCompactionProgressFileName()进度文件以COMPACTION_PROGRESS-前缀 时间戳命名临时文件额外带.tmp后缀先写临时文件、再原子改名与 RocksDB 其他文件类型保持一致的文件管理规范。worker 会在以下两类边界跳过检查点因为在这些位置恢复可能不安全或需要复杂的特殊处理当range deletions范围删除跨文件边界时当相邻输出文件共享同一个 user key时。这些约束保证了恢复后的结果与从未中断的压缩完全一致。恢复Resuming当以allow_resumption true调用OpenAndCompact()时系统会扫描输出目录查找有效的进度文件若找到加载检查点状态将输入迭代器 seek 到记录的恢复 key并恢复输出文件状态从该位置继续压缩若进度文件损坏或缺失则清理目录后回退到全新压缩fresh compaction。如何启用主实例与 worker 两侧的配置在主 RocksDB 实例上为 DB options 设置一个CompactionService实现在远程 worker上调用DB::OpenAndCompact()时在OpenAndCompactOptions中传入allow_resumption true。关键前提output_directory在每次重试之间必须保持一致恢复才能生效——每次使用相同目录的重试调用会自动检测并续跑之前的检查点REMOTE_COMPACT_RESUMED_BYTES统计指标ticker记录从上次中断运行中复用resume的输出文件总字节数用于直观衡量恢复节省了多少工作量。代码示例// Primary RocksDB instance DBOptions db_options; db_options.compaction_service std::make_sharedMyCompactionService(); // Remote worker OpenAndCompactOptions options; options.allow_resumption true; std::string result; Status s DB::OpenAndCompact( options, db_path, // source database path output_directory, // where output SSTs and progress are stored compaction_input, // serialized CompactionServiceInput result, // serialized CompactionServiceResult override_options);OpenAndCompactOptions 完整字段语义在 include/rocksdb/options.h 中OpenAndCompactOptions除allow_resumption外还包含以下字段从源码可确认其完整语义canceledstd::atomicbool*默认nullptr允许取消进行中的压缩max_secondary_open_retriesuint32_t默认2打开源 DB 作为 secondary 失败因 CURRENT/MANIFEST 被并发替换时的最大重试次数为 0 则禁用重试allow_resumptionbool默认false是否尝试从先前持久化的压缩进度恢复。关于allow_resumption的详细行为源码注释给出了比博客更精确的约定true时尝试从output_directory中持久化的进度恢复执行期间会周期性地把新进度持久化到同一目录供后续调用续跑。如果恢复无法满足例如恢复状态损坏或缺失系统会尽力回退到全新压缩——先清理output_directory中的相关文件以获得干净状态若连全新压缩都无法启动则返回非 OK 状态。需要注意若导致上一次OpenAndCompact()失败的根因仍然存在恢复尝试同样会无效大概率仍返回同样的非 OK 状态。进度持久化是串行且尽力而为best-effort的在每个新输出文件完成时触发若压缩在创建某个输出文件的中途被打断该部分工作需要在恢复时重做。false时从头开始全新压缩执行期间不保存任何进度中断后必须完全重来。关键要求调用前output_directory必须为空任何残留文件包括上次运行的恢复状态或输出文件都可能造成正确性错误。已知限制目前与paranoid_file_checkstrue不兼容启用该选项时此特性实际上被禁用。另外DB::OpenAndCompact()的重载签名include/rocksdb/db.h还说明output_directory在DBOptions::use_session_tmp_dir_for_remote_compaction为 true 时必须是单层目录名实际路径为name/session_tmp/output_directory否则为name/output_directory。统计指标REMOTE_COMPACT_RESUMED_BYTES在 include/rocksdb/statistics.h 的TickerType枚举中定义其 C 端实现位于 monitoring/statistics.ccJava 绑定位于 java/src/main/java/org/rocksdb/TickerType.java 与 java/rocksjni/portal.h。通过该指标运维人员可以量化每次恢复实际复用了多少输出字节从而评估重试是否真正省下了活。测试与验证依据仓库中的 db/compaction/compaction_service_test.cc 覆盖了该特性的关键场景多处测试以allow_resumption true配置OpenAndCompactOptions如 L2601、L3312、L3354、L3357验证恢复路径的正常执行测试通过statistics-getTickerCount(REMOTE_COMPACT_RESUMED_BYTES)L3533、L3619断言恢复后复用的字节数直接印证了复用输出文件这一行为的正确性。Future Work从远程压缩走向本地压缩目前该特性只针对远程压缩场景但同一套 checkpoint-and-resume 机制未来也可支持本地压缩在崩溃后的恢复。核心的持久化与恢复逻辑已经落在CompactionJob见 db/compaction/compaction_job.cc 与 db/compaction/subcompaction_state.h恢复状态在 db/compaction/compaction_service_job.cc 中用于远程任务编排中剩余工作主要是将其与本地压缩调度scheduling和崩溃恢复recovery流程集成。总结Resumable Remote Compaction 通过检查点文件 delta 编码把远程压缩从全有或全无变成可续跑显著缓解了长任务中断时的算力浪费与主实例压缩债务问题。使用时的三条关键经验重试时保持output_directory一致否则无法续跑不开恢复时务必保证输出目录为空避免正确性错误通过REMOTE_COMPACT_RESUMED_BYTES观察实际复用的输出量验证恢复是否真正生效。该特性当前标记为 EXPERIMENTAL且与paranoid_file_checkstrue不兼容生产使用前请结合仓库中的源码注释与测试用例充分验证。【免费下载链接】rocksdbA library that provides an embeddable, persistent key-value store for fast storage.项目地址: https://gitcode.com/gh_mirrors/ro/rocksdb创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考