mongod.lock 是意外关机的事故报告单，非空时触发自我保护机制拒绝启动；直接删除无法解决底层数据不一致问题，需用 mongod --repair 修复并确保权限、路径及副本集配置正确。
mongod.lock 文件不是“锁住数据库”的开关，而是意外关机的事故报告单。它本身不阻止启动，但它的存在（且非空）会触发 MongoDB 的自我保护机制——拒绝启动，除非你明确执行修复或确认安全。
为什么删了 mongod.lock 还是起不来？
常见错误现象：删完 mongod.lock 后直接 mongod --dbpath /var/lib/mongodb，报错 WiredTiger error、corrupted data 或卡在初始化阶段；副本集成员状态长期为 STARTUP2 或 RECOVERING，无法进入 SECONDARY。
- 根本原因不是 lock 文件本身，而是它背后未完成的写操作：journal 日志没刷完、WiredTiger 元数据不一致、或 oplog 截断点丢失
- 单纯删除
mongod.lock只是绕过“是否允许启动”的检查，但底层数据已处于不一致状态，副本集同步逻辑会拒绝加载损坏的集合文件 - 尤其在无 journaling 且非 replica set 模式下异常终止时，
mongod.lock非空 = 数据极大概率已损坏，必须修复
mongod --repair 必须配合 --dbpath 和权限校验
修复不是“一键回滚”，它本质是遍历所有 collection 文件，重建索引、清理 orphaned records、重写 WiredTiger 表结构。失败常因路径或权限错位。
- 必须显式指定
--dbpath，不能依赖配置文件里的storage.dbPath——mongod --repair不读配置文件中的存储路径 - 运行命令的用户需对
--dbpath目录有完整读写权限，且属主应为mongodb:mongodb（Ubuntu/Debian）或mongod:mongod（RHEL/CentOS） - 若原目录有 journal 子目录（
journal/），修复过程会尝试重放日志；若 journal 已损坏，修复可能失败，此时需加--repairpath指向干净临时目录 - 示例正确用法：
sudo mongod --dbpath /var/lib/mongodb --repair --repairpath /tmp/mongo-repair-20260410
副本集场景下，修复后仍不进入 SECONDARY 的关键检查点
修复成功 ≠ 副本集自动恢复。MongoDB 不会帮你重同步 oplog 或重拉全量数据，它只保证本地数据可读。后续同步由复制协议驱动，而该协议对初始状态极其敏感。
- 修复后的节点启动时，必须使用与原副本集完全一致的
replSet名称（通过--replSet或配置文件replication.replSetName） - 检查
local.oplog.rs是否存在且非空：若修复清空了 oplog（尤其用了--repairpath），该节点将无法从其他成员拉取增量变更，只能强制 resync - 若 oplog 太小或缺失，需手动执行
rs.syncFrom("primary-host:27017")或更稳妥地：停止该节点 → 清空整个数据目录（除mongod.lock）→ 重启触发 initial sync - 注意：initial sync 期间磁盘 I/O 和网络带宽压力极大，避免在业务高峰期操作
真正容易被忽略的是：修复操作本身不改变副本集配置元数据。如果故障前曾修改过 rs.conf() 但未 rs.reconfig() 生效，修复后节点仍按旧配置尝试连接，表现为反复 RECOVERING + 日志里大量 couldn't connect to xxx。先连上还能工作的 primary，用 rs.conf() 确认当前生效配置，再比对本地配置文件是否一致。
