第5章 副本集

5.1 副本集架构

在前面，我们已经完成了MongoDB在单机上的安装，并进行了基本的功能体验。然而，在生产环境中，不建议使用单机版的MongoDB服务器。原因如下：

● 单机版的MongoDB无法保证可靠性，一旦进程发生故障或是服务器宕机，业务将直接不可用。

● 一旦服务器上的磁盘损坏，数据会直接丢失，而此时并没有任何副本可用。

于是，任何生产环境的数据库都应该拥有一个或多个可用的副本实例，在出现任何异常情况时，能第一时间恢复数据库的读写访问。这通常可以称之为数据库的高可用，而如何实现高可用的架构也一定是现代数据库需要解决的关键问题。

对于MongoDB来说，数据库高可用是通过副本集架构（Replication Set）实现的，一个副本集由一个主节点（Primary）和若干个备节点（Secondary）所组成。一个典型的副本集架构如图5-1所示。

图5-1 副本集架构

客户端通过数据库主节点写入数据后，由备节点进行复制同步，这样所有备节点都会同时拥有这些业务数据的副本，当主节点发生故障而变得不可用时，备节点能主动发起选举并产生新的主节点进行接管，此时，客户端仍然能继续进行访问，这保证了业务的连续性。

下面的这个过程，更准确地描述了副本集的高可用机制：

● 搭建副本集，各节点会进行初始化选举，决定谁是主、谁是备。

● 各节点都开始工作，主节点负责接收客户端写入的数据，备节点则负责复制这些数据。

● 主节点发生故障，备节点通过心跳检测到了问题。

● 某个备节点率先发起新一轮选举，一举成为新的主节点。

● 客户端感知到主节点的变化，将后续的数据写入指向新的主节点。

可以发现，在上述过程中，并没有用到任何其他的技术。相比一些需要借助第三方HA组件实现高可用的数据库来说，MongoDB自身就提供了高可用的能力。

早期版本的MongoDB使用了一种Master-Slave的架构，该做法在MongoDB 3.4版本之后已经废弃。

为了进一步理解MongoDB副本集架构，我们通常需要了解如下几个关键点：

● 选举机制。

● 实时复制。

● 故障转移。