1. 先把问题摊开Hermes 状态库为什么会走到“恢复”这一步先说背景。Hermes 是我在负责的一套分布式状态存储服务底层选用类 LSM 架构的高性能键值库作为状态引擎上层单独维护了一套全文检索FTS索引。业务方把设备状态、会话状态、任务状态这类需要持久化的数据写入 Hermes同时通过 FTS 索引做多维度的检索查询比如按状态字段、时间范围、自定义标签组合过滤数据。这套架构跑了大半年日常读写都很稳但状态库和 FTS 索引天然存在一条隐性的“数据链路”业务写入时先落状态库再投递索引更新消息给 FTS 构建线程。只要这条链路上任何一个环节出问题——比如节点掉电、磁盘写坏、索引目录被误删、版本升级中断——就会出现一个特别头疼的局面状态库里的数据还在但 FTS 索引查不到或者两边数据都能读但完整性对不上。我这次写出来就是因为实际处理过一次非常典型的恢复场景某个节点因为异常掉电重启后状态库的 WAL 日志回放不完整同时 FTS 索引目录下好几个分片文件校验失败。当时的状态是“两个防线同时失守”恢复策略必须同时兼顾不能只修一边不管另一边。下面把这次恢复的全过程、关键原理和踩过的坑都整理出来希望对正在设计状态存储和检索系统的同学有一点参考价值。先说清楚一件事我这里说的“双重防线”并不是指两套备份方案互相冗余而是指两个不同层次的恢复动作——第一道防线针对状态库本体的数据恢复快照 WAL 回放第二道防线针对 FTS 全文索引的修复增量修补 全量重建。两条防线处理的故障类型不同恢复手段不同但又必须保证恢复完成后两边数据能够对齐。这才是这类系统恢复真正的难点。2. 第一道防线State DB 的状态快照与日志回放2.1 状态库存储模型决定了恢复的基本策略Hermes 的状态引擎采用的是 LSM 结构写入路径是 MemTable → 不可变表 → 分层压缩落盘。这种模型有几个特点直接决定了恢复策略第一写入操作并不会立刻同步到磁盘上的有序数据文件而是先缓存在内存里到了一定阈值再批量刷盘。这意味着一旦进程崩溃内存中未刷盘的数据就丢了必须依赖日志才能找回来。第二LSM 的多版本合并机制会让同一个 Key 在多个分层中存在历史版本恢复时如果只简单 dump 数据文件可能读到过期版本必须通过全量快照 增量回放才能得到一致的最新视图。第三数据文件的校验信息通常以块级校验和Block Checksum的形式存储在文件尾部磁盘坏道或非正常断电可能导致部分块损坏。恢复的第一步是校验文件完整性而不是直接尝试加载数据。所以标准的状态库恢复策略基本固定为三步1. 从最近的快照Snapshot恢复全量数据 2. 回放快照之后产生的 WAL 日志恢复到崩溃点时刻 3. 对内存索引和磁盘文件做一致性校验确认没有丢失写入这里要特别强调一个容易忽略的点快照不是越大越好也不是越频繁越好。快照本质上是一个一致性的数据副本生成时需要将 MemTable 强制刷盘Flush这个动作对正在运行的写入会有短暂阻塞。我们实际压测下来的经验是对于单节点写入 QPS 在 3k 左右的场景快照间隔设置在 15 分钟到 30 分钟之间比较合理。以 30 分钟快照为例恢复理论耗时 快照加载时间 最多 30 分钟 WAL 回放时间。如果快照间隔拉长到 4 小时WAL 回放时间就会显著增长而且 WAL 文件越大回放时遇到损坏日志段的风险也越高。2.2 写前日志WAL在恢复中的角色WAL 的作用一句话概括在真正修改内存和磁盘数据结构之前先把这操作记到日志里。只要日志落盘成功了即使随后进程崩溃重启之后也可以把日志重新执行一遍让状态库恢复到崩溃前一刻的内存视图。我在实际项目中踩过一个典型的坑很值得说一下WAL 的刷盘策略如果不做配置调整默认可能是“每秒刷盘”或者“由操作系统决定”这对恢复来说就是灾难级别的隐患。设想一个场景业务已经调用了写入接口并收到了成功响应但这个回执其实是基于内存写入成功的日志还在 Page Cache 里没刷到磁盘。这时候节点掉电重启后内存数据全部蒸发而 WAL 里压根没记下这条写入——数据就静默丢了。在 Hermes 项目里我们对 WAL 刷盘配置做了显式调整配置项推荐值说明WAL 刷盘模式每次写入同步刷盘性能会受影响但保证写入即可恢复日志文件滚动大小32MB 或 64MB过小导致文件过多过大会拖慢回放日志保留策略保留最近 2 份完整快照周期确保回放窗口完整关于“每次写入同步刷盘”这个配置我用一个生活化类比来解释为什么“性能损失”是值得的想象你在写日记有两种方式。一种是把每句话都马上刻到石板上很费力气但石板上的内容永远是真的另一种是先把话写在便利贴上攒一批再统一刻一次省力气但万一失火了便利贴烧掉了那这批内容就彻底没了。WAL 同步刷盘就是前者它牺牲了一点写吞吐换来了“只要接口确认成功重启就能恢复”的确定性。当然同步刷盘的实际代价没有想象中那么大。我们在压测环境里对比过开启同步刷盘后单分片写入延迟从平均 0.8ms 上升到 1.4ms但 p99 延迟从 5ms 左右上升到接近 9ms。对于状态存储这类对延迟不是极度敏感的中间件这个代价完全可接受。2.3 状态库恢复的完整执行步骤这次故障中状态库恢复的执行步骤我整理成了可以直接抄作业的操作序列第一步停服并保护现场恢复操作开始前先把节点从服务的可用节点列表里摘除让流量不再打到这台机器。然后检查数据目录和日志目录的挂载状态确认磁盘没有硬件层面的只读问题。# 摘除节点后先对数据目录做只读挂载检查 mount | grep hermes-data mount | grep hermes-wal # 查看数据目录文件系统的状态 dmesg | tail -50如果发现有文件系统错误的输出先不要做任何写操作直接联系基础设施团队确认磁盘是否还能继续用。这一步看起来多余但实际上非常重要——如果磁盘本身要坏了你做的任何恢复操作都可能在写回过程中再次触发损坏。第二步加载最近快照找到最近一份完整快照把它加载到数据目录。Hermes 的快照文件是分片打包的加载时会生成一个临时目录加载完成后再原子切换。加载时通过校验和机制验证所有块的完整性有任何一块校验失败这个快照就判定为无效必须回退到更早一份快照。# 列出当前节点已有的快照文件 ls -lht /data/hermes/snapshots/ # 执行快照加载以某个通用管理工具为例 hermes-admin snapshot restore --snapshot-id 20250118-060000-080 --data-dir /data/hermes这里有个心得加载快照前先手工比对快照的元信息文件与预期版本号。因为快照文件管理经常会因为备份任务、清理任务并发产生意外如果盲目加载了一份不完整的快照回放日志时会出现大量重复或者缺失的 Key 操作排查起来非常痛苦。第三步回放 WAL 日志快照加载完成后把快照时间点之后的 WAL 日志按顺序回放。回放过程中需要注意三个关键点断点续传WAL 文件是一个连续的日志序列每条记录有唯一的序号。如果你回放到第 10000 条时中断了需要能从第 10000 条继续而不是从文件头重新开始。损坏跳过某些日志段可能因为掉电时不完整的最终写入而损坏回放引擎要能识别出这部分并跳过而不是直接报错终止。幂等性回放操作必须设计成可重复执行的即使某一段日志被回放了两遍最终状态也应该一致。# 通过管理工具执行 WAL 回放 hermes-admin wal replay --wal-dir /data/hermes/wal --from-snapshot-id 20250118-060000-080第四步全量校验回放完成后执行一次全量 Key 的计数和抽样校验。最直接的方式是扫描所有数据目录下的 SST 文件统计 Key 数量与快照元信息中记录的预期数量做对比。另外还要抽查一批样本 Key和上一次快照的内容做差异比对。这次实际恢复中我们用一个统计脚本扫描后发现总数一致但抽样中有 17 个 Key 的版本落后于预期排查下来是回放时有一条 WAL 记录的序号被重复跳过导致的。这个问题不算致命但如果不处理这 17 个 Key 后续被查询时会读到旧值。第五步确认后重新接流量状态库恢复完成后先启动节点进入只读模式对外提供查询服务但不接受写入。观察一段时间确认查询结果没有异常再逐步放开写入。注意千万不要在状态库还没有完全确认恢复一致前就急着去处理 FTS 索引。索引修复需要读取状态库的数据源如果源本身还有问题重建出来的索引必然也是错的。我在一开始处理时差点犯这个错误幸好提前做了完整校验。3. 第二道防线FTS 全文索引的修复与重建3.1 FTS 索引损坏的典型表现FTS 索引和状态库的状态数据不同它本质上是为查询服务的“派生数据”。状态库负责存储事实FTS 负责加速检索。FTS 一旦损坏系统的表现通常是以下几种检索结果集变小明明状态库里某个状态码的记录有十万条通过 FTS 检索只有九万条缺了一部分文档。检索结果不一致按多个条件组合过滤时某些条件下能查出结果换一个过滤组合就查不出来——原因是文本切词或倒排链缺失导致部分文档没有被正确索引。索引写入持续失败索引构建线程反复报错某些分片无法写入新的文档导致新数据一直查不到。在 Hermes 的场景里这次出现的问题是第一种和第三种混合状态部分分片文件在校验时发现尾部块 CRC 错误导致加载失败同时写入侧因为分片状态异常开始阻塞索引更新消息积压越来越严重。3.2 增量修补还是全量重建判断依据很重要FTS 索引修复时最纠结的问题就是选“修补”还是“重建”。我的判断标准是这样轻量损坏如果只有个别分片损坏且损坏比例很小比如千分之一以内可以尝试对损坏分片执行增量修补。做法是把损坏分片标记为“待重建”然后从头扫描状态库中属于该分片的全部数据重新生成这个分片的倒排索引。因为这个过程只涉及部分数据代价可控。大面积损坏如果损坏分片数量超过总分片的 5%或者损坏出现在公共词典/全局元信息这类所有分片都要依赖的组件上那就没有必要修补了直接全量重建。版本升级导致的索引结构变更这类情况本质上也不是“修复”而是“迁移”只能全量重建新格式索引修补没有意义。这次实际故障里12 个分片中有 3 个分片出现了不同程度的问题占比 25%属于明确的大面积损坏所以决策非常干脆全量重建。3.3 全量重建 FTS 索引的完整流程与参数配置全量重建看起来就是“扫一遍数据建立索引”但实际执行时牵扯到资源占用、构建进度、查询一致性多个方面比想象中复杂得多。第一步确认索引源数据的完整性这个环节至关重要。FTS 重建的数据源是状态库的当前全量数据。如果状态库本身还没有恢复一致索引重建的结果一定会缺失。我在这次操作中专门写了一个比对程序先从状态库按分片范围做全量扫描计数再从现有可用索引分片做一次文档数统计两边数量差在预期范围内因为存在并行写入才开始进入正式重建。第二步创建“影子索引”所谓“影子索引”指的是在构建期间不直接覆盖旧的线上索引而是在另一个独立目录里从头构建一份完整的新索引。构建期间线上查询继续使用旧索引只有新索引构建完成并通过校验后才会通过原子切换方式把流量切到新索引上。# 创建影子索引指定独立构建目录 hermes-fts build --source-db /data/hermes --index-dir /data/fts/index.building --shard-count 12这一步非常重要好处很明显即使构建过程中途失败线上查询服务仍然使用的是旧索引不会产生一段“检索不可用”的空窗期。构建失败后只需要清理掉构建中的目录重新开始即可。第三步参数配置全量构建时最关心的参数有三个并行线程数、批量提交大小、内存中驻留的索引段数量。这三个参数直接影响构建速度和资源占用参数推荐配置设置依据构建线程数CPU 核数的 60%~70%线程太多会导致 CPU 上下文切换开销增大构建反而变慢批量提交大小每批 5000~10000 条文档太小则事务开销占比高太大会导致单次提交内存压力大内存索引段上限不超过堆内存的 25%超过的话合并段时很容易触发 GC 停顿用这次实际案例说明节点是 16 核 CPU构建线程配了 10 个16 × 65%批量提交 8000 条文档Java 进程堆内存 4GB内存段上限 1GB。实测下来1200 万条文档的索引构建耗时大约 22 分钟构建期间 CPU 使用率维持在 75% 左右线上查询延迟没有明显波动。第四步构建完成后的双跑校验新索引构建完成后先不要急着切流量。做一个“双跑对比”同一组查询语句同时打到旧索引和新索引上比对返回的文档 ID 列表是否一致。这里注意正常情况下的双跑结果允许有一定差异但差异只能是“新索引多旧索引少”或者两边一样多绝对不允许出现“旧索引有、但新索引没有”的结果。为什么因为重建索引的目的是把数据补齐如果新索引反而缺了旧索引的数据说明构建过程有问题需要排查。第五步原子切换校验通过后把线上索引目录的软链接从旧目录指向新目录这一步就是一次原子切换操作。切换完成后立刻对线上查询做一次抽样验证比如选取业务方常用的 10 个检索条件比对切换前后的查询结果和耗时。# 原子切换索引目录 ln -sfn /data/fts/index.building /data/fts/index.online4. 实操实录从故障发现到恢复验证的完整过程4.1 故障发现与影响面评估这次故障的发现过程值得记录一下因为它不是靠节点状态告警触发的而是靠检索质量监控发现的。早上 8 点 15 分监控平台显示 Hermes 的 FTS 查询平均命中率从正常的 99.2% 下降到 94.6%同时“查询无结果”的请求比例从 0.3% 上升到 5.4%。随后运维通过后台确认节点在凌晨 4 点 30 分左右出现过一次异常掉电重启状态库和索引都经历了不完整的启动过程。这个案例说明一个很重要的点对于状态存储系统“节点存活”不代表“服务健康”必须加检索质量层面的监控。如果只监控 CPU、内存、磁盘这些基础指标可能要好几个小时甚至几天后才会被业务方发现数据不对。影响面评估分两面。查询侧FTS 索引损坏导致约 5% 的查询结果缺失影响面是“检索准确性”而非“系统可用性”服务没有整体中断。写入侧索引构建线程阻塞后更新消息积压了大约 1 小时 20 分钟这意味着那段时间内写入的数据在索引里都查不到。4.2 先处理状态库再重建索引这个问题我在前面已经强调了这里展示实际操作顺序第一阶段状态库恢复上线耗时约 40 分钟8 点 20 分开始执行状态库恢复流程加载 1 小时前的快照回放期间累积的 WAL9 点 05 分确认状态库数据完整9 点 10 分开放只读查询9 点 20 分恢复写入恢复期间观察到写入延迟有约 30% 的提升原因是 WAL 回放过程中同步刷盘和正常写入存在共享锁竞争但恢复完成后延迟很快回归正常。第二阶段FTS 全量重建耗时约 30 分钟9 点 30 分做源数据完整统计确认状态库全量可读9 点 35 分创建影子索引目录启动构建10 点 05 分构建完成开始双跑对比10 点 15 分确认新索引不缺失任何旧索引已有的文档10 点 25 分完成原子切换10 点 30 分检索命中率监控回到 99.1%积压的索引更新消息全部消费完毕整个过程耗时 2 小时左右其中真正恢复组件数据的时间约 1 小时剩余时间是各种校验和观察。4.3 恢复后的全量一致性校验清单恢复完成不代表万事大吉我建议按照下面这个清单做最后的验收写入链路验证向状态库写入一批带标记的测试数据等索引消息消费完成后通过 FTS 检索这批数据确认能立即查到且字段内容正确。全量文档计数对比通过状态库全量扫描得到文档总数与 FTS 索引的 commit point 记录数做对比差异必须在 0 附近。历史数据抽样取随机 1000 个 Key逐条比对其在状态库和 FTS 中的字段值。这一步非常耗时但能有效发现字段级错位的问题。长时间运行稳定性恢复后持续观察 24 小时确认索引合并任务、段合并任务能正常执行不出现反复失败。演练文档更新把实际耗时和参数配置记录下来更新到恢复预案文档中作为后续演练的基准值。5. 这几个月踩过的坑故障排查经验速查5.1 典型故障案例与排查过程这次恢复之外结合平时运维的积累我把状态库和 FTS 恢复相关的典型故障整理成了一张速查表方便遇到相似问题时快速定位故障症状可能原因排查思路与方法解决方案WAL 回放卡住不动日志段尾部有未完成写入但格式上又未被判定为损坏查看回放引擎日志中最后一条成功回放的日志序号比对 WAL 文件大小手工截断损坏段配置跳过损坏段继续回放索引文档数少于状态库文档数索引消息积压或某些分片写入失败查看索引构建线程的积压队列长度检查失败分片列表积压则消费积压失败则单独重建对应分片双跑对比中新索引缺少旧索引已有文档构建源数据读取不完整或构建程序有过滤逻辑检查构建日志中的跳过记录比对状态库扫描范围的 Key 区间修正构建源数据选择逻辑重新构建快照加载后索引无法启动快照元信息损坏或快照版本与当前索引格式不兼容检查快照文件的元信息字段比对版本号回退到更早版本快照或直接触发全量重建恢复后索引查询结果重复回放日志出现重复操作导致索引重复写入检查回放是否执行了两次比对写入日志的去重记录校验回放幂等性针对重复 Key 做去重构建索引期间线上查询变慢构建任务占用了过多 CPU 或磁盘 IO查看系统负载比对构建前后的查询 p99 延迟降低构建线程数设低批量提交大小5.2 排查思路与方法实录针对最典型的“WAL 回放卡住不动”这个问题我说一下具体排查过程。回放引擎卡住时首先看日志输出找到最后一条成功回放的日志序号假设是 80000。然后用工具查看 WAL 目录下文件找到包含该序号的日志文件检查文件尾部的写入情况# 查看 WAL 文件大小与最后修改时间 ls -l --time-stylefull-iso /data/hermes/wal/ # 查看文件尾部是否有不完整的日志块 tail -c 1024 /data/hermes/wal/WAL-LOG-000000.log | xxd如果文件尾部是一串不完整的 0 字节或者 CRC 校验失败的数据块说明这是掉电瞬间产生的损坏段。处理方式是把文件截断到最后一个有效日志块的结束位置然后重新启动回放。# 截断 WAL 文件到有效日志块尾部以字节偏移量为例 truncate -s 134217600 /data/hermes/wal/WAL-LOG-000000.log这个操作要非常谨慎截断前一定要确认偏移量准确。我建议的做法是先用一个脚本解析日志文件格式输出最后一个完整日志块的偏移量然后人工确认后再执行 truncate。不要凭感觉估一个大小宁可先多保留一些数据也不要把有效日志截掉。5.3 恢复预案的持续迭代建议这次恢复操作结束后我做了三件事建议你也照做第一把恢复流程的每一步都写成可执行的脚本而不是靠人肉敲命令。人肉操作在紧急情况下非常容易出错比如参数写错、目录搞混、少执行一步。脚本化之后执行前可以自动做前置条件检查执行中也更容易定位失败步骤。第二每月做一次恢复演练。演练选在低峰期用备份节点模拟故障完整走一遍“快照恢复 WAL 回放 索引重建 双跑校验 原子切换”的流程。第一次演练时我们花了近 3 个小时中间踩了好几个坑演练到第三次时时间稳定在了 1 小时 20 分钟以内。恢复演练最大的价值在于提前发现预案里没有考虑到的问题而不是在真实故障时临场摸索。第三监控上增加“恢复相关”的专项指标。包括快照文件的有效性检查定期做全量校验和WAL 文件滞后量当前时间与最新 WAL 记录的时间差索引构建积压队列长度渲染后的检索命中率监控这些指标在平时看起来不痛不痒但一旦故障发生时它们就是判断恢复进展的关键输入。提示恢复演练不能和真实故障场景差太多。我见过有些团队演练时用的是“干干净净”的测试数据这种演练基本等于走过场。真正有价值的演练是往测试环境里塞满和线上规模差不多的数据模拟 WAL 文件损坏和索引分片丢失这种复合型故障让执行人切实感受恢复流程的耗时和坑点。6. 恢复实操中最不能省的那几步最后分享一点个人体会。状态库和 FTS 索引的“双重防线”听起来像是在讲架构设计但真正经历过一次故障之后我的感受是它更像是工程细节的累积。每一条防线能不能真正起作用取决于你有没有把恢复步骤落成脚本、有没有配置对 WAL 的刷盘策略、有没有在索引重建前先做源数据校验、有没有在恢复完成后做双跑对比。我在这次恢复中最大的收获可以总结成三点一是“停服保护现场”永远不能省不要在没确认磁盘完好前就启动任何恢复操作二是“源数据一致性校验”一定要在索引重建前执行让 FTS 重建基于一个可信的数据源而不是基于一个可能还有问题的状态库三是“双跑对比”是发现潜在问题的最有效手段一定不要因为急着恢复服务而跳过这一步。另外还有一个小技巧在日常运维中我会定期把 WAL 文件导出到另一台机器做“冷备”。这样即使主节点数据盘彻底报废也能通过最新的快照 冷备的 WAL 恢复绝大部分数据。这个操作成本很低但关键时刻能兜底。状态恢复这类工作在没出事时默默无闻但真正遇到问题时提前做好的每一个细节都会成为你快速恢复出去的底气。