自從10 gen用Replica Set取代Master/Slave方案后生活其實已經容易多了，但是真正實施起來還是會發現各種各樣的小問題，如果不小心一樣會栽跟頭。
在跟Replica Set血拼幾天之后，筆者寫下以下的血淚史，供大家參考。
背景知識
Replica Set的目標是取代Master/Slave方式成為MongoDB新的集群組織方式，目前已經適合生產環境使用。
原理上二者差不多，都是通過local庫中的oplog存放操作日志，再重做日志而把操作復制到新的實例上。
按照官方說法，Replica Set提供了更穩定的運行效果，操作更容易，並且提供自動故障恢復特性。相比之下，Master/Slave集群能夠勝出的只有“能夠容納更多實例”這一條。原因是前者為了保證實例之間能夠互相了解生存狀態，需要兩兩交換心跳（每2秒1次，可以從日志中看到）。這就要求構成一個n(n-1)/2條路徑的網絡，使得集群額外增加了通訊負擔，特別是在集群成員數量巨大的時候將會造成先顯著的影響（當然通常情況下是不需要把集群做到這種規模的）。作為交換，Replica Set則夠提供了新的故障轉移特性。
故障轉移介紹
故障轉移是通過不同結點之間的角色切換達到的。角色分為三種：Primary，Secondary和Arbiter。顧名思義，Primary是主結點，可進行寫入操作。操作日志從Primary向各個Secondary同步並重做達到數據復制的目的。當Primary出現故障時，集群成員會選舉其中一個Secondary成為新的Primary。而Arbiter則是一個只參與投票的結點，不復制實際的內容。
影響選舉進行的因素包括：
1. 心跳
心跳每2秒進行一次，如果在10秒（5次）內沒有收到一個結點的心跳，則認為這個結點已經死亡，需要選舉新的Primary結點。
2. priority配置
每個結點都具備Priority設置，默認為1。可以通過以下命令查看
rs.conf()
可能的情況下，集群結點總是選舉優先級最高的結點成為新的Primary。優先級0是特殊配置，這樣的結點不會成為選舉的候選結點（如Arbiter結點）。
當集群中出現了優先級比當前Primary更高的活躍結點時，會發生重新選舉，而無論當前Primary是否存活。所以如果之前死亡的高優先級Primary結點恢復工作，並同步完所有操作日志，會馬上發生選舉使它重新成為Primary。
這在某些情況下會造成問題，因為Primary角色會在不同結點之間來回切換，而切換過程中集群會有短暫的不可用時間。把所有結點的優先級設置為相同則可以保證選舉發生的次數更少，但這也不能說一定是件好事。總之沒有最好的方案，只有最合適的方案。
3. optime（最后同步時間）
一個結點的最后同步時間必須是最接近Primary的，才有參與選舉的資格，否則即使priority高也不行。
所以可以想象在群集中可能發生這樣的狀況：
Primary A死亡后，Secondary B具有更高的優先級，但同步時間比不上Secondary C。因此C會被優先提升為Primary。此后B從C處同步了最近的操作日志，成為了具備最高優先級，並且操作日志也最新的結點，因此B會成為新的Primary，C降級為Secondary。
當然在同一個網絡中，這種情況發生的可能性不高。異地機房則更有可能發生。
4. 投票
一個要成為Primary的結點必須得到集群中大多數成員選票。這里的多數成員並不是指的集群成員的數量，而是指參與投票的成員數量。
所以在3個成員的集群中，一個Primary死亡后，另外兩個Secondary會產生出一個新的Primary。而如果2個成員死亡，剩下的一個會保持Secondary身份，因為得不到其他成員的投票。如果剩下的成員是Primary，則它會降級為Secondary。
要注意對於其他成員是否死亡的判斷是相對的，一個結點只能判斷死亡的結點對自己已經不可見，但是否真的死亡並不確定。也可能是自己從網絡中脫離而造成自己對所有人都不可見。MongoDB必須保證任何時候任何情況都只能有一個Primary，因此對於升級的判斷也是保守的，寧可不升級為Primary，也不可以讓多於一個Secondary升級為Primary（會造成不可逆轉的錯誤）。
要小心集群只剩一個成員的情況，它極有可能變成一個只讀的集群，這對生產環境來說是災難性的。以后的篇幅會講如何處理這種情況。
5. 網絡划分
如果Primary死亡的時候沒有一個Secondary得到足夠的選票，則集群會變為只讀的。因此多數結點應該位於同一個數據中心，避免因為數據中心間的網絡故障造成集群變為只讀。
從以上問題可以了解到Arbiter的必要性，它的存在可以解決極端情況下集群成員無法投票決定新的Primary的問題。
下一篇將會講解Replica Set的實際操作情況。
參考文獻：MongoDb Manual