---

數據庫分布已經是當下互聯網的標準配置。原來單節點標準配置，一臺web服務器，一臺數據庫服務器的1+1模式，可以應對一個小公司或者少量的訪問量。而隨著服務的提升，對于7×24×365的高可用性的要求的需求，以及訪問量的增大我們的1+1的模式早已不能滿足需求，單點故障早已不允許在當下的系統中，大并發的訪問也不能輕易搞死系統，那么就有了服務器的cluster，數據庫的分布式，使得對于訪問服務器的用戶來講使用體驗是透明的，而面的服務到底是誰來給提供的就變得“飄忽不定”起來。

在接觸mongoDB之前，接觸過mysql以及oracle的rac，對于分布式有一定的了解。不過真正自己配置Replicaset還是拿mongoDB進行了落地。原因是，mongoDB首先很輕巧，配置很簡單，用戶界面雖然全都是Command但是并沒有復雜得讓人抓狂的程度（比如從最初下載CentOS開始配置Hadoop環境那么麻煩。。），一切都是手到擒來，一氣呵成的感覺。不得不說mongoDB的配置以及應用對于現在的快速迭代以及變化多端的需求運用場景來講都提供了很好的支持，使得原來做關系數據庫那么教條的范式思路在mongoDB中就顯得有些古板了，呵呵。

首先，先來介紹一下mongoDB的Replica set的一些基本的對象。以下和未來Replica的內容大部分來源于官網，例子有書上的也有官網的。因為我讀書后發現其實官網的順序以及講解更好一些。

Primary

Replica set翻譯過來叫做副本集，也就是相當于備份。那么有備胎就要有正選咯？是的。mongoDB的結構按照官方網站的圖片來說是醬的：

從圖中可以看出，只有正選的“Primary”才可以接受Writes寫和Reads的請求，而所有的Secondary的備胎們，只能作為仆人去Read。思路來說的話也很簡單也很常規，就是Primary去接受所有的Write然后存成log，所有的Secondary去讀這些log來備份數據。如下面的mongoDB的官網的解釋：

Primary?
The primary is the only member in the replica set that receives write operations. MongoDB applies write operations on the primary and then records the operations on the primary’s oplog. Secondary members replicate this log and apply the operations to their data sets.
In the following three-member replica set, the primary accepts all write operations. Then the secondaries replicate the oplog to apply to their data sets.

對于寫，只能去向Primary請求，默認的，所有的讀操作也是先請求到Primary的。不過也可以通過修改設置來直接讀Secondary的數據。另外，Primary是可以動態改變的，當一個Primary已經變得不可用，那么剩余的Secondary可以通過選舉選出一個Secondary作為新的Primary來用（嗯。。。充分體現了民主-v-）。

Secondary

嗯，所有的后宮都在這里了。順便說下，mongoDB的Replica Set不是無窮盡的，最多只支持12個成員。12個成員都是什么成員之后再說。那么，對于所有的Secondary來說，最根本的任務就是從oplog中讀取Primary過來的所有寫操作，而且上文也說過，在Primary掛掉的時候，不會后宮大亂而是理性通過投票機制選出來一個Primary來繼續統領，整個操作對客戶端來說都是透明的。通過一些設定，可以限制或者指定Secondary的動作行為，來自官網的解釋：

You can configure a secondary member for a specific purpose. You can configure a secondary to:
?Prevent it from becoming a primary in an election, which allows it to reside in a secondary data center or to serve as a cold standby. See Priority 0 Replica Set Members.
你可以人為阻止Secondary參加選舉（類似于剝奪你的政x權利），也就是不讓這個Secondary有機會參選為Primary。成為一個被打入冷宮（cold standby）的純粹的備胎。
?Prevent applications from reading from it, which allows it to run applications that require separation from normal traffic. See Hidden Replica Set Members.
阻止客戶程序去讀取這個節點，使得這個節點變成隱藏透明狀，不參與到外面的混戰操作中，不被外界打擾，踏踏實實做一些自己要執行的操作。
?Keep a running “historical” snapshot for use in recovery from certain errors, such as unintentionally deleted databases. See Delayed Replica Set Members.
可以定義歷史快照，當你不小心誤操作或者搞壞你的db，通過這些快照點來恢復你的數據。

Arbiter

這個比較拽了。既不是領導者也不是跟班的，不參與任何對于數據的存儲或者分布的操作，僅僅是一個仲裁機構。試想這種場景：1個Primary帶著4個Secondary在玩耍，突然，Primary駕崩，其中4個Secondary中被投票成為Primary的Secondary的得票是2：2，咋辦？。。。（其實，這個2v2的結果還有深層次的意思和意義，這也是我剛開始理解mongoDB的副本不到位的地方，后面會詳細闡述這個數字的的意義以及奇數偶數副本節點的概念）這個時候，Arbiter的作用就來了，隨便給哪一方一票，得票方就成為新的Primary了。這就是Arbiter的作用。只管投票，沒有當選和執行其他事物的權利。當然，如果你加入了一個Arbiter那使得你的members成為了4個，那么你的選舉就變成了Tied election，自己給自己找麻煩哦。所以，一般來說我們還是喜歡用奇數個成員來直接出選舉結果的，而不使用Arbiter，這也是mongoDB的建議。

つづく??

總結

以上是生活随笔為你收集整理的mongoDB的读书笔记(04)_【Replica】(01)_Replica的一些基本概念的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。