keyFile是MongoDB分片集群硬性前置条件，必须在所有节点启动前一次性配齐：生成756字节密钥、严格设置600权限与mongod用户属主、YAML中正确缩进配置security.keyFile路径，且config server与shard节点文件内容须字节级一致；mongos严禁配置security块。
keyFile必须在所有节点启动前一次性配齐
分片集群里加keyFile不是“开了开关就能用”的功能，而是硬性前置条件。一旦某个mongod实例以非认证模式启动过（哪怕只启动一次），再往配置里加security.keyFile就会直接失败，报错类似Unable to authenticate using sasl protocol或静默拒绝连接。这不是配置没生效，是MongoDB拒绝“降级信任”——它认定这个节点已经暴露过，不再接受后续加固。
所以真实操作节奏只能是：生成keyFile → 拷贝到所有节点 → 修改全部配置 → 一次性全量启动。中间不能有任一节点先跑起来。
- 所有
config server、shard节点必须共用同一份文件内容（不是同名，是字节级一致） -
mongos节点严禁配置security:块，否则启动失败，日志只显示Failed to load configuration from file，实际是配置语法校验不通过 - 别信“先启config再启shard”的分步启动法——只要有一个节点没配keyFile就启了，整个集群就得重搭
生成和分发keyFile的三个致命细节
很多人卡在权限、长度、路径三处，错误往往不报明确提示，只让节点起不来或连不上。
- 用
openssl rand -base64 756 > /etc/mongod-keyfile生成，少于756字节会触发keyFile must be 6–1024 bytes错误；多于1024也不行，但Base64编码后长度可控 -
chmod 600 /etc/mongod-keyfile必须执行，且运行mongod的用户（通常是mongod）必须是该文件所有者，否则报Permissions on /path/to/keyfile are too open - 不要把keyFile放在
/tmp或NFS挂载点——前者权限难控，后者可能因网络抖动导致读取失败，节点反复重启
配置文件里写错位置等于没写
keyFile路径必须落在security:下级，且缩进严格。YAML对空格敏感，下面这种写法会静默失效：
systemLog: destination: file security: keyFile: /etc/mongod-keyfile # ❌ 缺少缩进，YAML解析失败
正确写法是：
security: keyFile: /etc/mongod-keyfile # ✅ 两个空格缩进
- 确认
mongos.conf里**完全没有**security:字段，只保留sharding:和net: -
config server和shard的配置结构一致，但configsvr: true和shardsvr: true要各自加在replication:块里，别混进security: - 路径可以不同（比如
/data/conf/keyfilevs/etc/mongod-keyfile），但文件内容必须完全一样
验证节点间通信是否真通了
别只看rs.status()或sh.status()返回正常——那只是逻辑状态。真正要确认的是底层SASL握手成功。
- 在任意
shard节点上执行：db.runCommand({connectionStatus: 1})，检查输出中incompleteCREDENTIALS是否为false - 查日志关键词：
Successfully authenticated出现在各节点mongod.log里，且时间接近；如果只有单边日志，说明双向认证没通 - 用
mongosh连mongos时必须带?authMechanism=SCRAM-SHA-256，否则即使能连上，执行db.stats()也会返回not authorized
最常被忽略的一点：mongos本身不存用户数据，所有账号必须在admin库通过mongos创建，且每个config server和shard都要能访问到这套凭证——这靠的是config server里的system.users集合自动同步，不是靠keyFile。
