MongoDB - 复制集
架构
复制集(replica set)提供了数据冗余和高可用。它是一组mongod进程。
一个复制集里面有很多数据节点（data bearing node）和一个可选择的仲裁节点（arbiter node）。数据节点的角色也分为主节点（primary node）从节点（secondary node）。所有写操作都是在主节点上的，并记录oplog（operation log）。从节点通过主节点的oplog重放来保持数据的最终一致性，这个“主从复制”是异步的。当主节点挂了，二级节点会进行新的选举（基于Raft算法），从中找一个二级节点来充当主节点的角色。仲裁节点只负责参与选举，而不存储数据。
MongoDB推荐的最小架构是：一个主节点，两个二级节点(不推荐使用仲裁节点)。最大可以有50个成员节点，但是只有7个是voting member。
仲裁节点有一票的选票，优先级为0（priority为0）。仲裁节点不推荐使用，一般是为了保证不出现平票，奇数个结点才存在的。
复制集选配
可以给复制集的节点设置以下选配项：
- 是否可以参与投票(参数v)，默认是可以的
- 优先级（priority参数），优先级较高的节点优先成为主节点；优先级为0的节点，不能成为主节点，也不能发起选举，但是有一票选票（
members[n].votes > 0）。一般来说优先级为0的节点部署得会离主要部署点较远，如下图，所以有较高的延迟latency,不能很好地充当主节点的角色，但是对于local read性能较好。
对于一些特殊场景，复制集还能设立隐藏节点或者延迟节点。
- 隐藏节点（hidden参数）将不会有任何reads和writes的traffic,
db.hello()也不会展示隐藏节点，一般用来上报一些信息或者作为备份。 - 延迟节点（slaveDelay参数），存储的数据备份比正常的数据晚一段时间（复制n秒前的数据），延迟节点需要设置为隐藏，且优先级为0。
日志 Oplog
Oplog是一个特殊的capped collection。二级节点通过主节点记录的Oplog来实现数据复制, 他们保存在local.oplog.rs。Oplog记录的是对数据的操作，且这些操作是幂等的，也就是执行一次和很多次是结果一样的。
Oplog 大小 (Unix & Windows)
| Storage Engine | Default Oplog Size | Lower Bound | Upper Bound |
|---|---|---|---|
| In-Memory | 5% of physical memory | 50MB | 50GB |
| WiredTiger | 5% of free disk space | 990MB | 50GB |
Oplog 保留期
mongod将删掉Oplog如果它的大小超过上限或者存在的时间超过参数oplogMinRetentionHours
数据同步
主要有两种同步方式：
- 当加入一个新的二级节点时进行数据初始化，是全量数据同步
- 运行期间对于数据的变更进行增量同步
数据初始化
初始化的节点会根据一系列规则选择一个source来进行数据同步。3.4过后的初始化将会建立一致的索引。初始化同步完成，该节点的状态由STARTUP2转为SECONDARY。
增量同步
二级节点的同步是异步的，且开启了多个线程并行复制。4.4过后MongoDB传送Oplog是流式一直发送的，用来减少同步延迟。
默认情况是会根据一些规则从复制集中选一个出来当source来同步，但如果chaining设置为disabled就会选主节点来同步。
故障转移
默认发送心跳的周期是2s, 心跳检测的默认值(electionTimeoutMillis)是10s。超过这个值，二级节点还没有收到主节点的心跳，那么就会开启自动故障转移(automatic failover)，选举一个新的主节点。在这个选举过程中，是不支持写操作的可以支持打到二级节点上的读操作的。选举过程耗时的中位数大概是12s。
选举
触发选举的条件
- 向replica set内加入新的节点
- 初始化replica set
- 人为维护，使用
rs.stepDown()方法等 - 某个从节点丢失和主节点的心跳连接，默认是5次心跳未收到。
选举的规则
就是根据节点的vote和priority等信息，票数最高且超过一半成员支持的节点成为主节点。如果票数相同，则谁同步数据快（oplog较新），谁胜利。
读写分离
基于这个架构，我们可以把一些读操作放到二级节点上，来做到读写分离。
