新增节点必须复用原有keyFile，不能生成新文件；mongos不需keyFile且禁用security配置；新增shard/config server须手动创建本地admin用户；clusterAuthMode必须显式设为keyFile。
新增节点必须复用原有 keyFile，不能生成新文件
集群扩容时最常踩的坑，就是给新节点单独生成一份 keyFile。MongoDB 内部认证要求所有 mongod 节点（包括 config server 和 shard）使用完全相同的二进制密钥文件，哪怕只差一个字节，节点启动后也会拒绝加入集群，并在日志里报 Unable to authenticate using sasl protocol 或静默失败。
正确做法是：从任意一个已有节点上直接复制原 keyFile 到新节点相同路径下，然后严格设置权限：
chmod 600 /etc/mongod-keyfile-
chown mongod:mongod /etc/mongod-keyfile（确保属主与 mongod 进程运行用户一致） - 确认文件大小在 6–1024 字节之间（可用
stat -c "%s" /etc/mongod-keyfile检查）
mongos 节点不参与内部认证，但配置里不能写 security.keyFile
新增的是路由节点（mongos）？它不存储数据、不参与副本集同步，因此不需要 keyFile，也不支持 security: 配置块。如果在 mongos.conf 里误加了 security.keyFile，进程根本无法启动，日志只显示 Failed to load configuration from file，实际是配置语法校验失败。
mongos 的认证相关配置仅限于客户端连接层面：
- 确保
sharding:和net:配置正确，不含security:块 - 客户端连接
mongos时，仍需显式指定authMechanism=SCRAM-SHA-256和--authenticationDatabase admin -
mongos自身不存用户，所有认证请求都转发给后端 shard 或 config server 处理
新增 shard 或 config server 后，必须手动创建本地管理员用户
哪怕你已在 mongos 上用 db.createUser 创建了集群级用户，新增的 shard 或 config server 实例默认没有该用户凭证。如果不提前创建，后续执行 sh.addShard() 或分片操作时会卡住，报 not authorized on admin to execute command —— 这不是网络不通，而是目标节点压根不认识这个用户。
必须逐个登录新节点（用 localhost 绕过认证），在 admin 库中创建 root 级用户：
use admin
db.createUser({
user: "admin",
pwd: "xxx",
roles: ["root"]
})
注意：这一步不能省略，也不能指望通过 mongos 同步过去。
clusterAuthMode 必须显式设为 keyFile，不能依赖默认值
虽然 MongoDB 5.0+ 在配置了 keyFile 后会自动启用内部认证，但 clusterAuthMode 的默认值仍是 “sendKeyFile”（仅发送密钥，不验证对方身份）。这会导致节点间通信看似正常，实则未真正校验对方合法性，存在中间人风险。
务必在每个 mongod 节点的配置中显式声明：
security: keyFile: /etc/mongod-keyfile clusterAuthMode: keyFile
漏掉 clusterAuthMode: keyFile 这一行，就等于只系了半条安全带。
真正麻烦的从来不是生成密钥或重启服务，而是节点间认证状态不一致：有的节点认 keyFile，有的还在用 sendKeyFile 模式，有的甚至没建本地用户。扩容前最好先用 rs.status() 或 sh.status() 确认所有现存节点的 authSchema 和 clusterAuthMode 输出是否统一。
