local数据库损坏会导致mongod无法启动，需用--repair --nojournal（禁用journal）单节点修复；修复后必须重启为普通模式，并手动重建oplog.rs（仅限测试环境），生产环境应从备份恢复或重新初始化副本集。
local数据库损坏后直接启动mongod会失败
local数据库存储副本集元数据、oplog等关键运行时信息，一旦损坏（比如磁盘异常、强制断电），mongod通常无法正常启动，报错类似：Failed to load collection metadata from local.system.replset 或 Unable to read metadata for collection local.oplog.rs。这不是数据丢失警告，而是服务根本起不来——必须先绕过常规加载流程。
用--repair模式单节点启动，但必须禁用journal和fork
repair不是在线操作，不能在已有进程运行时执行，也不能和journal共存（journal会干扰底层文件校验）。常见错误是漏掉--nojournal或误加--fork导致启动静默失败。
- 确保mongod完全停止，且无残留
mongod.lock文件（如有，确认无其他实例在用再手动删除） - 使用绝对路径指定数据目录：
mongod --dbpath /var/lib/mongodb --repair --nojournal --port 27018 - 不要加
--replSet或--auth——repair阶段不加载配置，加了反而报错 - repair完成后，必须重启为普通模式（去掉
--repair和--nojournal），否则无法接受客户端连接
repair后local库可能仍缺oplog.rs，需手动重建
repair能恢复目录结构和基础元数据，但local.oplog.rs集合常为空或损坏，导致后续无法初始化副本集。这不是repair失败，而是设计使然：oplog是追加写日志，repair不重建其内容。
- 启动修复后的实例（普通模式），连上
mongo --port 27018 - 切换到local库：
use local - 检查oplog是否存在且有数据：
db.oplog.rs.countDocuments({})—— 若返回0，说明空 - 重建最小oplog（仅适用于单节点测试环境）：
db.createCollection("oplog.rs", {"capped": true, "size": 1073741824}) - **切勿**在生产环境盲目重建oplog；真实场景应从备份恢复或重新初始化副本集
Windows下repair容易因路径空格或权限卡住
Windows服务默认以LocalSystem运行，但repair需要对数据目录的完全读写权限，且路径含空格（如C:\Program Files\MongoDB\Server\6.0\data）会导致--dbpath解析失败。
- 把数据目录移到无空格路径，例如
C:\mongodb\data - 以管理员身份打开命令提示符，cd到mongod.exe所在目录再执行repair命令
- 避免用Windows服务方式启动repair；直接运行
mongod.exe二进制更可控 - repair日志默认输出到控制台，别关窗口——进度条停住不等于卡死，大库可能耗时几十分钟
