使用Sentinel機制實現Redis高可用主從複製

Sentinel(哨兵)是用於監控redis集羣中Master狀態的工具，其已經被集成在redis2.4+的版本中

1、Sentinel做用：

1)：Master狀態檢測 

2)：若是Master異常，則會進行Master-Slave切換，將其中一個Slave做爲Master，將以前的Master做爲Slave

3)：Master-Slave切換後，master_redis.conf、slave_redis.conf和sentinel.conf的內容都會發生改變，即master_redis.conf中會多一行slaveof的配置，sentinel.conf的監控目標會隨之調換。

2、Sentinel工做方式：

1)：每一個Sentinel以每秒鐘一次的頻率向它所知的Master，Slave以及其餘 Sentinel 實例發送一個PING命令

2)：若是一個實例（instance）距離最後一次有效回覆 PING 命令的時間超過 down-after-milliseconds選項所指定的值，則這個實例會被Sentinel 標記爲主觀下線。

3)：若是一個Master被標記爲主觀下線，則正在監視這個Master的全部Sentinel要以每秒一次的頻率確認Master的確進入了主觀下線狀態。

4)：當有足夠數量的 Sentinel（大於等於配置文件指定的值）在指定的時間範圍內確認Master的確進入了主觀下線狀態，則Master會被標記爲客觀下線

5)：在通常狀況下，每一個Sentinel會以每 10 秒一次的頻率向它已知的全部Master，Slave發送INFO命令

6)：當Master被Sentinel標記爲客觀下線時，Sentinel向下線的Master的全部Slave發送INFO命令的頻率會從10秒一次改成每秒一次

7)：若沒有足夠數量的Sentinel贊成Master已經下線，Master的客觀下線狀態就會被移除。 

若Master從新向Sentinel的PING命令返回有效回覆，Master的主觀下線狀態就會被移除。

3、主觀下線和客觀下線

主觀下線：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。

架構：  

 station11:192.168.1.11 redis master 6379 sentinel 26379

 station12:192.168.1.12 redis slave1 6379 sentinel 26479

 station13:192.168.1.13 redis slave2 6379 sentinel 26579

環境：Centos6.8  epel-6-ali.repo  ansible

一、ansible安裝3機redis

[root@station11 ~]# ansible all -m command -a "yum -y install gcc gcc-c++ tcl"

[root@station11 ~]# wget http://download.redis.io/releases/redis-3.2.6.tar.gz

[root@station11 ~]# ansible all -m copy -a 'src=/root/redis-3.2.6.tar.gz dest=/root/'

[root@station11 ~]# ansible all -m command -a 'tar -zxvf redis-3.2.6.tar.gz -C /usr/local'

[root@station11 ~]# ansible all -m file -a "src=/usr/local/redis-3.2.6 dest=/usr/local/redis state=link"

[root@station11 ~]# vim make.sh

#!/bin/bash
cd /usr/local/redis
make && make install

[root@station11 ~]# chmod +x make.sh

[root@station11 ~]# ansible all -m copy -a "src=/root/make.sh dest=/root/ mode=0755"

[root@station11 ~]# ansible all -m shell -a "/root/make.sh"

[root@station11 ~]# ansible all -m command -a "mkdir /etc/redis"

[root@station11 ~]# ansible all -m command -a "mkdir -pv /data/redis/6379"

[root@station11 ~]# ansible all -m copy -a "src=/usr/local/redis/redis.conf dest=/etc/redis/"

2.一、修改主庫配置文件

[root@station11 ~]# vim /etc/redis/redis.conf

daemonize  yes  以守護進程模式運行
bind 192.168.1.11 本機主庫監聽本機地址
logfile  "/var/log/redis_6379.log"  指定日誌文件
dir /data/redis/6379  指定rdb數據庫存放目錄
masterauth redhat  啓動主庫驗證
requirepass redhat  啓動用戶進入密碼驗證

[root@station11 ~]# redis-server /etc/redis/redis.conf&

[root@station11 ~]# ss -nutlp | grep redis

tcp  LISTEN   0   128  192.168.1.11:6379   *:*   users:(("redis-server",6447,4))

2.二、爲slave1提供redis配置文件

[root@station12 ~]# vim /etc/redis/redis.conf

