哨兵在redis主从与集群上的表现不同

Posted 2020-10-27 feifeizouzou

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了哨兵在redis主从与集群上的表现不同相关的知识，希望对你有一定的参考价值。

-------------------------------------哨兵+主从实验（3个）：---------------------------------------------------

实验一：
哨兵节点failover主：

当前主为56.33 6379 从为 56.22 6380

哨兵前后状态：
[[email protected] ~]# 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.56.33:6379,slaves=1,sentinels=1
127.0.0.1:26379>
127.0.0.1:26379>
127.0.0.1:26379> sentinel failover mymaster
OK
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.56.22:6380,slaves=1,sentinels=1
127.0.0.1:26379>

哨兵日志状态：
9559:X 08 Mar 00:04:53.300 # Executing user requested FAILOVER of ‘mymaster‘
9559:X 08 Mar 00:04:53.301 # +new-epoch 17
9559:X 08 Mar 00:04:53.301 # +try-failover master mymaster 192.168.56.33 6379
9559:X 08 Mar 00:04:53.331 # +vote-for-leader ad2f3e56df9e2b468cfbc18b7121615d12cbfbc1 17
9559:X 08 Mar 00:04:53.331 # +elected-leader master mymaster 192.168.56.33 6379
9559:X 08 Mar 00:04:53.331 # +failover-state-select-slave master mymaster 192.168.56.33 6379
9559:X 08 Mar 00:04:53.407 # +selected-slave slave 192.168.56.22:6380 192.168.56.22 6380 @ mymaster 192.168.56.33 6379
9559:X 08 Mar 00:04:53.407 * +failover-state-send-slaveof-noone slave 192.168.56.22:6380 192.168.56.22 6380 @ mymaster 192.168.56.33 6379
9559:X 08 Mar 00:04:53.467 * +failover-state-wait-promotion slave 192.168.56.22:6380 192.168.56.22 6380 @ mymaster 192.168.56.33 6379
9559:X 08 Mar 00:04:54.428 # +promoted-slave slave 192.168.56.22:6380 192.168.56.22 6380 @ mymaster 192.168.56.33 6379
9559:X 08 Mar 00:04:54.428 # +failover-state-reconf-slaves master mymaster 192.168.56.33 6379
9559:X 08 Mar 00:04:54.483 # +failover-end master mymaster 192.168.56.33 6379
9559:X 08 Mar 00:04:54.483 # +switch-master mymaster 192.168.56.33 6379 192.168.56.22 6380
9559:X 08 Mar 00:04:54.483 * +slave slave 192.168.56.33:6379 192.168.56.33 6379 @ mymaster 192.168.56.22 6380
9559:X 08 Mar 00:05:04.633 * +convert-to-slave slave 192.168.56.33:6379 192.168.56.33 6379 @ mymaster 192.168.56.22 6380

结论：日志和哨兵均显示为主库变为 56.22 6380

实验二：

直接宕机主库：当前主库为 56.22 6380 从库为 56.33 6379

哨兵状态：

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.56.22:6380,slaves=1,sentinels=1
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=odown,address=192.168.56.22:6380,slaves=1,sentinels=1
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.56.33:6379,slaves=1,sentinels=1 （备注虽然6380已经宕机，但这里仍然显示有个从）

哨兵的原始未启动的配置文件：

port 26379
daemonize yes
logfile "26379.log"
dir "/data/redis"
sentinel myid ad2f3e56df9e2b468cfbc18b7121615d12cbfbc1
sentinel monitor mymaster 192.168.56.33 6379 1
#sentinel auth-pass mymaster beijing
#sentinel auth-pass mymaster beijing
sentinel auth-pass mymaster beijing
# Generated by CONFIG REWRITE
maxclients 4064
sentinel config-epoch mymaster 18

sentinel leader-epoch mymaster 18
sentinel known-slave mymaster 192.168.56.22 6380
sentinel current-epoch 18

哨兵日志的状态：

9559:X 08 Mar 00:11:16.484 # +sdown master mymaster 192.168.56.22 6380
9559:X 08 Mar 00:11:16.484 # +odown master mymaster 192.168.56.22 6380 #quorum 1/1
9559:X 08 Mar 00:11:16.484 # +new-epoch 18
9559:X 08 Mar 00:11:16.484 # +try-failover master mymaster 192.168.56.22 6380
9559:X 08 Mar 00:11:16.495 # +vote-for-leader ad2f3e56df9e2b468cfbc18b7121615d12cbfbc1 18
9559:X 08 Mar 00:11:16.495 # +elected-leader master mymaster 192.168.56.22 6380
9559:X 08 Mar 00:11:16.495 # +failover-state-select-slave master mymaster 192.168.56.22 6380
9559:X 08 Mar 00:11:16.548 # +selected-slave slave 192.168.56.33:6379 192.168.56.33 6379 @ mymaster 192.168.56.22 6380
9559:X 08 Mar 00:11:16.548 * +failover-state-send-slaveof-noone slave 192.168.56.33:6379 192.168.56.33 6379 @ mymaster 192.168.56.22 6380
9559:X 08 Mar 00:11:16.614 * +failover-state-wait-promotion slave 192.168.56.33:6379 192.168.56.33 6379 @ mymaster 192.168.56.22 6380
9559:X 08 Mar 00:11:16.888 # +promoted-slave slave 192.168.56.33:6379 192.168.56.33 6379 @ mymaster 192.168.56.22 6380
9559:X 08 Mar 00:11:16.888 # +failover-state-reconf-slaves master mymaster 192.168.56.22 6380
9559:X 08 Mar 00:11:16.942 # +failover-end master mymaster 192.168.56.22 6380
9559:X 08 Mar 00:11:16.942 # +switch-master mymaster 192.168.56.22 6380 192.168.56.33 6379
9559:X 08 Mar 00:11:16.942 * +slave slave 192.168.56.22:6380 192.168.56.22 6380 @ mymaster 192.168.56.33 6379
9559:X 08 Mar 00:11:46.981 # +sdown slave 192.168.56.22:6380 192.168.56.22 6380 @ mymaster 192.168.56.33 6379

实验三：再重新把宕掉的节点重启：

哨兵：
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.56.33:6379,slaves=1,sentinels=1

