摘要

  • Atlas Core 使用独立搜索节点时，暂停会清空这些节点的数据；恢复后重建索引，期间 $search 和 $vectorSearch 不可用。
  • 搜索节点恢复时，暂停前的搜索监控指标不会跟着回来。省钱方案需要一份由买方保留的前后对照。
  • 暂停期间只收存储费，搜索节点运行则按小时计费。采购应把恢复可用的过程纳入账本，而不是只数关掉了多少小时。

暂停键里藏着一张施工单

暂停，听起来像给电影按了一个键。回来后人物还在原来的位置，台词接着往下说。MongoDB Atlas 的搜索能力采用另一种剧本：部分舞台先拆掉，开演前再搭回来。数据仍有存放处，帮用户找到数据的装置却需要重新施工。

这张施工单写在 MongoDB 自己的暂停说明里。对部署独立 Search Nodes 的 Atlas Core 集群，暂停会删除搜索节点上的数据；恢复集群后，平台创建新的搜索节点并重建搜索索引。重建期间，$search 与 $vectorSearch 这两条查询路径不可用。本文讨论的就是这类部署，Atlas Infinite 公开预览阶段尚不支持这些搜索节点。

这是一种很具体的产品选择：暂停时放弃已经准备好的搜索状态，换取较低的停用期开支；恢复时由平台自动重新构造它。买方不用亲手搭节点，却仍要安排什么时候把用户请回来。自动施工队有价值，开门时间也有价格。

想象一个准备演示商品目录的团队：数据库能接收连接，页面能打开，搜索框背后的索引仍在重建。这是由产品机制推演出的采购场景。负责人若只验收“集群恢复了”，演示就可能在最需要搜到商品时卡住。演示是否成功，取决于搜索路径完成工作；控制台上的资源状态只交付其中一部分。

节省发生在休息时，验收发生在回来后

MongoDB 的集群费用说明给出明确的好处：暂停的集群只收存储费，默认存储也在收费范围内。对于间歇使用的测试环境，停掉计算确实提供了节约空间。文件不会因为开发团队去吃饭就自带免费仓库，但处理器可以暂时离岗。

报价容易从这里开始，也容易在这里过早结束。一个团队把夜间关闭时间填进表格，便得到了漂亮的可节省小时数。第二天谁提前启动、谁确认索引就绪、谁验证关键查询、谁承担演示推迟，却常常分别躺在别人的日程里。财务表里的一个动作，落到组织里变成几个人的接力。

搜索节点价格规则按节点数量、配置档位和节点间数据传输计算成本；运行不足一小时也按整小时收费。买方因此需要同时检查实际账单与搜索恢复时间。本文没有把某个索引就绪时刻当成计费起点；价格规则按资源计算，用户要的是一次有用的搜索，两者应当放在同一张验收表里。

使用间隔越长，重新准备一次的工作越容易被摊薄；频繁开关则会反复触碰这段回程。这个关系无需凭空编造一个节约百分比。采购可以先问一个扎实的问题：为了少付一晚上的运行费，团队明天需要提前回来多少工作？

最需要对照时，旧搜索曲线走了

还有一笔容易漏记的成本。搜索指标文档说明，暂停再恢复后，平台只提供新搜索节点的指标，暂停前的搜索指标不会保留。平台重建了提供搜索的机器，也重开了这组观察窗口。

这让一次“我们省了多少”的复盘多了一道工序。团队若想比较暂停前后同一批查询的延迟、返回结果和可用时间，就该提前把需要的应用测量留在自己掌握的记录里。否则，新曲线看起来十分干净，旧基准却已经退场。干净的图表可以是新起点，也可以是一次比较被截成两半。

这里最有用的对照并不复杂：同样的目录、同样的检索条件、同样的预期结果，再加上启动指令发出与查询真正通过的时间。数据量、索引定义或测试条件变了，就把变化写下来。复盘才不会把“今天样本不同”误记成“暂停方案改善了表现”。

别把所有重建都装进同一个词

MongoDB 的索引管理说明还描述了另一条路径：修改索引定义时，新索引在后台建立，旧索引继续响应查询；调整搜索部署拓扑时，新节点先准备好，再移走旧节点。旧能力还在岗，替班者有时间练习。

暂停后的重建少了这位留守者。买方需要把“改索引”“换拓扑”“暂停后恢复”分开验收。把三个动作都叫维护，省下了几个字，抹掉的却是服务在转换期间靠什么继续工作的差别。产品功能清单很擅长把不同动作排成整齐的小勾，用户只关心点击之后搜索框还能不能工作。

MongoDB 为这种区分提供了可用的检查面。getSearchIndexes()会返回索引状态和 queryable 字段，后者表示索引能否接受查询。团队可以先确认技术就绪，再运行自己真正要交付的查询。一个能被调用的索引完成了基础准备；商品能否被找到、检索是否及时，仍要用产品的例子来检验。

现有材料缺少把客户真实重建耗时、查询表现与账单连在一起的测量；若回程持续短而稳定，频繁暂停的经济性就会增强。眼下最明确的判断已经足够：暂停是一份带返工的节约合同。MongoDB 包办重建，买方应当买清楚重新开门的过程。