mongod --repair 对鉴权元数据无效，因其仅修复存储引擎层物理文件，不解析 BSON 结构、不校验 system.users schema 或重建索引；需停机后以 --noauth 启动，手动重建集合与索引，并恢复用户数据。
standalone 模式下无法直接修复鉴权元数据（如 admin.system.users 或 admin.system.roles 损坏），因为 mongod --repair 不加载认证系统、不校验用户/角色集合结构，也不会重建其索引。真正有效的做法是：停机 + 临时禁用鉴权启动 + 手动修复集合 + 重建索引。
为什么 mongod --repair 对鉴权元数据无效
mongod --repair 只作用于存储引擎层（WiredTiger）的数据文件校验与页修复，它不解析 BSON 结构，也不理解 system.users 的 schema 约束或角色继承关系。即使 admin.system.users 集合的 .wt 文件物理损坏被跳过，集合本身仍可能处于“存在但不可读”状态——db.getSiblingDB("admin").system.users.find().toArray() 报错或返回空，db.auth() 持续失败。
常见现象包括：
- 启动时卡在
Failed to load user credentials from admin.system.users - 连接后执行
use admin; db.system.users.countDocuments({})返回 0，但db.getCollectionInfos({name: "system.users"})显示集合存在 - 尝试
db.createUser()报NamespaceNotFound或NotMaster（因鉴权系统未就绪）
手动修复流程：停机 → 无鉴权启动 → 检查并重建集合
必须确保 mongod 完全停止，且无残留 mongod.lock；Windows 下还需确认没被 Windows 服务后台静默占用。
- 用
mongod --dbpath /var/lib/mongodb --noauth --port 27018启动（绝对不要加--repair） - 连上
mongo --port 27018，切换到admin库：use admin - 检查集合状态：
db.system.users.stats()—— 若count为 0 但size> 0，说明数据损坏；若报NamespaceNotFound，说明集合元数据丢失 - 若集合缺失，重建：
db.createCollection("system.users", {capped: false})；再建system.roles（同理） - 重建必需索引：
db.system.users.createIndex({user: 1, db: 1}, {unique: true})；db.system.roles.createIndex({role: 1, db: 1}, {unique: true}) - 重新插入原始用户（需提前备份过
mongodump --db admin --collection system.users）：db.system.users.insertOne({...})
修复后重启必须带 --auth，且不能遗漏 keyFile（如启用）
修复只是恢复了集合和索引，不代表鉴权功能自动生效。重启时若漏掉 --auth，所有用户都可无密访问；若启用了副本集或 keyfile 认证，还必须指定 --keyFile 路径，否则启动报 Key file does not exist 或拒绝加载用户。
- 正确重启命令：
mongod --dbpath /var/lib/mongodb --auth --keyFile /etc/mongod-keyfile --port 27017 - 验证是否生效：
mongo -u root -p --authenticationDatabase admin；成功后运行db.runCommand({connectionStatus: 1}).authInfo查看 authenticatedUsers - Windows 下若用服务方式启动，确保服务配置里已写入
--auth参数（注册表或sc create命令中），而非仅靠配置文件
最易被忽略的一点：修复后的 system.users 集合虽然能查，但若原始备份里用户文档含 pwd 字段（旧 SHA-1 格式），而 MongoDB 4.0 默认要求 SCRAM-SHA-256，db.auth() 仍会失败——此时必须用 db.updateUser() 强制重置密码，触发哈希升级。