哨兵配置：
port 26379
daemonize yes
logfile "26379.log"
dir "/data/redis"
sentinel myid ad2f3e56df9e2b468cfbc18b7121615d12cbfbc1
sentinel monitor mymaster 192.168.56.33 6379 1
#sentinel auth-pass mymaster beijing
#sentinel auth-pass mymaster beijing
sentinel auth-pass mymaster beijing
# Generated by CONFIG REWRITE
maxclients 4064
sentinel config-epoch mymaster 18

sentinel leader-epoch mymaster 18
sentinel known-slave mymaster 192.168.56.22 6380
sentinel current-epoch 18

哨兵日志：

9559:X 08 Mar 00:11:46.981 # +sdown slave 192.168.56.22:6380 192.168.56.22 6380 @ mymaster 192.168.56.33 6379（这条是延续上一条的日志）
9559:X 08 Mar 00:19:33.851 # -sdown slave 192.168.56.22:6380 192.168.56.22 6380 @ mymaster 192.168.56.33 6379 （-sdown，相当于去掉了+sdown的标记）
9559:X 08 Mar 00:19:43.818 * +convert-to-slave slave 192.168.56.22:6380 192.168.56.22 6380 @ mymaster 192.168.56.33 6379

主库的日志：

9553:M 08 Mar 00:11:16.614 * Discarding previously cached master state.
9553:M 08 Mar 00:11:16.614 * MASTER MODE enabled (user request from ‘id=22 addr=192.168.56.33:33231 fd=7 name=sentinel-ad2f3e56-cmd age=382 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‘)
9553:M 08 Mar 00:11:16.615 # CONFIG REWRITE executed with success.
9553:M 08 Mar 00:19:44.610 * Slave 192.168.56.22:6380 asks for synchronization
9553:M 08 Mar 00:19:44.610 * Full resync requested by slave 192.168.56.22:6380
9553:M 08 Mar 00:19:44.610 * Starting BGSAVE for SYNC with target: disk
9553:M 08 Mar 00:19:44.611 * Background saving started by pid 9810
9810:C 08 Mar 00:19:44.626 * DB saved on disk
9810:C 08 Mar 00:19:44.626 * RDB: 10 MB of memory used by copy-on-write
9553:M 08 Mar 00:19:44.710 * Background saving terminated with success
9553:M 08 Mar 00:19:44.711 * Synchronization with slave 192.168.56.22:6380 succeeded

宕机恢复的从库的日志：

