MongoDB一次節點宕機引起的思考(源碼剖析)

時間  2019-11-06
標籤 mongodb 一次 節點 宕機 引起 思考 源碼 剖析 欄目 MongoDB 简体版
原文   原文鏈接

目錄ios

聲明：本文同步發表於 MongoDB 中文社區，傳送門：
http://www.mongoing.com/archives/26759算法

簡介

最近一個 MongoDB 集羣環境中的某節點異常下電了，致使業務出現了中斷，隨即又恢復了正常。
經過ELK 告警也監測到了業務報錯日誌。mongodb

運維部對於節點下電的緣由進行了排查，發現僅僅是資源分配上的一個失誤致使。 在解決了問題以後，你們也對此次中斷的也提出了一些問題：架構

"當前的 MongoDB集羣 採用了分片副本集的架構，其中主節點發生故障會產生多大的影響？"
"MongoDB 副本集不是能自動倒換嗎，這個是否是秒級的？"運維

帶着這些問題，下面針對副本集的自動Failover機制作一些分析。dom

日誌分析

首先能夠確認的是，此次掉電的是一個副本集上的主節點，在掉電的時候，主備關係發生了切換。
從另外的兩個備節點找到了對應的日誌：函數

備節點1的日誌this

2019-05-06T16:51:11.766+0800 I REPL     [ReplicationExecutor] Starting an election, since we've seen no PRIMARY in the past 10000ms
2019-05-06T16:51:11.766+0800 I REPL     [ReplicationExecutor] conducting a dry run election to see if we could be elected
2019-05-06T16:51:11.766+0800 I ASIO     [NetworkInterfaceASIO-Replication-0] Connecting to 172.30.129.78:30071
2019-05-06T16:51:11.767+0800 I REPL     [ReplicationExecutor] VoteRequester(term 3 dry run) received a yes vote from 172.30.129.7:30071; response message: { term: 3, voteGranted: true, reason: "", ok: 1.0 }
2019-05-06T16:51:11.767+0800 I REPL     [ReplicationExecutor] dry election run succeeded, running for election
2019-05-06T16:51:11.768+0800 I ASIO     [NetworkInterfaceASIO-Replication-0] Connecting to 172.30.129.78:30071
2019-05-06T16:51:11.771+0800 I REPL     [ReplicationExecutor] VoteRequester(term 4) received a yes vote from 172.30.129.7:30071; response message: { term: 4, voteGranted: true, reason: "", ok: 1.0 }
2019-05-06T16:51:11.771+0800 I REPL     [ReplicationExecutor] election succeeded, assuming primary role in term 4
2019-05-06T16:51:11.771+0800 I REPL     [ReplicationExecutor] transition to PRIMARY
2019-05-06T16:51:11.771+0800 I REPL     [ReplicationExecutor] Entering primary catch-up mode.
2019-05-06T16:51:11.771+0800 I ASIO     [NetworkInterfaceASIO-Replication-0] Ending connection to host 172.30.129.78:30071 due to bad connection status; 2 connections to that host remain open
2019-05-06T16:51:11.771+0800 I ASIO     [NetworkInterfaceASIO-Replication-0] Connecting to 172.30.129.78:30071
2019-05-06T16:51:13.350+0800 I REPL     [ReplicationExecutor] Error in heartbeat request to 172.30.129.78:30071; ExceededTimeLimit: Couldn't get a connection within the time limit

備節點2的日誌加密

2019-05-06T16:51:12.816+0800 I ASIO     [NetworkInterfaceASIO-Replication-0] Ending connection to host 172.30.129.78:30071 due to bad connection status; 0 connections to that host remain open
2019-05-06T16:51:12.816+0800 I REPL     [ReplicationExecutor] Error in heartbeat request to 172.30.129.78:30071; ExceededTimeLimit: Operation timed out, request was RemoteCommand 72553 -- target:172.30.129.78:30071 db:admin expDate:2019-05-06T16:51:12.816+0800 cmd:{ replSetHeartbeat: "shard0", configVersion: 96911, from: "172.30.129.7:30071", fromId: 1, term: 3 }
2019-05-06T16:51:12.821+0800 I REPL     [ReplicationExecutor] Member 172.30.129.160:30071 is now in state PRIMARY

