MongoDB副本集（二）

同步
复制用于在多台服务器之间备份数据，MongoDB的复制功能是使用操作日志oplog实现的，操作日志包含了主节点的每一次写操作。

oplog是主节点的local数据库的一个固定集合。每一个备份节点都维护着自己的oplog，记录每一次从主节点复制数据的操作，这样每个成员都可以作为同步源提供给其他成员使用。oplog中按顺序保存所有执行过得写操作。每个成员的oplog都应该与主节点保持一致，可能会有一些延迟。

操作的记录：

备份节点从当前使用的同步源中获取需要执行的操作，然后在自己的数据集上执行这些操作，最后才将这些操作写入到自己的oplog中(先复制数据，再写入oplog)。如果遇到某个操作失败，备份节点就会停止从当前的同步源复制数据。

oplog大小是固定的，它只能保存特定数量的操作日志。每个受影响的文档都会有一条记录，对应oplog中一条日志。

如果备份节点远远落后于同步源当前的操作，那这个备份节点就是陈旧的。当一个备份节点陈旧之后，它会查看副本集中的其他成员，如果某个成员的oplog足够详尽，可以用于处理那些落下的操作，就从这个成员进行同步。如果任何成员都没有参考价值，那么这个成员的复制操作就会终止，这个成员需要重新进行完全同步。

为了避免陈旧备份节点的出现，让主节点使用比较大的oplog保存足够多的操作日志。

心跳请求
每个成员都需要知道其他成员的状态，因此每个成员每隔两秒就会向其他成员发送一个心跳请求。用于检查每个成员的状态，包括哪个是主节点、哪个可以作为同步源、哪个挂掉了。
最重要的功能之一就是让主节点知道自己是否满足集合大多数的条件。

成员状态
各个成员通过心跳请求将自己的当前状态告诉其他成员。常见状态包括：
1、主节点（primary）
2、备份节点(secondary)
3、startup:成员刚启动时的状态，在这个状态，MongoDB会加载成员的副本集配置。
4、startup2:整个初始化同步过程都处于该状态。对于普通成员，该状态持续几秒钟。会创建几个线程，用于处理复制和选举。
5、recovering:该状态表面成员运行正常，但是暂时还不能处理读取请求。在启动过程中，到成为备份节点之前，每个成员都会经历该状态。但一个成员与其他成员脱节时，也会进入该状态，这是成员处于无效状态，需要重新进行同步。当发现一个详尽的oplog的成员，会继续同步，回到正常状态。
6、arbiter:仲裁者处于该状态。

回滚操作(略)

客户端到副本集的连接
默认情况下，驱动程序会连接到主节点，并且将所有请求都路由到主节点。当主节点挂了之后，驱动程序会尽快自动找到新的主节点，并且将请求路由到新的节点，如果没有可达的主节点，应用程序在这段时间内不会处理任何请求（读或写）。但是，可以选择将读请求路由到备份节点。

MongoDB的写入速度太快，主节点上执行完写入操作后，备份节点还来不及跟上，可以定期调用getLastError方法，会强制这个连接上的写操作一直等待直到给定数量的成员都执行完了最后的写入操作，确保写入操作被同步到了副本集的大多数。

只有当使用了”w”选项并且最后的操作被复制到多个服务器时才会有这个字段。
设置超时时间，单位是毫秒，避免一直等待下去。如果超过这个时间还没有返回，就会返回失败：MongoDB无法在指定时间内将写入操作复制到w个成员：

超时并不意味着写操作失败，仅仅表明写操作没能在指定时间内复制到足够多的成员。写操作仍然复制到了一些成员，而且会尽快传播到其他成员。

MongoDB允许将“w”指定为任意整数，它的值包含主节点。将”w”设置为 1,相当于没有传入这个选项。传入2个成员可设置如下：

当 w的值大于开启的服务器数量，会报错：

自定义复制保证规则
副本集允许创建自己的规则，并且可以传递给getLastError，以保证写操作被复制到所需的服务器上。
首先，对副本集中的成员进行分类，添加不同的标签”tags”。

每个成员可以拥有多个标签，本例中只有一个。
创建自己的规则，在副本集配置中创建”getLastErrorModes”字段。

每条规则的形式是: “name”:{“key”:number}，其中，name就是规则名称，该名称应该表明这条规则所做的事情。客户端就是调用该名字，本例中 使用”eachDC”。
这里”key”字段就是标签的键，本例中是”dc”。number是分组的数量。

客户端使用这条规则：