【向量检索引擎】副本、负载与故障恢复：内存副本与 WAL 迁移

前几篇默认「一段在某处加载一次」。生产读放大与可用性靠 内存副本、写侧靠 WAL 可迁移、段分布靠 Coordinator handoff。本文合并这三条恢复与扩缩路径。

本文是「向量检索引擎」系列第 14 篇（共 18 篇）。→ 系列目录

版本锚定：Milvus 2.6.x In-Memory Replica、Streaming Service、Data Processing、Architecture。

一、In-Memory Replica：同一 Sealed 多份内存象

In-Memory Replica：允许同一 segment 加载到 多个 Query Node 的工作内存，以提升性能与可用性。

1.1 关键概念（官方）

1.2 与 2.6 Streaming 架构的对照阅读

2.6 Architecture / Data Processing 将 Growing 放在 Streaming Node，Sealed 放在 Query Node。In-Memory Replica 文档仍大量使用「Query Node 服务 growing」的表述——属于组件演进中的术语滞后。

本系列采用如下对齐（不伪造未文档化的内部表结构）：

• Historical / Sealed 多副本：按 In-Memory Replica，同一 sealed 段可多 Query Node 加载——这是读扩缩与故障转移的主杠杆。
• Growing / 流侧多副本：Streaming Service 写明 Collection 配置多副本时，除与 WAL 共存的 Delegator 外，另有 \(N-1\) 个 Delegator 部署在其它 Streaming Node——流侧可用性按该叙述理解。
• 配置入口：官方指向 Query Node 相关配置（In-Memory Replica → Query Node-related Configurations）。

读源码或监控时同时搜 replica 与 delegator，避免只认旧名词。

二、Search 路径上的缓存与 Failover

In-Memory Replica · Search：

1. Proxy 缓存 segment→Query Node 映射，并周期性更新；请求到来时尽量均匀分配 sealed 段到各节点。
2. Growing 侧维护 channel→节点缓存并发送请求。
3. Failover：缓存可能过期；段已迁移则 Proxy 收到错误，更新缓存并改派。若更新后仍找不到段，可能因 compaction 已消除该段 而忽略。
4. 持有 DML channel 的节点可在响应中带回 可靠段列表，供 Proxy 校对缓存。
5. Enhancement：节点负载不均时，Proxy 可把其它节点上的活跃段请求派给同样持有该段、且更空闲的节点，缓解长尾。

这与第 4 篇「routing cache，缺则问 Coordinator」、第 9 篇多级 reduce 同一家族：正确性依赖 视图最终追上，短暂不一致靠重试与缓存刷新。

三、WAL 迁移与 Wait for Ready

Streaming Service：存算分离使 WAL 可从一 Streaming Node 迁到另一节点。迁移窗口：

• 旧节点拒绝部分请求；
• 新节点恢复 WAL；
• 客户端 Wait for Ready。

写路径可用性的关键不是「Query Node 副本数」，而是 WAL 单所有者 + 快速恢复（第 5 篇 fencing）。副本再多也救不了「WAL 未就绪」的写入。

四、Handoff 与负载均衡

Data Processing：flush 或 compaction 后，Coordinator handoff，在 Query Node 间分配 Sealed，平衡内存、CPU、segment 数，释放冗余。

故障与扩缩时：

五、代价：副本不是免费 QPS

小数据集 + 多硬件堆 QPS 是官方点名的甜区；十亿级全量多副本可能先被内存与对象费用打死。

六、学术谱系、工程间隙、开放问题

6.1 谱系

内存多副本 ≈ 只读副本组；与共识日志多副本不同——Milvus 写耐久在 WAL，读副本服务查询扩展。

6.2 工程间隙

• 文档术语跨 2.x→2.6 需人工对齐 Streaming/Query。
• 「至少一个副本加载成功即可服务」缩短上线时间，但副本未齐时容量与尾延迟仍差。
• Proxy 增强调度依赖段级副本拓扑正确；拓扑抖动期长尾可能恶化。

6.3 开放问题

1. 副本因子随 QPS 自动伸缩的策略？
2. 跨可用区放置时，延迟与删除广播的 SLA？
3. 与 Kubernetes 滚动升级的配合：先加副本再驱逐？

七、小结

读扩缩靠 Sealed 内存多副本 + Proxy 缓存改派；写可用靠 WAL 迁移与 Wait for Ready；段分布靠 handoff。下一批进入对照与收束：第 15–18 篇（Qdrant、Lance、排障、选型）。

参考资料

1. Milvus Documentation v2.6.x, In-Memory Replica。
2. Milvus Documentation v2.6.x, Streaming Service（多 Delegator、WAL 迁移、Wait for Ready）。
3. Milvus Documentation v2.6.x, Data Processing（handoff）、Architecture Overview。
4. 第 4、5、6、9、10 篇、系列 index。

返回 系列目录 ｜ 上一篇：Delete · Upsert · TTL ｜ 下一篇：Qdrant 对照