Redis叢集的主從切換研究

一見發表於2019-01-06

它的master為fail狀態（非pfail狀態）；
它的master至少負責了一個slot；
slave和master的複製連線斷開時間不超過給定的值（值可配置，目的是確保slave上的資料足夠完整，所以運維時不能任由一個slave長時間不可用，需要通過監控將異常的slave及時恢復）。

因過長時間不可用而不能自動切換的slave日誌：

slave過長時間不可用，導致無法自動切換為master

12961:S 06 Jan 2019 19:00:21.969 # Currently unable to failover: Disconnected from master for longer than allowed. Please check the 'cluster-replica-validity-factor' configuration option.

相關的原始碼：

/* 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) {

mstime_t data_age; // 與master斷開的時長，單位毫秒

mstime_t auth_age = mstime() - server.cluster->failover_auth_time;

int needed_quorum = (server.cluster->size / 2) + 1;

int manual_failover = server.cluster->mf_end != 0 && server.cluster->mf_can_start;

auth_timeout = server.cluster_node_timeout*2;

if (auth_timeout < 2000) auth_timeout = 2000;

auth_retry_time = auth_timeout*2;

。。。。。。

/* Set data_age to the number of seconds we are disconnected from

* the master. */

if (server.repl_state == REPL_STATE_CONNECTED) {

data_age = (mstime_t)(server.unixtime - server.master->lastinteraction) * 1000;

} else {

data_age = (mstime_t)(server.unixtime - server.repl_down_since) * 1000;

}

/* Remove the node timeout from the data age as it is fine that we are

* disconnected from our master at least for the time it was down to be

* flagged as FAIL, that's the baseline. */

if (data_age > server.cluster_node_timeout)

data_age -= server.cluster_node_timeout;

/* 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)))

{

// slave不可用時間過長，導致不能自動切換為master

if (!manual_failover) { // 人工切換除外

clusterLogCantFailover(CLUSTER_CANT_FAILOVER_DATA_AGE);

return;

}

。。。。。。

/* Ask for votes if needed. */

// failover_auth_sent標記是否已傳送過投票訊息

if (server.cluster->failover_auth_sent == 0) {

server.cluster->currentEpoch++;

server.cluster->failover_auth_epoch = server.cluster->currentEpoch;

serverLog(LL_WARNING,"Starting a failover election for epoch %llu.",

(unsigned long long) server.cluster->currentEpoch);

// 給所有節點（包括slaves）傳送投票訊息FAILOVE_AUTH_REQUEST（請求投票成為master訊息），但注意只有master響應該訊息

clusterRequestFailoverAuth();

server.cluster->failover_auth_sent = 1;

clusterDoBeforeSleep(CLUSTER_TODO_SAVE_CONFIG|

CLUSTER_TODO_UPDATE_STATE|

CLUSTER_TODO_FSYNC_CONFIG);

return; /* Wait for replies. */

}

/* Check if we reached the quorum. */

if (server.cluster->failover_auth_count >= needed_quorum) {

/* We have the quorum, we can finally failover the master. */

serverLog(LL_WARNING,

"Failover election won: I'm the new master.");

/* Update my configEpoch to the epoch of the election. */

if (myself->configEpoch < server.cluster->failover_auth_epoch) {

myself->configEpoch = server.cluster->failover_auth_epoch;

serverLog(LL_WARNING,

"configEpoch set to %llu after successful failover",

(unsigned long long) myself->configEpoch);

}

/* Take responsibility for the cluster slots. */

clusterFailoverReplaceYourMaster();

} else {

clusterLogCantFailover(CLUSTER_CANT_FAILOVER_WAITING_VOTES);

}

從上段程式碼，還可以看到配置項cluster-slave-validity-factor影響slave是否能夠切換為master。

發起選舉前，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後，並不立即服務，而是留了一個時間差。

master響應選舉

master收到slave的投票請求FAILOVER_AUTH_REQUEST後，只有滿足下列條件時，才會響應投票：

對一個epoch，只投票一次；
會拒絕所有更小epoch的投票請求；
不會給小於lastVoteEpoch的epoch投票；
master只給master狀態為fail的slave投票；
如果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可相對更快發起選舉。

選舉示例

假設一個master有A、B和C三個slaves節點，當這個master不可達時：

假設slave A贏得選舉成為master；
slave A因為網路分割槽不再可用；
slave B贏得選舉；
slave B因為網路分割槽不再可用；
網路分割槽修復，slave A又可用。

