MongoDB 复制

MongoDB 复制（Replication）是一种将数据从一个节点复制到其他节点的机制。 它是 MongoDB 分布式环境下的一种高可用性部署方案。 复制集是一组 MongoDB 服务器集合，其中每个服务器副本存储相同的数据。 副本集容许应用程序从副本集中读取数据，并将写操作传递到主节点，主节点再同步写操作到其他节点。

复制集的构成

复制集是 MongoDB 集群部署环境下的基础。在一个复制集中可以拥有最多 50 个成员，其中一个为主节点(Master)，其余为从节点(Slave)。

复制集中的成员可以是物理机，也可以是虚拟机或容器，它们使用MongoDB 的 replSet 配置进行协作。 下面是一个3个节点的复制集的描述:

{
   _id: "rs0",
   members: [
      { _id: 0, host: "mongodb0.example.net:27017" },
      { _id: 1, host: "mongodb1.example.net:27017" },
      { _id: 2, host: "mongodb2.example.net:27017" }
   ]
}

可见复制集“rs0”包含了三个成员，分别为成员 0,1,2，各自使用不同的主机名和端口号，每个成员都需要有唯一的 _id。

复制集的角色

一个复制集中，每个节点都有不同的角色：

• 主节点(Master)：主节点负责所有写操作并决定那些修改操作会被复制到其他成员
• 从节点(Slave)：从节点从主节点同步数据并处理读请求
• 选举节点(Voter)：选举节点不存储数据，仅用于在主节点失效时发起新的主节点选举

每个复制集中只有一个主节点，可以有多个从节点，并且至少需要三个节点才能进行选举。

复制集的选举

如果主节点失效，复制集必须选择一个新的主节点来接替角色。 MongoDB 通过维护一个单调递增的 oplog 以容许从节点同步所有主节点写操作，让同步进程成为主节点。 选举如下：

1. 当主节点无响应时，选举节点开始投票。
2. 选举节点向其他所有节点发送投票请求信息，并等候回应。
3. 如果接受请求的成员已经知道 该选举，投给自己。如果成员没有听说过这个选举，则投票给候选人，并开始尝试复制该候选人的操作日志。
4. 如果任何候选人赢得了管理员的多数投票，则该候选人成为新主节点。
5. 如果选举无法确定新的主节点，则将其视为不能解决的，每隔一段时间重试。

复制集的数据同步

一旦备份节点被选举为主节点，主节点就开始与备份节点同步更新操作。 写操作被复制到其他备份节点，因此每个节点都包含相同的所有数据。

另外，MongoDB 复制集提供了多种数据同步的模式：

• 主备模式：在主副本之间同步数据，由主节点处理读写请求。
• Follower Reads 模式：在从副本之间同步数据。有一个主副本，但这个角色是临时分配的，用于在主副本出现故障时维护读取的一致性。
• 多主模式：多个主副本可以写入和读取数据，导致数据写入时的冲突，在某些情况下可能需要应用程序实现明确的操作序列（串行和/或一致性保证）来应对冲突。

复制集的部署建议

为确保真正的高可用性和容错性，在复制集的部署中需要注意以下几点：

• 复制集至少需要 3 个成员，至多 50 个成员。
• 如有可能，应将每个节点部署在不同的物理机上。
• 配置至少 3 个节点以确保高可用性，可以通过增加节点来增加系统可用性。
• 每个节点要有足够的内存和 CPU，以支持高读/写负载。
• 相邻节点间的网络带宽大小应能支持数据复制的需求。
• 采用自适应选举超时时间，采用相对较高的选举超时时间，以避免磁盘故障下的错误选举，同时，也应该设置网络读取和写入超时时间，以避免网络问题造成的故障。

总结

MongoDB 复制集是一种高可用性的 MongoDB 集群方案，在实际的项目应用中，合理部署和配置复制集可以为应用程序提供数据安全、容错和高可用性等方面的保障，是 MongoDb 作为 NoSQL 数据库领域的佼佼者所不可或缺的核心特性之一。