bind 192.168.1.12    #綁定slave1的地址
logfile "/var/log/redis_6379.log"
dir /data/redis/6379
slaveof 192.168.1.11 6379 #此選項是主從配置的關鍵，指向master的ip和redis端口
slave-priority 95  #slave1服務器的優先級

[root@station12 ~]# nohup redis-server /etc/redis/redis.conf&   後臺執行

[1] 2572

[root@station11 ~]# tail -f  /var/log/redis_6379.log   主庫日誌

6447:M 22 Jan 23:49:34.809 * Slave 192.168.1.12:6379 asks for synchronization
6447:M 22 Jan 23:49:34.809 * Full resync requested by slave 192.168.1.12:6379

[root@station12 ~]# tail -f  /var/log/redis_6379.log   從庫日誌

7655:S 22 Jan 23:49:34.555 * Connecting to MASTER 192.168.1.11:6379
7655:S 22 Jan 23:49:34.555 * MASTER <-> SLAVE sync started

2.三、爲slave2提供redis配置文件

[root@station12 ~]# scp /etc/redis/redis.conf 192.168.1.13:/etc/redis/

[root@station13 ~]# vim /etc/redis/redis.conf

bind 192.168.1.13
slaveof 192.168.1.11 6379
slave-priority 97

[root@station13 ~]# nohup redis-server /etc/redis/redis.conf&

[1] 5659

[root@station13 ~]# tail -f /var/log/redis_6379.log 

5659:S 23 Jan 00:00:12.656 * Connecting to MASTER 192.168.1.11:6379
5659:S 23 Jan 00:00:12.656 * MASTER <-> SLAVE sync started

2.四、檢查主從庫複製正常？

[root@station11 ~]# redis-cli -h 192.168.1.11 -p 6379

192.168.1.11:6379> info replication
# Replication
role:master
connected_slaves:2
slave0:ip=192.168.1.12,port=6379,state=online,offset=1023,lag=1
slave1:ip=192.168.1.13,port=6379,state=online,offset=1023,lag=1
master_repl_offset:1023
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:2
repl_backlog_histlen:1022
192.168.1.11:6379> set 1 1000
OK
192.168.1.11:6379> keys *
1) "1"
192.168.1.11:6379> get 1
"1000"

[root@station12 ~]# redis-cli -h 192.168.1.12 -p 6379

192.168.1.12:6379> keys *
1) "1"
192.168.1.12:6379> get 1
"1000"

[root@station13 ~]# redis-cli -h 192.168.1.13 -p 6379

192.168.1.13:6379> get 1
"1000"
192.168.1.13:6379> keys *
1) "1"

3.一、主庫sentinel配置文件

[root@station11 ~]# cp /usr/local/redis/sentinel.conf /etc/redis/

[root@station11 ~]# vim /etc/redis/sentinel.conf

port 26379
sentinel monitor mymaster 192.168.1.11 6379 1
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 60000
logfile "/var/log/sentinel_master.log"
protected-mode no  打開保護模式，不然sentinel不會監聽除了127.0.0.1和192.168.1.1以外IP，也就不會超過1張投票給station11已經死，須要從新選舉主服
注意：192.168.1.12和192.168.1.13上的sentinel配置和192.168.1.11同樣，只有端口和log不同以下：
slave1 192.168.1.12

[root@station11 ~]# ansible all -m copy -a "src=/etc/redis/sentinel.conf dest=/etc/redis/"

3.二、從庫slave1的sentinel配置文件

[root@station12 ~]# vim /etc/redis/sentinel.conf

port 26479
logfile "/var/log/sentinel_slave1.log"

3.三、從庫slave1的sentinel配置文件

[root@station13 ~]# vim /etc/redis/sentinel.conf

port 26579
logfile "/var/log/sentinel_slave2.log"

3.四、主從庫sentinel鏈接時日誌

[root@station11 ~]# nohup redis-sentinel /etc/redis/sentinel.conf&

[1] 6640

[root@station11 ~]# tail -f /var/log/sentinel_master.log

6640:X 23 Jan 00:22:34.910 # Sentinel ID is 17c9ee07632d60c4c0aa75a853bbda93966caa22
6640:X 23 Jan 00:22:34.910 # +monitor master mymaster 192.168.1.11 6379 quorum 1
6640:X 23 Jan 00:22:34.910 * +slave slave 192.168.1.12:6379 192.168.1.12 6379 @ mymaster 192.168.1.11 6379
6640:X 23 Jan 00:22:34.912 * +slave slave 192.168.1.13:6379 192.168.1.13 6379 @ mymaster 192.168.1.11 6379