能夠看到，備節點1在 16:51:11 時主動發起了選舉，併成爲了新的主節點，隨即備節點2在 16:51:12 獲知了最新的主節點信息，所以能夠確認此時主備切換已經完成。
同時在日誌中出現的，還有對於原主節點(172.30.129.78:30071)大量心跳失敗的信息。設計

那麼，備節點具體是怎麼感知到主節點已經 Down 掉的，主備節點之間的心跳是如何運做的，這對數據的同步複製又有什麼影響？
下面，咱們挖掘一下 ** 副本集的 自動故障轉移(Failover)** 機制

副本集 如何實現 Failover

以下是一個PSS(一主兩備)架構的副本集，主節點除了與兩個備節點執行數據複製以外，三個節點之間還會經過心跳感知彼此的存活。

一旦主節點發生故障之後，備節點將在某個週期內檢測到主節點處於不可達的狀態，此後將由其中一個備節點事先發起選舉並最終成爲新的主節點。 這個檢測週期 由electionTimeoutMillis 參數肯定，默認是10s。

接下來，咱們經過一些源碼看看該機制是如何實現的：

<<來自 MongoDB 3.4源碼>>

db/repl/replication_coordinator_impl_heartbeat.cpp
相關方法

  • ReplicationCoordinatorImpl::_startHeartbeats_inlock 啓動各成員的心跳
  • ReplicationCoordinatorImpl::_scheduleHeartbeatToTarget 調度任務-(計劃)向成員發起心跳
  • ReplicationCoordinatorImpl::_doMemberHeartbeat 執行向成員發起心跳
  • ReplicationCoordinatorImpl::_handleHeartbeatResponse 處理心跳響應
  • ReplicationCoordinatorImpl::_scheduleNextLivenessUpdate_inlock 調度保活狀態檢查定時器
  • ReplicationCoordinatorImpl::_cancelAndRescheduleElectionTimeout_inlock 取消並從新調度選舉超時定時器
  • ReplicationCoordinatorImpl::_startElectSelfIfEligibleV1 發起主動選舉

db/repl/topology_coordinator_impl.cpp
相關方法

  • TopologyCoordinatorImpl::prepareHeartbeatRequestV1 構造心跳請求數據
  • TopologyCoordinatorImpl::processHeartbeatResponse 處理心跳響應並構造下一步Action實例

下面這個圖，描述了各個方法之間的調用關係


圖-主要關係

心跳的實現

首先，在副本集組建完成以後，節點會經過ReplicationCoordinatorImpl::_startHeartbeats_inlock方法開始向其餘成員發送心跳：

void ReplicationCoordinatorImpl::_startHeartbeats_inlock() {
    const Date_t now = _replExecutor.now();
    _seedList.clear();

    //獲取副本集成員
    for (int i = 0; i < _rsConfig.getNumMembers(); ++i) {
        if (i == _selfIndex) {
            continue;
        }
        //向其餘成員發送心跳
        _scheduleHeartbeatToTarget(_rsConfig.getMemberAt(i).getHostAndPort(), i, now);
    }

    //僅僅是刷新本地的心跳狀態數據
    _topCoord->restartHeartbeats();

    //使用V1的選舉協議(3.2以後)
    if (isV1ElectionProtocol()) {
        for (auto&& slaveInfo : _slaveInfo) {
            slaveInfo.lastUpdate = _replExecutor.now();
            slaveInfo.down = false;
        }

        //調度保活狀態檢查定時器
        _scheduleNextLivenessUpdate_inlock();
    }
}

在得到當前副本集的節點信息後，調用_scheduleHeartbeatToTarget方法對其餘成員發送心跳，
這裏_scheduleHeartbeatToTarget 的實現比較簡單，其真正發起心跳是由 _doMemberHeartbeat 實現的，以下：

void ReplicationCoordinatorImpl::_scheduleHeartbeatToTarget(const HostAndPort& target,
                                                            int targetIndex,
                                                            Date_t when) {
    //執行調度，在某個時間點調用_doMemberHeartbeat
    _trackHeartbeatHandle(
        _replExecutor.scheduleWorkAt(when,
                                     stdx::bind(&ReplicationCoordinatorImpl::_doMemberHeartbeat,
                                                this,
                                                stdx::placeholders::_1,
                                                target,
                                                targetIndex)));
}

ReplicationCoordinatorImpl::_doMemberHeartbeat 方法的實現以下：

