\_rs.syncFrom()在MongoDB 4.2+已彻底移除，强制指定同步源无效；可靠重同步仅两种：清空数据目录重启触发initial sync，或从SECONDARY成员复制数据文件。
不能用 _rs.syncFrom() 强制指定同步源——这个函数在 MongoDB 4.0+ 已彻底移除，且从未真正支持“强制覆盖”语义。真实有效的重新同步，只有两种可靠路径：走初始同步（initial sync），或用文件拷贝加速重建。所有“临时改 sync source”的尝试，都会被心跳机制覆盖。
为什么 _rs.syncFrom() 不再可用
它不是运维接口，只是旧版 shell 的调试残留。MongoDB 4.2 起完全删除该命令；即使你在 3.6 或 4.0 里侥幸调用成功，效果也仅维持一次心跳周期，随后就被 syncSourceHost 自动重选覆盖。更糟的是，它可能触发 NotSecondary 或 NodeNotFound 错误，导致节点状态异常。
真正可控的重新同步方式：清空数据目录 + 重启
这是最直接、最兼容所有版本的操作，适用于节点已陈旧（stale）、oplog 断档、或本地数据损坏等场景。
- 先确保目标节点是
SECONDARY状态（非主节点），避免影响写入法定人数 - 登录该节点，执行
db.shutdownServer()完全停止mongod - 备份
dbPath下的diagnostic.data目录（故障排查用），然后彻底清空整个dbPath目录 - 重启
mongod，它会自动进入 initial sync 流程，从当前syncSourceHost拉取全量数据
注意：initial sync 过程中会清空并重建 local 数据库里的 oplog，依赖源节点有足够长的 oplog window；否则会反复失败重试。
更快的替代方案：从另一个成员复制数据文件
适用于数据量大、带宽充足、且能停机维护的场景。比纯网络拉取快得多，但必须严格满足一致性前提：
- 源节点必须是
SECONDARY或刚完成rs.stepDown()的原PRIMARY，且未在写入中 - 复制前需执行
db.fsyncLock()（企业版）或至少db.adminCommand({setParameter:1,quiet:true})降低写入干扰 - 用
rs.printSlaveReplicationInfo()确认源节点的syncedTo时间戳足够新（比如落后不超过 5 秒） - 用
rs.status().members[n].optimeDate对齐时间点，避免复制出不一致快照 - 目标节点停机后，直接替换整个
dbPath（不含mongod.lock和日志），再启动
启动后它仍会做一次轻量级 oplog replay 校验，但跳过了全量克隆阶段 —— 这是唯一能绕过慢速 initial sync 的合法手段。
容易被忽略的关键点：同步源选择不是配置说了算，而是由 lastHeartbeatRecv、网络延迟、oplog 可用性三者实时竞争决定。哪怕你把某节点 priority 设为 10，只要它上次心跳超时或 oplog 不连续，其他节点照样会被选为 sync source。
