Qdrant 1.18.3发布：分片键重分片查询错误修复，哪些集群应该升级？

文章摘要Qdrant 1.18.3于2026年7月17日发布本次版本只包含一项Bug修复解决使用Shard Key进行重分片时可能出现的查询错误。更新内容虽然很少但它影响的是多租户、大规模Collection和在线扩缩容场景。本文解释Shard Key与Resharding的关系、故障可能出现在哪些阶段、升级前如何复现和验证以及为什么小版本修复也需要按生产级流程灰度发布。一、这次版本修复了什么Qdrant 1.18.3的Change Log非常短Fix query errors when using shard keys while resharding也就是使用Shard Key 集群正在Resharding → 某些查询可能报错这不是新功能版本也没有大规模API调整。但如果系统满足以下条件需要重点关注分布式Qdrant集群Collection使用Shard Key正在或计划在线重分片多租户RAG高并发查询不能接受扩容期间查询失败。二、Shard Key是什么默认情况下Qdrant根据Point ID将数据分布到不同Shard。Shard Key允许业务显式控制数据分组。例如多租户系统tenant_a → 指定Shard Key tenant_b → 另一个Shard Key好处按租户路由降低跨Shard查询便于租户隔离可以迁移特定数据组大租户可独立扩容。Payload示意{tenant_id:T001,document_id:DOC-1001}写入时指定shard_key T001三、Resharding为什么复杂当数据量和流量增长时原来的Shard数量可能不足。Resharding需要创建新Shard布局 → 搬迁数据 → 同步增量写入 → 更新路由 → 切换查询 → 清理旧布局在迁移期间部分Point可能仍在旧Shard部分已经迁移到新Shard新写入需要正确路由查询需要同时理解迁移状态Shard Key需要映射到正确分片。任何路由状态不一致都可能产生查询报错结果缺失重复结果延迟升高部分租户不可用。四、哪些RAG项目受影响最大1. 多租户知识库每个租户使用独立Shard Key。扩容时如果查询路由异常可能只有部分租户失败导致问题不容易被整体监控发现。2. 超大Collection通过Shard Key把业务线 地区 客户 时间分区分组管理。3. 在线扩容要求Resharding期间继续提供查询服务。4. 高频Metadata过滤查询既指定Shard Key又使用复杂过滤和混合检索故障链路更长。五、哪些项目可以暂缓如果项目是单节点不使用Shard Key没有执行Resharding开发或测试环境Collection规模较小这项修复的直接影响较低。但仍应结合1.18.2和1.18.x的其他安全、稳定性修复评估是否升级。六、如何确认自己是否使用Shard Key检查Collection创建和更新脚本SDK写入参数Shard Key管理API多租户路由代码集群运维文档Metrics和Telemetry。不要只看Payload中有没有tenant_id。Payload过滤 ≠ Shard Key路由只有显式使用Shard Key API或写入参数才属于本次问题范围。七、升级前建立专项测试测试一迁移前基线记录查询成功率 Recall结果数 P95延迟 Shard分布 租户数据量测试二Resharding期间持续查询运行写入 查询 删除 过滤 混合检索并覆盖全部Shard Key。测试三大租户与小租户避免只测试一个默认租户。测试四迁移后数量一致性检查每个Shard Key的Point总数 删除标记 Payload索引 检索结果测试五故障恢复在Resharding中模拟节点重启网络抖动副本切换请求超时写入积压。八、客户端不要无限重试如果Resharding期间查询报错客户端可能使用重试。必须设置最大重试次数 指数退避 总超时 幂等判断 熔断查询可以有限重试但不能while true否则集群处于迁移压力时会收到更多请求形成重试风暴。九、监控应该按Shard Key拆分整体成功率99.9%不代表所有租户都正常。如果一个小租户持续失败整体指标可能看不出来。建议记录query_success_rate_by_shard_key query_error_count_by_shard_key p95_latency_by_shard_key result_count_anomaly resharding_progress shard_transfer_status replica_state高基数标签可能增加监控成本可以只对重点租户和异常Shard Key展开。十、推荐升级流程1. 备份配置和Collection信息 2. 在预生产复现Shard Key场景 3. 升级一个非关键节点或测试集群 4. 启动Resharding专项压测 5. 验证查询结果和数量 6. 灰度升级生产节点 7. 观察错误率、延迟与迁移状态 8. 完成全部节点版本一致不要在大促 批量入库 模型重建 高峰流量期间同时执行版本升级和Resharding。十一、版本升级后的验证清单□ 所有节点版本一致 □ 集群状态正常 □ Collection绿色 □ Replica状态正确 □ Shard Key查询成功 □ Metadata过滤正确 □ 混合检索结果一致 □ Resharding能够完成 □ 迁移中无异常查询错误 □ Point数量无明显偏差 □ 延迟没有持续升高十二、为什么只有一项修复也值得关注基础设施版本价值不能只按功能数量判断。一个修复如果影响查询正确性 在线扩容 多租户隔离其业务价值可能比新增多个Demo功能更高。对于企业RAG向量库最重要的不是“支持多少新算法”而是查询不能错扩容不能中断数据不能跨租户失败能够恢复状态能够观测。总结Qdrant 1.18.3针对的是一个非常具体的生产问题Shard Key Resharding 查询使用这三个能力的集群建议完成预生产专项验证后升级。未使用Shard Key或Resharding的项目直接影响较低但仍应维护清晰的版本基线和升级节奏。