Redis sentinel主從切換
Redis sentinel主從切換通常有兩種方式
1.透過哨兵節點sentinel failover mastername命令進行切換。
2.透過重啟redis master例項進行切換。
環境：
10.1.1.100 10079 master 10.1.1.100 10080 slave 10.1.1.100 10081 slave 10.1.1.100 20079 sentinel1 10.1.1.100 20080 sentinel2 10.1.1.100 20081 sentinel3
主從切換：
將master由10.1.1.100 10079切換到其他redis 從例項上。
Redis sentinel主從切換一：
登入任一哨兵節點
執行切換操作
127.0.0.1:20079> sentinel failover mymaster
OK
故障轉移，檢查原主庫10079日誌：
master由10.1.1.100:10079切換到10.1.1.100:10081。
原master自動執行SLAVE OF 10.1.1.100:10081，並從新主庫同步了需要的資料。
1620:M 01 Sep 14:29:19.902 # Connection with slave 10.1.1.100:10081 lost. 1620:M 01 Sep 14:29:20.846 # Connection with slave client id #9 lost. 1620:S 01 Sep 14:29:30.933 * Before turning into a slave, using my master parameters to synthesize a cached master: I may be able to synchronize with the new master with just a partial transfer. 1620:S 01 Sep 14:29:30.933 * SLAVE OF 10.1.1.100:10081 enabled (user request from 'id=33 addr=10.1.1.100:43954 fd=11 name=sentinel-e50fd8d2-cmd age=10 idle=0 flags=x db=0 sub=0 psub=0 multi=3 qbuf=0 qbuf-free=32768 obl=36 oll=0 omem=0 events=r cmd=exec') 1620:S 01 Sep 14:29:30.934 # CONFIG REWRITE executed with success. 1620:S 01 Sep 14:29:31.696 * Connecting to MASTER 10.1.1.100:10081 1620:S 01 Sep 14:29:31.696 * MASTER <-> SLAVE sync started 1620:S 01 Sep 14:29:31.696 * Non blocking connect for SYNC fired the event. 1620:S 01 Sep 14:29:31.697 * Master replied to PING, replication can continue... 1620:S 01 Sep 14:29:31.697 * Trying a partial resynchronization (request 9d20ee7ee943a42ebcd9756c0d952d065d2c0250:2765734). 1620:S 01 Sep 14:29:31.698 * Full resync from master: 033c7d4ab3f1e604e1a95486c9ee80410f8412bd:2766349 1620:S 01 Sep 14:29:31.698 * Discarding previously cached master state. 1620:S 01 Sep 14:29:31.706 * MASTER <-> SLAVE sync: receiving 209 bytes from master 1620:S 01 Sep 14:29:31.707 * MASTER <-> SLAVE sync: Flushing old data 1620:S 01 Sep 14:29:31.707 * MASTER <-> SLAVE sync: Loading DB in memory 1620:S 01 Sep 14:29:31.707 * MASTER <-> SLAVE sync: Finished with success 10081從庫切換為主庫日誌如下： 啟用master角色MASTER MODE enabled，依次收到了10080，10079的資料同步申請，本機執行了BGSAVE，並將資料分別傳給從庫。 1645:M 01 Sep 14:29:19.901 # Setting secondary replication ID to 9d20ee7ee943a42ebcd9756c0d952d065d2c0250, valid up to offset: 2763788. New replication ID is 033c7d4ab3f1e604e1a95486c9ee80410f8412bd 1645:M 01 Sep 14:29:19.901 # Connection with master lost. 1645:M 01 Sep 14:29:19.901 * Caching the disconnected master state. 1645:M 01 Sep 14:29:19.901 * Discarding previously cached master state. 1645:M 01 Sep 14:29:19.901 * MASTER MODE enabled (user request from 'id=4 addr=10.1.1.100:56744 fd=8 name=sentinel-900c1440-cmd age=13459 idle=0 flags=x db=0 sub=0 psub=0 multi=3 qbuf=0 qbuf-free=32768 obl=36 oll=0 omem=0 events=r cmd=exec') 1645:M 01 Sep 14:29:19.902 # CONFIG REWRITE executed with success. 1645:M 01 Sep 14:29:21.288 * Slave 10.1.1.100:10080 asks for synchronization 1645:M 01 Sep 14:29:21.288 * Partial resynchronization not accepted: Requested offset for second ID was 2763927, but I can reply up to 2763788 1645:M 01 Sep 14:29:21.288 * Starting BGSAVE for SYNC with target: disk 1645:M 01 Sep 14:29:21.288 * Background saving started by pid 3562 3562:C 01 Sep 14:29:21.292 * DB saved on disk 3562:C 01 Sep 14:29:21.292 * RDB: 0 MB of memory used by copy-on-write 1645:M 01 Sep 14:29:21.380 * Background saving terminated with success 1645:M 01 Sep 14:29:21.381 * Synchronization with slave 10.1.1.100:10080 succeeded 1645:M 01 Sep 14:29:31.697 * Slave 10.1.1.100:10079 asks for synchronization 1645:M 01 Sep 14:29:31.697 * Partial resynchronization not accepted: Requested offset for second ID was 2765734, but I can reply up to 2763788 1645:M 01 Sep 14:29:31.698 * Starting BGSAVE for SYNC with target: disk 1645:M 01 Sep 14:29:31.698 * Background saving started by pid 3578 3578:C 01 Sep 14:29:31.701 * DB saved on disk 3578:C 01 Sep 14:29:31.702 * RDB: 0 MB of memory used by copy-on-write 1645:M 01 Sep 14:29:31.706 * Background saving terminated with success 1645:M 01 Sep 14:29:31.706 * Synchronization with slave 10.1.1.100:10079 succeeded
10080從庫日誌：
1005:S 01 Sep 14:29:20.846 # Connection with master lost. 1005:S 01 Sep 14:29:20.846 * Caching the disconnected master state. 1005:S 01 Sep 14:29:20.846 * SLAVE OF 10.1.1.100:10081 enabled (user request from 'id=4 addr=10.1.1.100:36399 fd=8 name=sentinel-900c1440-cmd age=13460 idle=0 flags=x db=0 sub=0 psub=0 multi=3 qbuf=139 qbuf-free=32629 obl=36 oll=0 omem=0 events=r cmd=exec') 1005:S 01 Sep 14:29:20.847 # CONFIG REWRITE executed with success. 1005:S 01 Sep 14:29:21.286 * Connecting to MASTER 10.1.1.100:10081 1005:S 01 Sep 14:29:21.286 * MASTER <-> SLAVE sync started 1005:S 01 Sep 14:29:21.286 * Non blocking connect for SYNC fired the event. 1005:S 01 Sep 14:29:21.287 * Master replied to PING, replication can continue... 1005:S 01 Sep 14:29:21.287 * Trying a partial resynchronization (request 9d20ee7ee943a42ebcd9756c0d952d065d2c0250:2763927). 1005:S 01 Sep 14:29:21.288 * Full resync from master: 033c7d4ab3f1e604e1a95486c9ee80410f8412bd:2764227 1005:S 01 Sep 14:29:21.288 * Discarding previously cached master state. 1005:S 01 Sep 14:29:21.381 * MASTER <-> SLAVE sync: receiving 209 bytes from master 1005:S 01 Sep 14:29:21.381 * MASTER <-> SLAVE sync: Flushing old data 1005:S 01 Sep 14:29:21.381 * MASTER <-> SLAVE sync: Loading DB in memory 1005:S 01 Sep 14:29:21.381 * MASTER <-> SLAVE sync: Finished with success
如何將master切換到指定節點呢？
需要在切換前調整從庫權重，slave-priority，將不需要成為master的從庫權重slave-priority調為0。
redis@cjchdb-aaa-01:/redis/sentinel$cat 10079/redis.conf |grep slave-priority slave-priority 100 redis@cjchdb-aaa-01:/redis/sentinel$cat 10080/redis.conf |grep slave-priority slave-priority 100 redis@cjchdb-aaa-01:/redis/sentinel$cat 10081/redis.conf |grep slave-priority slave-priority 100
檢查並修改權重
調低10080權重值，此時10079權重高於10080
127.0.0.1:10080> config get slave-priority 1) "slave-priority" 2) "100" 127.0.0.1:10080> config set slave-priority 0 OK 127.0.0.1:10080> config get slave-priority 1) "slave-priority" 2) "0"
配置檔案權重值並沒有自動修改
redis@cjchdb-aaa-01:/redis/sentinel$cat 10080/redis.conf |grep slave-priority
slave-priority 100
主從切換
127.0.0.1:20081> sentinel failover mymaster
OK
master成功切換到10079上
127.0.0.1:20081> info sentinel # Sentinel sentinel_masters:1 sentinel_tilt:0 sentinel_running_scripts:0 sentinel_scripts_queue_length:0 sentinel_simulate_failure_flags:0 master0:name=mymaster,status=ok,address=10.1.1.100:10079,slaves=2,sentinels=3
主從切換日誌
1645:M 01 Sep 14:44:58.591 # Connection with slave 10.1.1.100:10079 lost. 1645:M 01 Sep 14:44:59.479 # Connection with slave client id #18 lost. 1645:S 01 Sep 14:45:09.556 * Before turning into a slave, using my master parameters to synthesize a cached master: I may be able to synchronize with the new master with just a partial transfer. 1645:S 01 Sep 14:45:09.556 * SLAVE OF 10.1.1.100:10079 enabled (user request from 'id=26 addr=10.1.1.100:52265 fd=10 name=sentinel-8b0a2ce1-cmd age=10 idle=0 flags=x db=0 sub=0 psub=0 multi=3 qbuf=0 qbuf-free=32768 obl=36 oll=0 omem=0 events=r cmd=exec') 1645:S 01 Sep 14:45:09.556 # CONFIG REWRITE executed with success. 1645:S 01 Sep 14:45:09.792 * Connecting to MASTER 10.1.1.100:10079 1645:S 01 Sep 14:45:09.792 * MASTER <-> SLAVE sync started 1645:S 01 Sep 14:45:09.792 * Non blocking connect for SYNC fired the event. 1645:S 01 Sep 14:45:09.792 * Master replied to PING, replication can continue... 1645:S 01 Sep 14:45:09.793 * Trying a partial resynchronization (request 033c7d4ab3f1e604e1a95486c9ee80410f8412bd:2959217). 1645:S 01 Sep 14:45:09.794 * Full resync from master: c8ed4fe97f766dfbb8cf7b5a11066e8fcf2bf844:2959670 1645:S 01 Sep 14:45:09.794 * Discarding previously cached master state. 1645:S 01 Sep 14:45:09.870 * MASTER <-> SLAVE sync: receiving 209 bytes from master 1645:S 01 Sep 14:45:09.871 * MASTER <-> SLAVE sync: Flushing old data 1645:S 01 Sep 14:45:09.871 * MASTER <-> SLAVE sync: Loading DB in memory 1645:S 01 Sep 14:45:09.871 * MASTER <-> SLAVE sync: Finished with success
改回原權重
127.0.0.1:10080> config set slave-priority 100 OK
Redis sentinel主從切換方式二：
Redis sentinel主從切換，除了使用sentinel failover命令外，也可以透過重啟master redis例項來完成。
重啟主庫
127.0.0.1:10079> shutdown not connected>
檢視原主庫日誌：
1620:M 01 Sep 14:49:11.478 # User requested shutdown... 1620:M 01 Sep 14:49:11.478 * Saving the final RDB snapshot before exiting. 1620:M 01 Sep 14:49:11.487 * DB saved on disk 1620:M 01 Sep 14:49:11.487 * Removing the pid file. 1620:M 01 Sep 14:49:11.487 # Redis is now ready to exit, bye bye...
檢視新主庫資訊
127.0.0.1:20080> info Sentinel # Sentinel sentinel_masters:1 sentinel_tilt:0 sentinel_running_scripts:0 sentinel_scripts_queue_length:0 sentinel_simulate_failure_flags:0 master0:name=mymaster,status=ok,address=10.1.1.100:10081,slaves=2,sentinels=3
檢視新主庫10081日誌：
多次嘗試連線原主庫10079均失敗，啟用MASTER MODE enabled，並將資料同步到從庫。
1645:S 01 Sep 14:49:11.488 # Connection with master lost. 1645:S 01 Sep 14:49:11.488 * Caching the disconnected master state. 1645:S 01 Sep 14:49:12.212 * Connecting to MASTER 10.1.1.100:10079 1645:S 01 Sep 14:49:12.212 * MASTER <-> SLAVE sync started 1645:S 01 Sep 14:49:12.212 # Error condition on socket for SYNC: Connection refused 1645:S 01 Sep 14:49:13.214 * Connecting to MASTER 10.1.1.100:10079 1645:S 01 Sep 14:49:13.214 * MASTER <-> SLAVE sync started 1645:S 01 Sep 14:49:13.215 # Error condition on socket for SYNC: Connection refused 1645:S 01 Sep 14:49:14.217 * Connecting to MASTER 10.1.1.100:10079 1645:S 01 Sep 14:49:14.217 * MASTER <-> SLAVE sync started 1645:S 01 Sep 14:49:14.217 # Error condition on socket for SYNC: Connection refused 1645:S 01 Sep 14:49:15.218 * Connecting to MASTER 10.1.1.100:10079 1645:S 01 Sep 14:49:15.218 * MASTER <-> SLAVE sync started 1645:S 01 Sep 14:49:15.219 # Error condition on socket for SYNC: Connection refused 1645:S 01 Sep 14:49:16.221 * Connecting to MASTER 10.1.1.100:10079 1645:S 01 Sep 14:49:16.221 * MASTER <-> SLAVE sync started 1645:S 01 Sep 14:49:16.222 # Error condition on socket for SYNC: Connection refused 1645:S 01 Sep 14:49:17.224 * Connecting to MASTER 10.1.1.100:10079 1645:S 01 Sep 14:49:17.224 * MASTER <-> SLAVE sync started 1645:S 01 Sep 14:49:17.224 # Error condition on socket for SYNC: Connection refused 1645:S 01 Sep 14:49:18.226 * Connecting to MASTER 10.1.1.100:10079 1645:S 01 Sep 14:49:18.226 * MASTER <-> SLAVE sync started 1645:S 01 Sep 14:49:18.226 # Error condition on socket for SYNC: Connection refused 1645:S 01 Sep 14:49:19.229 * Connecting to MASTER 10.1.1.100:10079 1645:S 01 Sep 14:49:19.230 * MASTER <-> SLAVE sync started 1645:S 01 Sep 14:49:19.230 # Error condition on socket for SYNC: Connection refused 1645:M 01 Sep 14:49:19.894 # Setting secondary replication ID to c8ed4fe97f766dfbb8cf7b5a11066e8fcf2bf844, valid up to offset: 3009514. New replication ID is fddd686f75809723cc89e296b3daeee549e066d7 1645:M 01 Sep 14:49:19.894 * Discarding previously cached master state. 1645:M 01 Sep 14:49:19.894 * MASTER MODE enabled (user request from 'id=30 addr=10.1.1.100:45093 fd=7 name=sentinel-900c1440-cmd age=250 idle=0 flags=x db=0 sub=0 psub=0 multi=3 qbuf=0 qbuf-free=32768 obl=36 oll=0 omem=0 events=r cmd=exec') 1645:M 01 Sep 14:49:19.895 # CONFIG REWRITE executed with success. 1645:M 01 Sep 14:49:21.435 * Slave 10.1.1.100:10080 asks for synchronization 1645:M 01 Sep 14:49:21.435 * Partial resynchronization request from 10.1.1.100:10080 accepted. Sending 440 bytes of backlog starting from offset 3009514.
從庫10080日誌：
1005:S 01 Sep 14:49:11.488 # Connection with master lost. 1005:S 01 Sep 14:49:11.488 * Caching the disconnected master state. 1005:S 01 Sep 14:49:12.413 * Connecting to MASTER 10.1.1.100:10079 1005:S 01 Sep 14:49:12.414 * MASTER <-> SLAVE sync started 1005:S 01 Sep 14:49:12.414 # Error condition on socket for SYNC: Connection refused 1005:S 01 Sep 14:49:13.416 * Connecting to MASTER 10.1.1.100:10079 1005:S 01 Sep 14:49:13.416 * MASTER <-> SLAVE sync started 1005:S 01 Sep 14:49:13.417 # Error condition on socket for SYNC: Connection refused 1005:S 01 Sep 14:49:14.417 * Connecting to MASTER 10.1.1.100:10079 1005:S 01 Sep 14:49:14.417 * MASTER <-> SLAVE sync started 1005:S 01 Sep 14:49:14.417 # Error condition on socket for SYNC: Connection refused 1005:S 01 Sep 14:49:15.420 * Connecting to MASTER 10.1.1.100:10079 1005:S 01 Sep 14:49:15.420 * MASTER <-> SLAVE sync started 1005:S 01 Sep 14:49:15.420 # Error condition on socket for SYNC: Connection refused 1005:S 01 Sep 14:49:16.422 * Connecting to MASTER 10.1.1.100:10079 1005:S 01 Sep 14:49:16.422 * MASTER <-> SLAVE sync started 1005:S 01 Sep 14:49:16.423 # Error condition on socket for SYNC: Connection refused 1005:S 01 Sep 14:49:17.425 * Connecting to MASTER 10.1.1.100:10079 1005:S 01 Sep 14:49:17.425 * MASTER <-> SLAVE sync started 1005:S 01 Sep 14:49:17.425 # Error condition on socket for SYNC: Connection refused 1005:S 01 Sep 14:49:18.426 * Connecting to MASTER 10.1.1.100:10079 1005:S 01 Sep 14:49:18.426 * MASTER <-> SLAVE sync started 1005:S 01 Sep 14:49:18.426 # Error condition on socket for SYNC: Connection refused 1005:S 01 Sep 14:49:19.429 * Connecting to MASTER 10.1.1.100:10079 1005:S 01 Sep 14:49:19.429 * MASTER <-> SLAVE sync started 1005:S 01 Sep 14:49:19.429 # Error condition on socket for SYNC: Connection refused 1005:S 01 Sep 14:49:20.432 * Connecting to MASTER 10.1.1.100:10079 1005:S 01 Sep 14:49:20.432 * MASTER <-> SLAVE sync started 1005:S 01 Sep 14:49:20.432 # Error condition on socket for SYNC: Connection refused 1005:S 01 Sep 14:49:20.791 * SLAVE OF 10.1.1.100:10081 enabled (user request from 'id=22 addr=10.1.1.100:59965 fd=7 name=sentinel-900c1440-cmd age=261 idle=0 flags=x db=0 sub=0 psub=0 multi=3 qbuf=139 qbuf-free=32629 obl=36 oll=0 omem=0 events=r cmd=exec') 1005:S 01 Sep 14:49:20.791 # CONFIG REWRITE executed with success. 1005:S 01 Sep 14:49:21.434 * Connecting to MASTER 10.1.1.100:10081 1005:S 01 Sep 14:49:21.434 * MASTER <-> SLAVE sync started 1005:S 01 Sep 14:49:21.434 * Non blocking connect for SYNC fired the event. 1005:S 01 Sep 14:49:21.435 * Master replied to PING, replication can continue... 1005:S 01 Sep 14:49:21.435 * Trying a partial resynchronization (request c8ed4fe97f766dfbb8cf7b5a11066e8fcf2bf844:3009514). 1005:S 01 Sep 14:49:21.435 * Successful partial resynchronization with master. 1005:S 01 Sep 14:49:21.435 # Master replication ID changed to fddd686f75809723cc89e296b3daeee549e066d7 1005:S 01 Sep 14:49:21.436 * MASTER <-> SLAVE sync: Master accepted a Partial Resynchronization.
sentinel其他常用命令：
1.sentinel節點啟動兩種方式
redis-sentinel redis-sentinel-20079.conf
或
redis-server redis-sentinel-20079.conf --sentinel
2.顯示被哨兵管理的主庫資訊
sentinel masters
sentinel masters mastername
從庫資訊
sentinel slaves mastername
3.清除主節點相關狀態，重新發現從節點和Sentinel節點
sentinel reset mastername
4.將Sentinel節點配置強制重新整理到磁碟
當磁碟損壞等原因導致配置檔案損壞或丟失時，可以使用這個命令
sentinel flushconfig
來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/29785807/viewspace-2912958/，如需轉載，請註明出處，否則將追究法律責任。
相關文章
- Redis主從切換Redis
- keepalived配置redis主從切換Redis
- REDIS主從頻繁切換事件排查Redis事件
- Redis叢集的主從切換研究Redis
- Redis哨兵模式（sentinel）學習總結及部署記錄（主從複製、讀寫分離、主從切換）Redis模式
- Redis docker 主從模式與哨兵sentinelRedisDocker模式
- redis sentinel哨兵模式安裝部署和切換Redis模式
- Redis 哨兵模式實現主從故障互切換Redis模式
- MySQL主從切換MySql
- docker Redis單機主從哨兵模式切換失敗DockerRedis模式
- Redis+Keepalived主從熱備秒級切換Redis
- 手工切換MySQL主從MySql
- mysql主從搭建切換MySql
- mysql主從複製+主備切換MySql
- 實戰dataguard主從切換
- mysql for linux主從切換MySqlLinux
- nginx keepalived 主從切換Nginx
- Redis哨兵叢集：哨兵掛了，主從庫還能切換嗎？Redis
- StoneDB 主從切換實踐方案
- redis主從叢集搭建及容災部署(哨兵sentinel)Redis
- 用 docker 學習 redis 主從複製3 redis-sentinel(哨兵模式)DockerRedis模式
- Mongodb資料同步和主從切換MongoDB
- oracle 11g datagurd主從切換Oracle
- Redis主從複製 - 通過Keepalived實現Redis Failover自動故障切換功能RedisAI
- 5.6 MySql主從自動切換指令碼MySql指令碼
- mysql mha 主從自動切換 高可用MySql
- 一個月後，我們又從 MySQL 雙主切換成了主 - 從！MySql
- MySQL 主從切換延時高問題分析MySql
- 用 docker 學習 redis 主從複製3.2 redis-sentinel「哨兵模式」核心配置-命令-原理DockerRedis模式
- (九)主題切換
- Dledger是如何實現主從自動切換的
- Redis——SentinelRedis
- Redis SentinelRedis
- postgresql10主從+keepalived高可用自動切換(切換關鍵在指令碼)SQL指令碼
- 主備切換(failover)AI
- MYSQL5.6主從+keepalive高可用自動切換MySql
- ORACLE 12C DATAGUARD環境搭建和主從切換Oracle
- mysql 5.7+keepalived主從切換步驟簡述MySql