void ReplicationCoordinatorImpl::_doMemberHeartbeat(ReplicationExecutor::CallbackArgs cbData,
                                                    const HostAndPort& target,
                                                    int targetIndex) {
    LockGuard topoLock(_topoMutex);

    //取消callback 跟蹤
    _untrackHeartbeatHandle(cbData.myHandle);
    if (cbData.status == ErrorCodes::CallbackCanceled) {
        return;
    }

    const Date_t now = _replExecutor.now();
    BSONObj heartbeatObj;
    Milliseconds timeout(0);

    //3.2 之後的版本
    if (isV1ElectionProtocol()) {
        const std::pair<ReplSetHeartbeatArgsV1, Milliseconds> hbRequest =
            _topCoord->prepareHeartbeatRequestV1(now, _settings.ourSetName(), target);
        //構造請求，設置一個timeout
        heartbeatObj = hbRequest.first.toBSON();
        timeout = hbRequest.second;
    } else {
        ...
    }

    //構造遠程命令
    const RemoteCommandRequest request(
        target, "admin", heartbeatObj, BSON(rpc::kReplSetMetadataFieldName << 1), nullptr, timeout);

    //設置遠程命令回調，指向_handleHeartbeatResponse方法
    const ReplicationExecutor::RemoteCommandCallbackFn callback =
        stdx::bind(&ReplicationCoordinatorImpl::_handleHeartbeatResponse,
                   this,
                   stdx::placeholders::_1,
                   targetIndex);

    _trackHeartbeatHandle(_replExecutor.scheduleRemoteCommand(request, callback));
}

上面的代碼中存在的一些細節：

  • 心跳的超時時間，在_topCoord.prepareHeartbeatRequestV1方法中就已經設定好了
    具體的算法就是:

**hbTimeout=_rsConfig.getHeartbeatTimeoutPeriodMillis() - alreadyElapsed**

其中heartbeatTimeoutPeriodMillis是可配置的參數，默認是10s, 那麼alreadyElapsed是指此前連續心跳失敗(最多2次)累計的消耗時間，在心跳成功響應或者超過10s後alreadyElapsed會置爲0。所以能夠判斷，隨着心跳失敗次數的增長，超時時間會愈來愈短(心跳更加密集)

  • 心跳執行的回調，指向自身的_handleHeartbeatResponse方法，該函數實現了心跳響應成功、失敗(或是超時)以後的流程處理。

ReplicationCoordinatorImpl::_handleHeartbeatResponse方法的代碼片斷：

void ReplicationCoordinatorImpl::_handleHeartbeatResponse(
    const ReplicationExecutor::RemoteCommandCallbackArgs& cbData, int targetIndex) {
    LockGuard topoLock(_topoMutex);

    // remove handle from queued heartbeats
    _untrackHeartbeatHandle(cbData.myHandle);
    ...

    //響應成功後
    if (responseStatus.isOK()) {
        networkTime = cbData.response.elapsedMillis.value_or(Milliseconds{0});
        const auto& hbResponse = hbStatusResponse.getValue();

        // 只要primary 心跳響應成功，就會從新調度 electionTimeout定時器
        if (hbResponse.hasState() && hbResponse.getState().primary() &&
            hbResponse.getTerm() == _topCoord->getTerm()) {

            //取消並從新調度 electionTimeout定時器
            cancelAndRescheduleElectionTimeout();
        }
    }
    ...
    //調用topCoord的processHeartbeatResponse方法處理心跳響應狀態，並返回下一步執行的Action
    HeartbeatResponseAction action = _topCoord->processHeartbeatResponse(
        now, networkTime, target, hbStatusResponse, lastApplied);
    ...
    //調度下一次心跳，時間間隔採用action提供的信息
    _scheduleHeartbeatToTarget(
        target, targetIndex, std::max(now, action.getNextHeartbeatStartDate()));

    //根據Action 執行處理
    _handleHeartbeatResponseAction(action, hbStatusResponse, false);
}

這裏省略了許多細節，但仍然能夠看到，在響應心跳時會包含這些事情的處理：

  • 對於主節點的成功響應，會從新調度 electionTimeout定時器(取消以前的調度並從新發起)
  • 經過_topCoord對象的processHeartbeatResponse方法解析處理心跳響應，並返回下一步的Action指示
  • 根據Action 指示中的下一次心跳時間設置下一次心跳定時任務
  • 處理Action指示的動做

