【mongoDB】副本集

1.mongoDB的副本集

副本集市传统主从复制的一种复杂形势，并且是mongodb部署中的一种推荐方法。
副本集实际是主从复制的一种类型，但他们提供了自动化故障转移。
副本集中的一个主节点关闭了，那么其中一个从节点就会被自动提升为主节点。
客户端会开始连接到这个新的主节点。并且数据和应用程序都保持可用。
主副本节点时通过一种选举机制来选择的，如果主副本关闭了，
那么所选举的节点将被选中为主副本节点。

故障转移步骤：
1.主副本关闭，辅助副本被提升为主副本。
2.最初的主副本恢复，它会充当从节点，并且变成辅助副本节点。

需要注意的是：
1.副本集市Mongod的集群，它会在彼此之间进行复制，并且确保自动化故障恢复。
2.在副本集中，一个mongod将会是主副本成员，而其他的将是辅助副本成员。
3.主副本成员是由副本集的成员选举出来的，所有的写入都会被指向该主副本成员，而辅助
副本成员会从主副本异步使用oplog进行复制。
4.辅助副本的数据集会反射主副本数据集，让他们可以在当前主副本不可用的情况下被提升为主副本。

副本集在成员数量上有一个限制，在3.0之前，限制为12，3.0中这个限制改为50.
因此限制副本集复制只能拥有最多50个成员。并且在50个成员的副本集中，在任意指定时点。
只有7个成员可以参与一次投票。

从3.0开始，副本集成员可以使用不同的存储引擎。
例如WireTiger存储引擎可用于辅助副本成员，而MMAPv1引擎可用于主副本。

1.主副本和辅助副本成员。
主副本：
副本集只能具有一个主副本，它是由副本集中的投票节点选举出来的。任何所关联的优先级为1的节点
都可以被选举为主节点。客户端会将所有的写操作重定向到主副本成员，然后它会被复制到辅助副本成员。
辅助副本成员：
常态的辅助副本成员会保留数据副本，该辅助副本成员可以投票，也可以作为在当前主副本发送故障
时被提升为主副本的候选。

2.辅助副本成员的类型。
0优先级成员：
就是保留主成员数据副本但永远不会在故障转移时成为主副本的辅助副本成员。
可以通过参与投票以及接收读请求。可以通过设置优先级为0来创建0优先级成员。
0优先级成员作用如下：
1.充当冷备份。
2.在使用各种硬件或呈地理分布的副本集中，这一配置可以确保只有合格的成员能被选举
为主副本。
3.在跨网络分区的多个数据中心的副本集中，这一配置可以帮助确保主数据中心具有合格的
主副本。这杯用于确保快速的故障转移。

隐藏成员：
就是客户端不可见的0优先级成员。可以复制数据副本，它只能参与投票，不可被读数据。
通过将hidden属性设置为true来将一个节点设置为隐藏成员。可以用于报告需求或备份。

延迟成员：
就是从主副本的oplog延迟复制数据的辅助副本成员。有助于从认为错误中恢复数据
可以根据维护窗口设置延迟时间。它的hidden 属性也是true;

仲裁者：
不持有主节点数据副本的辅助成员，因此它绝不会成为主节点。仅用作投票。
这使得副本集可以具有奇数的节点数量，而无需任何会带来数据复制的复制开销。

非投票成员：
会持有主节点的副本数据，可以接收客户端读取请求，可以变成主副本，但不能参与投票。
可以通过设置一个成员的选票为0来禁用该成员的投票功能。默认，每个成员都可以投票。

假设有一个7个成员副本的副本集。设置4,5,6成员不能投票。
cfg_1=rs.conf() 
cfg_1.members[3].votes=0
cfg_1.members[4].votes=0
cfg_1.members[5].votes=0
rs.reconfig(cfg_1)
他们可以成员主副本，但是不能投票。


3.选举。
如果有x台服务器。至少有(x/2)+1 张票，它才可以成为主节点。

被选举的成员会检查自己是否具有被选举的资格，如果有被选举资格，则向其他节点发送投票请求。
其他节点检查被选节点是否具有资格，是否保留最新的数据，是否还有其他几点保留最新的数据。
如果有一个成员停止选票，则被选成员竞选失败。

mongodb是即发即弃的，在降级时会丢失数据，所以需要使用安全的写操作，即发送降级时，
向客户端发送套接字错误，然后客户端重新选举主副本写入。

4.数据复制过程。
每个副本成员包括主副本成员，都会维护一个Oplog;oplog代表操作日志，是一个固定集合，
记录了所有修改数据的操作。oplog是在一个特殊的数据库中维护的，位于集合oplog.$main中。
每一个操作都被当做一个文档。该文档包含以下键：
ts:这会存储操作的时间戳。由4个字节的时间戳和4个字节的递增计数器构成。
op:操作类型。一个字节的代码。例如插入：I 
ns:集合的命名空间。
o:被执行的操作。

只有修改数据的操作才会在oplog中维护，因为它是确保辅助节点数据与主节点数据保持同步的
一种机制。
oplog中存储的操作会被转换，这样他们就是保持幂等，也就是即使被应用到辅助节点多次，
辅助节点的数据也任然保持一致。由于oplog是一个固定集合，会添加每一个新的操作，
因此最老的操作将被自动删除，这样就确保不会超出oplog大小限制。

在MongoDB中，默认可用空间或5%的空间被用于实例上的oplog;
如果可用空间小于1G，MongoDB会分配1G的空间。
可以在启动MongoDB时使用 -oplogsize 选项指定oplog的大小。

如果有以下情况，需要考虑oplog大小。
1.同时对个文档进行更新。
2.以相同速度发送的涉及等量数据的删除和插入。
3.大量就地更新。

初始化同步。
1.克隆数据。
2.使用源节点oplog，应用oplog 
3.集合上重构索引。

同步。
1.将op应用到副本集。
2.将op写入本地oplog ,如果失败，重新请求。
3.请求下一个op 

由于oplog操作是幂等的，可以被应用任意次数，且每一次结构都相同。

启动。
检查辅助部分最后一次应用的时间。
sql>rs.debug.getLastOpWritten()     

如果没有找到ts:则该节点执行初始同步操作。

--检查被选举为同步源的服务器。
sql>db.adminCommand({replSetGetStatus:1})   

mongodb支持一下读取偏好。
Primary：默认模式，所有的读取请求都路由到主节点。
primaryPreferred:优先从主节点去取，主节点不可用时从辅助节点读取。
secondary:从辅助成员读取。
SecondaryPreferred:优先从辅助节点读取，辅助节点不可用从主节点读取。
nearest:从最近的副本集成员读取。

可以在辅助节点上执行辅助操作，而永远不会影响主节点的性能。