mongodb副本集必须跨至少3个az部署以避免单点故障，3节点全置同一az会导致多数派失联、primary降级；需用tags标记az并配置readpreference=nearest实现就近读，写操作依赖primary所在az为流量入口。
为什么 MongoDB 副本集节点不能全放在一个 AZ
单可用区（AZ）部署副本集，等于把所有鸡蛋放进一个篮子——网络分区、机架断电或云厂商局部故障会直接导致多数派失联，PRIMARY 降级甚至整个集群不可写。MongoDB 依赖多数派投票选举，3 节点若全在 us-east-1a，AZ 故障时剩余 0 节点在线，写操作立刻失败。
实操建议：
- 3 节点副本集至少跨 3 个 AZ（如 us-east-1a / us-east-1b / us-east-1c），确保任一 AZ 宕机后仍能维持 2/3 投票权
- 若只有 2 个 AZ 可用，必须加一个
arbiter（仲裁节点）放在第三个 AZ 或本地跳板机——它不存数据但参与投票，避免脑裂 - 禁止将
priority全设为 1 且未配置hidden或delayed：否则故障恢复时可能选错主节点，引发回滚
如何设置节点的 AZ 感知与读写偏好
MongoDB 本身不自动感知 AZ，需靠标签（tags）+ 应用层路由配合实现流量就近。否则即使节点物理分散，客户端仍可能把读请求发到跨 AZ 的节点，增加延迟和跨 AZ 流量费用。
实操建议：
- 启动每个
mongod时用--replSet "rs0?replicaSetTag=us-east-1a"（实际通过rs.add({host: "...", tags: {az: "us-east-1a"}})设置） - 应用连接字符串中指定
readPreference=nearest&readPreferenceTags=az:us-east-1a，让 SDK 自动选同 AZ 节点读 - 写操作默认走
PRIMARY，所以必须确保PRIMARY所在 AZ 是业务主流量入口，否则写延迟飙升；可通过rs.reconfig()手动调高某 AZ 节点的priority
云环境里哪些配置项容易被忽略导致 AZ 隔离失效
看似跨 AZ，实际因配置疏漏仍可能形成隐性单点。最典型的是 DNS、负载均衡器或 TLS 证书绑定错误，把多 AZ 流量悄悄引向单一入口。
常见错误现象：
- 所有节点用同一个弹性 IP 或 NLB DNS 名连接，而 NLB 后端未启用“跨 AZ 负载均衡”，流量只打到某个 AZ 的节点
-
bindIp配置为127.0.0.1或私有 IP 段但没开安全组入向规则，导致其他 AZ 节点无法发起心跳 - 使用云厂商托管 MongoDB（如 Atlas/AWS DocumentDB），误以为自动跨 AZ——其实 Atlas 免费层仅单 AZ，DocumentDB 默认也是单 AZ，需显式选择 multi-AZ 选项并确认实例状态为
available而非creating
副本集初始化时怎么验证 AZ 分布是否生效
光看节点 IP 段不够，得查 MongoDB 内部视角是否识别出拓扑差异。很多团队上线后才发现节点标签没生效，选举逻辑跑偏。
实操建议：
- 连上任意节点执行
rs.status().members.map(m => ({name: m.name, stateStr: m.stateStr, tags: m.tags}))，确认每项tags字段非空且互异 - 手动触发一次故障模拟：
rs.stepDown()，观察新PRIMARY是否落在预期 AZ；再停掉该 AZ 的节点，确认剩余节点能否重新选举 - 检查日志中是否有
not enough votes to win或voting for X but not in majority类报错——这是 AZ 网络不通或标签冲突的直接证据
真正麻烦的不是配不配得出来，而是配完没人验证 AZ 标签是否被复制集真正采纳。心跳超时阈值（heartbeatTimeoutSecs）、TLS 握手耗时、云防火墙动态规则，都可能让“看起来跨 AZ”的集群在秒级内退化成单点。
