rs.addArbiter()后聚合查询报NotMasterNoSlaveOk，根本原因是PSA架构下secondary列表为空，驱动fallback至primary时恰逢选举震荡；应确保至少一个SECONDARY节点，或改用primaryPreferred读取偏好。
rs.addArbiter() 后聚合查询仍报 NotMasterNoSlaveOk 怎么办
不是聚合本身的问题，而是客户端读取偏好没绕过仲裁节点——secondary 或 secondaryPreferred 模式下，驱动会从健康且可读的 secondary 成员中选一个；但如果副本集只有 1 个数据节点 + 1 个仲裁节点（PSA 架构），secondary 列表为空，驱动 fallback 到 primary，而此时主节点若因选举震荡短暂不可用，就直接抛 NotMasterNoSlaveOk。
实操建议：
- 检查
rs.status()中members数组：确认除 arbiter 外至少有一个stateStr: "SECONDARY"，否则 PSA 架构下secondary读取偏好必然失败 - 避免在 PSA 架构中硬编码
readPreference=secondary；改用readPreference=primaryPreferred，它会在 secondary 不可用时自动退到 primary，不中断查询 - 如果必须用
secondary，确保副本集有 ≥2 个数据节点（即去掉 arbiter，或加第二个 secondary），否则该模式在 PSA 下无意义
聚合管道里 $lookup 跨分片失败，和仲裁节点有关吗
有关，但间接。仲裁节点本身不参与数据读写，但它会影响写关注（w: "majority"）的“多数”计算——例如 PSA 架构中，“多数”是 2（3 个节点中需 2 个确认），而仲裁节点无法确认写入，所以实际依赖的只有 primary + secondary。一旦 secondary 滞后或断连，w: "majority" 就卡住，导致事务或带写操作的聚合（如含 $out 或 $merge）超时失败。
关键点：
-
$lookup本身不触发写，但如果聚合含$merge到另一个集合，且目标集合在分片集群中，仲裁节点会导致分片写关注无法满足majority，进而阻塞操作 - 分片集群中，任何含跨分片读写的事务，都要求所有参与分片的副本集不依赖仲裁节点来凑“多数”；否则
commitTransaction会因等待未响应节点而失败 - 查证方式：执行
db.runCommand({getLastError: 1, w: "majority"})，看是否卡在waited状态；再比对rs.conf().members中votes总和与arbiterOnly: true节点数
使用 nearest 读取偏好跑聚合，为什么延迟忽高忽低
因为 nearest 会从所有健康成员（包括 arbiter）里按网络延迟选一个，但仲裁节点不提供数据服务——当驱动误把 arbiter 当作可读节点（比如心跳成功但未校验 canServeReads），就会发请求过去，结果收到 NotPrimaryNoSecondaryOk 后重试，造成延迟毛刺。
开箱即用的技能链路由引擎。13 条预定义链覆盖搜索、开发、审查、MLOps、法律、创意等场景，三层路由架构（触发词→SAD反馈→DAG编排），recall@10=96.97%。配置驱动（chains.yaml），零代码扩展。pip install skill-weave-chains 一键安装。
真实行为取决于驱动版本：
- MongoDB Node.js Driver ≥ 4.13 和 Java Driver ≥ 4.11 已修复该问题：
nearest自动过滤掉arbiterOnly: true成员 - 旧版驱动（如 Python PyMongo ?readPreferenceTags=region:us-east 并给非 arbiter 节点打标签，或升级驱动
- 验证方法：开启 mongod 日志级别为 1（
mongod --logLevel 1），搜read preference和eligible关键字，看候选列表是否含 arbiter-host
聚合结果不一致，是不是仲裁节点同步滞后导致的
不是。仲裁节点根本不存数据，也不参与 oplog 复制，所以它的存在不会导致数据滞后。真正影响聚合结果一致性的，是所选节点的数据新鲜度——比如用 secondary 读取时，secondary 本身可能落后 primary 几百毫秒，而聚合管道中的多阶段计算（尤其含 $facet 或多次 $lookup）会放大这种不一致。
要控制一致性，得靠读关注（readConcern），不是仲裁节点：
-
readConcern: "local"：返回节点本地最新数据，不管是否已复制到 majority——这是默认值，也是结果最“飘”的 -
readConcern: "majority"：确保返回的数据已被大多数节点确认，但要求副本集所有数据节点（不含 arbiter）都支持该特性（FCV ≥ 4.0），且不能是 PSA 架构下仅剩 1 个 secondary 的场景 - 聚合命令本身不改变读关注行为；必须显式传参，例如：
db.collection.aggregate(pipeline, { readConcern: { level: "majority" } })
仲裁节点唯一能干扰的一致性场景，是它让副本集“多数”变虚——比如 3 节点 PSA 中，w: "majority" 实际只等 2 个响应，但其中 1 个是 arbiter（它不写数据），等于只等 1 个 real secondary 确认，这会让 readConcern: "majority" 的语义失效。