B掛了，A又可用。同一時刻，slave C發起選舉，試圖替代B成為master。由於slave C的master已不可用，所以它能夠選舉成為master，並將configEpoch值增一。而A將不能成為master，因為C已成為master，並且C的epoch值更大。

雜湊槽傳播方式

有兩種雜湊槽（hash slot）傳播途徑：

心跳訊息（Heartbeat messages）。節點在傳送ping和pong訊息時，總是攜帶了它所負責（或它的master所負責）的雜湊槽資訊；
更新訊息（UPDATE messages）。由於心跳包還包含了epoch資訊，當訊息接收者發現心跳包攜帶的資訊陳舊時，會響應更新的資訊，這樣強迫傳送者更新雜湊槽。

一次主從切換記錄1

測試叢集執行在同一個物理機上，cluster-node-timeout值比repl-timeout值大。

1. 相關引數

cluster-slave-validity-factor值為1

cluster-node-timeout值為30000

repl-ping-slave-period值為1

repl-timeout值為10

1. 時間點記錄

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秒

1. 其它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

1. 其它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

1. 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的訊息

一次主從切換記錄2

測試叢集執行在同一個物理機上，cluster-node-timeout值比repl-timeout值小。

1. 相關引數

cluster-slave-validity-factor值為1

cluster-node-timeout值為10000

repl-ping-slave-period值為1

repl-timeout值為30

1. 時間點記錄

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秒

1. 其它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

1. 其它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

1. 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

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;

}

。。。。。。

}

Redis哨兵叢集：哨兵掛了，主從庫還能切換嗎？
2023-10-27
Redis
Redis主從切換
2019-10-11
Redis
Redis sentinel主從切換
2022-09-01
Redis
Redis主從同步叢集搭建
2020-12-21
Redis主從同步
基於Dokcer搭建Redis叢集（主從叢集）
2020-12-10
Redis
keepalived配置redis主從切換
2018-12-04
Redis
Redis高可用-主從,哨兵,叢集
2020-06-03
Redis
Redis叢集搭建三主三從
2019-09-19
Redis
redis原理及叢集主從配置
2019-06-12
Redis
Redis叢集搭建（三主三從）
2023-01-28
Redis
keepalived與mysql主主叢集自動切換
2015-09-17
MySql
REDIS主從頻繁切換事件排查
2020-06-05
Redis事件
【Redis】Redis叢集主從調整演算法
2020-03-03
Redis演算法
Redis搭建主從複製、哨兵叢集
2020-10-06
Redis
Redis學習筆記七：主從叢集
2021-05-28
Redis筆記
Docker環境搭建redis叢集(主從模式)
2017-03-19
DockerRedis模式
Redis 哨兵模式實現主從故障互切換
2016-08-09
Redis模式
三千字介紹Redis主從+哨兵+叢集
2021-09-30
Redis
MySQL主從切換
2015-08-25
MySql
docker Redis單機主從哨兵模式切換失敗
2020-11-01
DockerRedis模式
Redis+Keepalived主從熱備秒級切換
2016-05-01
Redis
基於docker環境下搭建redis主從叢集
2020-06-22
DockerRedis
redis安裝，主從複製，哨兵機制，叢集
2020-12-31
Redis
redis主從叢集搭建及容災部署(哨兵sentinel)
2020-12-01
Redis
linux系統——Redis叢集搭建（主從+哨兵模式）
2022-01-27
LinuxRedis模式
手工切換MySQL主從
2018-11-27
MySql
mysql主從搭建切換
2016-06-29
MySql
redis叢集之主從複製叢集的原理和部署
2022-11-29
Redis
mongodb叢集節點故障的切換方法
2019-06-20
MongoDB
mysql主從複製+主備切換
2018-01-05
MySql
實戰dataguard主從切換
2014-03-26
mysql for linux主從切換
2014-10-25
MySqlLinux
nginx keepalived 主從切換
2016-05-31
Nginx
docker 配置 Mysql主從叢集
2023-04-14
DockerMySql
基於 Docker 的 MongoDB 主從叢集
2018-08-07
DockerMongoDB
Redis系列：搭建Redis叢集(叢集模式)
2020-09-23
Redis模式
StoneDB 主從切換實踐方案
2022-10-11
記一次阿里雲 Redis 主從版升級到 Redis 叢集版的坑
2019-08-08
阿里Redis

Redis叢集的主從切換研究

目錄

相關文章