必须在每个副本集节点的 admin 数据库中单独创建用户，否则 Secondary 无法认证；连接时需显式指定 --authenticationDatabase admin 或连接字符串中添加 ?authSource=admin，且仅支持 SCRAM-SHA-256 认证机制。
必须在每个副本集节点的 admin 数据库中单独创建用户，不能只在 Primary 上建完就认为生效；否则 Secondary 节点无法完成认证协商，连接会卡在“能连上但查不了数据”。
为什么 mongosh 连副本集总提示 not authorized on admin？
这不是权限配错，而是没指定认证数据库。副本集里每个节点都独立校验用户凭证，mongosh 默认不自动切换到 admin，所以即使用户名密码对，也会因认证上下文错误被拒。
- 连接时必须显式加
--authenticationDatabase admin参数 - 如果用连接字符串，得带
?authSource=admin（不是authMechanism） - 错误示例：
mongosh mongodb://user:pass@rs1:27017/test→ 缺少authSource，默认去test库找用户 - 正确写法：
mongosh mongodb://user:pass@rs1:27017/test?authSource=admin
SCRAM-SHA-256 是唯一可用机制，旧配置会直接失效
MongoDB 7.0 已彻底移除 SCRAM-SHA-1 和 MONGODB-CR。如果你从老版本升级，哪怕配置文件里还留着 authenticationMechanisms=SCRAM-SHA-1，启动时会报错或静默降级失败。
- 确认机制是否启用：连接后执行
db.runCommand({getCmdLineOpts: 1})，检查parsed.security.authenticationMechanisms字段 - 若为空或不含
SCRAM-SHA-256，说明配置未生效，需检查配置文件中是否漏了security.authorization: true或拼写错误 - 重置旧用户密码必须用
db.changeUserPassword()，不能只改pwd字段，否则仍走旧哈希路径
副本集节点间通信和客户端连接要用不同认证逻辑
内部节点通信靠 keyFile 或 x.509，而客户端连接走 SCRAM。这两层不共用凭证，但容易混淆——比如开了 keyFile 后忘了给客户端连接串加 authMechanism=SCRAM-SHA-256，结果连得上却查不出数据。
- 客户端连接字符串必须含
?authMechanism=SCRAM-SHA-256，尤其使用驱动（如 Node.js 的mongodb包）时，缺这个参数会 fallback 到不支持的机制 -
keyFile只影响副本集成员间通信，不影响应用连接；它启用后，mongosh连接时无需额外参数，但认证仍要走 SCRAM - Robo 3T 等 GUI 工具需在连接设置里手动勾选 “Perform authentication”，并填对
Authentication Database（即authSource）
最常被忽略的一点：副本集里每个节点的 admin 数据库都要有同名用户，且角色一致；Secondary 不同步 admin 用户表，它只同步业务库数据。你登录 Primary 创建完用户，必须再分别连 Secondary 手动创建——哪怕只是复制粘贴同一段 db.createUser()。
