keyFile认证必须在所有节点启动前配置完成，且所有节点共用同一份严格权限（600）的6–1024字节随机二进制密钥文件；mongos无需keyFile，客户端连接须显式指定authMechanism=SCRAM-SHA-256并使用--authenticationDatabase admin。
keyFile认证必须在所有节点启动前配置好
MongoDB副本集或分片集群的内部认证不是运行时开关，而是启动即生效的硬性要求。一旦节点以非认证模式启动过，再想加 keyFile 就会直接拒绝连接——它不会“升级”已有实例，只会报 Authentication failed 或更隐蔽的 Unable to authenticate using sasl protocol。
- 所有节点（包括 config server、shard、mongos）必须共用同一份
keyFile文件，且权限严格设为600（chmod 600 /etc/mongod-keyfile），否则 mongod 启动失败并提示Permissions on /path/to/keyfile are too open -
keyFile内容必须是 6–1024 字节的随机二进制数据（推荐用openssl rand -base64 756 > /etc/mongod-keyfile），不能是明文密码、不能含换行、不能用echo "abc" > file这类方式生成 - 配置项必须写在
mongod.conf的security:下级，不是systemLog:或其他位置：security:<br> keyFile: /etc/mongod-keyfile
启用keyFile后，客户端连接必须显式指定认证机制
内部认证开启后，节点间通信默认走 SCRAM-SHA-256，但你自己的应用连接时，如果没配对，会卡在“能连上但查不了数据”。这不是网络问题，是认证协商失败。
- 连接字符串里必须带
authMechanism=SCRAM-SHA-256，例如：mongodb://user:pass@host:27017/db?authMechanism=SCRAM-SHA-256 - 如果用
mongoshell 连副本集，得加--authenticationDatabase admin，否则即使用户名密码对，也会提示not authorized on admin to execute command - mongos 节点本身不存用户凭证，它只转发请求，所以每个 shard 和 config server 都得单独创建管理员用户（
db.createUser({user:"admin", pwd:"...", roles:["root"]})），不能只在某个节点上建
分片集群中，config server 和 shard 必须用同一套 keyFile，但 mongos 不需要
mongos 是无状态路由进程，不参与数据存储，也不做节点间数据同步，所以它不需要 keyFile。但很多人误给 mongos 加了 security.keyFile，结果 mongos 启动失败，日志里只写 Failed to load configuration from file，实际是语法校验不过（mongos 的配置不支持 keyFile）。
- 确认 mongos 配置中没有
security:块，只有sharding:和net: - config server 和所有 shard 的
keyFile路径可以不同，但文件内容必须完全一致；建议统一路径（如都用/etc/mongod-keyfile），避免部署脚本漏复制 - 如果某 shard 没配
keyFile，而其他节点配了，整个集群会无法完成初始化，rs.status()里那个节点的状态永远是STARTUP2，且日志反复刷Failed to receive hello response
升级集群时，keyFile 不能热替换，必须滚动重启
没有“先加 keyFile 配置、再 reload”的操作路径。mongod 不支持重载安全配置，任何修改都需完整重启。滚动重启顺序错了，集群可能分裂或不可写。
- 优先重启 secondary 节点，最后重启 primary；等每个节点
rs.status().members[n].stateStr === "SECONDARY"稳定后再动下一个 - config server 必须三个全启且
rs.status()显示 majority 成员在线，才能继续重启 shard；否则sh.addShard()会卡住或返回NotMaster - 重启期间，应用可能收到
InterruptedAtShutdown或NotWritablePrimary错误，这是正常现象，不是配置失败——只要集群最终恢复PRIMARY状态且sh.status()显示 all shards online，就说明成功了
644，或 mongos 多写了一行 keyFile，整个集群就会停在“半认证”状态，表现就是部分节点互相 ping 不通、选举失败、sh.status() 卡住。这些都不是 MongoDB 的 bug，是安全模型的刚性约束。 
