- Primary
副本集中的主节点，副本集中只能通过Primary写入数据 - Secondary
副本集中的从节点，主要备份Primary节点的数据。
?Secondary通过Primary的oplog将数据复制到自己上面数据只能先写到Primary->Secondary同步到自己身上->读数据既可以从Primary也可以从Secondary，但是默认只能从Primary读，可以设置【Read Preference】实现从Secondary也可以读数据如果Primary不可用了，便会从其他的Secondary中选出一个作为Primary（技术是Secondary而不是Arbiter，注意两者区别，Arbiter只用于进行投票选举）
关于Secondary的一些特殊配置
1.可以设置Secondary不成为Primary【一般方法就是设置Priority为 0】（参考Priority 0 Replica Set Members.）
2.可以设置Secondary不提供对外读数据的功能，这样的目的主要是为了让这个Secondary只负责保存数据用（参考 Hidden Replica Set Members）
3.可以将将其作为历史备份使用，以防止其他节点误删除数据库的现象 -
Arbiter
在副本集中如果没有Arbiter，那么只有Primary和Secondary的情况下，当Primary不可用时，就可以自动从Secondary中选举出一个作为Primary，但是会出现无法不确定谁来最为Primary的情况，
比如每个Secondary都有2票，就不能确定到底谁来成为Primary了，这时就用到了Arbiter，他把自己手上的那一票给哪个Secondary，哪个Secondary就可以成为Primary。由此看出了Arbiter唯一的作用
就是头上这一票（一个Arbiter只有一票），除此之外没有其他的作用，所以在副本集中Arbiter不能存数据，只能投票。
知识点：
1.如何添加一个Arbiter？
2. Arbiter带来的问题点？Arbiter不存数据，但是会占用一个节点的位置。那么在writer:majority的时候，会影响Primary的效率问题。所以不要在一个副本集设置多个Arbiter -
Priority 0 Replica Set Members
表示在副本集中它是一个不能成为Primary并且不能参与选举的节点。但是他可以做下面两件事情：
1.他只能将Primary中的数据备份到自己这里了
2.他虽然不能进行选举，但是他可以进行投票一个Secondary如果Priority 0了，那么这个Secondary节点就只能做以下的事情：
1.备份Primary上的数据
2.可以从他上面读数据
3.可以进行投票使用场景：
一般如果这个节点离着其他节点很远，容易出现延迟的情况下，就将它设置为Priority 0.
有些时候，无法后期添加节点，那么前期可以先将这个节点加上然后Priority 0，先作为备用，后期如果有那个节点不可用时，可以直接将其Priority 1，来接替不可用的节点。 -
Hidden Replica Set Members
隐藏副本集中的节点，隐藏后，这样的节点只能备份数据，不能参与选举Primary，但是可以进行投票，另外这样的节点是不能通过客户端设置读属性（就是可以从Secondary上读数据）。
db.hello()方法不会显示出Hidden的节点。场景：
1.延迟大的节点，可以让他变为Hidden -
Delayed Replica Set Members
专门用作延迟备份Primary中数据的节点，所谓延迟指的是在一定时间后，再回复Primary自己已经完成了备份操作
场景：
1.10点要版本更新，那么为了10点到11点这段时间mongodb中存入错误的数据，可以设置一个Delayed Replica Set Member，让他延迟1个小时再去备份数据，也就是让他11点之后再去讲Primary的数据
同步到自己身上。这样玩意10点到11点之间数据库出现问题了，就可以用这个延迟节点上的数据进行数据恢复用（这个数据恢复就是官网的"rolling backup" or a running "historical"）。要成为延时节点，必须满足下面2个条件
1. Must be priority 0 members
2. Must be hidden members.
3. 必须是一个可以投票的节点 -
Replica Set Oplog
就是一个文件，里面记录了Primary上所有对数据库的CURD操作语句
oplog的保存期是以小时为单位的。当出现下面两种情况，会自动删除oplog中的内容：
1. 文件大小超过了设置的最多size
2. 达到了设置的保留时间 -
Write Concern for Replica Sets
Write Concern主要用于Primary在执行写操作的时候，与其他节点（可以投票的节点）进行确认的一个事情（有点类似于tcp中的三次握手的ack操作）。就是指副本集中有多少个节点反馈你已成功写入的信息，然后就可以继续下面操作的一种策略。例如常见的w:majority,那么例如5个节点中，有超过2个节点都反馈给你以已成功写入数据
那么你就可以继续下面的操作了，否则你会一直堵塞。Write Concern中的journal是跟什么时候持久化有关
j，该参数表示是否写操作要进行journal持久化之后才向用户确认；
{j: true} 要求primary写操作进行了journal持久化之后才向用户确认；
{j: false} 要求写操作已经在journal缓存中即可向用户确认；journal后续会将持久化到磁盘，默认是100ms；通过官网中的例子，来理解这个概念：
当通过app或者client端执行了一个写操作时（insert，update等），Primary会先堵塞住，然后等待接收其他节点的确认反馈，看其他节点是否同时得到了 client端要进行一个写操作的消息。
如果我们用的是w:majority，那么只要大多数的节点讲接收到的写操作的确认信息反馈给Primay后，Primary就可以继续执行后面的操作了。 -
Read preference
用于改变从什么节点读取数据，默认是从Primary上读，通过这个设置可以改为从Secondary上读【关于具体的选项参考https://www.mongodb.com/docs/manual/core/read-preference/】
