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