那麼，心跳響應以後會等待多久繼續下一次心跳呢？ 在 TopologyCoordinatorImpl::processHeartbeatResponse方法中，實現邏輯爲：
若是心跳響應成功，會等待heartbeatInterval，該值是一個可配參數，默認爲2s；
若是心跳響應失敗，則會直接發送心跳(不等待)。

代碼以下：

HeartbeatResponseAction TopologyCoordinatorImpl::processHeartbeatResponse(...) {
  
    ...

    const Milliseconds alreadyElapsed = now - hbStats.getLastHeartbeatStartDate();
    Date_t nextHeartbeatStartDate;

    // 計算下一次 心跳啓動時間
    // numFailuresSinceLastStart 對應連續失敗的次數(2次之內)
    if (hbStats.getNumFailuresSinceLastStart() <= kMaxHeartbeatRetries &&
        alreadyElapsed < _rsConfig.getHeartbeatTimeoutPeriod()) {
        // 心跳失敗，不等待，直接重試心跳
        nextHeartbeatStartDate = now;
    } else {
        // 心跳成功，等待必定間隔後再次發送(通常是2s)
        nextHeartbeatStartDate = now + heartbeatInterval;
    }

    ...
    // 決定下一步的動做，可能發生 tack over(本備節點優先級更高，且數據與主節點同樣新時)
    HeartbeatResponseAction nextAction;
    if (_rsConfig.getProtocolVersion() == 0) {
       ...
    } else {
        nextAction = _updatePrimaryFromHBDataV1(memberIndex, originalState, now, myLastOpApplied);
    }
    nextAction.setNextHeartbeatStartDate(nextHeartbeatStartDate);
    return nextAction;
}

electionTimeout 定時器

至此，咱們已經知道了心跳實現的一些細節，默認狀況下副本集節點會每2s向其餘節點發出心跳(默認的超時時間是10s)。
若是心跳成功，將會持續以2s的頻率繼續發送心跳，在心跳失敗的狀況下，則會當即重試心跳(以更短的超時時間)，一直到心跳恢復成功或者超過10s的週期。

那麼，心跳失敗是如何觸發主備切換的呢，electionTimeout 又是如何發揮做用？

在前面的過程當中，與electionTimeout參數相關兩個方法以下，它們也分別對應了單獨的定時器：

  • ReplicationCoordinatorImpl::_scheduleNextLivenessUpdate_inlock 發起保活狀態檢查定時器
  • ReplicationCoordinatorImpl::_cancelAndRescheduleElectionTimeout_inlock 從新發起選舉超時定時器

第一個是 _scheduleNextLivenessUpdate_inlock這個函數，它的做用在於保活狀態檢測，以下：

void ReplicationCoordinatorImpl::_scheduleNextLivenessUpdate_inlock() {
    //僅僅支持3.2+
    if (!isV1ElectionProtocol()) {
        return;
    }

   
    // earliestDate 取全部節點中更新時間最先的(以儘量早的發現問題)
    // electionTimeoutPeriod 默認爲 10s
    auto nextTimeout = earliestDate + _rsConfig.getElectionTimeoutPeriod();
   
    // 設置超時回調函數爲 _handleLivenessTimeout
    auto cbh = _scheduleWorkAt(nextTimeout,
                               stdx::bind(&ReplicationCoordinatorImpl::_handleLivenessTimeout,
                                          this,
                                          stdx::placeholders::_1));
}

所以，在大約10s後，若是沒有什麼意外，_handleLivenessTimeout將會被觸發，以下：

void ReplicationCoordinatorImpl::_handleLivenessTimeout(...) {

    ...
    for (auto&& slaveInfo : _slaveInfo) {
        ...

        //lastUpdate 不夠新(小於electionTimeout)
        if (now - slaveInfo.lastUpdate >= _rsConfig.getElectionTimeoutPeriod()) {
            ...
            //在保活週期後仍然未更新節點，置爲down狀態
            slaveInfo.down = true;

            //若是當前節點是主，且檢測到某個備節點爲down的狀態，進入memberdown流程
            if (_memberState.primary()) {
 
                //調用_topCoord的setMemberAsDown方法，記錄某個備節點不可達，並得到下一步的指示
               //當大多數節點不可見時，這裏會得到讓自身降備的指示
                HeartbeatResponseAction action =
                    _topCoord->setMemberAsDown(now, memberIndex, _getMyLastDurableOpTime_inlock());
                //執行指示
                _handleHeartbeatResponseAction(action,
                                               makeStatusWith<ReplSetHeartbeatResponse>(),
                                               true);
            }
        }
    }
    //繼續調度下一個週期
    _scheduleNextLivenessUpdate_inlock();
}

