必须停机后配置认证，否则导致握手失败、复制中断或数据回滚；操作前需确认节点状态正常、主节点无写入、dbpath 无残留锁文件；keyFile 需统一生成分发、权限设为600且属主正确；security 中须同时启用 keyFile、authorization 和显式 clusterAuthMode: keyFile；管理员用户须在单节点 localhost 连接下创建，完成后逐个启动节点。
必须先停掉整个副本集再加认证，不能边运行边改配置；否则节点间握手失败、复制中断、甚至数据回滚。
停机前必须确认的三件事
加权限验证不是改个配置重启就行，它会切断所有节点间的信任链。操作前务必确认：
-
rs.status()显示所有成员状态为"stateStr" : "PRIMARY"或"SECONDARY"，没有"RECOVERING"或"STARTUP2" - 主节点上执行
db.fsyncLock()（4.2 仍支持），确保无写入进行中；完成后立即db.fsyncUnlock() - 所有节点的
dbpath目录下没有残留的mongod.lock文件；若有，说明上次非正常退出，需先运行mongod --repair --dbpath /path/to/db
生成并分发 keyFile 的关键细节
keyFile 是副本集内部通信的“暗号”，内容一致但权限和路径极易出错：
- 用
openssl rand -base64 756 > /etc/mongodb-keyfile生成（长度必须在 6–1024 字节之间；756 是安全且兼容的常用值） - 文件权限必须是
400或600，且属主为运行mongod的用户（如mongod用户）；chmod 600 /etc/mongodb-keyfile && chown mongod:mongod /etc/mongodb-keyfile - 每个节点的
mongod启动时都必须挂载**同一份文件内容**（推荐用scp复制，不要重新生成）；Docker 场景下注意挂载路径在容器内是否可读（如-v /host/keyfile:/opt/keyfile:ro）
配置文件里 authorization 和 keyFile 的启用顺序
很多人以为只要打开 security.authorization: enabled 就行了，其实内部通信认证（keyFile）和客户端访问认证（authorization）是两层事，必须同时启用且协同生效：
- 在
mongod.conf中取消注释并严格按如下结构写：security: keyFile: /etc/mongodb-keyfile authorization: enabled clusterAuthMode: keyFile
-
clusterAuthMode: keyFile必须显式指定（4.2 默认是auth，不兼容副本集内部校验）；漏掉这行会导致节点能连上但拒绝同步，日志报"No keys found for replica set" - 所有节点配置完全一致（包括
replSetName、bindIp、port），否则rs.add()会因连接超时或认证失败静默失败
创建管理员用户必须在启用 auth 后、首次连接时完成
认证开启后，任何连接默认无权限；必须用 localhost 接口（绕过 auth 检查）连上主节点才能建用户：
- 停掉所有节点 → 修改配置 → 逐个启动（只启一个，其他先别动）→ 用
mongo --port 27017 --host 127.0.0.1连本地 - 在
admin库执行：use admin db.createUser({ user: "root", pwd: "your_strong_password", roles: ["root"] }) - 切勿用
userAdminAnyDatabase：它在 4.2 中已不推荐，"root"角色覆盖全部管理能力且更明确 - 建完再启第二个节点；如果启太快，新节点会尝试同步但没权限，卡在
"STARTUP2"状态，需手动rs.remove()清理后重试
最常被忽略的是 clusterAuthMode 配置项和 fsyncLock 的使用时机——前者缺了就同步断，后者没做就可能丢正在写的 oplog 记录。
