mongodb 的副本集（replica set） ，是一组维护相同数据的进程集合，为数据提供冗余和高可用。（ high availability）
数据冗余和数据可用
副本提供了冗余和可用性。在不同的db服务器上维护数据的多份副本，针对单db服务的宕机提供了容错性。同时还可以增加读性能，因为读请求可以分散到不同的服务器中。（容灾、备份、高可用）
mongodb 的副本
一个副本集（replica set）包含几个数据节点。可选择是否有仲裁节点。在数据节点中，有且只有一个是主节点（primary ），其余是次节点（secondary）
主节点（primary node ）接受所有写请求。对于{ w: "majority" } write concern 的事务级别，一个副本集中只有一个主节点可以对其确认写完成，尽管某些情况下其他的节点会短暂认为自己就是主节点（网络）。主节点将所有修改记录到操作日志中（oplog）
更多主节点相关详见： Replica Set Primary.
次节点将主节点的oplog拷贝并执行，以保持数据与主节点一致。主节点不可用时，一个合法的次节点将发起一个选举来竞选主节点。更多次节点相关详见：Replica Set Secondary Members.
某些情况下，有一个主节点一个次节点，受制于成本无法添加一个次节点，可以添加一个仲裁 arbiter 节点。仲裁节点参与选举，但是不存放数据。关于仲裁节点更多参考：Replica Set Arbiter.
在主节点降级为次节点， 原次节点升级为主节点过程中，仲裁节点身份不变。
异步副本
次节点拷贝主节点的oplog 并异步执行其中的操作。保持与主节点数据一致，副本集可以持续运作，即使有某些节点宕机。
更多副本机制详见：
慢操作
4.2版本开始，次节点将耗时超出阈值的操作记录到oplog中，这部分日志以 applied op: <oplogentry> took <num>ms 格式保存在 diagnostic log 中。
复制延时与流控制
复制延时（Replication lag ）表示将主节点上的一个写操作拷贝到次节点的耗时。耗时小可以接受，增大时会引发严重问题，给主节点的缓存带来压力（估计是同步到了次节点后主节点才可以删，所以一直占着内存）
4.2版本后，主节点可以将 majority committed 的延时控制在 flowControlTargetLagSeconds 以下
默认情况下，流控制是打开的，此时，当延时增加至接近 flowControlTargetLagSeconds，主节点的写操作在加锁前需要先获取 票据（tickets）。通过限制一秒内可以获取的票据梳理，流控制将延时控制在指定阈值下。
更多延时与流控制详见：
自动故障转移（Failover）
当一个主节点与集群其他节点失联超过配置的 electionTimeoutMillis 时间（默认10s），一个合格的次节点发起一次选举来请求成为新的主节点。集群选出一个新主节点来恢复工作。
直到选举成功结束前，集群不能处理写操作。若查询请求配置了主节点下线时 run on secondaries ，则可以继续处理读请求。
集群选举耗时一般不超过12s，包括了将主节点标志位不可用，且发起并完成选举，可以通过 settings.electionTimeoutMillis 修改。
将 electionTimeoutMillis 从默认值 10s 降低，可以更快的检测到主节点故障，但是可能导致选举更频繁，特别是网络延时但主节点还是正常的情况。可能会导致更频繁的 w : 1 写操作回滚。
应用层逻辑应该能处理好这种故障切换和选举的情况。3.6 版本后，api可以检测到主节点的下线并自动发起一次写操作重试。
- MongoDB 4.2-compatible drivers 默认打开写重试
- MongoDB 4.0 和 3.6-compatible drivers 要手动打开写重试 通过在连接里设置
retryWrites=true
副本选举详见： Replica Set Elections
mongodb 更多故障切换过程详见：
读操作
Read Preference
默认下客户度从主节点读，但可以通过设置 read preference 在次节点读取。
异步复制 意味着从次节点读取到的不是实时的数据。
多文档事务 包含读操作的必须使用 read preference primary。一个事务中的所有操作必须路由到同一个节点。
副本集群的读取更多详见： Read Preference.
数据可见性
在 read concern 下，客户端可以在写操作持久化前看到其中的修改。
- 不考虑一次写的 write concern 配置的值, 其余使用
"local"or"available"read concern 的客户端 可以看到写操作的修改结果，即使写操作还没被多数节点接受。. - 使用
"local"or"available"read concern 的客户端可以读取到一些可能后面会因故障主备切换被回滚的数据 .
多文档事务的操作，在 提交后，事务内的所有修改都被保存且对外界可见（原子性）。
直到事务提交前，事务中的数据修改对外界都不可见。
然而对于在多个分片写的事务，并非所有外界读操作要等该事务的改动在所有 分片可见后再执行。 例如一个事务在分片A写入1，在分片B还没写入2，外部的一个 read concern "local" 可以读取到写入的1，2则看不到.
读操作隔离性、一致性、实时性详见：Read Isolation, Consistency, and Recency.
事务
版本4.0开始支持 副本集群的多文档事务
包含读操作的多文档事务必须使用 read preference primar，保证所有操作在一个节点上
知道事务提交前，事务中所有修改对外界不可见。
多分片的写，和 数据可见性 提到的一样
修改流（Change Streams）
mongodb 3.6 开始，副本集群和分片集群支持 change streams 。修改流支持应用获取到实时数据，不需要追踪oplog。应用可以订阅一个或多个数据集上的改动。
其他特性
- 副本集群的部署： members in multiple data centers
- 调整选举的优先级：
members[n].priority - Priority 0 Replica Set Members
- Hidden Replica Set Members
- Delayed Replica Set Members.
转自：Replication
60
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
