[Mongodb 5.0]Replica Set副本集核心概念

• 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/】

• Non-voting
  在副本集中，通过rs.config()会看到每个节点的配置，也就是下图members数组中的内容，数组中每个节点中都有一个votes的属性。如果这个votes的属性的值为0，就说这个节点是Non-voting的。所谓Non-voting节点就是说这个节点在选举Primary的时候不具有投票权