\_rs.syncFrom() 在 MongoDB 4.0+ 已废弃并移除，它仅是旧版调试函数，不支持强制覆盖同步源，且效果短暂易失效；真实同步源由 syncSourceHost 和选举逻辑动态决定，需通过 rs.freeze()、优先级调整与主动降级等配置手段间接控制。
不能直接用 _rs.syncFrom() 强制从指定节点同步 —— 这个命令在 4.0+ 版本已移除，且从未支持“强制覆盖当前同步源”的语义。
为什么 _rs.syncFrom() 不再可用
这个命令在 MongoDB 4.0 中被正式废弃，4.2+ 完全删除。它原本是 shell 内部的调试辅助函数，不是官方支持的运维接口。即使旧版本能调用，它也只临时修改一次同步源，下次心跳或主节点变更后立刻失效，还可能触发 NotSecondary 或 NodeNotFound 错误。
- 真实生效的同步行为由
replSetGetStatus中的syncSourceHost和内部选举逻辑决定 - 手动干预必须走配置层面（
rs.reconfig()）或状态控制（rs.freeze()+ 主动降级） - 所有 shell 命令都运行在当前节点上下文，
_rs.syncFrom()并不跨节点执行
真正可控的替代方案：冻结 + 主动降级 + 等待重选
想让某 Secondary 节点固定从 A 同步，本质是让它无法选到其他源、同时让 A 成为唯一可行候选。核心思路是：让目标节点暂时“失能”，再让 A 成为主或长期在线的最高优先级节点，最后解冻触发重同步。
- 在目标 Secondary 上执行
rs.freeze(0)：阻止它参与选举，但保持数据同步能力 - 在 A 节点上调高其
priority（如设为 10），并确保它votes: 1、hidden: false、slaveDelay: 0 - 在目标 Secondary 上执行
db.adminCommand({replSetStepDown: 60, force: true})（如果它当前是主） - 等待 30–60 秒，再执行
rs.freeze(-1)解除冻结 —— 此时它会重新参与心跳，并大概率选 A 为 sync source
检查是否真的从目标节点同步了
别信配置，看实时状态。最可靠的验证方式是查 replSetGetStatus 输出里的 syncSourceHost 字段，以及 oplog 进度是否追平目标节点。
- 运行
rs.status().members.find(m => m.stateStr === 'SECONDARY').syncSourceHost - 对比
rs.printSlaveReplicationInfo()中该节点的syncedTo时间戳和 A 节点的optimeDate - 如果
syncSourceHost是空，说明它处于 initial sync 或连接异常；如果显示的是非预期节点，说明心跳选源逻辑仍绕过了你的意图
容易被忽略的底层约束
MongoDB 的同步源选择不是纯配置驱动，而是受网络延迟、lastHeartbeatRecv 时间戳、oplog 可用性三者共同影响。哪怕你把 A 设成唯一高优先级节点，只要它最近一次心跳超时（默认 10 秒），目标节点就会立刻切走。
- 确认所有节点间
ping和telnet端口连通，防火墙没丢心跳包 - 检查
rs.status().members[n].lastHeartbeatRecv是否持续更新 —— 卡在几分钟前就说明网络或负载异常 - 避免在 oplog 小于 1 小时保留窗口的集群里强行干预，否则可能触发 initial sync，拖垮磁盘 IO
同步源不是开关，是多个状态变量动态博弈的结果。改完配置后至少等两个心跳周期（20 秒）再验证，中间别反复 freeze/unfreeze。
