同步

MongoDB的復制功能是使用操作日志oplog實現的,操作日志包含了主節點的每一次寫操作.

這樣,每個成員都可以作為同步源供給其他成員使用

備份節點從當前使用的同步源中獲取需要執行的操作,然后在自己的數據集上執行這些操作,最后再將這些操作寫入自己的oplog

初始化同步

副本集中的成員啟動之后,就會堅持自身狀態,確定是否可以從某個成員哪里進行同步

如果不行的話,它會嘗試從副本的另一個成員那里進行完整的數據復制.這個過程就是初始化同步(initial syncing)

處理陳舊數據

如果備份節點遠遠落后于同步源當前的操作,那么這個備份節點就是陳舊的(sale).

當一個備份節點陳舊之后,它會查看副本集中的其他成員,如果某個成員的oplog足夠詳盡,可以用于處理那些落下的操作,就從這個成員處進行同步

如果任何一個成員的oplog都沒有參考價值,那么這個成員的復制操作就會中止,這個成員需要重新進行完全同步(或者從最近的備份中恢復)

為了避免陳舊備份節點的出現,讓主節點使用比較大的oplog保存足夠多的操作日志是很重要的

心跳

每個成員每隔兩秒鐘就會向其他成員發送一個心跳請求(heartbeat request)

心跳請求的信息量非常小,用于檢查每個成員的狀態

STARTUP

成員剛啟動時處于這個狀態.在這個狀態下,MongoDB會嘗試加載成員的副本集配置.配置加載成功之后,就會進入STARTUP2狀態

STARTUP2

這個初始化同步過程都處于這個狀態,但是如果是在普通成員上,這個狀態只會持續幾秒鐘.在這個狀態下,MongoDB會創建幾個線程,

用于處理復制和選舉,然后就會切換到RECOVERING狀態

RECOVERING

這個狀態表明成員運作正常,但是暫時還不能處理讀取請求.如果有成員處于這個狀態,可能會造成輕微的系統過載,以后可能會經常見到

啟動時,成員需要做一些檢查以確保自己處于有效狀態,之后才可以處理讀取請求.

ARBITER

在正常的操作中,仲裁者應該始終處于ARBITER狀態

系統出現問題時會處于下面這些狀態

DOWN

如果一個正常運行的成員變得不可達,它就處于DOWN狀態,如果網絡有問題,狀態可能是DOWN狀態

UNKNOWN

如果一個成員無法到達其他任何成員,其他成員就無法知道它處于什么狀態,會將其報告為UNKNOWN狀態

通常,這表明這個未知狀態的成員掛掉了,或者是兩個成員之間存在網絡訪問問題

REMOVED

當成員被移出副本集時,它就處于這個狀態.

如果被移出的成員又被重新添加到副本集中,它就會回到“正常”狀態

ROLLBACK

如果成員正在進行數據回滾,它就處于ROLLBACK狀態

回滾過程結束時,服務器會轉換為RECOVERING狀態,然后成為備份節點

FATAL

如果一個成員發生了不可挽回的錯誤,也不再嘗試恢復正常的話,它就處于FATAL狀態

使用"replSet FATAL"關鍵詞在日志上執行grep

選舉

回滾