两地三中心MongoDB副本集必须显式配置priority、votes和tags，异地节点设votes:0/priority:0，同城节点设不同priority且votes:1，并通过rs.initiate()一次性初始化完整配置，否则易致脑裂或选举异常。
两地三中心不是简单把三个节点扔到不同机房就能跑起来的。MongoDB 5.0 的副本集本身不感知地理拓扑，必须靠显式配置 priority、votes 和 tags 来约束选举行为，否则同城双中心网络抖动时可能触发跨城选主，造成高延迟写入甚至脑裂。
为什么不能直接用默认 rs.initiate() 部署两地三中心
MongoDB 副本集选举只看投票权和心跳，不区分物理位置。如果三个节点（A 北京、B 上海、C 深圳）都设为 priority: 1 且 votes: 1，一旦北京-上海链路中断，A 和 B 可能各自认为对方失联，而 C 同时收不到 A/B 心跳——此时若 C 的 oplog 落后太多，它可能无法当选；更糟的是，A 和 B 在各自网络分区里凑够两票，各自选出主节点，形成脑裂。
关键点在于：两地三中心要求「同城双中心可自动切换，异地中心仅容灾、不参与日常选举」。这必须通过人工干预配置实现，而不是副本集默认行为。
- 异地节点必须设置
votes: 0和priority: 0，确保它永远无法成为主节点，也不影响多数派计算 - 同城两个节点需设置不同
priority（如北京 2、上海 1），保证正常情况下北京为主；但两者votes: 1，确保任一挂掉另一仍能获多数票 - 必须给节点打
tags，例如{"region": "beijing"}，后续读偏好和备份策略才可基于地理位置路由
初始化时必须用带成员配置的 rs.initiate()，不能省略
很多团队先用空配置 rs.initiate() 启动，再逐个 rs.add()，这是错的。MongoDB 5.0 对副本集配置变更敏感，初始配置一旦提交就很难动态调整 votes 和 priority ——尤其 votes: 0 节点加入后，若未在 init 阶段声明，后续 rs.reconfig() 可能因多数派校验失败而拒绝生效。
正确做法是构造完整 config 对象再初始化：
rs.initiate({
_id: "rs0",
members: [
{
_id: 0,
host: "bj-mongo-01:27017",
priority: 2,
votes: 1,
tags: {"region": "beijing", "type": "primary-preferred"}
},
{
_id: 1,
host: "sh-mongo-01:27017",
priority: 1,
votes: 1,
tags: {"region": "shanghai", "type": "secondary"}
},
{
_id: 2,
host: "sz-mongo-01:27017",
priority: 0,
votes: 0,
tags: {"region": "shenzhen", "type": "arbiter-like"}
}
]
})注意：votes: 0 节点虽然不参与投票，但它仍要同步 oplog（除非显式设 hidden: true），所以磁盘和网络开销仍在。若仅需异地备份，可考虑将其设为 hidden: true + priority: 0 + votes: 0，彻底隔离于读写路径。
客户端连接字符串必须带 readPreference 和 tag sets
只用 replicaSet=rs0 连接，驱动会把读请求随机发给任意节点，包括深圳的异地节点——这会导致查询延迟飙升。必须显式控制读流量走向：
- 写操作天然走主节点，无需额外配置
- 强一致性读（如订单详情）应加
readPreference=primary - 报表类弱一致性读可走同城从节点：
readPreference=nearest&readPreferenceTags=region:beijing,region:shanghai - 绝对禁止将
readPreference=primaryPreferred与异地节点混用，否则主节点压力未分担，还可能因网络延迟导致超时重试放大
验证是否生效：在客户端执行 db.runCommand({isMaster: 1})，检查返回中的 hosts 和 passives 字段，确认深圳节点出现在 passives（表示驱动识别其为非选举节点）而非 hosts 列表中。
oplog 大小和同步延迟监控必须按地域拆分
两地三中心下，同城节点间延迟通常 rs.printSecondaryReplicationInfo() 输出是全局平均值，掩盖了异地节点严重滞后的问题。
真正要盯的是每个节点的 optimeDate 差值：
rs.status().members.forEach(m => console.log(m.name, ":", new Date() - new Date(m.optimeDate)) )
若深圳节点落后超过 5 分钟，说明它已无法作为 RPO≈0 的容灾节点——此时应检查其磁盘 I/O、WiredTiger cache 压力，或考虑关闭其 oplog 同步（设 buildIndexes: false）仅用于定时快照备份。
容易被忽略的一点：MongoDB 5.0 默认 oplog 是固定大小（如 5% 磁盘空间），但跨城同步慢时，oplog 可能被新写入覆盖，导致从节点进入 STARTUP2 或 RECOVERING 状态后无法追上。必须为异地节点单独规划更大 oplog（如 20GB），并在启动参数中用 --oplogSize 20480 显式指定。
