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

最新推荐文章于 2022-10-05 00:59:40 发布
最新推荐文章于 2022-10-05 00:59:40 发布
阅读量341 收藏
点赞数
文章标签： 数据库 网络
原文链接：http://www.cnblogs.com/feifeizouzou/p/8543895.html
版权

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


实验一：
哨兵节点failover主：

当前主为56.33 6379 从为 56.22 6380


哨兵前后状态：
[root@mysql3 ~]# 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 宕机：

[root@mysql2 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
[root@mysql2 conf]#
[root@mysql2 conf]#
[root@mysql2 conf]#
[root@mysql2 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

哨兵的配置文件：
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.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

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

转载于:https://www.cnblogs.com/feifeizouzou/p/8543895.html

weixin_33827590
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
Redis集群-Redis安装、Redis主从复制、哨兵、Redis集群
12-25
Redis集群是Redis的一种高可用性解决方案，通过主从复制、哨兵和集群三大技术模块来实现高可用性和可扩展性。本文将对Redis集群进行详细的介绍，包括Redis安装、主从复制、哨兵和集群的配置和实现。 一、Redis安装 ...
redis：哨兵选举新的master报错——-failover-abort-no-good-slave master mymaster
最新发布
aflyingpig11的博客
09-27 300
3.sentinel.config 的sentinel monitor mymaster 和sentinel auth-pass mymaster 也没有错。但在我测试主从复制的时候，发现主从主机无法相连，我在网上找的解决方案的关闭了master主机所在的防火墙。1.我核对了sentinel.config和redis.config bind 绑定的端口。现在master下线了，需要选举新的master，需要关闭新master所在主机的防火墙。2.三台redis masterauth都设置了密码。
redis哨兵主从切换失败failover-abort-slave-timeout，发现是 rename-command CONFIG导致
ljq354004063的博客
10-16 2069
在某次修改完redis基线后（网信安啊），想测试下redis的 自动切换是否有效，发现哨兵的日志都很正常，哨兵也正常进行了选举，选出了新的master，但却在切换的时候出现failover-abort-slave-timeout，最终还是沿用了已经down掉的旧master 网上搜索了半天，发现全是千篇一律的密码问题、bind问题、网络问题，不禁想吐槽，这种常识性的东西没必要单独写文章记录吧，于是自行查找，还原基线。 发现是rename-commad，re...
我的Redis哨兵为什么不切换？
wx370092877的博客
10-05 2523
今天在值班空闲之余，正好想起在前几天遇到的一个奇怪的redis问题，顺便就记录一下，如果大家能看到也可以为大家做个避坑参考。
-failover-abort-not-elected master mymaster问题
一叶知秋hwb的博客
11-13 2587
redis配置sentinel，master shutdown后主从切换失败，提示错误 -failover-abort-not-elected master mymaster x.x.x.x 6379 原因是sentinel.conf缺少配置，若redis.conf中添加 protected-mode yes bind 0.0.0.0 则sentinel.conf中添加该属性。 ...
Redis Sentinel主从复制自动切换方案
qq_33285112的博客
12-11 2000
一、准备环境 #配置环境： Redis Sentinel：192.68.40.16:26379 Redis server主：192.168.40.17:6379 Redis server从：192.168.40.18:6380 #查看主服务器状态： [root@localhost ~]# redis-cli -p 6379 -a pwd123 info Replication # R
docker-compose redis主从哨兵 redis多节点高可用 redis集群高可用
04-12
docker-compose 形式部署 redis 1主2从3哨兵 redis 多节点高可用 redis 主从哨兵 redis 集群高可用 redis 哨兵 redis 高可用
windows redis 主从集群实例加哨兵集群
08-24
windows redis 主从集群实例加哨兵集群 相关使用博客 https://blog.csdn.net/weixin_42749765/article/details/82023029
Docker搭建redis主从+哨兵模式集群.docx
07-27
Docker搭建Redis主从+哨兵模式集群 本文档主要介绍了使用Docker搭建Redis主从复制和哨兵模式集群的步骤。下面是详细的知识点总结： 一、Docker安装 * 下载Docker二进制文件（离线安装包），使用wget命令下载 * ...
Redis部署笔记（单机+主从+哨兵+集群）
09-14
基于Centos7系统，由浅入深讲解如何部署Redis的四种模式，分别是：单机模式、主从模式、哨兵模式、集群模式。 完整原文：http://exp-blog.com/2018/09/14/pid-2285/ 同时提供Jedis客户端封装源码： ● 屏蔽Jedis与...
Redis集群丢数据问题——机器宕机没有自动切库，手动takeover后，老主库重启又抢回master
耕云者~
05-17 1322
文章目录背景事故描述问题分析日志记录关键日志疑惑与猜测原因排查查看资料集群间通信手动故障转移配置纪元的主要作用:同版本集群测试准备测试流程日志分析根据日志查看源码逻辑has old slots configurationis back online网络问题确认异常信息信息确认集群间通信问题排查通信端口连接情况抓包确认之前疑惑的解答总结后续操作急救措施反思改进措施 背景 机器发生了宕机，查看后发现有个节点没有自动切库成功，为了保证集群对外能正常服务，所以决定手动强制切库，保证集群对外的可用性。 事故描述 先使
redis cluster master failover问题
阿拉斯加大闸蟹的博客
02-24 5778
背景： 在进行主从切换演练的过程中，发现client应用端会在master下线后，slave选举成为主且节点topology拓扑更新完毕的过程中出现报错信息 默认的时间是60s，我这里配置的是300ms io.lettuce.core.RedisCommandTimeoutException: Command timed out after 300 millisecond(s) at io.lettuce.core.ExceptionFactory.createTimeoutExc
Redis入门完整教程：哨兵的安装和部署
Lee达森的博客
07-06 1421
上一节介绍了Redis Sentinel的基本架构，本节将介绍如何安装和部署 Redis Sentinel。 9.2.1　部署拓扑结构 下面将以3个Sentinel节点、1个主节点、2个从节点组成一个Redis Sentinel进行说明，拓扑结构如图9-13所示。具体的物理部署如表9-2所示。 9.2.2　部署Redis数据节点 9.1节提到过，Redis Sentinel中Redis数据节点没有做任何特殊配置，按 照之前章节介绍的方法启动就可以，下面以一个比较简单的配置进行说明。 1.启动主节点 配置：
Redis部署（单机，主从（哨兵），Cluster
qq_39166937的博客
06-17 796
Redis单机，主从（哨兵），Cluster集群的安装部署
sentinel 官方文档_redis哨兵（Sentinel）模式详解
weixin_39906245的博客
11-22 388
官方文档https://redis.io/topics/sentinel简介Redis Sentinel为Redis提供高可用性Sentinel模式是一种特殊的模式，首先Redis提供了Sentinel的命令，Sentinel是一个独立的进程，作为进程，它会独立运行其原理是Sentinel通过发送命令，等待Redis服务器响应，从而监控运行的多个Redis实例作用通过发送命令，让Redis服务器返...
redis高可用之redis-Sentinel
05-27 125
配置： 先搭建好redis主从环境： 主： 100.5.120.118 6379 从1 100.5.120.118 6380 从2 100.5.120.118 6381 从3 100.5.120.11...
【Redis专题】redis日志分析
weixin_41248819的博客
12-27 2616
SLAVEOF not allowed in cluster mode 不允许在集群中使用 主从切换日志 1:M 01 Dec 14:44:51.799 # Setting secondary replication ID to 63e58e3dc3d0d1fc4607a519e5a20383eeb70219, valid up to offset: 3823202378426. New replication ID is a8c16c15a0db9f55370096cb7460edba449d3b.
Redis 学习笔记(二)【原创】
未觉池塘青草梦，阶前梧叶已秋声
01-04 666
公司引入redis服务已经有两年多时间了，目前已经很有很多项目在使用，并且一直很稳定，日常客户端链接数维持在2k左右。由于原先只做了主从，没有做failover，随着项目的增多，存在一定的安全隐患，因此最近腾出时间研究redis服务升级。 目前可选的方案： 1）sentinel集群 + redis主从 2）redis cluster 两种方案的区别： 1）sentinel集群 + red...
redis错误排查
热门推荐
rongge2008的专栏
12-07 3万+
日志集中式监控平台上线已经有一段时间，但是大部分情况下只是作为发布或者出问题时查看日志的便利工具使用。平时大家都不怎么主动上去看看。于是前几天把应用的错误日志也加上邮件、Hi和短信报警，马上就收到很多错误报警，引起了大家的重视。其中有一个Redis报错： Push notify error: => redis.clients.jedis.exceptions.JedisConnectionExc
redis主从哨兵集群
08-26
Redis主从哨兵集群是一种常见的Redis高可用架构，用于提供数据的冗余备份和故障切换。在这种集群中，有一个主节点和多个从节点，还有若干个哨兵节点。 主节点负责处理所有的写操作和读操作，并将写操作的结果同步到...

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值