2. MongoDB副本集基础与跨地域扩展

MongoDB的高可用能力建立在副本集（Replica Set）之上。副本集是一组维护相同数据集的mongod实例，其中只有一个节点承担写入，其余节点持续复制数据。当主节点不可用时，副本集通过选举产生新的主节点，使服务在秒级到十几秒级内恢复。理解副本集的成员角色、选举规则以及跨地域部署时的延迟影响，是设计跨地域灾备方案的前提。

成员角色与数据流向

副本集中每个节点都有明确角色。主节点（Primary）是唯一接受写操作的成员，所有写入先落到主节点，再通过oplog（操作日志）异步复制到从节点。从节点（Secondary）持续拉取oplog并重放，保持与主节点的数据一致。从节点可以配置为隐藏节点（Hidden），对客户端不可见，常用于备份或离线分析；也可以配置为延迟节点（Delayed），故意落后主节点固定时间，用于抵御误删除等逻辑故障。

仲裁节点（Arbiter）不保存数据，只参与选举投票，用于在硬件资源有限时凑够奇数投票成员。但仲裁节点不持有数据副本，无法在数据恢复中提供帮助，生产环境应谨慎使用。此外，副本集还支持投票权配置，通过votes参数控制成员是否参与选举，通过priority参数控制成员成为主节点的优先级。

副本集要求投票成员总数为奇数，或通过仲裁节点补足奇数，以避免选举出现平票。一个典型的跨地域副本集可能包含：1个主节点、2个可投票从节点、1个隐藏节点和1个仲裁节点，总投票成员为3或5。

选举机制

当主节点失联超过electionTimeoutMillis（默认10秒）时，从节点会发起选举。选举采用Raft-like协议：候选节点向其他投票成员请求投票，获得多数票（N/2+1）即可成为新主节点。多数票的定义基于投票成员总数，而非存活成员数。这意味着如果投票成员总数为5，则至少需要3票才能当选。

选举过程中，priority高的节点更可能被选为主节点。如果多个节点priority相同，则数据更新的节点优先。选举完成后，新主节点开始接受写入，其他从节点从新主节点继续复制。整个故障切换时间通常在10～30秒之间，取决于网络延迟和选举配置。

需要特别注意的是，跨地域部署时，如果投票成员分布在多个地域，选举需要跨地域通信，延迟会显著增加故障切换时间。因此，跨地域副本集的投票成员分布需要精心设计，通常建议将多数投票成员放在同一个低延迟地域，而将灾备节点放在远端。

跨地域部署的拓扑模式

跨地域副本集的核心矛盾在于：数据复制需要跨地域带宽，选举需要跨地域通信，而两者都受网络延迟影响。常见的拓扑模式有三种。

模式一：主地域多节点 + 灾备地域单节点。在地域A部署3个投票成员（1主2从），在地域B部署1个非投票从节点。这种模式下，选举完全在地域A内完成，故障切换时间短；地域B节点仅用于数据备份和灾难恢复，不参与选举。缺点是地域B节点无法在本地域A整体故障时自动接管，需要人工干预。

模式二：主地域2节点 + 灾备地域2节点 + 仲裁。投票成员分布为2+2+1，多数票为3。这种模式允许任一地域故障后仍能选举，但跨地域选举延迟较高。如果地域A的2个节点失联，地域B的2个节点需要与仲裁节点通信才能获得多数票，选举时间可能达到30秒以上。

模式三：三地域各1节点 + 仲裁。将投票成员分散到三个地域，每个地域1个节点，另加1个仲裁节点。这种模式容灾能力最强，但跨地域复制和选举延迟最大，通常只适用于对RPO要求极低、对RTO容忍度较高的场景。

延迟对复制与选举的影响

跨地域复制延迟直接影响RPO（恢复点目标）。假设主节点每秒写入1000条操作，oplog大小足够，网络RTT为50ms，则从节点至少落后主节点50ms的数据量，即约50条操作。如果网络抖动导致RTT升至200ms，则落后约200条操作。对于金融交易类场景，这种延迟可能不可接受，需要评估是否采用更近的灾备地域或同步复制方案。

选举延迟则影响RTO（恢复时间目标）。选举需要候选节点与多数投票成员完成一轮或多轮通信。如果投票成员跨地域分布，每轮通信耗时约等于RTT。以RTT=50ms计算，一轮选举至少需要50ms，加上选举超时10秒和状态切换时间，实际RTO通常在15～30秒。如果RTT=200ms，RTO可能超过40秒。

配置示例与验证

以下是一个跨地域副本集的配置示例，主地域3个投票成员，灾备地域1个非投票从节点：

// 在主节点上初始化副本集
rs.initiate({
  _id: "rs-cross-region",
  members: [
    { _id: 0, host: "mongo-a1:27017", priority: 10, votes: 1 },
    { _id: 1, host: "mongo-a2:27017", priority: 5,  votes: 1 },
    { _id: 2, host: "mongo-a3:27017", priority: 5,  votes: 1 },
    { _id: 3, host: "mongo-b1:27017", priority: 0,  votes: 0 }
  ]
});

// 查看副本集状态
rs.status();

// 查看复制延迟
rs.printSlaveReplicationInfo();

执行rs.printSlaveReplicationInfo()后，输出会显示每个从节点落后主节点的秒数。如果灾备节点延迟持续超过预期，应检查网络带宽、oplog大小和写入速率。通常建议oplog大小至少能容纳24小时的写入量，以便从节点在断连后能追上进度。

验证选举行为时，可以手动将主节点降级：rs.stepDown(60)，观察新主节点产生的时间和客户端连接恢复情况。在跨地域场景中，应特别关注灾备节点是否被错误选举为主节点，导致写入跨地域绕行。

关键参数速查

跨地域副本集的设计没有唯一正确答案，需要在RPO、RTO、成本和网络条件之间权衡。核心原则是：让选举发生在低延迟地域，让数据复制覆盖灾备地域，让延迟节点提供逻辑故障保护。理解这些机制后，才能进一步设计跨地域分片集群和灾备切换流程。