能夠看到，這個定時器主要是用於實現主節點對其餘節點的保活探測邏輯：

當主節點發現大多數節點不可達時(不知足大多數原則)，將會讓本身執行降備

所以，在一個三節點的副本集中，其中兩個備節點掛掉後，主節點會自動降備。 這樣的設計主要是爲了不產生意外的數據不一致狀況產生。


圖- 主自動降備

第二個是_cancelAndRescheduleElectionTimeout_inlock函數，這裏則是實現自動Failover的關鍵了，
它的邏輯中包含了一個選舉定時器，代碼以下：

void ReplicationCoordinatorImpl::_cancelAndRescheduleElectionTimeout_inlock() {

    //若是上一個定時器已經啓用了，則直接取消
    if (_handleElectionTimeoutCbh.isValid()) {
        LOG(4) << "Canceling election timeout callback at " << _handleElectionTimeoutWhen;
        _replExecutor.cancel(_handleElectionTimeoutCbh);
        _handleElectionTimeoutCbh = CallbackHandle();
        _handleElectionTimeoutWhen = Date_t();
    }

    //僅支持3.2後的V1版本
    if (!isV1ElectionProtocol()) {
        return;
    }
    //僅備節點可執行
    if (!_memberState.secondary()) {
        return;
    }
    ...
    //是否能夠選舉
    if (!_rsConfig.getMemberAt(_selfIndex).isElectable()) {
        return;
    }

    //檢測週期，由 electionTimeout + randomOffset
    //randomOffset是隨機偏移量，默認爲 0~0.15*ElectionTimeoutPeriod = 0~1.5s
    Milliseconds randomOffset = _getRandomizedElectionOffset();
    auto now = _replExecutor.now();
    auto when = now + _rsConfig.getElectionTimeoutPeriod() + randomOffset;
  
    LOG(4) << "Scheduling election timeout callback at " << when;
    _handleElectionTimeoutWhen = when;

    //觸發調度，時間爲 now + ElectionTimeoutPeriod + randomOffset
    _handleElectionTimeoutCbh =
        _scheduleWorkAt(when,
                        stdx::bind(&ReplicationCoordinatorImpl::_startElectSelfIfEligibleV1,
                                   this,
                                   StartElectionV1Reason::kElectionTimeout));
}

上面代碼展現了這個選舉定時器的邏輯，在每個檢測週期中，定時器都會嘗試執行超時回調，
而回調函數指向的是_startElectSelfIfEligibleV1，這裏面就實現了主動發起選舉的功能，
若是心跳響應成功，經過cancelAndRescheduleElectionTimeout調用將直接取消當次的超時回調(即不會發起選舉)
若是心跳響應遲遲不能成功，那麼定時器將被觸發，進而致使備節點發起選舉併成爲新的主節點！

同時，這個回調方法(產生選舉)被觸發必需要知足如下條件：

  1. 當前是備節點
  2. 當前節點具有選舉權限
  3. 在檢測週期內仍然沒有與主節點心跳成功

這其中的檢測週期略大於electionTimeout(10s)，加入一個隨機偏移量後大約是10-11.5s內，猜想這樣的設計是爲了錯開多個備節點主動選舉的時間，提高成功率。
最後，將整個自動選舉切換的邏輯梳理後，以下圖所示：


圖-超時自動選舉

業務影響評估

副本集發生主備切換的狀況下，不會影響現有的讀操做，只會影響寫操做。 若是使用3.6及以上版本的驅動，能夠經過開啓retryWrite來下降影響。
可是若是主節點是屬於強制掉電，那麼整個 Failover 過程將會變長，極可能須要在Election定時器超時後才被副本集感知並恢復，這個時間窗口會在12s之內。
此外還須要考慮客戶端或mongos對於副本集角色的監視和感知行爲。但總之在問題恢復以前，對於原主節點的任何讀寫都會發生超時。
所以，對於極爲重要的業務，建議最好在業務層面作一些防禦策略，好比設計重試機制。

參考連接

https://docs.mongodb.com/manual/replication/#automatic-failover
https://www.percona.com/blog/2016/05/25/mongodb-3-2-elections-just-got-better/
https://www.percona.com/blog/2018/10/10/mongodb-replica-set-scenarios-and-internals/

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程