MongoDB副本集本身不支持跨地域实时同步，因其依赖低延迟稳定通信，高RTT会导致选举失败、同步滞后、节点频繁降级；changeStream仅限单副本集内使用，无法跨集群；官方唯一支持方案是mongosync，它通过全量快照+changeStream增量捕获+位点管理实现可靠跨集群同步。
直接用副本集本身无法实现跨地域实时同步——它只在单个集群内部工作，跨机房或跨云区域部署副本集节点会因网络延迟、分区容忍度低、选举不稳定等问题导致不可靠甚至服务中断。
为什么不能把异地节点加进同一个副本集
副本集要求所有成员能稳定通信，且 electionTimeoutMillis（默认10秒）和心跳间隔（默认2秒）在高延迟网络下极易触发误判。一旦两地间 RTT 超过 200ms，secondary 就可能频繁失联、反复降级为 STARTUP 或 RECOVERING，主节点也容易因多数派无法达成而退位。
- oplog 同步依赖 TCP 流式拉取，跨地域丢包/重传会放大 lag，
rs.status()中optimeDate和lastHeartbeatRecv时间差常达分钟级 - 仲裁节点（arbiter）不能缓解问题——它不存数据，也无法降低异地节点的同步压力
- 启用
priority: 0或hidden: true也不能让异地节点“安静地同步”，它仍参与心跳、投票、oplog 拉取全流程
changeStream 不是跨集群同步方案
db.collection.watch() 只能在同一副本集内使用，且依赖本地 local.oplog.rs 的可读性。跨集群调用会报错 CommandNotSupportedOnView 或 NotMaster，因为 changeStream 底层绑定的是当前连接的 replica set ID，无法桥接两个独立集群的逻辑时钟与 oplog 偏移。
- 即使手动从 A 集群拉 changeStream 事件再写入 B 集群，也会丢失事务边界、$inc 等非幂等操作语义
- 没有内置的断点续传机制：B 集群宕机后，A 集群的 resume token 在 B 重启时已过期或不可用
- 无法处理集合重命名、drop、create 等 command 类型变更，
operationType: "invalidate"会直接终止流
mongosync 是唯一官方支持的跨集群同步路径
它不是简单转发 oplog，而是分层处理：先做全量快照拷贝（跳过 local 数据库），再基于源集群的 changeStream 持续捕获增量，同时在目标集群按 namespace 映射、自动建库建集合、转换 ObjectId 与时间戳格式，并维护内部 checkpoint 表记录同步位点。
- 必须用
mongosync二进制而非自研脚本——它内置了对applyOps的封装、冲突检测（如目标已有同名集合时跳过或报错）、以及writeConcern: "majority"对齐逻辑 - 启动前需确保源集群开启
featureCompatibilityVersion: "6.0"（或匹配版本），否则 changeStream 格式不兼容 - 目标集群不能有同名数据库正在被应用写入，
mongosync默认以readPreference=primary连接源，但写入目标时使用majority写关注，避免脏读
真正需要警惕的隐蔽风险点
很多团队在测试环境跑通 mongosync 后就上线，却忽略三类硬性约束：
- 源集群必须启用
enableMajorityReadConcern: true，否则 changeStream 无法保证 majority-committed 事件可见性，导致目标集群出现“幻读”或“回滚丢失” - 跨云同步时，若源集群在 AWS us-east-1、目标在阿里云 cn-shanghai，DNS 解析延迟或 TLS 握手失败会导致
/api/v1/progress返回"state": "FAILED"，但日志里只写connection refused，需手动检查两端安全组与证书链 -
mongosync不同步system.*集合、用户权限、索引构建过程——这些必须提前在目标集群手工初始化，否则应用连上去会报NamespaceNotFound或Unauthorized
