Redis HA方案之sentinel

    上一篇研究了redis監控，這一篇來分析redis HA，普遍流傳的是keepalived+redis，這個我在分析時有些問題還沒搞明白，下一篇會提到，這一篇主要是研究官方的sentinel。

IP 10.20.112.26/27

redis-server  2.6.16

官網：http://redis.io/topics/sentinel

    sentinel是一個管理redis實例的工具，它能夠實現對redis的監控、通知、自動故障轉移。sentinel不斷的檢測redis實例是否能夠正常工做，經過API向其餘程序報告redis的狀態，若是redis master不能工做，則會自動啓動故障轉移進程，將其中的一個slave提高爲master，其餘的slave從新設置新的master服務器。

    sentinel是一個分佈式系統，在源碼包的src目錄下會有redis-sentinel命令，其實比較其和redis-server命令的md5sum值，發現是同樣的，你能夠在多臺機器上部署sentinel進程，共同監控redis實例。

redis sentinel    10.20.112.26:26379
redis master      10.20.112.26:6379
redis slave       10.20.112.26:6380
redis slave       10.20.112.27:6379
redis slave       10.20.112.27:6380

部署10.20.112.26，全部redis配置文件在/etc/redis/

redis_6379.conf

daemonize yes
pidfile /var/run/redis_6379.pid
port 6379
bind 0.0.0.0
timeout 0
tcp-keepalive 0
loglevel notice
logfile /var/log/redis_6379.log
databases 16
save 900 1
save 300 10
save 60 10000
stop-writes-on-bgsave-error yes
rdbcompression yes
rdbchecksum yes
dbfilename dump_6379.rdb
dir ./
slave-serve-stale-data yes
slave-read-only yes
repl-disable-tcp-nodelay no
slave-priority 100
appendonly no
appendfsync everysec
no-appendfsync-on-rewrite no
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
lua-time-limit 5000
slowlog-log-slower-than 10000
slowlog-max-len 128
hash-max-ziplist-entries 512
hash-max-ziplist-value 64
list-max-ziplist-entries 512
list-max-ziplist-value 64
set-max-intset-entries 512
zset-max-ziplist-entries 128
zset-max-ziplist-value 64
activerehashing yes
client-output-buffer-limit normal 0 0 0
client-output-buffer-limit slave 256mb 64mb 60
client-output-buffer-limit pubsub 32mb 8mb 60
hz 10
aof-rewrite-incremental-fsync yes

redis_6380.conf

###配置和redis_6379.conf大部分一致，只要修改以下幾行
pidfile /var/run/redis_6380.pid
port 6380
logfile /var/log/redis_6380.log
dbfilename dump_6380.rdb

sentinel.conf

port 26379
sentinel monitor mymaster 0.0.0.0 6379 1
sentinel down-after-milliseconds mymaster 30000
sentinel can-failover mymaster yes
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 900000

    部署完畢後，啓動redis實例，三個配置文件中sentinel.conf的配置文件你們不常見，不過裏面內容比較少，解釋起來很方便，在文章最後面有解釋。

部署10.20.112.27

    在27上面一樣部署redis_6379.conf和redis_6380.conf，方法同26同樣，能夠在27上部署sentinel，也能夠不用部署sentinel，我選擇沒有部署sentinel。

在10.20.112.26/27上分別執行以下命令：

###10.20.112.26
#終端1
redis-cli -p 6379

#終端2
redis-cli -p 6380
  SLAVEOF 10.20.112.26 6379


###10.20.112.27
#終端1
redis-cli -p 6379
  SLAVEOF 10.20.112.26 6379
#終端2
redis-cli -p 6380
  SLAVEOF 10.20.112.26 6379

在26上執行以下命令：

redis-cli -p 6379 INFO Replication

效果以下：

   能夠看到有三臺slave鏈接上來。

在27上執行以下命令：

redis-cli -p 6379 INFO Replication
redis-cli -p 6380 INFO Replication

效果以下：

   能夠看到他們的master都是26的6379

在26上啓動sentinel

redis-server sentinel.conf --sentinel

效果以下：

執行以下命令，查看master信息：

redis-cli -h 10.20.112.26 -p 26379 info sentinel

效果以下：

     能夠看到master的信息及狀態。

開始模擬redis master故障，在26上執行以下命令：

redis-cli -p 6379 shutdown

sentinel日誌以下：

在27上執行如下命令：

redis-cli -p 6379 info Replication
redis-cli -p 6380 info Replication

結果以下：

   能夠看到sentinel選擇10.20.112.27的6380爲新的redis master。並且其餘redis slave已經連接到新的master上面了。

下面咱們接着恢復26上面的6379 redis，這時候27的6380是master，26的6380和27的6379做爲slave連接到master上面。26執行以下命令：

redis-server redis_6379.conf

sentinel日誌以下：

這時候咱們在27上看看6379和6380的信息：

redis-cli -p 6379 info Replication
redis-cli -p 6380 info Replication

效果以下：

   能夠看到新恢復的26的6379並無恢復到master，而是做爲新的slave連接到現有的master上面。

sentinel.conf詳解

#sentinel實例監聽的端口
port 26379


#告訴sentinel監控這個名爲mymaster的master，它的監聽地址是127.0.0.1，而且設置failing sentinel爲2，表示當有2臺sentinel探測到該實例失敗時，該實例進入O_DOWN狀態。
sentinel monitor mymaster 127.0.0.1 6379 2


#redis實例多少毫秒不可達sentinel，sentinel則認爲該實例的狀態轉變爲S_DOWN，可是這個狀態還不足以啓動automatic failover機制。只有足夠多的實例認爲該實例是S_DOWN狀態，這時該實例進入O_DOWN狀態，
sentinel down-after-milliseconds mymaster 30000


#在sentinel檢測到O_DOWN後，是否對這臺redis啓動failover機制
sentinel can-failover mymaster yes


#在failover時，咱們能夠設置容許多少slave同時能夠鏈接新的master。該值越低，完成failover的進程花費的時間越多，若是對從數據要求不是很及時，你可能不須要全部的從在同一時間同步到新的主（同步到新主，意味着數據重傳），你肯定在宕機時只有一個從可達則設置爲1（若是這樣的話其它的從還能用老的數據來幹活
sentinel parallel-syncs mymaster 1


#設置failover的超時時間是多少毫秒
sentinel failover-timeout mymaster 900000

redis sentinel在監控redis實例時有兩種redis宕機狀態S_DOWN和O_DOWN：

    S_DOWN:當sentinel在指定的超時時間內沒有收到一個正確的ping回覆值，則認爲是S_DOWN

    O_DOWN:O_DOWN的條件是有足夠多的sentinel認爲該redis實例是S_DOWN。

    注意：O_DOWN只能是發生在主服務器，sentinel和其餘從服務器不會發生O_DOWN

上面只是簡單的試用，sentinel還沒合併進穩定版本中，你們能夠嘗試試用。