此文已由作者溫正湖授權網易雲社區發布。
歡迎訪問網易雲社區，了解更多網易技術產品運營經驗。
Primary（主）是MongoDB復制集中的最重要的角色，是能夠接受客戶端/Driver寫請求的節點，（讀請求也是默認路由到Primary節點）。在復制集中，與Primary相對應的有Secondary節點和Arbiter節點，分別表示從節點（可以接受讀請求）和投票節點（僅用於投票選出新的Primary）。復制集是MongoDB的高可用框架，同時可以作為業務讀寫分離的一種方式。復制集提供了自動故障處理功能（當然還有其他功能，本文不展開），能夠自動檢測Primary節點是否宕機，進而選取新的Primary節點，並通過數據回追或數據回滾等方式實現復制集中數據一致。本文借助蜂巢MongoDB雲服務的運行日志查看功能，來簡要介紹Primary的選舉過程。
MongoDB提供了強大的SystemLog模塊，相比MySQL，MongoDB的運行日志模塊做得更為貼心，通過日志能夠有效跟蹤MongoDB內部是如何進行一個個操作的。下面的圖都截取自蜂巢MongoDB雲服務的運行日志模塊，從中能夠看到了一串的MongoDB選主日志，非常清晰明了。
1、什么時候會發起選舉？
圖中所示，該節點（我）發現在過去的10s中時間內，復制集中沒有Primary，
那么我怎么知道這段時間沒有主呢，因為我每2s會給復制集中的其他節點發送心跳，
有些節點不回我
在超時時間內（默認10s）我會一直發。
除了心跳，我還會發送其他的命令，另外我還需要跟着Primary的opLog做復制，但是我發現沒法再跟他做復制了，也找不到其他節點做復制
既然沒有Primary。。。
2、我能不能被選為Primary呢？
我先試探性的問大家願不願意讓我當Primary。於是我打算先發起 “dry election”，讓人驚喜的是另一個節點竟然同意了，開心 ：）。由於復制集中一共3個節點。除了自己外另一個節點也同意了，那么我就有資格當Primary；注意此時term 沒有更新，還是0（看第一個圖~~）。因為這個是非正式選舉
3、既然這樣，那我就發起正式選舉吧
結果當然是十拿九穩了，那么為什么要先有dry呢，為了保證選舉成功率，相比正式選舉，dry階段檢查的東西少，效率更高些。此時term已經自豪地更新為1。
4、我果然被大家選為Primary
一切盡在掌握中的感覺真爽！！
5、那我就把自己的角色切換為Primary唄
等等，這個時候我還不能馬上接受客戶端的寫請求，因為我得看看自己的數據是不是最新的，怎么辦呢，oplog里面的optime。看看大家的狀態（數據新舊情況）
我等大家回復我：
好了，節點202回我了（他把他自己的rs.status()發給我， 看看在他的世界里這個復制集是什么情況），（200連不上），從這些信息我可以知道，我的數據是最新的。而且我從202知道200確實掛了。
6、既然我的數據是最新的，那么我就不需要從其他節點拷貝數據了
這里跟raft不一樣，從raft的論文中，可以確定raft選為primary是必須要求數據最新的。但MongoDB選出的Primary，數據不一定要最新，只需要滿足一個約定條件即可（oplog落后10s以內）。如果數據落后集群中的某個/些存活節點（這個情況一般出現在當前節點的priority比擁有更新數據的節點高的時候），在我對外提供寫服務前，我先把這些數據從其他節點從抓過來，應用到我自己這里。但是我這個是有原則的，我不會那么貪婪，給我2s（catchUpTimeoutMillis）就好了。我能追上多少就追多少。如果時間到了，我還沒有完全追上咋辦呢，那也沒有辦法，讓這些節點把沒追上的數據回滾掉好了。
7、現在我的數據是最新的了，我開始作為Primary對外提供寫服務。你們把寫請求發過來吧~~~
也就是說，並不是成為Primary后馬上就會提供寫服務，而是會有個追數據的過程。我覺得這個特性如果大家么有正確理解，很容易出現問題。比如用戶設置了writeconcern是majority，在主從切換的場景下，可能還未寫到大多數節點的請求因為主掛了返回失敗，但其實這個數據會被持久化到新主上。而嚴格的raft不會出現這個情況。
以上用第一張圖大體介紹了選舉過程。然后每一點的仔細介紹時，我將MongoDB的SystemLog級別通過db.setLogLevel()從0設置為2，重演了一遍選舉。讓大家看到更多的細節。
最后安利下，網易蜂巢MongoDB雲服務已經重磅上線，蜂巢MongoDB由業界著名的數據庫專家姜承堯親自把關架構設計，免費提供售前技術支持。要知道姜大神的出台費可是業界最貴的 ：），歡迎大家注冊試用。有任何意見和建議，請隨時提出。
網易雲免費體驗館，0成本體驗20+款雲產品！
更多網易技術、產品、運營經驗分享請點擊。
相關文章：
【推薦】 流式處理框架storm淺析（上篇）
【推薦】 視覺設計師的進化
【推薦】 白木彰：具有普遍性的設計力