[root@station12 ~]# nohup redis-sentinel /etc/redis/sentinel.conf&

[2] 7782

[root@station12 ~]# tail -f /var/log/sentinel_slave1.log 

7782:X 23 Jan 00:24:36.059 # Sentinel ID is 7c000aa564ed603eeefd031333ebc2c916597ec6
7782:X 23 Jan 00:24:36.059 # +monitor master mymaster 192.168.1.11 6379 quorum 1
7782:X 23 Jan 00:24:36.060 * +slave slave 192.168.1.12:6379 192.168.1.12 6379 @ mymaster 192.168.1.11 6379
7782:X 23 Jan 00:24:36.061 * +slave slave 192.168.1.13:6379 192.168.1.13 6379 @ mymaster 192.168.1.11 6379
7782:X 23 Jan 00:24:36.516 * +sentinel sentinel 17c9ee07632d60c4c0aa75a853bbda93966caa22 192.168.1.11 26379 @ mymaster 192.168.1.11 6379
7782:X 23 Jan 00:24:41.597 # +sdown sentinel 17c9ee07632d60c4c0aa75a853bbda93966caa22 192.168.1.11 26379 @ mymaster 192.168.1.11 6379

[root@station13 ~]# nohup redis-sentinel /etc/redis/sentinel.conf&

[2] 5763

[root@station13 ~]# tail -f /var/log/sentinel_slave2.log

5763:X 23 Jan 00:26:14.286 # Sentinel ID is a78518e4955d3602c61e212be0cbdc378daa3cdc
5763:X 23 Jan 00:26:14.286 # +monitor master mymaster 192.168.1.11 6379 quorum 1
5763:X 23 Jan 00:26:14.287 * +slave slave 192.168.1.12:6379 192.168.1.12 6379 @ mymaster 192.168.1.11 6379
5763:X 23 Jan 00:26:14.288 * +slave slave 192.168.1.13:6379 192.168.1.13 6379 @ mymaster 192.168.1.11 6379
5763:X 23 Jan 00:26:14.708 * +sentinel sentinel 7c000aa564ed603eeefd031333ebc2c916597ec6 192.168.1.12 26479 @ mymaster 192.168.1.11 6379
5763:X 23 Jan 00:26:15.779 * +sentinel sentinel 17c9ee07632d60c4c0aa75a853bbda93966caa22 192.168.1.11 26379 @ mymaster 192.168.1.11 6379
5763:X 23 Jan 00:26:19.716 # +sdown sentinel 7c000aa564ed603eeefd031333ebc2c916597ec6 192.168.1.12 26479 @ mymaster 192.168.1.11 6379
5763:X 23 Jan 00:26:20.797 # +sdown sentinel 17c9ee07632d60c4c0aa75a853bbda93966caa22 192.168.1.11 26379 @ mymaster 192.168.1.11 6379

3.五、客戶端查看sentinel

[root@station11 ~]# redis-cli -p 26379

127.0.0.1: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.1.11:6379,slaves=2,sentinels=3
127.0.0.1:26379> sentinel masters
1)  1) "name"
    2) "mymaster"
    3) "ip"
    4) "192.168.1.11"
    5) "port"
    6) "6379"
    7) "runid"
    8) "e0ae553828b47db69e0d75ef8c20b30f1ed96c3c"
    9) "flags"
   10) "master"
 .....................................................
127.0.0.1:26379> sentinel slaves mymaster
1)  1) "name"
    2) "192.168.1.12:6379"
    3) "ip"
    4) "192.168.1.12"
    5) "port"
    6) "6379"
    7) "runid"
    8) "486ebcb9ad89bf9c6889fd98b0d669c0addb9d10"
    9) "flags"
   10) "slave"
 ....................................................
   31) "master-link-status"
   32) "ok"
   33) "master-host"
   34) "192.168.1.11"
   35) "master-port"
   36) "6379"
   37) "slave-priority"
   38) "95"
   39) "slave-repl-offset"
   40) "75763"
2)  1) "name"
    2) "192.168.1.13:6379"
    3) "ip"
    4) "192.168.1.13"
    5) "port"
    6) "6379"
    7) "runid"
    8) "30fdcff948a6e249a87da41ef42f41897eaf4104"
    9) "flags"
   10) "slave"
 .................................................
   31) "master-link-status"
   32) "ok"
   33) "master-host"
   34) "192.168.1.11"
   35) "master-port"
   36) "6379"
   37) "slave-priority"
   38) "97"
   39) "slave-repl-offset"
   40) "75763"