9648:M 08 Mar 00:19:37.788 * Increased maximum number of open files to 10032 (it was originally set to 1024).
_._
_.-``__ ‘‘-._
_.-`` `. `_. ‘‘-._ Redis 3.2.9 (00000000/0) 64 bit
.-`` .-```. ```\/ _.,_ ‘‘-._
( ‘ , .-` | `, ) Running in standalone mode
|`-._`-...-` __...-.``-._|‘` _.-‘| Port: 6380
| `-._ `._ / _.-‘ | PID: 9648
`-._ `-._ `-./ _.-‘ _.-‘
|`-._`-._ `-.__.-‘ _.-‘_.-‘|
| `-._`-._ _.-‘_.-‘ | http://redis.io
`-._ `-._`-.__.-‘_.-‘ _.-‘
|`-._`-._ `-.__.-‘ _.-‘_.-‘|
| `-._`-._ _.-‘_.-‘ |
`-._ `-._`-.__.-‘_.-‘ _.-‘
`-._ `-.__.-‘ _.-‘
`-._ _.-‘
`-.__.-‘

9648:M 08 Mar 00:19:37.791 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
9648:M 08 Mar 00:19:37.791 # Server started, Redis version 3.2.9
9648:M 08 Mar 00:19:37.791 # WARNING overcommit_memory is set to 0! Background save may fail under low memory condition. To fix this issue add ‘vm.overcommit_memory = 1‘ to /etc/sysctl.conf and then reboot or run the command ‘sysctl vm.overcommit_memory=1‘ for this to take effect.
9648:M 08 Mar 00:19:37.791 # WARNING you have Transparent Huge Pages (THP) support enabled in your kernel. This will create latency and memory usage issues with Redis. To fix this issue run the command ‘echo never > /sys/kernel/mm/transparent_hugepage/enabled‘ as root, and add it to your /etc/rc.local in order to retain the setting after a reboot. Redis must be restarted after THP is disabled.
9648:M 08 Mar 00:19:37.791 * DB loaded from disk: 0.000 seconds
9648:M 08 Mar 00:19:37.791 * The server is now ready to accept connections on port 6380
9648:M 08 Mar 00:19:37.791 * The server is now ready to accept connections at /tmp/redis6380.sock
9648:S 08 Mar 00:19:48.070 * SLAVE OF 192.168.56.33:6379 enabled (user request from ‘id=2 addr=192.168.56.33:50631 fd=7 name=sentinel-ad2f3e56-cmd age=11 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‘)
9648:S 08 Mar 00:19:48.070 # CONFIG REWRITE executed with success.
9648:S 08 Mar 00:19:48.859 * Connecting to MASTER 192.168.56.33:6379
9648:S 08 Mar 00:19:48.860 * MASTER <-> SLAVE sync started
9648:S 08 Mar 00:19:48.860 * Non blocking connect for SYNC fired the event.
9648:S 08 Mar 00:19:48.860 * Master replied to PING, replication can continue...
9648:S 08 Mar 00:19:48.861 * Partial resynchronization not possible (no cached master)
9648:S 08 Mar 00:19:48.863 * Full resync from master: ce0ed5724eae43fc6b17dcc933b10c1b8b7f35dd:1
9648:S 08 Mar 00:19:48.963 * MASTER <-> SLAVE sync: receiving 76 bytes from master
9648:S 08 Mar 00:19:48.963 * MASTER <-> SLAVE sync: Flushing old data
9648:S 08 Mar 00:19:48.963 * MASTER <-> SLAVE sync: Loading DB in memory
9648:S 08 Mar 00:19:48.963 * MASTER <-> SLAVE sync: Finished with success

--------------------以下是集群+ 哨兵模式的实验----------------------------------------------

ip 主从

架构 56.33 6379 6380
56.22 6379 6380
56.11 6379 6380

哨兵的初始配置文件：

port 26379
daemonize yes
logfile "/redis/logs/26379.log"
dir /redis/data
sentinel monitor mymaster1 192.168.56.11 6379 2

sentinel monitor mymaster2 192.168.56.22 6379 2

sentinel monitor mymaster3 192.168.56.33 6379 2

sentinel auth-pass mymaster1 beijing
sentinel auth-pass mymaster2 beijing
sentinel auth-pass mymaster3 beijing

sentinel down-after-milliseconds mymaster1 60000
sentinel down-after-milliseconds mymaster2 60000
sentinel down-after-milliseconds mymaster3 60000

sentinel parallel-syncs mymaster1 1
sentinel parallel-syncs mymaster2 1
sentinel parallel-syncs mymaster3 1

sentinel failover-timeout mymaster1 180000
sentinel failover-timeout mymaster2 180000
sentinel failover-timeout mymaster3 180000

启动后的哨兵配置文件：
port 26379
daemonize yes
logfile "/redis/logs/26379.log"
dir "/redis/data"
sentinel myid 13be94770954b8122340c3f1806f2f82f9e76360
sentinel monitor mymaster2 192.168.56.22 6379 2
sentinel down-after-milliseconds mymaster2 60000
sentinel auth-pass mymaster2 beijing
sentinel config-epoch mymaster2 0
sentinel leader-epoch mymaster2 0
sentinel known-slave mymaster2 192.168.56.22 6380
sentinel known-sentinel mymaster2 192.168.56.22 26379 77656703b90490d49d5302af4dffe329b40eca82
sentinel known-sentinel mymaster2 192.168.56.11 26379 ad4f90b73e809495d34f15f29dd5ee6b2d3a2443
sentinel monitor mymaster1 192.168.56.11 6379 2
sentinel down-after-milliseconds mymaster1 60000
sentinel auth-pass mymaster1 beijing
sentinel config-epoch mymaster1 0
sentinel leader-epoch mymaster1 0
sentinel known-slave mymaster1 192.168.56.11 6380
# Generated by CONFIG REWRITE
sentinel known-sentinel mymaster1 192.168.56.22 26379 77656703b90490d49d5302af4dffe329b40eca82
sentinel known-sentinel mymaster1 192.168.56.11 26379 ad4f90b73e809495d34f15f29dd5ee6b2d3a2443
sentinel monitor mymaster3 192.168.56.33 6379 2
sentinel down-after-milliseconds mymaster3 60000
sentinel auth-pass mymaster3 beijing
sentinel config-epoch mymaster3 0
sentinel leader-epoch mymaster3 1
sentinel known-slave mymaster3 192.168.56.33 6380
sentinel known-sentinel mymaster3 192.168.56.22 26379 77656703b90490d49d5302af4dffe329b40eca82
sentinel known-sentinel mymaster3 192.168.56.11 26379 ad4f90b73e809495d34f15f29dd5ee6b2d3a2443
sentinel current-epoch 1

实验1：在56.33节点的哨兵对主56.33 6379进行failover 操作：

哨兵：

127.0.0.1:26379> sentinel failover mymaster3
OK
127.0.0.1:26379> info sentinel
# Sentinel
sentinel_masters:3
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
sentinel_simulate_failure_flags:0
master0:name=mymaster2,status=ok,address=192.168.56.22:6379,slaves=1,sentinels=3
master1:name=mymaster1,status=ok,address=192.168.56.11:6379,slaves=1,sentinels=3
master2:name=mymaster3,status=ok,address=192.168.56.33:6379,slaves=1,sentinels=3
127.0.0.1:26379> info sentinel
# Sentinel
sentinel_masters:3
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
sentinel_simulate_failure_flags:0
master0:name=mymaster2,status=ok,address=192.168.56.22:6379,slaves=1,sentinels=3
master1:name=mymaster1,status=ok,address=192.168.56.11:6379,slaves=1,sentinels=3
master2:name=mymaster3,status=ok,address=192.168.56.33:6379,slaves=1,sentinels=3
哨兵的监控信息没有变化。

56.33节点的哨兵日志：
9902:X 08 Mar 00:42:56.839 # Executing user requested FAILOVER of ‘mymaster3‘
9902:X 08 Mar 00:42:56.839 # +new-epoch 1
9902:X 08 Mar 00:42:56.840 # +try-failover master mymaster3 192.168.56.33 6379
9902:X 08 Mar 00:42:56.854 # +vote-for-leader 13be94770954b8122340c3f1806f2f82f9e76360 1
9902:X 08 Mar 00:42:56.854 # +elected-leader master mymaster3 192.168.56.33 6379
9902:X 08 Mar 00:42:56.854 # +failover-state-select-slave master mymaster3 192.168.56.33 6379
9902:X 08 Mar 00:42:56.925 # +selected-slave slave 192.168.56.33:6380 192.168.56.33 6380 @ mymaster3 192.168.56.33 6379
9902:X 08 Mar 00:42:56.926 * +failover-state-send-slaveof-noone slave 192.168.56.33:6380 192.168.56.33 6380 @ mymaster3 192.168.56.33 6379
9902:X 08 Mar 00:42:56.992 * +failover-state-wait-promotion slave 192.168.56.33:6380 192.168.56.33 6380 @ mymaster3 192.168.56.33 6379
9902:X 08 Mar 00:45:57.026 # -failover-abort-slave-timeout master mymaster3 192.168.56.33 6379 （-failover timeout 说明没有failover成功）

56.22哨兵节点的日志：
9728:X 08 Mar 00:43:01.259 # +new-epoch 1 （只有一条这个信息）

结论：说明在正常集群状态下的哨兵，哨兵对主的 sentinel failover mymaster3 操作不生效。

实验二：集群内部进行的failover操作，在56.33的从节点进行：

当前节点状态：
127.0.0.1:26379> info sentinel
# Sentinel
sentinel_masters:3
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
sentinel_simulate_failure_flags:0
master0:name=mymaster2,status=ok,address=192.168.56.22:6379,slaves=1,sentinels=3
master1:name=mymaster1,status=ok,address=192.168.56.11:6379,slaves=1,sentinels=3
master2:name=mymaster3,status=ok,address=192.168.56.33:6379,slaves=1,sentinels=3

进行failover操作后的：
127.0.0.1:6380> cluster failover
OK
127.0.0.1:6380>

哨兵监控状态：
127.0.0.1:26379> info sentinel
# Sentinel
sentinel_masters:3
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
sentinel_simulate_failure_flags:0
master0:name=mymaster2,status=ok,address=192.168.56.22:6379,slaves=1,sentinels=3
master1:name=mymaster1,status=ok,address=192.168.56.11:6379,slaves=1,sentinels=3
master2:name=mymaster3,status=sdown,address=192.168.56.33:6379,slaves=1,sentinels=3

各个节点的哨兵日志（一样）：

9902:X 08 Mar 01:04:24.069 # +sdown master mymaster3 192.168.56.33 6379

主节点的日志：

9866:M 08 Mar 01:03:02.599 # Manual failover requested by slave 836ee0beeba49a4bc02df6e0169db160d1b96890.
9866:M 08 Mar 01:03:02.862 # Failover auth granted to 836ee0beeba49a4bc02df6e0169db160d1b96890 for epoch 47
9866:M 08 Mar 01:03:02.863 # Connection with slave 192.168.56.33:6380 lost.
9866:M 08 Mar 01:03:02.867 # Configuration change detected. Reconfiguring myself as a replica of 836ee0beeba49a4bc02df6e0169db160d1b96890
9866:S 08 Mar 01:03:03.781 * Connecting to MASTER 192.168.56.33:6380
9866:S 08 Mar 01:03:03.783 * MASTER <-> SLAVE sync started
9866:S 08 Mar 01:03:03.784 * Non blocking connect for SYNC fired the event.
9866:S 08 Mar 01:03:03.784 * Master replied to PING, replication can continue...
9866:S 08 Mar 01:03:03.785 * Partial resynchronization not possible (no cached master)
9866:S 08 Mar 01:03:03.789 * Full resync from master: 6c16dda7bff854e09549a38847bf658840066f6d:2313
9866:S 08 Mar 01:03:03.870 * MASTER <-> SLAVE sync: receiving 76 bytes from master
9866:S 08 Mar 01:03:03.871 * MASTER <-> SLAVE sync: Flushing old data
9866:S 08 Mar 01:03:03.871 * MASTER <-> SLAVE sync: Loading DB in memory
9866:S 08 Mar 01:03:03.871 * MASTER <-> SLAVE sync: Finished with success
9866:S 08 Mar 01:03:03.873 * Background append only file rewriting started by pid 10036
9866:S 08 Mar 01:03:03.912 * AOF rewrite child asks to stop sending diffs.
10036:C 08 Mar 01:03:03.912 * Parent agreed to stop sending diffs. Finalizing AOF...
10036:C 08 Mar 01:03:03.912 * Concatenating 0.00 MB of AOF diff received from parent.
10036:C 08 Mar 01:03:03.912 * SYNC append only file rewrite performed
10036:C 08 Mar 01:03:03.913 * AOF rewrite: 6 MB of memory used by copy-on-write
9866:S 08 Mar 01:03:03.983 * Background AOF rewrite terminated with success
9866:S 08 Mar 01:03:03.983 * Residual parent diff successfully flushed to the rewritten AOF (0.00 MB)
9866:S 08 Mar 01:03:03.983 * Background AOF rewrite finished successfully

从节点的日志：

9874:S 08 Mar 01:03:02.599 # Manual failover user request accepted.
9874:S 08 Mar 01:03:02.672 # Received replication offset for paused master manual failover: 2312
9874:S 08 Mar 01:03:02.760 # All master replication stream processed, manual failover can start.
9874:S 08 Mar 01:03:02.760 # Start of election delayed for 0 milliseconds (rank #0, offset 2312).
9874:S 08 Mar 01:03:02.860 # Starting a failover election for epoch 47.
9874:S 08 Mar 01:03:02.863 # Failover election won: I‘m the new master.
9874:S 08 Mar 01:03:02.863 # configEpoch set to 47 after successful failover
9874:M 08 Mar 01:03:02.863 # Connection with master lost.
9874:M 08 Mar 01:03:02.863 * Caching the disconnected master state.
9874:M 08 Mar 01:03:02.863 * Discarding previously cached master state.
9874:M 08 Mar 01:03:03.785 * Slave 192.168.56.33:6379 asks for synchronization
9874:M 08 Mar 01:03:03.785 * Full resync requested by slave 192.168.56.33:6379
9874:M 08 Mar 01:03:03.785 * Starting BGSAVE for SYNC with target: disk
9874:M 08 Mar 01:03:03.786 * Background saving started by pid 10035
10035:C 08 Mar 01:03:03.806 * DB saved on disk
10035:C 08 Mar 01:03:03.807 * RDB: 8 MB of memory used by copy-on-write
9874:M 08 Mar 01:03:03.870 * Background saving terminated with success
9874:M 08 Mar 01:03:03.870 * Synchronization with slave 192.168.56.33:6379 succeeded

从库提升为主库：
127.0.0.1:6380> info replication
# Replication
role:master
connected_slaves:1
slave0:ip=192.168.56.33,port=6379,state=online,offset=2677,lag=1
master_repl_offset:2691
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:2314
repl_backlog_histlen:378
127.0.0.1:6380>

哨兵的配置文件：
port 26379
daemonize yes
logfile "/redis/logs/26379.log"
dir "/redis/data"
sentinel myid 13be94770954b8122340c3f1806f2f82f9e76360
sentinel monitor mymaster2 192.168.56.22 6379 2
sentinel down-after-milliseconds mymaster2 60000
sentinel auth-pass mymaster2 beijing
sentinel config-epoch mymaster2 0
sentinel leader-epoch mymaster2 0
sentinel known-slave mymaster2 192.168.56.22 6380
sentinel known-sentinel mymaster2 192.168.56.22 26379 77656703b90490d49d5302af4dffe329b40eca82
sentinel known-sentinel mymaster2 192.168.56.11 26379 ad4f90b73e809495d34f15f29dd5ee6b2d3a2443
sentinel monitor mymaster1 192.168.56.11 6379 2
sentinel down-after-milliseconds mymaster1 60000
sentinel auth-pass mymaster1 beijing
sentinel config-epoch mymaster1 0
sentinel leader-epoch mymaster1 0
sentinel known-slave mymaster1 192.168.56.11 6380
# Generated by CONFIG REWRITE
sentinel known-sentinel mymaster1 192.168.56.22 26379 77656703b90490d49d5302af4dffe329b40eca82
sentinel known-sentinel mymaster1 192.168.56.11 26379 ad4f90b73e809495d34f15f29dd5ee6b2d3a2443
sentinel monitor mymaster3 192.168.56.33 6379 2
sentinel down-after-milliseconds mymaster3 60000
sentinel auth-pass mymaster3 beijing
sentinel config-epoch mymaster3 0
sentinel leader-epoch mymaster3 2
sentinel known-slave mymaster3 192.168.56.33 6380
sentinel known-sentinel mymaster3 192.168.56.22 26379 77656703b90490d49d5302af4dffe329b40eca82
sentinel known-sentinel mymaster3 192.168.56.11 26379 ad4f90b73e809495d34f15f29dd5ee6b2d3a2443
sentinel current-epoch 2

实验二：
对56.22的主6379 宕机：

[[email protected] conf]# ps -ef|grep redis
root 9700 1 0 00:34 ? 00:00:19 redis-server *:6379 [cluster]
root 9705 1 0 00:35 ? 00:00:19 redis-server *:6380 [cluster]
root 9728 1 0 00:39 ? 00:00:20 redis-sentinel *:26379 [sentinel]
root 9880 9858 0 01:19 pts/3 00:00:00 tail -f redis6379.log
root 9882 9837 0 01:19 pts/2 00:00:00 tail -f redis6380.log
root 9886 9528 0 01:20 pts/0 00:00:00 grep redis
[[email protected] conf]#
[[email protected] conf]#
[[email protected] conf]#
[[email protected] conf]# kill -9 9700 1

哨兵的状态变化：

127.0.0.1:26379> info sentinel
# Sentinel
sentinel_masters:3
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
sentinel_simulate_failure_flags:0
master0:name=mymaster2,status=ok,address=192.168.56.22:6379,slaves=1,sentinels=3
master1:name=mymaster1,status=ok,address=192.168.56.11:6379,slaves=1,sentinels=3
master2:name=mymaster3,status=sdown,address=192.168.56.33:6379,slaves=1,sentinels=3
127.0.0.1:26379> info sentinel
# Sentinel
sentinel_masters:3
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
sentinel_simulate_failure_flags:0
master0:name=mymaster2,status=sdown,address=192.168.56.22:6379,slaves=1,sentinels=3
master1:name=mymaster1,status=ok,address=192.168.56.11:6379,slaves=1,sentinels=3
master2:name=mymaster3,status=sdown,address=192.168.56.33:6379,slaves=1,sentinels=3

哨兵日志：
9902:X 08 Mar 01:21:47.882 # +sdown master mymaster2 192.168.56.22 6379（只有一条）

节点主日志：
因为宕机无日志

从节点日志：
9705:S 08 Mar 01:20:52.300 # Connection with master lost.
9705:S 08 Mar 01:20:52.300 * Caching the disconnected master state.
9705:S 08 Mar 01:20:53.118 * Connecting to MASTER 192.168.56.22:6379
9705:S 08 Mar 01:20:53.118 * MASTER <-> SLAVE sync started
9705:S 08 Mar 01:20:53.119 # Error condition on socket for SYNC: Connection refused
9705:S 08 Mar 01:20:54.126 * Connecting to MASTER 192.168.56.22:6379
9705:S 08 Mar 01:20:54.127 * MASTER <-> SLAVE sync started
9705:S 08 Mar 01:20:54.127 # Error condition on socket for SYNC: Connection refused
9705:S 08 Mar 01:20:55.134 * Connecting to MASTER 192.168.56.22:6379
9705:S 08 Mar 01:20:55.134 * MASTER <-> SLAVE sync started
9705:S 08 Mar 01:20:55.134 # Error condition on socket for SYNC: Connection refused
9705:S 08 Mar 01:20:56.137 * Connecting to MASTER 192.168.56.22:6379
9705:S 08 Mar 01:20:56.138 * MASTER <-> SLAVE sync started
9705:S 08 Mar 01:20:56.138 # Error condition on socket for SYNC: Connection refused
9705:S 08 Mar 01:20:57.146 * Connecting to MASTER 192.168.56.22:6379
9705:S 08 Mar 01:20:57.147 * MASTER <-> SLAVE sync started
9705:S 08 Mar 01:20:57.147 # Error condition on socket for SYNC: Connection refused
9705:S 08 Mar 01:20:58.156 * Connecting to MASTER 192.168.56.22:6379
9705:S 08 Mar 01:20:58.156 * MASTER <-> SLAVE sync started
9705:S 08 Mar 01:20:58.156 # Error condition on socket for SYNC: Connection refused
9705:S 08 Mar 01:20:59.164 * Connecting to MASTER 192.168.56.22:6379
9705:S 08 Mar 01:20:59.164 * MASTER <-> SLAVE sync started
9705:S 08 Mar 01:20:59.164 # Error condition on socket for SYNC: Connection refused
9705:S 08 Mar 01:21:00.172 * Connecting to MASTER 192.168.56.22:6379
9705:S 08 Mar 01:21:00.173 * MASTER <-> SLAVE sync started
9705:S 08 Mar 01:21:00.173 # Error condition on socket for SYNC: Connection refused
9705:S 08 Mar 01:21:01.178 * Connecting to MASTER 192.168.56.22:6379
9705:S 08 Mar 01:21:01.178 * MASTER <-> SLAVE sync started
9705:S 08 Mar 01:21:01.178 # Error condition on socket for SYNC: Connection refused
9705:S 08 Mar 01:21:02.188 * Connecting to MASTER 192.168.56.22:6379
9705:S 08 Mar 01:21:02.188 * MASTER <-> SLAVE sync started
9705:S 08 Mar 01:21:02.188 # Error condition on socket for SYNC: Connection refused
9705:S 08 Mar 01:21:03.199 * Connecting to MASTER 192.168.56.22:6379
9705:S 08 Mar 01:21:03.200 * MASTER <-> SLAVE sync started
9705:S 08 Mar 01:21:03.201 # Error condition on socket for SYNC: Connection refused
9705:S 08 Mar 01:21:04.208 * Connecting to MASTER 192.168.56.22:6379
9705:S 08 Mar 01:21:04.208 * MASTER <-> SLAVE sync started
9705:S 08 Mar 01:21:04.208 # Error condition on socket for SYNC: Connection refused
9705:S 08 Mar 01:21:05.219 * Connecting to MASTER 192.168.56.22:6379
9705:S 08 Mar 01:21:05.220 * MASTER <-> SLAVE sync started
9705:S 08 Mar 01:21:05.220 # Error condition on socket for SYNC: Connection refused
9705:S 08 Mar 01:21:06.225 * Connecting to MASTER 192.168.56.22:6379
9705:S 08 Mar 01:21:06.226 * MASTER <-> SLAVE sync started
9705:S 08 Mar 01:21:06.226 # Error condition on socket for SYNC: Connection refused
9705:S 08 Mar 01:21:07.232 * Connecting to MASTER 192.168.56.22:6379
9705:S 08 Mar 01:21:07.232 * MASTER <-> SLAVE sync started
9705:S 08 Mar 01:21:07.232 # Error condition on socket for SYNC: Connection refused
9705:S 08 Mar 01:21:07.776 * Marking node 91844383ccb52cee4308ab247f1def0a60848ddd as failing (quorum reached).
9705:S 08 Mar 01:21:07.776 # Cluster state changed: fail
9705:S 08 Mar 01:21:07.836 # Start of election delayed for 931 milliseconds (rank #0, offset 3781).
9705:S 08 Mar 01:21:08.241 * Connecting to MASTER 192.168.56.22:6379
9705:S 08 Mar 01:21:08.242 * MASTER <-> SLAVE sync started
9705:S 08 Mar 01:21:08.242 # Error condition on socket for SYNC: Connection refused
9705:S 08 Mar 01:21:08.846 # Starting a failover election for epoch 48.
9705:S 08 Mar 01:21:08.849 # Failover election won: I‘m the new master.
9705:S 08 Mar 01:21:08.849 # configEpoch set to 48 after successful failover
9705:M 08 Mar 01:21:08.849 * Discarding previously cached master state.
9705:M 08 Mar 01:21:08.849 # Cluster state changed: ok

哨兵的配置文件：

port 26379
daemonize yes
logfile "/redis/logs/26379.log"
dir "/redis/data"
sentinel myid 77656703b90490d49d5302af4dffe329b40eca82
sentinel monitor mymaster2 192.168.56.22 6379 2
sentinel down-after-milliseconds mymaster2 60000
sentinel auth-pass mymaster2 beijing
sentinel config-epoch mymaster2 0
sentinel leader-epoch mymaster2 0
sentinel known-slave mymaster2 192.168.56.22 6380
sentinel known-sentinel mymaster2 192.168.56.11 26379 ad4f90b73e809495d34f15f29dd5ee6b2d3a2443
sentinel known-sentinel mymaster2 192.168.56.33 26379 13be94770954b8122340c3f1806f2f82f9e76360
sentinel monitor mymaster3 192.168.56.33 6379 2
sentinel down-after-milliseconds mymaster3 60000
sentinel auth-pass mymaster3 beijing
sentinel config-epoch mymaster3 0
sentinel leader-epoch mymaster3 0
sentinel known-slave mymaster3 192.168.56.33 6380
# Generated by CONFIG REWRITE
sentinel known-sentinel mymaster3 192.168.56.11 26379 ad4f90b73e809495d34f15f29dd5ee6b2d3a2443
sentinel known-sentinel mymaster3 192.168.56.33 26379 13be94770954b8122340c3f1806f2f82f9e76360
sentinel monitor mymaster1 192.168.56.11 6379 2
sentinel down-after-milliseconds mymaster1 60000
sentinel auth-pass mymaster1 beijing
sentinel config-epoch mymaster1 0
sentinel leader-epoch mymaster1 0
sentinel known-slave mymaster1 192.168.56.11 6380
sentinel known-sentinel mymaster1 192.168.56.11 26379 ad4f90b73e809495d34f15f29dd5ee6b2d3a2443
sentinel known-sentinel mymaster1 192.168.56.33 26379 13be94770954b8122340c3f1806f2f82f9e76360
sentinel current-epoch 2

实验三：把56.22 节点的6379在重启启动：

哨兵日志的变化：

9902:X 08 Mar 01:35:00.940 * +reboot master mymaster2 192.168.56.22 6379
9902:X 08 Mar 01:35:01.015 # -sdown master mymaster2 192.168.56.22 6379
9902:X 08 Mar 01:36:20.981 # +sdown master mymaster2 192.168.56.22 6379

哨兵状态：
127.0.0.1:26379> info sentinel
# Sentinel
sentinel_masters:3
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
sentinel_simulate_failure_flags:0
master0:name=mymaster2,status=sdown,address=192.168.56.22:6379,slaves=1,sentinels=3
master1:name=mymaster1,status=ok,address=192.168.56.11:6379,slaves=1,sentinels=3
master2:name=mymaster3,status=sdown,address=192.168.56.33:6379,slaves=1,sentinels=3

实验四：把56.22 的6379 进行cluster failover：

哨兵状态变化：
127.0.0.1:26379> info sentinel
# Sentinel
sentinel_masters:3
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
sentinel_simulate_failure_flags:0
master0:name=mymaster2,status=sdown,address=192.168.56.22:6379,slaves=1,sentinels=3
master1:name=mymaster1,status=ok,address=192.168.56.11:6379,slaves=1,sentinels=3
master2:name=mymaster3,status=sdown,address=192.168.56.33:6379,slaves=1,sentinels=3
127.0.0.1:26379>
127.0.0.1:26379>
127.0.0.1:26379> info sentinel
# Sentinel
sentinel_masters:3
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
sentinel_simulate_failure_flags:0
master0:name=mymaster2,status=ok,address=192.168.56.22:6379,slaves=1,sentinels=3
master1:name=mymaster1,status=ok,address=192.168.56.11:6379,slaves=1,sentinels=3
master2:name=mymaster3,status=sdown,address=192.168.56.33:6379,slaves=1,sentinels=3

哨兵日志：

9728:X 08 Mar 01:38:36.279 # -sdown master mymaster2 192.168.56.22 6379（只有一天更新）

主节点日志：

原主节点日志：
9705:M 08 Mar 01:38:28.230 # Manual failover requested by slave 91844383ccb52cee4308ab247f1def0a60848ddd.
9705:M 08 Mar 01:38:28.436 # Failover auth granted to 91844383ccb52cee4308ab247f1def0a60848ddd for epoch 49
9705:M 08 Mar 01:38:28.438 # Connection with slave 192.168.56.22:6379 lost.
9705:M 08 Mar 01:38:28.441 # Configuration change detected. Reconfiguring myself as a replica of 91844383ccb52cee4308ab247f1def0a60848ddd
9705:S 08 Mar 01:38:28.836 * Connecting to MASTER 192.168.56.22:6379
9705:S 08 Mar 01:38:28.837 * MASTER <-> SLAVE sync started
9705:S 08 Mar 01:38:28.837 * Non blocking connect for SYNC fired the event.
9705:S 08 Mar 01:38:28.837 * Master replied to PING, replication can continue...
9705:S 08 Mar 01:38:28.837 * Partial resynchronization not possible (no cached master)
9705:S 08 Mar 01:38:28.840 * Full resync from master: e9236b0ced4f631434a44320691dd021bc909026:282
9705:S 08 Mar 01:38:28.931 * MASTER <-> SLAVE sync: receiving 76 bytes from master
9705:S 08 Mar 01:38:28.931 * MASTER <-> SLAVE sync: Flushing old data
9705:S 08 Mar 01:38:28.931 * MASTER <-> SLAVE sync: Loading DB in memory
9705:S 08 Mar 01:38:28.931 * MASTER <-> SLAVE sync: Finished with success
9705:S 08 Mar 01:38:28.932 * Background append only file rewriting started by pid 9945
9705:S 08 Mar 01:38:28.975 * AOF rewrite child asks to stop sending diffs.
9945:C 08 Mar 01:38:28.976 * Parent agreed to stop sending diffs. Finalizing AOF...
9945:C 08 Mar 01:38:28.976 * Concatenating 0.00 MB of AOF diff received from parent.
9945:C 08 Mar 01:38:28.976 * SYNC append only file rewrite performed
9945:C 08 Mar 01:38:28.977 * AOF rewrite: 6 MB of memory used by copy-on-write
9705:S 08 Mar 01:38:29.039 * Background AOF rewrite terminated with success
9705:S 08 Mar 01:38:29.039 * Residual parent diff successfully flushed to the rewritten AOF (0.00 MB)
9705:S 08 Mar 01:38:29.039 * Background AOF rewrite finished successfully

原从节点日志：

9926:S 08 Mar 01:38:28.230 # Manual failover user request accepted.
9926:S 08 Mar 01:38:28.233 # Received replication offset for paused master manual failover: 281
9926:S 08 Mar 01:38:28.326 # All master replication stream processed, manual failover can start.
9926:S 08 Mar 01:38:28.326 # Start of election delayed for 0 milliseconds (rank #0, offset 281).
9926:S 08 Mar 01:38:28.427 # Starting a failover election for epoch 49.
9926:S 08 Mar 01:38:28.437 # Currently unable to failover: Waiting for votes, but majority still not reached.
9926:S 08 Mar 01:38:28.438 # Failover election won: I‘m the new master.
9926:S 08 Mar 01:38:28.438 # configEpoch set to 49 after successful failover
9926:M 08 Mar 01:38:28.438 # Connection with master lost.
9926:M 08 Mar 01:38:28.438 * Caching the disconnected master state.
9926:M 08 Mar 01:38:28.438 * Discarding previously cached master state.
9926:M 08 Mar 01:38:28.837 * Slave 192.168.56.22:6380 asks for synchronization
9926:M 08 Mar 01:38:28.837 * Full resync requested by slave 192.168.56.22:6380
9926:M 08 Mar 01:38:28.837 * Starting BGSAVE for SYNC with target: disk
9926:M 08 Mar 01:38:28.838 * Background saving started by pid 9944
9944:C 08 Mar 01:38:28.854 * DB saved on disk
9944:C 08 Mar 01:38:28.854 * RDB: 8 MB of memory used by copy-on-write
9926:M 08 Mar 01:38:28.930 * Background saving terminated with success
9926:M 08 Mar 01:38:28.930 * Synchronization with slave 192.168.56.22:6380 succeeded

在集群状态下：56.11 未做任何实验的主从的配置文件：

主6379：

#general
# 开启集群模式
cluster-enabled yes
# 节点超时时间，单位毫秒
cluster-node-timeout 15000
# 集群内部配置文件
cluster-config-file "nodes-6379.conf"
daemonize yes
pidfile /redis/data/redis6379.pid
port 6379
unixsocket /tmp/redis6379.sock
unixsocketperm 755
timeout 0
tcp-keepalive 0
loglevel notice
logfile /redis/logs/redis6379.log
syslog-enabled no
syslog-ident redis
syslog-facility local0
databases 16
requirepass beijing
masterauth beijing
#snap
save 900 1
save 300 10
save 60 10000
stop-writes-on-bgsave-error yes
rdbcompression yes
rdbchecksum yes
dbfilename "dump6379.rdb"
rdbcompression yes
dir /redis/data/6379
appendonly yes
appendfilename appendonly.aof
# appendfsync always
appendfsync everysec
# appendfsync no
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

从6380：

#general
# 开启集群模式
cluster-enabled yes
# 节点超时时间，单位毫秒
cluster-node-timeout 15000
# 集群内部配置文件
cluster-config-file "nodes-6380.conf"
daemonize yes
pidfile "/redis/data/redis6380.pid"
port 6380
unixsocket "/tmp/redis6380.sock"
unixsocketperm 755
timeout 0
tcp-keepalive 0
loglevel notice
logfile "/redis/logs/redis6380.log"
syslog-enabled no
syslog-ident "redis"
syslog-facility local0
databases 16
requirepass "beijing"
masterauth "beijing"
#snap
save 900 1
save 300 10
save 60 10000
stop-writes-on-bgsave-error yes
rdbcompression yes
rdbchecksum yes
dbfilename "dump6380.rdb"
dir "/redis/data/6380"
appendonly yes
appendfilename "appendonly.aof"
# appendfsync always
appendfsync everysec
# appendfsync no
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

结论：从集群的主从的配置文件中没有slaveof的信息。（说明哨兵无法标记集群的slaveof的信息）

实验五：在56.11 6380（从）节点进行cluster failover操作：（哨兵主正常显示了）

哨兵状态：

1. ok状态下先reset：
127.0.0.1:26379> info sentinel
# Sentinel
sentinel_masters:3
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
sentinel_simulate_failure_flags:0
master0:name=mymaster1,status=ok,address=192.168.56.11:6379,slaves=0,sentinels=3
master1:name=mymaster3,status=ok,address=192.168.56.33:6379,slaves=1,sentinels=3
master2:name=mymaster2,status=ok,address=192.168.56.22:6379,slaves=1,sentinels=3
127.0.0.1:26379> sentinel reset mymaster1
(integer) 1
127.0.0.1:26379>
127.0.0.1:26379>
127.0.0.1:26379> info sentinel
# Sentinel
sentinel_masters:3
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
sentinel_simulate_failure_flags:0
master0:name=mymaster1,status=ok,address=192.168.56.11:6379,slaves=0,sentinels=3
master1:name=mymaster3,status=ok,address=192.168.56.33:6379,slaves=1,sentinels=3
master2:name=mymaster2,status=ok,address=192.168.56.22:6379,slaves=1,sentinels=3
127.0.0.1:26379> info sentinel
# Sentinel
sentinel_masters:3
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
sentinel_simulate_failure_flags:0
master0:name=mymaster1,status=ok,address=192.168.56.11:6379,slaves=1,sentinels=3
master1:name=mymaster3,status=ok,address=192.168.56.33:6379,slaves=1,sentinels=3
master2:name=mymaster2,status=ok,address=192.168.56.22:6379,slaves=1,sentinels=3
ok状态下reset没事，也会再更新到正常状态。

2. failover操作哨兵状态：
127.0.0.1:26379> info sentinel
# Sentinel
sentinel_masters:3
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
sentinel_simulate_failure_flags:0
master0:name=mymaster1,status=ok,address=192.168.56.11:6379,slaves=1,sentinels=3
master1:name=mymaster3,status=ok,address=192.168.56.33:6379,slaves=1,sentinels=3
master2:name=mymaster2,status=ok,address=192.168.56.22:6379,slaves=1,sentinels=3
127.0.0.1:26379>
127.0.0.1:26379>
127.0.0.1:26379> info sentinel
# Sentinel
sentinel_masters:3
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
sentinel_simulate_failure_flags:0
master0:name=mymaster1,status=ok,address=192.168.56.11:6380,slaves=1,sentinels=3
master1:name=mymaster3,status=ok,address=192.168.56.33:6379,slaves=1,sentinels=3
master2:name=mymaster2,status=ok,address=192.168.56.22:6379,slaves=1,sentinels=3
自动切换新的主了，而且状态是ok，且监控信息正确。

哨兵56.11日志：
9101:X 08 Mar 03:17:26.356 * +slave slave 192.168.56.11:6380 192.168.56.11 6380 @ mymaster1 192.168.56.11 6379
9101:X 08 Mar 03:17:29.920 # +reset-master master mymaster1 192.168.56.11 6379
9101:X 08 Mar 03:17:30.735 * +sentinel sentinel df61bc06648666a82c2f484f05170f077615e05d 192.168.56.22 26379 @ mymaster1 192.168.56.11 6379
9101:X 08 Mar 03:17:30.781 # +sdown sentinel df61bc06648666a82c2f484f05170f077615e05d 192.168.56.22 26379 @ mymaster1 192.168.56.11 6379
9101:X 08 Mar 03:17:31.336 * +sentinel sentinel 1f189e711ef43ae87c6616544fc29d30ef3dd854 192.168.56.33 26379 @ mymaster1 192.168.56.11 6379
9101:X 08 Mar 03:17:31.384 # +sdown sentinel 1f189e711ef43ae87c6616544fc29d30ef3dd854 192.168.56.33 26379 @ mymaster1 192.168.56.11 6379
9101:X 08 Mar 03:17:36.407 * +slave slave 192.168.56.11:6380 192.168.56.11 6380 @ mymaster1 192.168.56.11 6379
9101:X 08 Mar 03:20:06.531 # +config-update-from sentinel df61bc06648666a82c2f484f05170f077615e05d 192.168.56.22 26379 @ mymaster1 192.168.56.11 6379
9101:X 08 Mar 03:20:06.531 # +switch-master mymaster1 192.168.56.11 6379 192.168.56.11 6380
9101:X 08 Mar 03:20:06.531 * +slave slave 192.168.56.11:6379 192.168.56.11 6379 @ mymaster1 192.168.56.11 6380

哨兵56.22日志：
10189:X 08 Mar 02:40:37.573 # +try-failover master mymaster1 192.168.56.11 6379
10189:X 08 Mar 02:40:37.589 # +vote-for-leader df61bc06648666a82c2f484f05170f077615e05d 1
10189:X 08 Mar 02:40:37.589 # +elected-leader master mymaster1 192.168.56.11 6379
10189:X 08 Mar 02:40:37.589 # +failover-state-select-slave master mymaster1 192.168.56.11 6379
10189:X 08 Mar 02:40:37.652 # +selected-slave slave 192.168.56.11:6380 192.168.56.11 6380 @ mymaster1 192.168.56.11 6379
10189:X 08 Mar 02:40:37.652 * +failover-state-send-slaveof-noone slave 192.168.56.11:6380 192.168.56.11 6380 @ mymaster1 192.168.56.11 6379
10189:X 08 Mar 02:40:37.707 * +failover-state-wait-promotion slave 192.168.56.11:6380 192.168.56.11 6380 @ mymaster1 192.168.56.11 6379
10189:X 08 Mar 03:19:53.151 # +promoted-slave slave 192.168.56.11:6380 192.168.56.11 6380 @ mymaster1 192.168.56.11 6379
10189:X 08 Mar 03:19:53.151 # +failover-state-reconf-slaves master mymaster1 192.168.56.11 6379
10189:X 08 Mar 03:19:53.200 # +failover-end master mymaster1 192.168.56.11 6379
10189:X 08 Mar 03:19:53.200 # +switch-master mymaster1 192.168.56.11 6379 192.168.56.11 6380
10189:X 08 Mar 03:19:53.200 * +slave slave 192.168.56.11:6379 192.168.56.11 6379 @ mymaster1 192.168.56.11 6380

结论：在集群状态下测试的实验四和实验五，操作相同，虽然集群的主从正常切换了，但是哨兵的显示状态和哨兵日志事件却不同，目前还没有找出原因。希望大神们能看到，并且能够给些提示建议。

以上是关于哨兵在redis主从与集群上的表现不同的主要内容，如果未能解决你的问题，请参考以下文章

Redis 主从复制机制（集群）与哨兵机制

高可用集群架构——redis的主从复制与哨兵模式，cluster

Redis高可用方案-哨兵与集群

Redis主从,哨兵结构与集群详解

玩转Redis的高可用（主从、哨兵、集群）

redis主从redis哨兵redis集群配置搭建和使用