MongoDB副本集心跳和同步機制

如果兩個網段的網路發生故障，則每個網段都有兩個節點存活，他們檢視自己的對映表,不能確定對方是否已死，也不能確定自己是否能成為主節點。
如果他們各自推選出主節點，則叢集網路恢復的時候，就會有兩個主節點，資料無法達成一致。所以這個時候，MongoDB會選擇讓所有的節點只讀。

整個叢集需要保持一定的通訊才能知道哪些節點活著哪些節點掛掉。mongodb節點會向副本集中的其他節點每兩秒就會傳送一次pings包，如果其他節點在10秒鐘之內沒有返回就標示為不能訪問。每個節點內部都會維護一個狀態對映表，表明當前每個節點是什麼角色、日誌時間戳等關鍵資訊。如果是主節點，除了維護對映表外還需要檢查自己能否和叢集中內大部分節點通訊，如果不能則把自己降級為secondary只讀節點。

副本集同步分為初始化同步和keep複製。初始化同步指全量從主節點同步資料，如果主節點資料量比較大同步時間會比較長。而keep複製指初始化同步過後，節點之間的實時同步一般是增量同步。初始化同步不只是在第一次才會被觸發，有以下兩種情況會觸發：

secondary第一次加入，這個是肯定的。

secondary落後的資料量超過了oplog的大小，這樣也會被全量複製。

那什麼是oplog的大小？前面說過oplog儲存了資料的操作記錄，secondary複製oplog並把裡面的操作在secondary執行一遍。但是oplog也是mongodb的一個集合，儲存在local.oplog.rs裡，但是這個oplog是一個capped collection也就是固定大小的集合，新資料加入超過集合的大小會覆蓋。所以這裡需要注意，跨IDC的複製要設定合適的oplogSize，避免在生產環境經常產生全量複製。oplogSize 可以通過–oplogSize設定大小，對於linux 和windows 64位，oplog size預設為剩餘磁碟空間的5%。

同步也並非只能從主節點同步，假設叢集中3個節點，節點1是主節點在IDC1，節點2、節點3在IDC2，初始化節點2、節點3會從節點1同步資料。後面節點2、節點3會使用就近原則從當前IDC的副本集中進行復制，只要有一個節點從IDC1的節點1複製資料。

設定同步還要注意以下幾點：

secondary不會從delayed和hidden成員上覆制資料。

只要是需要同步，兩個成員的buildindexes必須要相同無論是否是true和false。buildindexes主要用來設定是否這個節點的資料用於查詢，預設為true。