四、進行容災測試：

4.一、模擬redis的HA集羣slave服務器宕機

停掉一臺slave，觀察集羣的狀態，這裏將slave2的redis-server停掉

[root@station13 ~]# killall redis-server

首先查看三臺sentinel的日誌信息，都會刷新一條，以下：

[root@station11 ~]# tail -f /var/log/sentinel_master.log

6640:X 23 Jan 00:33:05.032 # +sdown slave 192.168.1.13:6379 192.168.1.13 6379 @ mymaster 192.168.1.11 6379

能夠看到192.168.1.13掉了

到master服務器上查看主從複製信息:

192.168.1.11:6379> info replication
# Replication
role:master
connected_slaves:1
slave0:ip=192.168.1.12,port=6379,state=online,offset=131310,lag=0
master_repl_offset:131310
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:2
repl_backlog_histlen:131309

能夠看到192.168.1.13已經被master剔除了!

再從新將slave2的redis-server啓動起來，繼續觀察：

[root@station13 ~]# nohup redis-server /etc/redis/redis.conf&

三臺sentinel的日誌信息，以下：

[root@station11 ~]# tail -f /var/log/sentinel_master.log

6640:X 23 Jan 00:36:10.845 * +reboot slave 192.168.1.13:6379 192.168.1.13 6379 @ mymaster 192.168.1.11 6379
6640:X 23 Jan 00:36:10.936 # -sdown slave 192.168.1.13:6379 192.168.1.13 6379 @ mymaster 192.168.1.11 6379

能夠看出192.168.1.13已經從新啓動了！

在master上繼續查看複製信息，以下：13主機又重回集羣

192.168.1.11:6379> info replication
# Replication
role:master
connected_slaves:2
slave0:ip=192.168.1.12,port=6379,state=online,offset=162401,lag=1
slave1:ip=192.168.1.13,port=6379,state=online,offset=162401,lag=1
master_repl_offset:162401
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:2
repl_backlog_histlen:162400

4.二、模擬redis的HA集羣master服務器宕機 

說明：停掉master的6379端口，假設master是由於外部問題宕機了（直接kill掉redis-server進程）

[root@station11 ~]# killall redis-server

觀察三臺redis的sentinel日誌：

[root@station11 ~]#tail -f /var/log/sentinel_master.log

6640:X 23 Jan 00:39:07.305 # +sdown master mymaster 192.168.1.11 6379
6640:X 23 Jan 00:39:07.305 # +odown master mymaster 192.168.1.11 6379 #quorum 1/1
6640:X 23 Jan 00:39:07.305 # +new-epoch 1
6640:X 23 Jan 00:39:07.305 # +try-failover master mymaster 192.168.1.11 6379
6640:X 23 Jan 00:39:07.308 # +vote-for-leader 17c9ee07632d60c4c0aa75a853bbda93966caa22 1
6640:X 23 Jan 00:39:17.380 # -failover-abort-not-elected master mymaster 192.168.1.11 6379
6640:X 23 Jan 00:39:17.438 # Next failover delay: I will not start a failover before Mon Jan 23 00:41:07 2017
6640:X 23 Jan 00:41:07.432 # +new-epoch 2
6640:X 23 Jan 00:41:07.432 # +try-failover master mymaster 192.168.1.11 6379
6640:X 23 Jan 00:41:07.434 # +vote-for-leader 17c9ee07632d60c4c0aa75a853bbda93966caa22 2
6640:X 23 Jan 00:41:17.505 # -failover-abort-not-elected master mymaster 192.168.1.11 6379
6640:X 23 Jan 00:41:17.592 # Next failover delay: I will not start a failover before Mon Jan 23 00:43:07 2017

一直嘗試恢復master失敗，投票只有1票，從新選舉出新主服數量不夠

[root@station11 ~]#tail -f sentinel_master.log

