DAY17 MongoDB Replication 观念

本系列至今都是介绍 MongoDB 在单一实体运作的状况，我们称为 standalone，从今天开始将介绍多个实体共同运作的模式，称为 replication。

Replication

Replication，MongoDB 的强项之一。

透过 Replication 功能，可以将数个 MongoDB instance 组成一个群体，并且拥有一样的资料，透过这样的组成，提升资料的备份、安全性以及高可用性(Data redundancy, availability)。另一个好处就是读写分离。

架构

首先我们来看架构图，

(reference: https://docs.mongodb.com/manual/replication/)

从上图可以看到要形成一个 replication 至少需要 3 个 MongoDB 实体，一台为 Primary 另外两台为 Secondary。

MongoDB 的 Replicatioh 最多共有 50 个成员，有投票权的最多仅有 7 个，剩下的是无投票权的次节点。所以请记得 replication 实体数量请保持奇数。

Replication Members

• Primary:
  Replication 同一时间仅会有一个Primary节点，这主节点负责所有功能(CRUD)，而资料异动类型的(Insert, Update, Delete)会额外产生修改历史纪录并写入oplog(目前仅需要了解这是纪录资料修改异动的历史纪录即可)。

• Secondary:
  次节点，它们负责几件事：

  1. 不断向主节点请求资料同步
  2. 每个节点间相互发送 heartbeat，确保存活状态
  3. 当主节点失效时，次节点会推选出下一个主节点并继续运作
  4. 次节点资料读取

• Arbiter:
  其实在 replication 中还有第三个角色，这个角色的设计是避免高成本或者硬体资源不足用的。arbiter 只负责进行上面的 2, 3 两项工作，不涉及任何资料面的运作，也意味着它仅会负责投票选下一个主节点，永远不会成为主节点。此角色非必须。

在 member 身份中，还有一些比较进阶的设定，例如设定 priority 为 0，这意思是不会在选举过程中成为主节点，永远是一个次节点提供资料同步以及读取的服务。

下一个是隐藏会员(hidden member)，这个设定不仅是要 priority:0，还不会出现在一般查询指令中，通常这样设定是即将把这个节点下架或者专心做资料备份使用，备份到另一个地方之类的，

Failover

上面提到当主节点失效时，次节点群会进行投票动作，选择下一个主节点。而判定的方式就是心跳(heartbeat)没有回覆。

心跳未回覆的失效判定预设为 10秒，没有得到节点回覆，会判定失效。选出下个主节点期间(过程预设为 12秒)，针对主节点的任何操作将会直接被判定为失败，次节点的读取则不在此限制。

在写文章时的当前版本 (5.0.3)，都已经具备重写功能，也就是当修改资料的操作遇上 failover，MongoDB driver 能够知道这个状况，并且当新主节点出现时，进行重试的操作。

以上的时间以及频率都能分别设定。

ReadPreference

上述还有提到一个观念是次节点的读取，在 MongoDB 叫做 ReadPreference。每一个读取都能够设定此项目，如下图：

(reference: https://docs.mongodb.com/manual/replication/)

适用在一些不需要最即时更新的资料读取，适度地减少主节点的负担。

额外提一个观念，在多文件交易(multi-documents transcation)中，是强制在主节点执行的，目前还没办法支援次节点。

MongoDB Replication 概念应该就先提到这就好，再讲就会太深入了，不太适合在 30 天挑战赛出现(估计是没人要看XD)，再来就可以进入实作的部分了。

本系列文章会同步发表於我个人的部落格 Pie Note