Redis叢集的主從切換研究
目錄
目錄 1
1. 前言 1
2. slave發起選舉 2
3. master響應選舉 3
4. 選舉示例 3
5. 雜湊槽傳播方式 3
6. 一次主從切換記錄1 4
6.1. 相關引數 4
6.2. 時間點記錄 4
6.3. 其它master日誌 4
6.4. 其它master日誌 5
6.5. slave日誌 5
7. 一次主從切換記錄2 6
7.1. 相關引數 6
7.2. 時間點記錄 6
7.3. 其它master日誌 6
7.4. 其它master日誌 7
7.5. slave日誌 7
8. slave延遲發起選舉程式碼 7
1. 前言
Redis官方原文:https://redis.io/topics/cluster-spec。另外,從Redis-5.0開始,slave已改叫replica,配置項和部分文件及變數已做改名。
Redis叢集的主從切換採取選舉機制,要求少數服從多數,而參與選舉的只能為master,所以只有多數master存活動時才能進行,選舉由slave發起。
Redis用了和Raft演算法term(任期)類似的的概念,在Redis中叫作epoch(紀元),epoch是一個無符號的64整數,一個節點的epoch從0開始。
如果一個節點接收到的epoch比自己的大,則將自已的epoch更新接收到的epoch(假定為信任網路,無拜占庭將軍問題)。
每個master都會在ping和pong訊息中廣播自己的epoch和所負責的slots點陣圖,slave發起選舉時,建立一個新的epoch(增一),epoch的值會持久化到檔案nodes.conf中,如(最新epoch值為27,最近一次投票給了27):
vars currentEpoch 27 lastVoteEpoch 27 |
2. slave發起選舉
只有master為fail狀態,slave才會發起選舉。但並不是master為fail時立即發起選舉,而是延遲下列隨機時長,以避免多個slaves同時發起選舉(至少延遲0.5秒後才會發起選舉):
500 milliseconds + random delay between 0 and 500 milliseconds + SLAVE_RANK * 1000 milliseconds |
一個slave發起選舉的條件:
1) 它的master為fail狀態(非pfail狀態);
2) 它的master至少負責了一個slot;
3) slave和master的複製連線斷開時間不超過給定的值(值可配置,目的是確保slave上的資料足夠完整,所以運維時不能任由一個slave長時間不可用,需要通過監控將異常的slave及時恢復)。
發起選舉前,slave先給自己的epoch(即currentEpoch)增一,然後請求其它master給自己投票。slave是通過廣播FAILOVER_AUTH_REQUEST包給集中的每一個masters。
slave發起投票後,會等待至少兩倍NODE_TIMEOUT時長接收投票結果,不管NODE_TIMEOUT何值,也至少會等待2秒。
master接收投票後給slave響應FAILOVER_AUTH_ACK,並且在(NODE_TIMEOUT*2)時間內不會給同一master的其它slave投票。
如果slave收到FAILOVER_AUTH_ACK響應的epoch值小於自己的epoch,則會直接丟棄。一旦slave收到多數master的FAILOVER_AUTH_ACK,則宣告自己贏得了選舉。
如果slave在兩倍的NODE_TIMEOUT時間內(至少2秒)未贏得選舉,則放棄本次選舉,然後在四倍NODE_TIMEOUT時間(至少4秒)後重新發起選舉。
只所以強制延遲至少0.5秒選舉,是為確保master的fail狀態在整個叢集內傳開,否則可能只有小部分master知曉,而master只會給處於fail狀態的master的slaves投票。如果一個slave的master狀態不是fail,則其它master不會給它投票,Redis通過八卦協議(即Gossip協議,也叫謠言協議)傳播fail。而在固定延遲上再加一個隨機延遲,是為了避免多個slaves同時發起選舉。
slave的SLAVE_RANK是一個與master複製數有關的值,具有最新複製時SLAVE_RANK值為0,第二則為1,以此類推。這樣可讓具有最全資料的slave優先發起選舉。當具有更高SLAVE_RANK值的slave如果沒有當選,則其它slaves會很快發起選舉(至少4秒後)。
在slave贏得選舉後,會向叢集內的所有節點廣播pong,以儘快完成重新配置(體現在node.conf的更新)。當前未能到達的節點,最終也會完成重新配置。
其它節點會發現有兩個相同的master負責相同的slots,這時就看哪個master的epoch值更大。
slave成為master後,並不立即服務,而是留了一個時間差。
3. master響應選舉
master收到slave的投票請求FAILOVER_AUTH_REQUEST後,只有滿足下列條件時,才會響應投票:
1) 對一個epoch,只投票一次;
2) 會拒絕所有更小epoch的投票請求;
3) 不會給小於lastVoteEpoch的epoch投票;
4) master只給master狀態為fail的slave投票;
5) 如果slave請求的currentEpoch小於master的currentEpoch,則master忽略該請求,但下列情況例外:
① 假設master的currentEpoch值為5,lastVoteEpoch值為1(當有選舉失敗會出現這個情況,亦即currentEpoch值增加了,但因為選舉失敗,lastVoteEpoch值未變); ② slave的currentEpoch值為3; ③ slave增一,使用值為4的epoch發起選舉,這個時候master會響應epoch值為5,不巧這個響應延遲了; ④ slave重新發起選舉,這個時候選舉用的epoch值為5(每次發起選舉epoch值均需增一),湊巧這個時候原來延遲的響應達到了,這個時候原來延遲的響應被slave認為有效。 |
在master投票後,會用請求中的epoch更新本地的lastVoteEpoch,並持久化到node.conf檔案中。master不會參與選擇最優的slave,由於最優的slave有最好的SLAVE_RANK,因此最優的slave可相對更快發起選舉。
4. 選舉示例
假設一個master有A、B和C三個slaves節點,當這個master不可達時:
1) 假設slave A贏得選舉成為master;
2) slave A因為網路分割槽不再可用;
3) slave B贏得選舉;
4) slave B因為網路分割槽不再可用;
5) 網路分割槽修復,slave A又可用。
B掛了,A又可用。同一時刻,slave C發起選舉,試圖替代B成為master。由於slave C的master已不可用,所以它能夠選舉成為master,並將configEpoch值增一。而A將不能成為master,因為C已成為master,並且C的epoch值更大。
5. 雜湊槽傳播方式
有兩種雜湊槽(hash slot)傳播途徑:
1) 心跳訊息(Heartbeat messages)。節點在傳送ping和pong訊息時,總是攜帶了它所負責(或它的master所負責)的雜湊槽資訊;
2) 更新訊息(UPDATE messages)。由於心跳包還包含了epoch資訊,當訊息接收者發現心跳包攜帶的資訊陳舊時,會響應更新的資訊,這樣強迫傳送者更新雜湊槽。
6. 一次主從切換記錄1
測試叢集執行在同一個物理機上,cluster-node-timeout值比repl-timeout值大。
6.1. 相關引數
cluster-slave-validity-factor值為1 cluster-node-timeout值為30000 repl-ping-slave-period值為1 repl-timeout值為10 |
6.2. 時間點記錄
master為FAIL之時的1秒左右時間內,即為主從切換之時。
master A標記fail時間:20:12:55.467 master B標記fail時間:20:12:55.467 master A投票時間:20:12:56.164 master B投票時間:20:12:56.164 slave發起選舉時間:20:12:56.160 slave準備發起選舉時間:20:12:55.558(延遲579毫秒) slave發現和master心跳超時時間:20:12:32.810(在這之後24秒才發生主從切換) slave收到其它master發來的自己的master為fail時間:20:12:55.467 切換前服務最後一次正常時間:(服務異常約發生在秒)20:12:22/279275 切換後服務恢復正常時間:20:12:59/278149 服務不可用時長:約37秒 |
6.3. 其它master日誌
該master ID為c67dc9e02e25f2e6321df8ac2eb4d99789917783。
30613:M 04 Jan 2019 20:12:55.467 * FAIL message received from bfad383775421b1090eaa7e0b2dcfb3b38455079 about 44eb43e50c101c5f44f48295c42dda878b6cb3e9 // 從其它master收到44eb43e50c101c5f44f48295c42dda878b6cb3e9已fail訊息 30613:M 04 Jan 2019 20:12:55.467 # Cluster state changed: fail 30613:M 04 Jan 2019 20:12:56.164 # Failover auth granted to 0ae8b5400d566907a3d8b425d983ac3b7cbd8412 for epoch 30 // 對選舉投票 30613:M 04 Jan 2019 20:12:56.204 # Cluster state changed: ok 30613:M 04 Jan 2019 20:12:56.708 * Ignoring FAIL message from unknown node 082c079149a9915612d21cca8e08c831a4edeade about 44eb43e50c101c5f44f48295c42dda878b6cb3e9 |
6.4. 其它master日誌
該master ID為bfad383775421b1090eaa7e0b2dcfb3b38455079。
30614:M 04 Jan 2019 20:12:55.467 * Marking node 44eb43e50c101c5f44f48295c42dda878b6cb3e9 as failing (quorum reached). // 標記44eb43e50c101c5f44f48295c42dda878b6cb3e9為已fail 30614:M 04 Jan 2019 20:12:56.164 # Failover auth granted to 0ae8b5400d566907a3d8b425d983ac3b7cbd8412 for epoch 30 // 對選舉投票 30614:M 04 Jan 2019 20:12:56.709 * Ignoring FAIL message from unknown node 082c079149a9915612d21cca8e08c831a4edeade about 44eb43e50c101c5f44f48295c42dda878b6cb3e9 |
6.5. slave日誌
slave的master ID為44eb43e50c101c5f44f48295c42dda878b6cb3e9,slave自己的ID為0ae8b5400d566907a3d8b425d983ac3b7cbd8412。
30651:S 04 Jan 2019 20:12:32.810 # MASTER timeout: no data nor PING received... // 發現master超時,master異常10秒後發現,原因是repl-timeout的值為10 30651:S 04 Jan 2019 20:12:32.810 # Connection with master lost. 30651:S 04 Jan 2019 20:12:32.810 * Caching the disconnected master state. 30651:S 04 Jan 2019 20:12:32.810 * Connecting to MASTER 1.9.16.9:4073 30651:S 04 Jan 2019 20:12:32.810 * MASTER <-> REPLICA sync started 30651:S 04 Jan 2019 20:12:32.810 * Non blocking connect for SYNC fired the event.
30651:S 04 Jan 2019 20:12:43.834 # Timeout connecting to the MASTER... 30651:S 04 Jan 2019 20:12:43.834 * Connecting to MASTER 1.9.16.9:4073 30651:S 04 Jan 2019 20:12:43.834 * MASTER <-> REPLICA sync started 30651:S 04 Jan 2019 20:12:43.834 * Non blocking connect for SYNC fired the event. 30651:S 04 Jan 2019 20:12:54.856 # Timeout connecting to the MASTER... 30651:S 04 Jan 2019 20:12:54.856 * Connecting to MASTER 1.9.16.9:4073 30651:S 04 Jan 2019 20:12:54.856 * MASTER <-> REPLICA sync started 30651:S 04 Jan 2019 20:12:54.856 * Non blocking connect for SYNC fired the event. 30651:S 04 Jan 2019 20:12:55.467 * FAIL message received from bfad383775421b1090eaa7e0b2dcfb3b38455079 about 44eb43e50c101c5f44f48295c42dda878b6cb3e9 // 從其它master收到自己的master的FAIL訊息 30651:S 04 Jan 2019 20:12:55.467 # Cluster state changed: fail 30651:S 04 Jan 2019 20:12:55.558 # Start of election delayed for 579 milliseconds (rank #0, offset 227360). // 準備發起選舉,延遲579毫秒,其中500毫秒為固定延遲,279秒為隨機延遲,因為RANK值為0,所以RANK延遲為0毫秒 30651:S 04 Jan 2019 20:12:56.160 # Starting a failover election for epoch 30. // 發起選舉 30651:S 04 Jan 2019 20:12:56.180 # Failover election won: I'm the new master. // 贏得選舉 30651:S 04 Jan 2019 20:12:56.180 # configEpoch set to 30 after successful failover 30651:M 04 Jan 2019 20:12:56.180 # Setting secondary replication ID to 154a9c2319403d610808477dcda3d4bede0f374c, valid up to offset: 227361. New replication ID is 927fb64a420236ee46d39389611ab2d8f6530b6a 30651:M 04 Jan 2019 20:12:56.181 * Discarding previously cached master state. 30651:M 04 Jan 2019 20:12:56.181 # Cluster state changed: ok 30651:M 04 Jan 2019 20:12:56.708 * Ignoring FAIL message from unknown node 082c079149a9915612d21cca8e08c831a4edeade about 44eb43e50c101c5f44f48295c42dda878b6cb3e9 // 忽略來自非叢集成員1.9.16.9:4077的訊息 |
7. 一次主從切換記錄2
測試叢集執行在同一個物理機上,cluster-node-timeout值比repl-timeout值小。
7.1. 相關引數
cluster-slave-validity-factor值為1 cluster-node-timeout值為10000 repl-ping-slave-period值為1 repl-timeout值為30 |
7.2. 時間點記錄
master為FAIL之時的1秒左右時間內,即為主從切換之時。
master A標記fail時間:20:37:10.398 master B標記fail時間:20:37:10.398 master A投票時間:20:37:11.084 master B投票時間:20:37:11.085 slave發起選舉時間:20:37:11.077 slave準備發起選舉時間:20:37:10.475(延遲539毫秒) slave發現和master心跳超時時間:沒有發生,因為slave在超時之前已成為master slave收到其它master發來的自己的master為fail時間:20:37:10.398 切換前服務最後一次正常時間:20:36:55/266889(服務異常約發生在56秒) 切換後服務恢復正常時間:20:37:12/265802 服務不可用時長:約17秒 |
7.3. 其它master日誌
該master ID為c67dc9e02e25f2e6321df8ac2eb4d99789917783。
30613:M 04 Jan 2019 20:37:10.398 * Marking node 44eb43e50c101c5f44f48295c42dda878b6cb3e9 as failing (quorum reached). 30613:M 04 Jan 2019 20:37:10.398 # Cluster state changed: fail 30613:M 04 Jan 2019 20:37:11.084 # Failover auth granted to 0ae8b5400d566907a3d8b425d983ac3b7cbd8412 for epoch 32 30613:M 04 Jan 2019 20:37:11.124 # Cluster state changed: ok 30613:M 04 Jan 2019 20:37:17.560 * Ignoring FAIL message from unknown node 082c079149a9915612d21cca8e08c831a4edeade about 44eb43e50c101c5f44f48295c42dda878b6cb3e9 |
7.4. 其它master日誌
該master ID為bfad383775421b1090eaa7e0b2dcfb3b38455079。
30614:M 04 Jan 2019 20:37:10.398 * Marking node 44eb43e50c101c5f44f48295c42dda878b6cb3e9 as failing (quorum reached). 30614:M 04 Jan 2019 20:37:11.085 # Failover auth granted to 0ae8b5400d566907a3d8b425d983ac3b7cbd8412 for epoch 32 30614:M 04 Jan 2019 20:37:17.560 * Ignoring FAIL message from unknown node 082c079149a9915612d21cca8e08c831a4edeade about 44eb43e50c101c5f44f48295c42dda878b6cb3e9 |
7.5. slave日誌
slave的master ID為44eb43e50c101c5f44f48295c42dda878b6cb3e9,slave自己的ID為0ae8b5400d566907a3d8b425d983ac3b7cbd8412。
30651:S 04 Jan 2019 20:37:10.398 * FAIL message received from c67dc9e02e25f2e6321df8ac2eb4d99789917783 about 44eb43e50c101c5f44f48295c42dda878b6cb3e9 30651:S 04 Jan 2019 20:37:10.398 # Cluster state changed: fail 30651:S 04 Jan 2019 20:37:10.475 # Start of election delayed for 539 milliseconds (rank #0, offset 228620). 30651:S 04 Jan 2019 20:37:11.077 # Starting a failover election for epoch 32. 30651:S 04 Jan 2019 20:37:11.100 # Failover election won: I'm the new master. 30651:S 04 Jan 2019 20:37:11.100 # configEpoch set to 32 after successful failover 30651:M 04 Jan 2019 20:37:11.100 # Setting secondary replication ID to 0cf19d01597610c7933b7ed67c999a631655eafc, valid up to offset: 228621. New replication ID is 53daa7fa265d982aebd3c18c07ed5f178fc3f70b 30651:M 04 Jan 2019 20:37:11.101 # Connection with master lost. 30651:M 04 Jan 2019 20:37:11.101 * Caching the disconnected master state. 30651:M 04 Jan 2019 20:37:11.101 * Discarding previously cached master state. 30651:M 04 Jan 2019 20:37:11.101 # Cluster state changed: ok 30651:M 04 Jan 2019 20:37:17.560 * Ignoring FAIL message from unknown node 082c079149a9915612d21cca8e08c831a4edeade about 44eb43e50c101c5f44f48295c42dda878b6cb3e9 |
8. slave延遲發起選舉程式碼
// 摘自Redis-5.0.3
// cluster.c /* This function is called if we are a slave node and our master serving * a non-zero amount of hash slots is in FAIL state. * * The gaol of this function is: * 1) To check if we are able to perform a failover, is our data updated? * 2) Try to get elected by masters. * 3) Perform the failover informing all the other nodes. */ void clusterHandleSlaveFailover(void) { 。。。。。。 /* Check if our data is recent enough according to the slave validity * factor configured by the user. * * Check bypassed for manual failovers. */ if (server.cluster_slave_validity_factor && data_age > (((mstime_t)server.repl_ping_slave_period * 1000) + (server.cluster_node_timeout * server.cluster_slave_validity_factor))) { if (!manual_failover) { clusterLogCantFailover(CLUSTER_CANT_FAILOVER_DATA_AGE); return; } } /* If the previous failover attempt timedout and the retry time has * elapsed, we can setup a new one. */ if (auth_age > auth_retry_time) { server.cluster->failover_auth_time = mstime() + 500 + /* Fixed delay of 500 milliseconds, let FAIL msg propagate. */ random() % 500; /* Random delay between 0 and 500 milliseconds. */ server.cluster->failover_auth_count = 0; server.cluster->failover_auth_sent = 0; server.cluster->failover_auth_rank = clusterGetSlaveRank(); /* We add another delay that is proportional to the slave rank. * Specifically 1 second * rank. This way slaves that have a probably * less updated replication offset, are penalized. */ server.cluster->failover_auth_time += server.cluster->failover_auth_rank * 1000; /* However if this is a manual failover, no delay is needed. */ if (server.cluster->mf_end) { server.cluster->failover_auth_time = mstime(); server.cluster->failover_auth_rank = 0; } serverLog(LL_WARNING, "Start of election delayed for %lld milliseconds " "(rank #%d, offset %lld).", server.cluster->failover_auth_time - mstime(), server.cluster->failover_auth_rank, replicationGetSlaveOffset()); /* Now that we have a scheduled election, broadcast our offset * to all the other slaves so that they'll updated their offsets * if our offset is better. */ clusterBroadcastPong(CLUSTER_BROADCAST_LOCAL_SLAVES); return; } 。。。。。。 } |