6732:X 23 Jan 01:24:18.921 # +new-epoch 18
6732:X 23 Jan 01:24:18.933 # +vote-for-leader a78518e4955d3602c61e212be0cbdc378daa3cdc 18
6732:X 23 Jan 01:24:18.946 # +sdown master mymaster 192.168.1.11 6379
6732:X 23 Jan 01:24:18.946 # +odown master mymaster 192.168.1.11 6379 #quorum 1/1
6732:X 23 Jan 01:24:18.946 # Next failover delay: I will not start a failover before Mon Jan 23 01:26:19 2017
6732:X 23 Jan 01:24:19.240 # +config-update-from sentinel a78518e4955d3602c61e212be0cbdc378daa3cdc 192.168.1.13 26579 @ mymaster 192.168.1.11 6379
6732:X 23 Jan 01:24:19.240 # +switch-master mymaster 192.168.1.11 6379 192.168.1.12 6379   切換master從11到12
6732:X 23 Jan 01:24:19.241 * +slave slave 192.168.1.13:6379 192.168.1.13 6379 @ mymaster 192.168.1.12 6379
6732:X 23 Jan 01:24:19.241 * +slave slave 192.168.1.11:6379 192.168.1.11 6379 @ mymaster 192.168.1.12 6379
6732:X 23 Jan 01:24:24.258 # +sdown slave 192.168.1.11:6379 192.168.1.11 6379 @ mymaster 192.168.1.12 6379

[root@station11 ~]#tail -f /var/log/redis_slave1.log   #slave1啓動master模式

7846:M 23 Jan 01:24:18.857 * MASTER MODE enabled (user request from 'id=7 addr=192.168.1.13:44615 fd=10 name=sentinel-a78518e4-cmd age=183 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')
7846:M 23 Jan 01:24:18.858 # CONFIG REWRITE executed with success.
7846:M 23 Jan 01:24:19.060 * Slave 192.168.1.13:6379 asks for synchronization
7846:M 23 Jan 01:24:19.061 * Full resync requested by slave 192.168.1.13:6379
7846:M 23 Jan 01:24:19.061 * Starting BGSAVE for SYNC with target: disk
7846:M 23 Jan 01:24:19.061 * Background saving started by pid 7852
7852:C 23 Jan 01:24:19.091 * DB saved on disk
7852:C 23 Jan 01:24:19.091 * RDB: 8 MB of memory used by copy-on-write
7846:M 23 Jan 01:24:19.178 * Background saving terminated with success
7846:M 23 Jan 01:24:19.178 * Synchronization with slave 192.168.1.13:6379 succeeded

[root@station12 ~]# redis-cli -h 192.168.1.12 -p 6379

192.168.1.12:6379> info replication
# Replication
role:master
connected_slaves:1
slave0:ip=192.168.1.13,port=6379,state=online,offset=65036,lag=0
master_repl_offset:65036
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:2
repl_backlog_histlen:65035

[root@station12 ~]# redis-cli -h 192.168.1.12 -p 26479

192.168.1.12:26479> 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.1.12:6379,slaves=2,sentinels=3
192.168.1.12:26479> sentinel masters
1)  1) "name"
    2) "mymaster"
    3) "ip"
    4) "192.168.1.12"
    5) "port"
    6) "6379"
    7) "runid"
    8) "0a4b1b8c6b3595dde9446697a025fca0f0530ac7"
    9) "flags"
   10) "master"
 ........................................................
   31) "num-slaves"
   32) "2"
   33) "num-other-sentinels"
   34) "2"
   35) "quorum"
   36) "1"
   37) "failover-timeout"
   38) "60000"
   39) "parallel-syncs"
   40) "1"
192.168.1.12:26479> sentinel slaves mymaster
1)  1) "name"
    2) "192.168.1.13:6379"
    3) "ip"
    4) "192.168.1.13"
    5) "port"
    6) "6379"
    7) "runid"
    8) "eb29d1741121071accc633db186f63b81fc33ffc"
    9) "flags"
   10) "slave"
 ........................................................
   29) "master-link-down-time"
   30) "0"
   31) "master-link-status"
   32) "ok"
   33) "master-host"
   34) "192.168.1.12"
   35) "master-port"
   36) "6379"
   37) "slave-priority"
   38) "97"
   39) "slave-repl-offset"
   40) "112029"
2)  1) "name"
    2) "192.168.1.11:6379"
    3) "ip"
    4) "192.168.1.11"
    5) "port"
    6) "6379"
    7) "runid"
    8) ""
    9) "flags"
   10) "s_down,slave,disconnected"
 ..............................................
   27) "role-reported"
   28) "slave"
   29) "role-reported-time"
   30) "546434"
   31) "master-link-down-time"
   32) "0"
   33) "master-link-status"
   34) "err"
   35) "master-host"
   36) "?"
   37) "master-port"
   38) "0"
   39) "slave-priority"
   40) "100"
   41) "slave-repl-offset"
   42) "0"

