文末有免费红包封面领取哦
上一次我们说到的主从复制是这样搭建的
主机可以读,可以写
从机只能读,不能写
想一想,那么我们是不是也可以这样呢?
多个 redis-server 首尾相连
那么咱们部署的时候就是 6379 – 6380 – 6381
此时,若主机 6379 宕机掉,6380 会不会变成主机呢?
127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:1
slave0:ip=127.0.0.1,port=6380,state=online,offset=0,lag=1
master_failover_state:no-failover
master_replid:f1e3db9e5e438f5d98e4cad23f684b12d790ae56
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:0
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:0
我们可以看到 6379 有一个从机,6380 自身也是作为从机(虽然 6380 是 6381 的主机)
此时将 6379 宕机掉,发现 6380 仍然是 slave
127.0.0.1:6379> shudown
not connected>
我们人为的将 reids 6380 的服务器修改为主机,看看 6379 redis-server 起来之后,是否可以把 master 抢回去
使用 slaveof no one
可以将自己设置成 master
启动 6379 redis-server
redis-server /usr/local/redis/redis-6.2.5/6379.conf
发现 6380 仍然是主机,6379 成为了光杆司令
实际项目中,我们肯定不会采取上面和上一次文章说到的部署方式,他们抵御风险的能力太低了
因为实际生产环境中,主机宕机了,若从机没有办法成为主机的话,岂不是在主机回复之前再也不能做写入操作了吗?这是很严重的问题
下面我们来详细看看 哨兵模式是如何解决上述问题的
自动选举 master 的模式
主动切换 master 的方法是:
当主机服务器宕机后,以往的情况咱们需要手动把某一个从机服务器修改为主机服务器,需要人为处理,耗时耗力,且会造成一段时间内服务不可用的情况,这种做法是不可取的
所以有了哨兵模式,哨兵模式是 redis 2.8 版本开始真是提供的 sentinel 架构来解决上述的问题
哨兵模式,能够监控后台的主机服务器是否故障,若出现了故障,则会投票选举出一个从机服务器来做主机
哨兵模式是一种特殊的模式,Redis 提供了哨兵的命令
哨兵其实是一个独立的进程,作为进程,它会独立运行
其原理就是哨兵通过发送命令,等到 Redis 服务器响应,从而监控运行的多个 Redis 实例
上图中的架构图,哨兵有 2 个作用:
可是一个哨兵来监控一个 redis 集群,出现问题的可能性会大很多,因此,我们的哨兵也可以是集群的,每隔哨兵之间还会互相监控的,就像下面这张图
主观下线
例如咱们举一个例子,如果 master 服务器宕机了,那么其中一个哨兵就会检测到,系统并不会马上执行 failover 的过程,仅仅是当前这个哨兵,判断 master 不可用,这个就是主观下线
客观下线
当其他两个哨兵也发现 master 服务器不可用的时候,那么哨兵之间就会产生投票,具体的投票算法我们后续再写,投票的结构由一个哨兵发起,进行 failover 故障转移的操作,切换成功之后,就会通过发布订阅模式,让每一个监控的哨兵把自己监控的服务器切换到这个 master 服务器上, 这个就是 客观下线
我们来配置和开启一个哨兵:
同样在我们的配置文件目录,与 redis 是同级的目录下,创建一个 sentinel.conf 文件, 并写入配置,这个文件安装 redis 默认也会生成一个
如上,咱们关注的命令是
sentinel monitor mymaster 127.0.0.1 6379 1
配置一个哨兵,进行监控 redis 集群
开启 哨兵 进程
root@iZuf66y3tuzn4wp3h02t7pZ:/usr/local/redis/redis-6.2.5# redis-sentinel sentinel.conf
18148:X 26 Aug 2021 22:22:36.187 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
18148:X 26 Aug 2021 22:22:36.187 # Redis version=6.2.5, bits=64, commit=00000000, modified=0, pid=18148, just started
18148:X 26 Aug 2021 22:22:36.187 # Configuration loaded
18148:X 26 Aug 2021 22:22:36.188 * monotonic clock: POSIX clock_gettime
_._
_.-``__ ''-._
_.-`` `. `_. ''-._ Redis 6.2.5 (00000000/0) 64 bit
.-`` .-```. ```\/ _.,_ ''-._
( ' , .-` | `, ) Running in sentinel mode
|`-._`-...-` __...-.``-._|'` _.-'| Port: 26379
| `-._ `._ / _.-' | PID: 18148
`-._ `-._ `-./ _.-' _.-'
|`-._`-._ `-.__.-' _.-'_.-'|
| `-._`-._ _.-'_.-' | https://redis.io
`-._ `-._`-.__.-'_.-' _.-'
|`-._`-._ `-.__.-' _.-'_.-'|
| `-._`-._ _.-'_.-' |
`-._ `-._`-.__.-'_.-' _.-'
`-._ `-.__.-' _.-'
`-._ _.-'
`-.__.-'
18148:X 26 Aug 2021 22:22:36.189 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
18148:X 26 Aug 2021 22:22:36.193 # Sentinel ID is 7e01f5aa31aadb7fc54ed8ef2579c77120682dc9
18148:X 26 Aug 2021 22:22:36.193 # +monitor master mymaster 127.0.0.1 6379 quorum 1
18148:X 26 Aug 2021 22:22:36.193 * +slave slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6379
18148:X 26 Aug 2021 22:22:36.196 * +slave slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6379
我们可以看到,开启哨兵进程之后,开始监控到 redis 集群,并输出了监控的 redis 的 ip 和端口
此时,咱们查看一个 master redis 服务器的信息,可以看到目前有 2 个 slave ,现在咱们让主机宕机
查看哨兵的日志,咱们可以看到 哨兵进程在 30 秒之后,开始进行投票选举主机
根据日志,我们可以看出,6379 的主机宕机之后,哨兵选举了 6381 的从机作为新的主机,自动故障恢复成功,nice
查看 6381 的 master 主机进程,查看到自己是主机,有1 个从机
由于 6379 默认配置就是 主机,因此将 6379 服务器再次启动的时候,6379 就变成了光杆司令,从机就变成了 0 个
root@iZuf66y3tuzn4wp3h02t7pZ:~# redis-server /usr/local/redis/redis-6.2.5/6379.conf
root@iZuf66y3tuzn4wp3h02t7pZ:~# redis-cli -p 6379
127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:0
master_failover_state:no-failover
master_replid:80843f8a6497705983f6463b92d71ebd451ef385
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:0
second_repl_offset:-1
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0
sentinel.conf 配置文件里面的配置项也不多,下面咱们详细的一一说明一下:
哨兵 sentinel 实例运行的端口 , 默认是26379,如果有哨兵集群,我们还需要配置每个哨兵端口
哨兵sentinel的工作目录
哨兵 sentinel 监控的 redis 主节点的 ip port
master-name ,可以自己命名的主节点名字 只能由字母A-Z、数字0-9、这三个字符" . - _ "组成。
quorum 配置多少个 sentinel 哨兵统一认为master主节点失联那么这时客观上认为主节点失联了
当在 Redis 实例中开启了requirepass foobared 授权密码这样所有连接 redis 实例的客户端都要提供密码
设置哨兵 sentinel 连接主从的密码注意必须为主从设置一样的验证密码
指定多少毫秒之后主节点没有应答哨兵sentine1 此时哨兵主观上认为主节点下线默认30秒
指定了在发生 failover 主备切换时最多可以有多少个 slave 同时对新的 master 进行同步
这个数字越小,完成 failover 所需的时间就越长
但是如果这个数字越大,就意味着越多的 slave 因为 replication 而 不可用
可以通过将这个值设为 1 来保证每次只有一个 slave 处于不能处理命令请求的状态
故障转移的超时时间failover-timeout 可以用在以下这些方面:
1、同一个 sentinel 对同一 个 master 两次 failover 之间的间隔时间
2、当一个 slave 从一 个错误的 master 那里同步数据开始计算时间
直到 slave 被纠正为向正确的 master 那里同步数据时
3、当想要取消一个正在进行的 failover 所需要的时间
4、当进行 failover 时,配置所有 slave 指向新的master所需的最大时间
不过,即使过了这个超时,slaves 依然会被正确配置为指向 master , 但是就不按 parallel-syncs所配置的规则来了
5、默认时间是三分钟
当 sentinel 有任何警告级别的事件发生时(比如说redis实例的主观失效和客观失效等等),将会去调用这个脚本
这时这个脚本应该通过邮件,SMS 等方式去通知系统管理员关于系统不正常运行的信息
调用该脚本时,将传给脚本两个参数
1、事件的类型
2、事件的描述
如果 sentinel . conf
配置文件中配置了这个脚本路径,那么必须保证这个脚本存在于这个路径,并且是可执行的,否则 sentinel 无法正常启动成功
该配置是客户端重新配置主节点参数脚本
当一个 master 由于 failover 而发生改变时,这个脚本将会被调用,通知相关的客户端关于master 地址已经发生改变的信息
以下参数将会在调用脚本时传给脚本:
, 是 Teader 或者 observer 中的-一个
, 一般是 failover
参数 from-ip, from-port, to-ip,to-port 是用来和旧的 master 和新的 master (即旧的s lave)通信的
port 26379
dir /tmp
sentinel monitor mymaster 127.0.0.1 6379 2
sentine1 auth-pass mymaster MySUPER--secret-0123passwOrd
sentine1 down-after-mi 11iseconds mymaster 30000
sentine1 paralle1-syncs mymaster 1
sentine1 fai lover-ti meout mymaster 180000
sentine1 notificati on-script mymaster /var/redis/notify. sh
sentine1 client-reconfig-script mymaster /var/redis/reconfig.sh
参考资料:
redis_doc
朋友们,你的支持和鼓励,是我坚持分享,提高质量的动力
好了,本次就到这里
技术是开放的,我们的心态,更应是开放的。拥抱变化,向阳而生,努力向前行。
我是小魔童哪吒,欢迎点赞关注收藏,下次见~