前文我們搭建MongoDB三成員副本集，了解集群基本特性，今天我們圍繞下圖聊一聊背后的細節。
默認搭建的replica set均在主節點讀寫，從節點冗余部署，形成高可用和備份，具備自動故障轉移的能力。
集群心跳保活
集群每個節點以周期性向其他成員發出心跳命令 replSetHeartbeat來獲取狀態，
根據應答消息來更新節點的狀態，根據最終狀態確定是否重選主節點。
默認心跳周期 heartbeatIntervalMillis= 2000ms；
認定Primary節點失聯的閾值 electionTimeoutMillis=10s
選舉主節點
集群會因為各種事件觸發選舉主節點
-
在集群中添加新節點
-
初始化replica set集群
-
執行人工運維命令（rs.stepDown() rs.reconfig()）維護集群
-
從節點與主節點失聯時間超過默認10s
自動故障轉移說的是最后一種情況：
默認情況下，從節點A與主節點心跳失聯超過10s，A節點標記主節點不可用；
與其他從節點心跳保活，溝通各自信息（節點的票數、節點優先級、PingMs等因素）確立出新主節點。
在發生故障轉移時，集群不能再執行寫入操作； 如果你在客戶端配置了在從節點的讀取首選項 read preference，則集群可繼續提供讀取能力。
你的應用程序可用重試邏輯應對自動故障轉移和后續的重選，從MongoDB3.6版本開始，MongoDB Driver可偵測主節點的失聯，並執行一次重試操作。
適配MongoDB4.2的Driver默認會重試寫入操作；
適配Mongodb4.0-3.6的Driver需顯式在連接字符串包含retryWrites = true，以確保主節點失聯時能重試寫入操作。
連接副本集的客戶端配置字符串，其中rs0是配置文件中設置的副本集名稱 replSetName
mongodb://account:passward@mongodb0.example.com:27017,mongodb1.example.com:27017,mongodb2.example.com:27017?replicaSet=rs0
OK， 以上便是MongoDB副本集心跳保活、異步復制、自動故障轉移的背景知識。
異步復制
從節點復制主節點的oplog，並將改變應用到數據集，從而保持與主節點數據同步。
這里有三個知識點：
-
oplog是一個特殊的封頂集合capped collection， 主節點上的operation log會記錄在主節點的oplog中，從節點異步拷貝這些操作，這樣所有的節點的都包含operatin log的一個副本：local.oplog.rs集合
-
每次異步復制觸發的時機是在心跳保活階段，所有的從節點都會在ping階段從其他成員插入oplog文檔。
-
oplog中的每個操作都是冥等的：無論是一次還是多次應用到目標數據集，oplog操作會產生相同的結果
刪除和插入操作：
若多次應用刪除操作，后續刪除操作無效果；
若多次應用插入操作，因為每次操作均包含_id值，因此它也不會插入文檔的第二個副本（因為_id必須是唯一的）。
當有新節點加入集群，該節點會啟動另一種同步：initial sync, 將所有數據從副本集一個成員拷貝到另外一個成員， 復制完成，將過渡為從節點。
留一個作業？
客戶端連接MongoDB副本集的連接字符串，只是一個很普通的IP數組，
- 並未體現主從節點， 客戶端是怎么區分主副節點，並向主節點發出寫入指令？
- MongoDB集群發生故障轉移后，客戶端又是如何再次識別出主從節點？
這就涉及到客戶端Moninoring, 所有遵守MongoDB官方規范的Driver都會實現 Service discovery和Monitoring :
我們在連接字符串指定的IP節點其實是種子節點，Driver會准實時監視集群，獲取集群最新的狀態信息。（heartbeatFrequencyMS 約定了客戶端Driver檢查集群狀態的時間間隔）
這也與我在MongoDB 從節點看到的日志相互照應， 這也說明了 MongoBB故障轉移並不只是服務端的事，客戶端Driver 也為我們做了不少的事情。
+ https://github.com/mongodb/specifications/blob/master/source/server-discovery-and-monitoring/server-discovery-and-monitoring.rst#heartbeatfrequencyms
+ https://docs.mongodb.com/manual/reference/connection-string/#urioption.heartbeatFrequencyMS