Redis哨兵机制

Dear 丶 2022-06-02 04:29 242阅读 0赞

一、什么是哨兵模式

我们知道Redis 在一个主库在对应多个从库的情况下,如果主库出了故障,那么所有的从库都会等待主库恢复,所这种情况是很危险的。哨兵模式是指如果主库出了故障,那么后台监控能够检查出该问题,从而在众多对应的从库中进行投票,产生新的主库,其余原主库的从库都会连接该主库,而不再与之前的主库相连接。

二、哨兵模式应用

因为是在一个虚拟机中进行演示,所以准备了三个Redis 服务,修改对应的文件,用来模拟三台主机。

需要新建一个sentinel.conf 文件,文件语法规则为:

  1. sentinel monitor 被监控数据库名字(自定义名字) 127.0.0.1 6379 票数

启用 redis-sentinel /myredis/sentinel.conf 启动哨兵

过程演示(只监视一个主库)

[1] 开启三个Redis 服务

  1. [root@localhost bin]# ./redis-server /myredis/redis.conf
  2. [root@localhost bin]# ./redis-cli -p 6379
  3. 127.0.0.1:6379>
  4. root@localhost bin]# ./redis-server /myredis/redis6380.conf
  5. [root@localhost bin]# ./redis-cli -p 6380
  6. 127.0.0.1:6380>
  7. [root@localhost bin]# ./redis-server /myredis/redis6381.conf
  8. [root@localhost bin]# ./redis-cli -p 6381
  9. 127.0.0.1:6381>

[2] 将6380 端口与6381 端口对应的服务设置为6379 的从库

  1. 127.0.0.1:6380> SLAVEOF 127.0.0.1 6379
  2. OK
  3. 127.0.0.1:6380>
  4. 127.0.0.1:6381> SLAVEOF 127.0.0.1 6379
  5. OK
  6. //查看主库对应的从库信息,配置完成
  7. 127.0.0.1:6379> INFO REPLICATION
  8. # Replication
  9. role:master //主库
  10. connected_slaves:2 //对应两个从库,分别是6380 与6381
  11. slave0:ip=127.0.0.1,port=6380,state=online,offset=90030,lag=1
  12. slave1:ip=127.0.0.1,port=6381,state=online,offset=90030,lag=2
  13. master_repl_offset:90030
  14. repl_backlog_active:1
  15. repl_backlog_size:1048576
  16. repl_backlog_first_byte_offset:2
  17. repl_backlog_histlen:90029

[3] 打开一个终端,在redis.conf 配置文件的目录下创建sentinel.conf 文件,用vim 打开进行如下配置

  1. sentinel monitor host6379 127.0.0.1 6379 1

