5.4 自動故障轉移

在故障轉移場景中，我們所關心的問題是：

● 備節(jié)點是怎么感知到主節(jié)點已經(jīng)發(fā)生故障的？

● 如何降低故障轉移對業(yè)務產(chǎn)生的影響？

下面來看一些細節(jié)。

圖5-13是一個PSS（一主兩備）架構的副本集，主節(jié)點除了與兩個備節(jié)點執(zhí)行數(shù)據(jù)復制，三個節(jié)點之間還會通過心跳感知彼此的存活。

一旦主節(jié)點發(fā)生故障以后，備節(jié)點將在某個周期內檢測到主節(jié)點處于不可達的狀態(tài)，此后將由其中一個備節(jié)點事先發(fā)起選舉并最終成為新的主節(jié)點，如圖5-14所示。

一個影響檢測機制的因素是心跳，在副本集組建完成之后，各成員節(jié)點會開啟定時器，持續(xù)向其他成員發(fā)起心跳，這里涉及的參數(shù)為heartbeatIntervalMillis，即心跳間隔時間，默認值是2s。如果心跳成功，則會持續(xù)以2s的頻率繼續(xù)發(fā)送心跳；如果心跳失敗，則會立即重試心跳，一直到心跳恢復成功。

另一個重要的因素是選舉超時檢測，一次心跳檢測失敗并不會立即觸發(fā)重新選舉。實際上除了心跳，成員節(jié)點還會啟動一個選舉超時檢測定時器，該定時器默認以10s的間隔執(zhí)行，具體可以通過electionTimeoutMillis參數(shù)指定：

● 如果心跳響應成功，則取消上一次的electionTimeout調度（保證不會發(fā)起選舉），并發(fā)起新一輪electionTimeout調度。

● 如果心跳響應遲遲不能成功，那么electionTimeout任務被觸發(fā)，進而導致備節(jié)點發(fā)起選舉并成為新的主節(jié)點。

因此，在electionTimeout任務中觸發(fā)選舉必須要滿足以下條件：

（1）當前節(jié)點是備節(jié)點。

（2）當前節(jié)點具備選舉權限。

（3）在檢測周期內仍然沒有與主節(jié)點心跳成功。

整個選舉切換的邏輯如圖5-15所示。

在MongoDB的實現(xiàn)中，選舉超時檢測的周期要略大于electionTimeoutMillis設定。該周期會加入一個隨機偏移量，大約在10～11.5s，如此的設計是為了錯開多個備節(jié)點主動選舉的時間，提升成功率。

業(yè)務影響評估

● 在副本集發(fā)生主備節(jié)點切換的情況下，會出現(xiàn)短暫的無主節(jié)點階段，此時無法接受業(yè)務寫操作。如果是因為主節(jié)點故障導致的切換，則對于該節(jié)點的所有讀寫操作都會產(chǎn)生超時。如果使用MongoDB 3.6及以上版本的驅動，則可以通過開啟retryWrite來降低影響。

● 如果主節(jié)點屬于強制掉電，那么整個Failover過程將會變長，很可能需要在Election定時器超時后才被其他節(jié)點感知并恢復，這個時間窗口一般會在12s以內。然而實際上，對于業(yè)務呼損的考量還應該加上客戶端或mongos對于副本集角色的監(jiān)視和感知行為（真實的情況可能需要長達30s以上）。

● 對于非常重要的業(yè)務，建議在業(yè)務層面做一些防護策略，比如設計重試機制。