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中會多一行slave的配置, 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。
redis主從復制的背景問題 :
Redis主從復制可將主節點數據同步給從節點, 從節點此時有兩個作用 :
1. 一旦主節點宕機, 從節點作為主節點的備份可以隨時頂上來
2. 擴展主節點的讀能力, 分擔主節點讀壓力
但是問題是 :
1. 一旦主節點宕機, 從節點上位, 那么需要人為修改所有應用 方的主節點地址(改為新的master地址), 還需要命令所有從節點復制新的主節點.
這個問題使用Redis-sentinel就可以解決.
主從復制架構 :
Rdis sentinel架構 :
redis命令整理 :
# 官網地址 http://redisdoc.com/ # 查看redis數據庫信息 redis-cli info # 查看redis的復制授權信息 redis-cli info replication # 查看redis的哨兵信息 redis-cli info sentinel
redis-sentinel安裝與配置
准備三個redis服務器環境, 一個主節點兩個從節點
主節點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-server /etc/redis-6379.conf
測試主節點是否通信 :
redis-cli ping
啟動兩個從節點的redis服務 :
redis-server /etc/redis-6380.conf
redis-server /etc/redis-6381.conf
驗證從節點的redis服務 :
redis-cli -p 6380 ping
redis-cli -p 6381 ping
確定主從關系 :
在節點上查看主從通信關系
[root@master ~]# redis-cli -p 6378 info replication # Replication role:master connected_slaves:2 slave0:ip=192.168.119.10,port=6381,state=online,offset=407,lag=0 slave1:ip=192.168.119.10,port=6382,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
在從節點上查看主從關系(6381, 6382)
[root@slave 192.168.119.11 ~]$redis-cli -p 6381 info replication # Replication role:slave master_host:192.168.119.10 master_port:6380 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配置
配置三個哨兵並啟動(和配置redis-server方法基本一致) :
# 配置文件信息 // Sentinel節點的端口 port 26380 dir /var/redis/data/ logfile "26380.log" // 當前Sentinel節點監控 127.0.0.1:6380 這個主節點 // 2代表判斷主節點失敗至少需要2個Sentinel節點節點同意 // mymaster是主節點的別名 sentinel monitor mymaster 127.0.0.1 6380 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
其他兩個哨兵的配置和上面的差距僅僅是port(端口)的不同而已.
啟動三個redis哨兵(啟動方法和redis-server基本一致) :
// redis-sentinel sentinel的配置文件 redis-sentinel /data/26381/sentinel.conf redis-sentinel /data/26382/sentinel.conf
查看哨兵是否成功通信 :
[root@master ~]# redis-cli -p 26380 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:6380,slaves=2,sentinels=3 #看到最后一條信息正確即成功了哨兵，哨兵主節點名字叫做mymaster，狀態ok，監控地址是192.168.119.10:6379，有兩個從節點，3個哨兵
哨兵監控拓補圖 :
redis故障實驗 :
1. 殺掉主節點的redis進程6380端口, 觀察從節點是否會進行新的master選舉, 進行切換
2. 重新恢復舊的master節點, 查看此時的redis身份
檢查三個redis的進程狀態 :
ps -ef | grep redis
殺死6380端口的進程等待片刻后會發現6381成為了主節點, 而6382端口成為了6381的從節點.