不能。主节点数据目录损坏后，直接用从节点文件替换会因oplog截断点、checkpoint位置和节点ID不一致导致启动失败或后续同步异常；必须停机、清空目标目录、完整拷贝同副本集同版本同存储引擎的从节点数据，并验证状态、数据量及oplog窗口重叠。
主节点数据目录损坏后，能否直接用从节点文件替换？
不能。直接复制从节点的 dbpath 到主节点启动会失败，常见报错是 WiredTiger error: Invalid argument 或 recovery required but disabled。这是因为副本集每个节点有独立的 oplog 截断点、内部 checkpoint 位置和节点唯一标识（__system 集合里的 host 和 pid），文件级拷贝不满足一致性前提。
冷备份恢复必须满足的三个前提条件
缺一不可，否则即使启动成功也会在后续同步中异常退出或丢数据：
- 目标节点（待恢复的原主节点）必须完全停止
mongod进程，确认无残留锁文件（如mongod.lock） - 用于恢复的数据源必须来自**同一副本集、同一版本、同一 storage engine（WiredTiger）且未执行过
rs.reconfig()或节点 ID 变更**的从节点 - 恢复前需清空目标节点的
dbpath下所有文件（包括_mdb_catalog.wt、WiredTiger等元数据文件），不能只覆盖collection-*.wt
实际操作步骤：停→删→拷→改→启
以从节点 A（IP: 192.168.1.10）恢复原主节点 B（IP: 192.168.1.20）为例：
- 在 B 上执行
sudo systemctl stop mongod，确认ps aux | grep mongod无残留进程 - 删除 B 的整个数据目录：
rm -rf /var/lib/mongodb/*（假设dbpath是/var/lib/mongodb） - 从 A 拷贝完整
dbpath：rsync -avz --delete root@192.168.1.10:/var/lib/mongodb/ /var/lib/mongodb/（注意末尾斜杠） - 修改 B 的
mongod.conf，确保replication.replSetName与集群一致，且bindIp正确（不要写成127.0.0.1） - 启动并观察日志：
sudo systemctl start mongod && tail -f /var/log/mongodb/mongod.log，等待出现Starting replication oplog collection和Member is now in state SECONDARY
恢复后必须立即验证的两件事
很多团队以为启动成功就完事了，结果几小时后发现数据不同步或查询返回旧快照：
- 登录 B 执行
rs.status().members.find(m => m.name.includes("192.168.1.20"))，确认stateStr是SECONDARY，且optimeDate与其它节点差距在秒级（不是小时级） - 在任意节点执行
db.runCommand({collStats: "your_collection", scale: 1})，比对 B 与 A 的count和size，数值必须完全一致；若不一致，说明恢复过程被中断或 rsync 未完成
最易被忽略的是 oplog 截断点偏移——即使节点状态正常，如果它从错误的 optime 开始同步，后续所有增量都会丢失。务必用 rs.printSecondaryReplicationInfo() 检查各节点 oplog 覆盖时间窗口是否重叠。