[4] 开启哨兵,对应日志信息如下

  1. [root@localhost bin]# ./redis-sentinel /myredis/sentinel.conf
  2. *** FATAL CONFIG FILE ERROR ***
  3. Reading the configuration file, at line 1
  4. >>> 'entinel monitor host6379 127.0.0.1 6379 1'
  5. Bad directive or wrong number of arguments
  6. [root@localhost bin]# ./redis-sentinel /myredis/sentinel.conf
  7. 8874:X 03 Jan 14:16:15.633 * Increased maximum number of open files to 10032 (it was originally set to 1024).
  8. _._
  9. _.-``__ ''-._
  10. _.-`` `. `_. ''-._ Redis 3.0.4 (00000000/0) 64 bit
  11. .-`` .-```. ```\/ _.,_ ''-._
  12. ( ' , .-` | `, ) Running in sentinel mode |`-._`-...-` __...-.``-._|'` _.-'| Port: 26379 | `-._ `._ / _.-' | PID: 8874
  13. `-._ `-._ `-./ _.-' _.-'
  14. |`-._`-._ `-.__.-' _.-'_.-'| | `-._`-._ _.-'_.-' | http://redis.io `-._ `-._`-.__.-'_.-' _.-'
  15. |`-._`-._ `-.__.-' _.-'_.-'| | `-._`-._ _.-'_.-' | `-._ `-._`-.__.-'_.-' _.-'
  16. `-._ `-.__.-' _.-'
  17. `-._ _.-' `-.__.-'
  18. 8874:X 03 Jan 14:16:15.721 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
  19. 8874:X 03 Jan 14:16:15.721 # Sentinel runid is 6c33484891d59eae4fe90470378486f833c67fb2
  20. 8874:X 03 Jan 14:16:15.721 # +monitor master host6379 127.0.0.1 6379 quorum 1
  21. 8874:X 03 Jan 14:16:16.677 * +slave slave 127.0.0.1:6380 127.0.0.1 6380 @ host6379 127.0.0.1 6379
  22. 8874:X 03 Jan 14:16:16.693 * +slave slave 127.0.0.1:6381 127.0.0.1 6381 @ host6379 127.0.0.1 6379

[5] 6379 关闭服务,主库被关闭,日志信息发生变化,新的主库产生

  1. 127.0.0.1:6379> SHUTDOWN
  2. not connected> exit
  3. //当主库退出后,哨兵日志信息发生了变化,经过对两个从库的投票,最后选择 6380 端口对应的服务为主库
  4. [root@localhost bin]# ./redis-sentinel /myredis/sentinel.conf
  5. 8874:X 03 Jan 14:16:15.633 * Increased maximum number of open files to 10032 (it was originally set to 1024).
  6. _._
  7. _.-``__ ''-._
  8. _.-`` `. `_. ''-._ Redis 3.0.4 (00000000/0) 64 bit
  9. .-`` .-```. ```\/ _.,_ ''-._
  10. ( ' , .-` | `, ) Running in sentinel mode |`-._`-...-` __...-.``-._|'` _.-'| Port: 26379 | `-._ `._ / _.-' | PID: 8874
  11. `-._ `-._ `-./ _.-' _.-'
  12. |`-._`-._ `-.__.-' _.-'_.-'| | `-._`-._ _.-'_.-' | http://redis.io `-._ `-._`-.__.-'_.-' _.-'
  13. |`-._`-._ `-.__.-' _.-'_.-'| | `-._`-._ _.-'_.-' | `-._ `-._`-.__.-'_.-' _.-'
  14. `-._ `-.__.-' _.-'
  15. `-._ _.-' `-.__.-'
  16. 8874:X 03 Jan 14:16:15.721 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
  17. 8874:X 03 Jan 14:16:15.721 # Sentinel runid is 6c33484891d59eae4fe90470378486f833c67fb2
  18. 8874:X 03 Jan 14:16:15.721 # +monitor master host6379 127.0.0.1 6379 quorum 1
  19. 8874:X 03 Jan 14:16:16.677 * +slave slave 127.0.0.1:6380 127.0.0.1 6380 @ host6379 127.0.0.1 6379
  20. 8874:X 03 Jan 14:16:16.693 * +slave slave 127.0.0.1:6381 127.0.0.1 6381 @ host6379 127.0.0.1 6379
  21. sentinel monito8874:X 03 Jan 14:41:54.364 # +sdown master host6379 127.0.0.1 6379
  22. 8874:X 03 Jan 14:41:54.364 # +odown master host6379 127.0.0.1 6379 #quorum 1/1
  23. 8874:X 03 Jan 14:41:54.366 # +new-epoch 1
  24. 8874:X 03 Jan 14:41:54.366 # +try-failover master host6379 127.0.0.1 6379
  25. 8874:X 03 Jan 14:41:54.375 # +vote-for-leader 6c33484891d59eae4fe90470378486f833c67fb2 1
  26. 8874:X 03 Jan 14:41:54.375 # +elected-leader master host6379 127.0.0.1 6379
  27. 8874:X 03 Jan 14:41:54.375 # +failover-state-select-slave master host6379 127.0.0.1 6379
  28. 8874:X 03 Jan 14:41:54.440 # +selected-slave slave 127.0.0.1:6380 127.0.0.1 6380 @ host6379 127.0.0.1 6379
  29. 8874:X 03 Jan 14:41:54.440 * +failover-state-send-slaveof-noone slave 127.0.0.1:6380 127.0.0.1 6380 @ host6379 127.0.0.1 6379
  30. 8874:X 03 Jan 14:41:54.509 * +failover-state-wait-promotion slave 127.0.0.1:6380 127.0.0.1 6380 @ host6379 127.0.0.1 6379
  31. 8874:X 03 Jan 14:41:54.806 # +promoted-slave slave 127.0.0.1:6380 127.0.0.1 6380 @ host6379 127.0.0.1 6379
  32. 8874:X 03 Jan 14:41:54.806 # +failover-state-reconf-slaves master host6379 127.0.0.1 6379
  33. 8874:X 03 Jan 14:41:54.885 * +slave-reconf-sent slave 127.0.0.1:6381 127.0.0.1 6381 @ host6379 127.0.0.1 6379
  34. 8874:X 03 Jan 14:41:55.861 * +slave-reconf-inprog slave 127.0.0.1:6381 127.0.0.1 6381 @ host6379 127.0.0.1 6379
  35. 8874:X 03 Jan 14:41:56.934 * +slave-reconf-done slave 127.0.0.1:6381 127.0.0.1 6381 @ host6379 127.0.0.1 6379
  36. 8874:X 03 Jan 14:41:57.022 # +failover-end master host6379 127.0.0.1 6379
  37. 8874:X 03 Jan 14:41:57.024 # +switch-master host6379 127.0.0.1 6379 127.0.0.1 6380
  38. 8874:X 03 Jan 14:41:57.032 * +slave slave 127.0.0.1:6381 127.0.0.1 6381 @ host6379 127.0.0.1 6380
  39. 8874:X 03 Jan 14:41:57.039 * +slave slave 127.0.0.1:6379 127.0.0.1 6379 @ host6379 127.0.0.1 6380
  40. 8874:X 03 Jan 14:42:27.039 # +sdown slave 127.0.0.1:6379 127.0.0.1 6379 @ host6379 127.0.0.1 6380

[6] 查看6380 端口,与6381 端口,6380 由原来的从库变成了主库,6381 对应的主库也发生了变化

  1. 127.0.0.1:6380> INFO REPLICATION
  2. # Replication
  3. role:master //由从库变成了主库
  4. connected_slaves:1 //现在只有一个从库6381
  5. slave0:ip=127.0.0.1,port=6381,state=online,offset=5190,lag=0
  6. master_repl_offset:5190
  7. repl_backlog_active:1
  8. repl_backlog_size:1048576
  9. repl_backlog_first_byte_offset:2
  10. repl_backlog_histlen:5189
  11. 127.0.0.1:6381> INFO REPLICATION
  12. # Replication
  13. role:slave //由于投票决定还是从库
  14. master_host:127.0.0.1
  15. master_port:6380 //主库由原来的6379 变成了6380
  16. master_link_status:up
  17. master_last_io_seconds_ago:1
  18. master_sync_in_progress:0
  19. slave_repl_offset:5736
  20. slave_priority:100
  21. slave_read_only:1
  22. connected_slaves:0
  23. master_repl_offset:0
  24. repl_backlog_active:0
  25. repl_backlog_size:1048576
  26. repl_backlog_first_byte_offset:0
  27. repl_backlog_histlen:0

[7] 如果原主库6379 恢复了正常,那么它将变成新主库的从库

  1. [root@localhost bin]# ./redis-server /myredis/redis.conf
  2. [root@localhost bin]# ./redis-cli -p 6379
  3. 127.0.0.1:6379> INFO REPLICATION
  4. # Replication
  5. role:slave // 由故障前的主库变成了从库
  6. master_host:127.0.0.1 //对应的主库为投票出来的6380
  7. master_port:6380
  8. master_link_status:up
  9. master_last_io_seconds_ago:2
  10. master_sync_in_progress:0
  11. slave_repl_offset:34543
  12. slave_priority:100
  13. slave_read_only:1
  14. connected_slaves:0
  15. master_repl_offset:0
  16. repl_backlog_active:0
  17. repl_backlog_size:1048576
  18. repl_backlog_first_byte_offset:0
  19. repl_backlog_histlen:0

三、图解

为了更好理解,对这个过程画了图解,如果有不正确的地方还望大家指正。

一开始一个主库对应着两个从库,正常的工作着。
这里写图片描述

主库挂掉之后,新的主库产生。
这里写图片描述

后来出故障的主库恢复了正常,发现却不再是主库。

这里写图片描述

同理如果主库6380 端口对应的服务出故障,那么将会在6379 与6381 从库中重新选出主库。

发表评论

表情:
评论列表 (有 0 条评论,242人围观)

还没有评论,来说两句吧...

相关阅读

    相关 Redis哨兵机制

    > slave节点宕机恢复后可以找master节点同步数据,那master节点宕机了怎么办呢? 1.哨兵的作用和原理 ![在这里插入图片描述][c95decb035e5

    相关 redis 哨兵机制

    1,什么是redis sentinel(哨兵) 哨兵在redis集群架构中是一个非常重要的组件,其主要功能有下面这些: 1. 集群监控,即时刻监控着redis的mas

    相关 redis哨兵机制

    redis有很多种集群方式,而哨兵机制就是其中的一种 如何配置哨兵机制呢? 首先理解一线哨兵是什么 哨兵就是监控redis服务是否正常运行的一种监控服务,可以把它理

    相关 redis哨兵机制

    redis哨兵机制 在集群模式下,如果主库发生故障,就导致主库的写操作失败以及从库的数据同步失败 哨兵机制主要解决主从库故障切换 哨兵主要功能: 监控:监控库

    相关 Redis哨兵机制

    1、哨兵机制的简介        有了主从复制的实现以后,如果想对主服务器进行监控,那么在redis2.6以后提供了一个"哨兵"的机制。顾名思义,哨兵的含义就是监控Redis

    相关 Redis哨兵机制

    一、什么是哨兵模式 我们知道Redis 在一个主库在对应多个从库的情况下,如果主库出了故障,那么所有的从库都会等待主库恢复,所这种情况是很危险的。哨兵模式是指如果主库出了

    相关 Redis 哨兵机制

    目录 什么是Redis 什么是哨兵机制 哨兵机制作用 -------------------- 什么是Redis Redis 是一个基于内存的高性能非关系型数据