KeyFile是MongoDB分片集群中实现节点间内部身份验证的机制，确保mongos、shard和config server相互认证身份；它仅解决“你是谁”，不提供加密通信，需配合--auth和--clusterAuthMode keyFile使用，且文件须6–1024字节随机内容、权限600、各节点路径一致并完全相同。
KeyFile在MongoDB分片集群中起什么作用
KeyFile是MongoDB启用内部身份验证（internal authentication）的最简方式，它让mongos、shard节点、config server之间能相互认证身份，防止未授权节点加入集群。它不提供加密通信（那是TLS的事），只解决“你是谁”这个问题。如果跳过这步，即使配置了–keyFile启动参数，节点间握手会失败，rs.status() 或 sh.status() 会显示 UNREACHABLE 或反复重连。
生成符合要求的KeyFile文件
MongoDB对KeyFile有硬性要求：必须是6–1024字节的随机内容、权限严格限制为600（仅属主可读写）、不能是空文件或纯文本密码。用/dev/urandom生成最稳妥：
openssl rand -base64 756 > /data/mongodb/keyfile chmod 600 /data/mongodb/keyfile
注意：756 是为了确保base64编码后长度落在6–1024字节范围内（base64会膨胀约33%，756字节原文编码后约1008字节）。别用echo "mypass" > keyfile——这种明文密钥会被日志、ps命令暴露，且长度不合规，mongod直接拒绝启动并报错：key file does not have permissions restricted 或 key file is empty。
如何同步KeyFile到所有节点（含mongos/config/shard）
KeyFile内容必须**完全一致**，且每个节点都得放在**相同路径**下（否则启动时找不到）。同步不是“复制一次就完事”，而是要覆盖所有角色节点：
- Config server 的所有节点（通常3个）
- 每个Shard副本集的所有成员（包括primary/secondary/arbiters）
- 所有mongos进程所在机器（mongos不存数据，但需用KeyFile向config server认证）
推荐用scp逐台推送，并校验MD5：
scp /data/mongodb/keyfile user@shard1-node1:/data/mongodb/ ssh user@shard1-node1 "md5sum /data/mongodb/keyfile"
千万别用共享存储（如NFS）挂载同一份KeyFile——MongoDB明确禁止多个进程同时打开同一KeyFile，会触发unable to lock key file错误。
启动时如何正确引用KeyFile并启用认证
KeyFile必须配合--auth和--clusterAuthMode keyFile使用，三者缺一不可。单独加--keyFile不启用认证，单独加--auth没KeyFile则集群无法初始化。
典型启动命令示例（shard节点）：
mongod --shardsvr --replSet shard1 --dbpath /data/shard1 --port 27018 \ --keyFile /data/mongodb/keyfile --auth --clusterAuthMode keyFile
常见疏漏点：
- mongos必须加
--keyFile，但不用--shardsvr或--configsvr - config server必须用
--configsvr+--replSet+--keyFile - 所有节点的
--replSet名称必须与初始化时一致，否则认证通过但复制集无法识别成员 - 第一次启动前，确保各节点已用
rs.initiate()或sh.addShard()完成逻辑注册，否则即使KeyFile有效，sh.status()仍为空
KeyFile本身没有生命周期管理机制，一旦泄露，必须轮换全部节点的文件并重启整个集群——这点常被低估。生产环境建议后续迁移到x.509证书认证，KeyFile更适合快速验证或测试集群。
