磁盘损坏后必须彻底清空dbPath才能触发initialSync，否则因元数据不一致导致启动失败或同步异常；清空需递归删除全部文件，包括local目录；同步完成后optimeDate应与PRIMARY相差≤5秒。
磁盘损坏后直接替换硬盘再启动 mongod 会失败
不会自动触发 initialSync，而是报 WiredTiger error: Invalid argument 或卡在 STARTUP2 状态。因为 MongoDB 启动时发现现有数据文件与当前副本集元数据（如 local.replset.minvalid 中的 _initialSyncFlag、oplog 截断点、节点唯一标识）不一致，拒绝加载。强行启动可能让节点以错误状态加入，后续同步中断或丢数据。
必须清空 dbPath 才能强制 initialSync
只有彻底删除目标节点的整个 dbPath 目录（包括 WiredTiger、_mdb_catalog.wt、local/ 等所有子项），重启后 mongod 才会识别为“无数据成员”，进入初始同步流程。常见错误是只删 collection 文件或留着 local/ 目录——这会导致同步源选择异常或 oplog 应用失败。
- 停机前先确认无残留进程：
sudo systemctl stop mongod+ps aux | grep mongod - 检查并删除锁文件：
rm -f /var/lib/mongodb/mongod.lock（路径按实际dbPath调整） - 清空操作必须递归且彻底：
rm -rf /var/lib/mongodb/*，不能只rm -rf /var/lib/mongodb/*/*.wt - 确保
local数据库有足够空间：同步期间临时 oplog 缓存会写入local，建议预留 ≥10% 总数据量的空间
initialSync 启动后要盯住三件事
同步不是“启动就完事”。从 STARTUP2 到 SECONDARY 的过程可能持续数小时，中间出错不易察觉：
- 查日志关键行：
tail -f /var/log/mongodb/mongod.log，确认出现Starting replication oplog collection和initial sync done - 验证同步源是否合理：
rs.status().members.find(m => m.stateStr === "STARTUP2").lastHeartbeatMessage，避免选到过时或网络延迟高的节点 - 同步完成后立刻比对：
rs.status().members.find(m => m.name.includes("your_node_host:port")).optimeDate，和 PRIMARY 的optimeDate差值应 ≤5 秒；否则说明 oplog window 不够或网络抖动严重
initialSync 失败后不要反复重试
如果同步中途失败（比如网络闪断、磁盘 I/O 拒绝写入、源节点 oplog 被截断），节点重启后仍会尝试继续，但大概率卡死或进入无限重试。此时最稳妥的做法是：
- 再次停止
mongod - 重新清空
dbPath（即使上次已删过，也要再执行一遍） - 检查源节点 oplog 窗口：
db.adminCommand({replSetGetStatus: 1}).members.find(m => m.stateStr === "PRIMARY").optimeDate减去db.getSiblingDB("local").oplog.rs.findOne({}, {sort: {$natural: -1}}).ts，确保差值 > 预估同步耗时 - 必要时换一个更稳定的同步源，通过
initialSyncSourceReadPreference启动参数指定
真正麻烦的不是同步慢，而是同步完成但 optimeDate 明显落后——这意味着该节点虽然状态是 SECONDARY，却无法参与多数派写入确认，也容易在下次选举中被跳过。
