priority不等于强制主节点，选举由priority、votes等共同决定；跨机房容灾关键在votes分布与tags地理标签配合readPreference/writeConcern实现就近读写。
跨机房部署时，priority 配置不等于“强制主节点”
副本集选举由 priority、votes、hidden、slaveDelay 等多个字段共同决定，仅调高某节点的 priority 并不能确保它在跨机房网络分区时当选主节点——尤其当该节点所在机房与其他节点失联，它会因无法获得多数票而自动退选。
实操建议：
-
priority值只在所有节点可达时起作用；真正影响跨机房容灾的是投票节点分布和members[n].votes设置 - 每个机房至少保留 1 个
votes: 1节点，避免单机房断网后整个集群无法选举 - 不要把所有高
priority节点放在同一机房；应按机房权重分配（例如：主中心设priority: 10，备份中心设priority: 8，灾备中心设priority: 1） - 隐藏节点（
hidden: true）默认votes: 0且priority: 0，即使手动设priority: 5也无效，必须显式加votes: 1
MongoDB 6.0 中用 tags 实现地理位置感知读写
tags 本身不参与选举，但配合读偏好（readPreference）和写关注（writeConcern）可实现就近访问。MongoDB 不自动识别“机房”，需人工打标并约定 key 名（如 "dc": "shanghai"）。
常见错误现象：
- 应用连接字符串中指定
readPreference=nearest，但所有节点tags字段为空 → 实际仍走默认 nearest 逻辑（按 ping 时间），未生效地理感知 - 使用
readPreference=primaryPreferred+maxStalenessSeconds，但未在tags中统一定义"region"或"dc"→ 驱动无法匹配标签 -
writeConcern设为{"w": "majority", "wtimeout": 5000}，但多数节点跨机房 → 写入延迟飙升甚至超时，而非按地理“降级”
正确配置示例（在 rs.reconfig() 中）：
members: [
{
_id: 0,
host: "sh1.example.com:27017",
tags: { dc: "shanghai", region: "east" }
},
{
_id: 1,
host: "bj1.example.com:27017",
tags: { dc: "beijing", region: "north" }
},
{
_id: 2,
host: "sz1.example.com:27017",
tags: { dc: "shenzhen", region: "south" }
}
]
配置 priority 和 tags 后必须重载配置
修改 members[n].priority 或 members[n].tags 后，MongoDB 不会自动生效；必须调用 rs.reconfig() 并传入完整新配置对象（含 _id、host 等全部字段），否则会报错 replSetReconfig invalid config 或静默忽略变更。
关键细节：
- 执行前先用
rs.conf()获取当前配置，再修改对应成员字段，避免遗漏host或误删arbiterOnly - 若配置中含仲裁节点（
arbiterOnly: true），它不能有priority > 0或tags，否则rs.reconfig()拒绝提交 - 6.0 默认开启
enableMajorityReadConcern: true，若降级写关注（如w: 1），需确认业务能容忍读未提交数据 - 执行
rs.reconfig(..., {force: true})仅在主节点宕机无法通信时使用；正常场景下不应加force，否则可能引发双主或回滚
跨机房延迟导致 heartbeat 失败的典型表现与应对
MongoDB 副本集靠心跳（默认 2 秒发一次，超时 10 秒）检测节点状态。跨机房 RTT 若常超 100ms，叠加网络抖动，极易触发 state: ARBITER 或 health: 0，进而引发不必要的选举震荡。
可调整项（在 rs.reconfig() 的 settings 中）：
-
heartbeatTimeoutSecs：建议设为30（最大支持值），避免因瞬时延迟误判节点下线 -
electionTimeoutMillis：默认 10000，跨机房建议提高到20000，给网络恢复留出窗口 - 不推荐调大
heartbeatIntervalMillis（默认 2000），会导致故障发现变慢；优先优化网络或改用专线 - 务必关闭
tcpKeepAlive相关内核参数干扰（如 Linux 的net.ipv4.tcp_keepalive_time设过小，可能提前断连）
真实部署中，最易被忽略的是心跳超时与选举超时的协同关系：前者影响“是否认为节点挂了”，后者决定“多久后启动新选举”。两者都偏保守调大，比强行压低 priority 更可靠。
