Redis-Sentinel

Redis-Sentinel是redis官方推薦的高可用性解決方案，
當用redis作master-slave的高可用時，如果master本身宕機，redis本身或者客戶端都沒有實現主從切換的功能。而redis-sentinel就是一個獨立運行的進程，用于監控多個master-slave集群，
自動發現master宕機，進行自動切換slave > master。

sentinel主要功能如下：

• 不時的監控redis是否良好運行，如果節點不可達就會對節點進行下線標識
• 如果被標識的是主節點，sentinel就會和其他的sentinel節點“協商”，如果其他節點也人為主節點不可達，就會選舉一個sentinel節點來完成自動故障轉義
• 在master-slave進行切換后，master_redis.conf、slave_redis.conf和sentinel.conf的內容都會發生改變，即master_redis.conf中會多一行slaveof的配置，sentinel.conf的監控目標會隨之調換

Sentinel的工作方式：

每個Sentinel以每秒鐘一次的頻率向它所知的Master，Slave以及其他 Sentinel 實例發送一個 PING 命令如果一個實例（instance）距離最后一次有效回復 PING 命令的時間超過 down-after-milliseconds 選項所指定的值， 則這個實例會被 Sentinel 標記為主觀下線。如果一個Master被標記為主觀下線，則正在監視這個Master的所有 Sentinel 要以每秒一次的頻率確認Master的確進入了主觀下線狀態。當有足夠數量的 Sentinel（大于等于配置文件指定的值）在指定的時間范圍內確認Master的確進入了主觀下線狀態， 則Master會被標記為客觀下線在一般情況下， 每個 Sentinel 會以每 10 秒一次的頻率向它已知的所有Master，Slave發送 INFO 命令當Master被 Sentinel 標記為客觀下線時，Sentinel 向下線的 Master 的所有 Slave 發送 INFO 命令的頻率會從 10 秒一次改為每秒一次若沒有足夠數量的 Sentinel 同意 Master 已經下線， Master 的客觀下線狀態就會被移除。若 Master 重新向 Sentinel 的 PING 命令返回有效回復， Master 的主觀下線狀態就會被移除。主觀下線和客觀下線主觀下線：Subjectively Down，簡稱 SDOWN，指的是當前 Sentinel 實例對某個redis服務器做出的下線判斷。 客觀下線：Objectively Down， 簡稱 ODOWN，指的是多個 Sentinel 實例在對Master Server做出 SDOWN 判斷，并且通過 SENTINEL is-master-down-by-addr 命令互相交流之后，得出的Master Server下線判斷，然后開啟failover.SDOWN適合于Master和Slave，只要一個 Sentinel 發現Master進入了ODOWN， 這個 Sentinel 就可能會被其他 Sentinel 推選出， 并對下線的主服務器執行自動故障遷移操作。ODOWN只適用于Master，對于Slave的 Redis 實例，Sentinel 在將它們判斷為下線前不需要進行協商， 所以Slave的 Sentinel 永遠不會達到ODOWN。sentinel公作方式

?

redis主從復制背景問題

Redis主從復制可將主節點數據同步給從節點，從節點此時有兩個作用：

• 一旦主節點宕機，從節點作為主節點的備份可以隨時頂上來。
• 擴展主節點的讀能力，分擔主節點讀壓力。

但是問題是：

• 一旦主節點宕機，從節點上位，那么需要人為修改所有應用方的主節點地址（改為新的master地址），還需要命令所有從節點復制新的主節點

那么這個問題，redis-sentinel就可以解決了

主從復制架構

Redis Sentinel架構

redis的一個進程，但是不存儲數據，只是監控redis

?

redis命令整理

官網地址：http://redisdoc.com/redis-cli info #查看redis數據庫信息redis-cli info replication #查看redis的復制授權信息

redis-cli info sentinel #查看redis的哨兵信息

?

安裝與配置

本實驗是在測試環境下，考慮到學生機器較弱，因此只準備一臺linux服務器用作環境！！

服務器環境，一臺即可完成操作

master 192.168.119.10

所有配置文件如下

主節點master的redis-6379.conf

port 6379 daemonize yes logfile "6379.log" dbfilename "dump-6379.rdb" dir "/var/redis/data/"

從節點slave的redis-6380.conf

port 6380 daemonize yes logfile "6380.log" dbfilename "dump-6380.rdb" dir "/var/redis/data/" slaveof 127.0.0.1 6379 // 從屬主節點

從節點slave的redis-6381.conf

port 6381 daemonize yes logfile "6380.log" dbfilename "dump-6380.rdb" dir "/var/redis/data/" slaveof 127.0.0.1 6379 // 從屬主節點

啟動redis主節點

redis-server /etc/redis-6379.conf

測試redis主節點是否通信

redis-cli ping

啟動兩slave節點

還記得上面超哥的截圖嗎？總體redis配置文件如下，6379為master，6380和6381為slave

-rw-r--r-- 1 root root 145 Nov 7 17:44 /etc/redis-6379.conf #這個為主，port是6379 -rw-r--r-- 1 root root 93 Nov 7 17:42 /etc/redis-6380.conf　　　 # 這個是從，port6380，并且得加上新的參數slaveof -rw-r--r-- 1 root root 115 Nov 7 17:42 /etc/redis-6381.conf # 這個是從，port6381，并且得加上新的參數slaveof

redis-6380.conf? slave配置文件詳解，6381端口的配置文件，僅僅和6380端口不一樣

port 6380 daemonize yes logfile "6379.log" dbfilename "dump-6379.rdb" dir "/var/redis/data" # Generated by CONFIG REWRITE slaveof 127.0.0.1 6379

