能设，但仅对非事务、非跨分片的普通读有效；涉及sharded命令、explain、聚合含$lookup等隐式跨分片操作时，MongoDB自动降级为primary或报错。
分片集群里 readPreference 能不能设成 secondary？
能设，但只对非事务、非跨分片的普通读有效；一旦涉及 sharded 命令、explain、count（v6.0+ 已弃用）或聚合管道含 $lookup 等隐式跨分片操作，MongoDB 会自动降级为 primary，甚至直接报错。
- 显式设置
readPreference: 'secondary'在 mongosh 或驱动中是合法的，比如：db.collection.find().readPref('secondary') - 但若该查询实际需访问多个分片（例如无 shard key 的
find、带$facet的聚合），mongos 会忽略该设置，强制路由到各分片的 primary —— 这不是 bug，是分片一致性保障机制 -
nearest在分片集群中仍可用，但它选的是“离 mongos 最近的分片成员”，不是全局最近；且不保证跨分片结果顺序一致
db.runCommand() 在分片集群中怎么指定读偏好？
必须用 options.readPreference 显式传，全局 setReadPref() 或连接字符串里的 readPreference 对它完全无效。
- 正确写法：
db.runCommand({ count: "users" }, { readPreference: { mode: "secondary" } }) - 错误写法：
db.getMongo().setReadPref('secondary'); db.runCommand({ count: "users" })—— 这会走primary，因为runCommand从不读全局配置 - 注意：某些命令（如
listDatabases、getCmdLineOpts）只允许在admin库执行，且强制primary，传了readPreference也会被无视
maxStalenessSeconds 在分片集群里生效吗？
生效，但仅限于 mongos 路由到单一分片时；跨分片查询下该参数会被忽略，因为无法统一衡量所有分片 secondary 的滞后程度。
- 值必须 ≥ 90 秒，否则驱动抛
InvalidOptionsError - 启用条件：分片集群的每个 shard 必须是副本集（非单节点），且 mongos 启用了对冲读支持（默认开启）
- 常见误用：
readPreference: { mode: "secondary", maxStalenessSeconds: 30 }—— 直接报错，30 小于最小阈值 - 真实场景建议：设为 120 或 180，配合监控
replSetGetStatus中各 secondary 的optimeDate差值来校准
标签集（tag sets）在分片集群中怎么用才不踩坑？
标签必须打在 **shard 的副本集成员** 上，而不是 mongos 或 config server；且标签匹配失败时，默认行为是报错，不是 fallback。
- 正确配置路径：先在每个 shard 的 replica set 成员上设置
members[n].tags，再在客户端传{ mode: "secondary", tags: [ { "region": "us-east" } ] } - 务必在 tag list 末尾加空对象：
[ { "region": "us-east" }, {} ]，否则没匹配到就直接失败，而不是退回到任意 secondary - mongos 不继承 shard 的标签逻辑 —— 它只把带 tag 的 readPreference 透传给对应 shard，不参与匹配决策
- 验证方式：用
sh.status()查看各 shard 成员的 tags 字段，再用db.collection.find().readPref(...).explain("executionStats")看实际路由节点
真正容易被忽略的是：分片集群的读偏好最终生效点不在 mongos，而在每个 shard 内部的 replica set。你设的 secondary 只管“去哪个 shard 读”，而那个 shard 自己再按它的 readPreference 规则选 member。两层控制，缺一不可。