假如此時192.168.1.11這臺服務器的redis-server恢復了，也會被加入slave隊列中

[root@station11 ~]# nohup redis-server /etc/redis/redis.conf&

[root@station11 ~]# tail -f sentinel_master.log

6732:X 23 Jan 01:35:31.759 # -sdown slave 192.168.1.11:6379 192.168.1.11 6379 @ mymaster 192.168.1.12 6379
6732:X 23 Jan 01:35:41.740 * +convert-to-slave slave 192.168.1.11:6379 192.168.1.11 6379 @ mymaster 192.168.1.12 6379

[root@station12 ~]#tail -f redis_6379.log

7846:M 23 Jan 01:35:42.083 * Slave 192.168.1.11:6379 asks for synchronization
7846:M 23 Jan 01:35:42.083 * Full resync requested by slave 192.168.1.11:6379
7846:M 23 Jan 01:35:42.083 * Starting BGSAVE for SYNC with target: disk
7846:M 23 Jan 01:35:42.084 * Background saving started by pid 7859
7859:C 23 Jan 01:35:42.095 * DB saved on disk
7859:C 23 Jan 01:35:42.095 * RDB: 6 MB of memory used by copy-on-write
7846:M 23 Jan 01:35:42.177 * Background saving terminated with success
7846:M 23 Jan 01:35:42.178 * Synchronization with slave 192.168.1.11:6379 succeeded

五、查看故障轉移以後redis和sentinel配置文件的變化

5.一、首先查看三臺redis的redis.conf文件

由於模擬1.11服務器的redis-server宕機然後又從新開啓，因此sentinel機制rewrite了redis.conf文件，以下：

[root@station11 ~]# vim /etc/redis/redis.conf 

# Generated by CONFIG REWRITE
slaveof 192.168.1.12 6379

rewrite機制在1.11的redis.conf末尾添加了如上2行，表示指向1.12這臺新的master

查看1.12的redis.conf文件，你會發現原來的參數slaveof 192.168.1.11 6379 已經消失了！

查看1.13的redis.conf文件，以下：

slaveof 192.168.1.12 6379  

由原來的指向192.168.1.11變成了指向新的master 192.168.1.12

六、查看三臺redis的sentinel.conf文件

1.11上的sentinel.conf文件：

#cat sentinel.conf
port 26379
sentinel monitor mymaster 192.168.1.12 6379 1  #已經由原來的192.168.1.11變成了192.168.1.12
# Generated by CONFIG REWRITE
sentinel known-slave mymaster 192.168.1.11 6379
sentinel known-slave mymaster 192.168.1.13 6379
sentinel known-sentinel mymaster 192.168.1.12 26479 7c000aa564ed603eeefd031333ebc2c916597ec6
sentinel known-sentinel mymaster 192.168.1.13 26579 a78518e4955d3602c61e212be0cbdc378daa3cdc
  #後邊的字符串是sentinel啓動時候爲每一臺redis生成的惟一標識

1.12上的sentinel.conf

#cat sentinel.conf
port 26479
sentinel monitor mymaster 192.168.1.12 6379 1
# Generated by CONFIG REWRITE
sentinel known-slave mymaster 192.168.1.13 6379
sentinel known-slave mymaster 192.168.1.11 6379
sentinel known-sentinel mymaster 192.168.1.13 26579 a78518e4955d3602c61e212be0cbdc378daa3cdc
sentinel known-sentinel mymaster 192.168.1.11 26379 17c9ee07632d60c4c0aa75a853bbda93966caa22

1.13上的sentinel.conf

#cat sentinel.conf
port 26579
sentinel monitor mymaster 192.168.1.12 6379 1
# Generated by CONFIG REWRITE
sentinel known-slave mymaster 192.168.1.11 6379
sentinel known-slave mymaster 192.168.1.13 6379
sentinel known-sentinel mymaster 192.168.1.12 26479 7c000aa564ed603eeefd031333ebc2c916597ec6
sentinel known-sentinel mymaster 192.168.1.11 26379 17c9ee07632d60c4c0aa75a853bbda93966caa22