?

啟動slave從節點的redis服務

[root@master 192.168.119.10 ~]$redis-server /etc/redis-6380.conf [root@master 192.168.119.10 ~]$redis-server /etc/redis-6381.conf

驗證從節點的redis服務

[root@master ~]$redis-cli -p 6380 ping PONG [root@master ~]$redis-cli -p 6381 ping PONG

確定主從關系

在主節點上查看主從通信關系

[root@master ~]# redis-cli -p 6379 info replication # Replication role:master connected_slaves:2 slave0:ip=192.168.119.10,port=6380,state=online,offset=407,lag=0 slave1:ip=192.168.119.10,port=6381,state=online,offset=407,lag=0 master_repl_offset:407 repl_backlog_active:1 repl_backlog_size:1048576 repl_backlog_first_byte_offset:2 repl_backlog_histlen:406

在從節點上查看主從關系（6380、6379）

[root@slave 192.168.119.11 ~]$redis-cli -p 6380 info replication # Replication role:slave master_host:192.168.119.10 master_port:6379 master_link_status:up master_last_io_seconds_ago:3 master_sync_in_progress:0 slave_repl_offset:505 slave_priority:100 slave_read_only:1 connected_slaves:0 master_repl_offset:0 repl_backlog_active:0 repl_backlog_size:1048576 repl_backlog_first_byte_offset:0 repl_backlog_histlen:0

此時可以在master上寫入數據，在slave上查看數據，此時主從復制配置完成

開始配置Redis Sentinel

超哥實驗的環境是單獨一臺linux，192.168.119.10

[root@master tmp]# ll /etc/redis-* -rw-r--r-- 1 root root 145 Nov 7 17:44 /etc/redis-6379.conf -rw-r--r-- 1 root root 93 Nov 7 17:42 /etc/redis-6380.conf -rw-r--r-- 1 root root 115 Nov 7 17:42 /etc/redis-6381.conf -rw-r--r-- 1 root root 556 Nov 7 17:42 /etc/redis-sentinel-26379.conf -rw-r--r-- 1 root root 556 Nov 7 17:42 /etc/redis-sentinel-26380.conf -rw-r--r-- 1 root root 556 Nov 7 17:42 /etc/redis-sentinel-26381.conf

redis-sentinel-26379.conf配置文件寫入如下信息

// Sentinel節點的端口 port 26379 dir /var/redis/data/ logfile "26379.log"// 當前Sentinel節點監控 192.168.119.10:6379 這個主節點 // 2代表判斷主節點失敗至少需要2個Sentinel節點節點同意 // mymaster是主節點的別名 sentinel monitor mymaster 192.168.119.10 6379 2//每個Sentinel節點都要定期PING命令來判斷Redis數據節點和其余Sentinel節點是否可達，如果超過30000毫秒30s且沒有回復，則判定不可達 sentinel down-after-milliseconds mymaster 30000//當Sentinel節點集合對主節點故障判定達成一致時，Sentinel領導者節點會做故障轉移操作，選出新的主節點，
原來的從節點會向新的主節點發起復制操作，限制每次向新的主節點發起復制操作的從節點個數為1 sentinel parallel-syncs mymaster 1//故障轉移超時時間為180000毫秒 sentinel failover-timeout mymaster 180000 redis-sentinel-26380.conf和redis-sentinel-26381.conf的配置僅僅差異是port(端口)的不同。
然后啟動三個sentinel哨兵 redis-sentinel /etc/redis-sentinel-26379.conf redis-sentinel /etc/redis-sentinel-26380.conf redis-sentinel /etc/redis-sentinel-26381.conf

?

監控拓撲圖

?

此時查看哨兵是否成功通信

[root@master ~]# redis-cli -p 26379 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=192.168.119.10:6379,slaves=2,sentinels=3
#看到最后一條信息正確即成功了哨兵，哨兵主節點名字叫做mymaster，狀態ok，監控地址是192.168.119.10:6379，有兩個從節點，3個哨兵

redis高可用故障實驗

大致思路

• 殺掉主節點的redis進程6379端口，觀察從節點是否會進行新的master選舉，進行切換
• 重新恢復舊的“master”節點，查看此時的redis身份

?首先查看三個redis的進程狀態

ps -ef|grep redis

檢查三個節點的復制身份狀態

第一個

[root@master tmp]# redis-cli -p 6381 info replication # Replication role:slave master_host:127.0.0.1 master_port:6380

第二個

[root@master tmp]# redis-cli -p 6380 info replication # Replication role:master connected_slaves:2 slave0:ip=127.0.0.1,port=6381,state=online,offset=54386,lag=0 slave1:ip=127.0.0.1,port=6379,state=online,offset=54253,lag=0

第三個

[root@master tmp]# redis-cli -p 6379 info replication # Replication role:slave master_host:127.0.0.1 master_port:6380

此時，干掉master！！！然后等待其他兩個節點是否能自動被哨兵sentienl，切換為master節點

?

ps -ef|grep 6380 #干掉master進程

?

此時查看兩個slave的狀態

精髓就是查看一個參數

master_link_down_since_seconds:13

?

稍等片刻之后，發現slave節點成為master節點！！

[root@master tmp]# redis-cli -p 6379 info replication # Replication role:master connected_slaves:1 slave0:ip=127.0.0.1,port=6381,state=online,offset=41814,lag=1

大功告成！！開心！！！

?

轉載于:https://www.cnblogs.com/Godisgirl/p/10657182.html

總結

以上是生活随笔為你收集整理的redis-sentinel主从复制高可用的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。