redis哨兵模式

最新推荐文章于 2024-03-01 10:45:45 发布
最新推荐文章于 2024-03-01 10:45:45 发布
阅读量673 收藏 1
点赞数
分类专栏： Redis + MongoDB 文章标签： redis 数据库 哨兵 高可用
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/u010520724/article/details/109714202
版权

备注:测试版本 redis 4.0.9

文章目录

一.redis哨兵模式介绍

Sentinel(哨兵)是用于监控redis集群中Master状态的工具，是Redis 的高可用性解决方案，sentinel哨兵模式已经被集成在redis2.4之后的版本中。sentinel是redis高可用的解决方案，sentinel系统可以监视一个或者多个redis master服务，以及这些master服务的所有从服务；当某个master服务下线时，自动将该master下的某个从服务升级为master服务替代已下线的master服务继续处理请求。

sentinel可以让redis实现主从复制，当一个集群中的master失效之后，sentinel可以选举出一个新的master用于自动接替master的工作，集群中的其他redis服务器自动指向新的master同步数据。一般建议sentinel采取奇数台，防止某一台sentinel无法连接到master导致误切换。

二.redis哨兵模式搭建

环境要求:

服务器类别IP
主10.31.1.123
从10.31.1.124

123、124两台服务器已经成功搭建了主从

2.1 修改配置文件并启动哨兵模式

123主库执行如下操作:

-- 拷贝哨兵模式的配置文件
[root@10-31-1-123 redis]# find / -name sentinel.conf                    
/usr/local/src/redis-4.0.9/sentinel.conf
[root@10-31-1-123 redis]# 
[root@10-31-1-123 redis]# cp /usr/local/src/redis-4.0.9/sentinel.conf /usr/local/redis/
[root@10-31-1-123 redis]# 

-- 修改哨兵模式的参数文件
vi  sentinel.conf
bind 10.31.1.123 127.0.0.1
sentinel monitor mymaster 10.31.1.123 6379 1
sentinel auth-pass mymaster 123456
logfile "/tmp/26379.log"
-- 启动哨兵
 redis-sentinel sentinel.conf &
-- 查看日志
[root@10-31-1-123 tmp]# tail -100f 26379.log 
22387:X 03 Nov 18:17:19.068 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
22387:X 03 Nov 18:17:19.068 # Redis version=4.0.9, bits=64, commit=00000000, modified=0, pid=22387, just started
22387:X 03 Nov 18:17:19.068 # Configuration loaded
22387:X 03 Nov 18:17:19.069 * Increased maximum number of open files to 10032 (it was originally set to 1024).
22387:X 03 Nov 18:17:19.072 * Running mode=sentinel, port=26379.
22387:X 03 Nov 18:17:19.072 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
22387:X 03 Nov 18:17:19.073 # Sentinel ID is b07e0bdbc836f6cb29f943bb8cf8d983d68b6e7a
22387:X 03 Nov 18:17:19.073 # +monitor master mymaster 10.31.1.123 6379 quorum 2
22387:X 03 Nov 18:17:19.074 * +slave slave 10.31.1.124:6379 10.31.1.124 6379 @ mymaster 10.31.1.123 6379

主库123 redis.conf文件要添加密码认证，不然切换的时候没有密码认证，连接不上新的主库

masterauth 123456

2.2 模拟故障

在125上远程访问主库123上的redis

[root@10-31-1-125 ~]# redis-cli -h 10.31.1.123 -p 6379 -a 123456 
10.31.1.123:6379> 
10.31.1.123:6379> keys *
1) "my_db3"
2) "my_db1"
3) "my_db4"
4) "my_db2"
5) "user_id"
6) "my_db5"

关闭主库123的redis服务

[root@10-31-1-123 redis]# redis-cli -a 123456 shutdown
[root@10-31-1-123 redis]#

此时125上显示not connect

[root@10-31-1-125 ~]# redis-cli -h 10.31.1.123 -p 6379 -a 123456 
10.31.1.123:6379> 
10.31.1.123:6379> keys *
1) "my_db3"
2) "my_db1"
3) "my_db4"
4) "my_db2"
5) "user_id"
6) "my_db5"
10.31.1.123:6379> keys *
Could not connect to Redis at 10.31.1.123:6379: Connection refused
not connected>

重新启动123上的redis，查看123 redis服务日志
发现此时123上的主库已经变为从库了，从新主库124上同步数据

3020:S 04 Nov 09:48:48.871 * Connecting to MASTER 10.31.1.124:6379
3020:S 04 Nov 09:48:48.871 * MASTER <-> SLAVE sync started
3020:S 04 Nov 09:48:48.871 * Non blocking connect for SYNC fired the event.
3020:S 04 Nov 09:48:48.872 * Master replied to PING, replication can continue...
3020:S 04 Nov 09:48:48.872 * Partial resynchronization not possible (no cached master)
3020:S 04 Nov 09:48:48.875 * Full resync from master: e82e16eb8645f4dced3d99e64c15da8710297cb5:3623877
3020:S 04 Nov 09:48:48.926 * MASTER <-> SLAVE sync: receiving 283 bytes from master
3020:S 04 Nov 09:48:48.927 * MASTER <-> SLAVE sync: Flushing old data
3020:S 04 Nov 09:48:48.927 * MASTER <-> SLAVE sync: Loading DB in memory
3020:S 04 Nov 09:48:48.927 * MASTER <-> SLAVE sync: Finished with success
3020:S 04 Nov 09:48:48.928 * Background append only file rewriting started by pid 3024
3020:S 04 Nov 09:48:48.953 * AOF rewrite child asks to stop sending diffs.
3024:C 04 Nov 09:48:48.953 * Parent agreed to stop sending diffs. Finalizing AOF...
3024:C 04 Nov 09:48:48.954 * Concatenating 0.00 MB of AOF diff received from parent.
3024:C 04 Nov 09:48:48.954 * SYNC append only file rewrite performed
3024:C 04 Nov 09:48:48.954 * AOF rewrite: 6 MB of memory used by copy-on-write
3020:S 04 Nov 09:48:48.971 * Background AOF rewrite terminated with success
3020:S 04 Nov 09:48:48.972 * Residual parent diff successfully flushed to the rewritten AOF (0.00 MB)
3020:S 04 Nov 09:48:48.972 * Background AOF rewrite finished successfully

查看123的哨兵日志
发现启动了failover

1262:X 04 Nov 09:16:33.137 # +sdown master mymaster 10.31.1.123 6379
1262:X 04 Nov 09:16:33.137 # +odown master mymaster 10.31.1.123 6379 #quorum 1/1
1262:X 04 Nov 09:16:33.137 # +new-epoch 1
1262:X 04 Nov 09:16:33.137 # +try-failover master mymaster 10.31.1.123 6379
1262:X 04 Nov 09:16:33.138 # +vote-for-leader b07e0bdbc836f6cb29f943bb8cf8d983d68b6e7a 1
1262:X 04 Nov 09:16:33.139 # +elected-leader master mymaster 10.31.1.123 6379
1262:X 04 Nov 09:16:33.139 # +failover-state-select-slave master mymaster 10.31.1.123 6379
1262:X 04 Nov 09:16:33.215 # +selected-slave slave 10.31.1.124:6379 10.31.1.124 6379 @ mymaster 10.31.1.123 6379
1262:X 04 Nov 09:16:33.215 * +failover-state-send-slaveof-noone slave 10.31.1.124:6379 10.31.1.124 6379 @ mymaster 10.31.1.123 6379
1262:X 04 Nov 09:16:33.316 * +failover-state-wait-promotion slave 10.31.1.124:6379 10.31.1.124 6379 @ mymaster 10.31.1.123 6379
1262:X 04 Nov 09:16:33.742 # +promoted-slave slave 10.31.1.124:6379 10.31.1.124 6379 @ mymaster 10.31.1.123 6379
1262:X 04 Nov 09:16:33.742 # +failover-state-reconf-slaves master mymaster 10.31.1.123 6379
1262:X 04 Nov 09:16:33.806 # +failover-end master mymaster 10.31.1.123 6379
1262:X 04 Nov 09:16:33.807 # +switch-master mymaster 10.31.1.123 6379 10.31.1.124 6379
1262:X 04 Nov 09:16:33.807 * +slave slave 10.31.1.123:6379 10.31.1.123 6379 @ mymaster 10.31.1.124 6379
1262:X 04 Nov 09:16:46.013 * +convert-to-slave slave 10.31.1.123:6379 10.31.1.123 6379 @ mymaster 10.31.1.124 6379

查看 124 redis服务日志
刚开始的时候是连接不到主库，后面提升为主库

12344:S 04 Nov 09:16:28.562 * Connecting to MASTER 10.31.1.123:6379
12344:S 04 Nov 09:16:28.563 * MASTER <-> SLAVE sync started
12344:S 04 Nov 09:16:28.563 # Error condition on socket for SYNC: Connection refused
12344:S 04 Nov 09:16:29.565 * Connecting to MASTER 10.31.1.123:6379
12344:S 04 Nov 09:16:29.566 * MASTER <-> SLAVE sync started
12344:S 04 Nov 09:16:29.566 # Error condition on socket for SYNC: Connection refused
12344:S 04 Nov 09:16:30.569 * Connecting to MASTER 10.31.1.123:6379
12344:S 04 Nov 09:16:30.569 * MASTER <-> SLAVE sync started
12344:S 04 Nov 09:16:30.570 # Error condition on socket for SYNC: Connection refused
12344:S 04 Nov 09:16:31.572 * Connecting to MASTER 10.31.1.123:6379
12344:S 04 Nov 09:16:31.572 * MASTER <-> SLAVE sync started
12344:S 04 Nov 09:16:31.572 # Error condition on socket for SYNC: Connection refused
12344:S 04 Nov 09:16:32.573 * Connecting to MASTER 10.31.1.123:6379
12344:S 04 Nov 09:16:32.573 * MASTER <-> SLAVE sync started
12344:S 04 Nov 09:16:32.574 # Error condition on socket for SYNC: Connection refused
12344:M 04 Nov 09:16:33.316 # Setting secondary replication ID to 21f6348d7db2446e2369e1b6243a7d4fc5fe3a42, valid up to offset: 3494901. New replication ID is e82e16eb8645f4dced3d99e64c15da8710297cb5
12344:M 04 Nov 09:16:33.316 * Discarding previously cached master state.
12344:M 04 Nov 09:16:33.316 * MASTER MODE enabled (user request from 'id=52920 addr=10.31.1.123:55852 fd=10 name=sentinel-b07e0bdb-cmd age=205 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')
12344:M 04 Nov 09:16:33.319 # CONFIG REWRITE executed with success.
12344:M 04 Nov 09:19:25.098 * 1 changes in 900 seconds. Saving...
12344:M 04 Nov 09:19:25.099 * Background saving started by pid 21765
21765:C 04 Nov 09:19:25.100 * DB saved on disk
21765:C 04 Nov 09:19:25.103 * RDB: 6 MB of memory used by copy-on-write
12344:M 04 Nov 09:19:25.200 * Background saving terminated with success

查看123主库的redis.conf
可以看到已经成为新的主库124的备库，从124上同步数据

# Generated by CONFIG REWRITE
slaveof 10.31.1.124 6379

查看123主库的sentinel.conf
可以看到，主从库已经互换了

sentinel monitor mymaster 10.31.1.124 6379 1
# Generated by CONFIG REWRITE
sentinel known-slave mymaster 10.31.1.123 6379
sentinel current-epoch 1

三.Sentinel 总结

3.1 Sentinel的作用：

A、Master 状态监测
B、如果Master 异常，则会进行Master-slave 转换，将其中一个Slave作为Master，将之前的Master作为Slave
C、Master-Slave切换后，master_redis.conf、slave_redis.conf和sentinel.conf的内容都会发生改变，即master_redis.conf中会多一行slaveof的配置，sentinel.conf的监控目标会随之调换

3.2 Sentinel的工作方式:

1)：每个Sentinel以每秒钟一次的频率向它所知的Master，Slave以及其他Sentinel实例发送一个PING命令
2)：如果一个实例（instance）距离最后一次有效回复 PING 命令的时间超过 down-after-milliseconds 选项所指定的值，则这个实例会被 Sentinel 标记为主观下线。
3)：如果一个Master被标记为主观下线，则正在监视这个Master的所有 Sentinel 要以每秒一次的频率确认Master的确进入了主观下线状态。
4)：当有足够数量的 Sentinel（大于等于配置文件指定的值）在指定的时间范围内确认Master的确进入了主观下线状态， 则Master会被标记为客观下线
5)：在一般情况下， 每个 Sentinel 会以每10 秒一次的频率向它已知的所有Master，Slave发送 INFO 命令
6)：当Master被 Sentinel 标记为客观下线时，Sentinel 向下线的 Master 的所有 Slave 发送 INFO 命令的频率会从 10 秒一次改为每秒一次
7)：若没有足够数量的 Sentinel 同意Master 已经下线， Master 的客观下线状态就会被移除。
若 Master 重新向 Sentinel 的 PING 命令返回有效回复， Master 的主观下线状态就会被移除。

3.3 Sentinel参数介绍

# 禁止保护模式
protected-mode no
# 配置监听的主服务器，这里sentinel monitor代表监控，mymaster代表服务器的名称，可以自定义，192.168.11.128代表监控的主服务器，6379代表端口，2代表只有两个或两个以上的哨兵认为主服务器不可用的时候，才会进行failover操作。
sentinel monitor mymaster 192.168.11.128 6379 2
# sentinel author-pass定义服务的密码，mymaster是服务名称，123456是Redis服务器密码
# sentinel auth-pass <master-name> <password>
sentinel auth-pass mymaster 123456

参考

1.https://www.cnblogs.com/kevingrace/p/9004460.html
2.https://blog.csdn.net/yaooch/article/details/80167571

只是甲
关注
  • 0
    点赞
  • 踩
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
Redis哨兵模式配置文件
03-26
Windows环境下，搭建Redis哨兵模式【一主二从三哨兵】所需要的配置文件。
Redis哨兵（Sentinel）模式
以爱护甲,爱满枫林。
10-13 450
主从切换技术的方法是：当主服务器宕机后，需要手动把一台从服务器切换为主服务器，这就需要人工干预，费事费力，还会造成一段时间内服务不可用。这不是一种推荐的方式，更多时候，我们优先考虑哨兵模式。 ** 一、哨兵模式概述 ** 哨兵模式是一种特殊的模式，首先Redis提供了哨兵的命令，哨兵是一个独立的进程，作为进程，它会独立运行。其原理是哨兵通过发送命令，等待Redis服务器响应，从而监控运行的多个Redis实例。 这里的哨兵有两个作用 通过发送命令，让Redis服务器返回监控其运行状态，包括主服务器和从服务器
Redis 之六：Redis 的哨兵模式（Sentinel）
最新发布
zp8126的专栏
03-01 1681
Redis 哨兵（Sentinel）模式是一种高可用性解决方案，用于监控和自动故障转移的集群系统。在 Redis Sentinel 架构中，哨兵是一组运行在特殊模式下的 Redis 进程，它们可以监控一个或多个主从复制结构中的 Redis 主服务器以及其他从服务器的状态。sentinel 哨兵模式已经被集成在 redis2.4 之后的版本中，哨兵的核心功能是主节点的自动故障转移。
Redis系列--哨兵模式
weixin_42972832的博客
05-18 4451
当主节点被判断为客观下线后，各个哨兵节点会进行协商，先选举出一个哨兵节点（Raft实算法），并由该哨兵节点推送故障迁移，选出新的master。当启动哨兵模式之后，如果你的master服务器宕机之后，哨兵自动会在从redis服务器里面 投票选举一个master主服务器出来；这个主服务器也可以进行读写操作！如果之前宕机的主服务器已经修好，可以正式运行了。那么这个服务器只能进行读的操作，也就说前大哥现在变为小弟了。
Redis 哨兵模式
qq15035899256的博客
02-24 1669
本文是对Redis哨兵的学习，认识了什么是哨兵？如何搭建哨兵模式？以及哨兵工作的三个阶段：监控、通知和故障转移。之后的学习内容将持续更新！！！
Redis哨兵模式
乌鸦喜欢写字台
11-24 3万+
一、哨兵模式概述 （自动选主机的方式） 主从切换技术：当主机宕机后，需要手动把一台从（slave）服务器切换为主服务器，这就需要人工干预，费时费力，还回造成一段时间内服务不可用，所以推荐哨兵架构（Sentinel）来解决这个问题。 哨兵模式是一种特殊的模式，首先Redis提供了哨兵的命令，哨兵是一个独立的进程，作为进程，它独立运行。其原理是哨兵通过发送命令，等待Redis服务器响应，从而监控运行的多个Redis实例。 这里哨兵模式有两个作用： 通过发送命令，让Redis服务器返回监控.
redis哨兵模式搭建及测试.doc
10-31
公司测试环境下搭建redis哨兵模式，经过一番测试是可以使用的。
docker-compose构建Redis哨兵模式镜像包
01-09
docker-compose构建Redis哨兵模式镜像包
Redis哨兵主从模式+keepalived.docx
12-12
Redis哨兵主从模式+keepalived
Redis哨兵模式：什么是哨兵模式、哨兵模式的优缺点、哨兵模式的主观下线和客观下线、投票选举、Redis 哨兵模式搭建
一码归一码@
12-07 3372
总结：哨兵模式在主从复制模式的基础上实现了自动故障转移，提高了系统的高可用性。然而，它仍然无法实现数据分片。如果需要实现数据分片和负载均衡，可以考虑使用Cluster模式。高可用性要求较高的场景：通过自动故障转移，确保服务的持续可用。数据备份和容灾恢复：在主从复制的基础上，提供自动故障转移功能。具有主从复制模式的所有优点，如数据冗余和读写分离。依然无法实现数据分片，受单节点内存限制。重要的配置看截图，ip地址以及格式请注意。自动故障转移，提高系统的高可用性。配置和管理相对复杂。混合持久化模式的开启。
Redis-Sentinel（哨兵模式），看这篇就够了哦
养歌的博客
12-15 8894
简介 Sentinel（哨兵） 是redis的高可用性解决方案：由一个或多个Sentinel实例组成的Sentinel系统可以监视任意多个主服务器，以及这些主服务器属下的所有从服务器，并在被监视的主服务器进行下线时，自动将下线主服务器属下的某个从服务器升级为新的主服务器。然后由新的主服务器代替已下线的主服务器继续处理命令请求。 例如下图所示： 当Server1 掉线后： 升级Server2 为新的主服务器： 启动并初始化Sentinel 启动一个Sentinel可以使用命令： redis-sentin
Redis(进阶)-----哨兵模式
weixin_43994761的博客
05-30 1328
首先要能理解SDOWN和ODOWN这两个词的含义，上面已经详细介绍了它们俩。在此再提一下：SDOWN : subjectively down , 直接翻译的为 "主观" 失效 , 即当前sentinel实例认为某个redis服务为 "不可用" 状态 . ODOWN : objectively down , 直接翻译为 "客观" 失效 , 即多个sentinel实例都认为master处于 "SDOWN" 状态 , 那么此时master将处于ODOWN , ODOWN可以简单理解为master已经被集群确定。
Redis的哨兵模式
热门推荐
qq_44299529的博客
03-03 3万+
引子 Master挂了，如何保证可用性，实现继续读写 什么是哨兵 Sentinel(哨兵)是用于监控Redis集群中Master状态的工具，是Redis高可用解决方案，哨兵可以监视一个或者多个redis master服务，以及这些master服务的所有从服务。 某个master服务宕机后，会把这个master下的某个从服务升级为master来替代已宕机的master继续工作。 （顺带提一句，即使后来之前的master重启服务，也不会变回master了，而是作为slave从服务） 哨兵模式原理图
Redis的哨兵模式详解
Hi，我是sharkchili，CSDN Java领域博客专家，开源项目JavaGuide维护人员，我想写一些有意思的东西，希望对你有帮助。
08-15 3179
通过下面的三条命令启动三个哨兵，完成命令且没有报错后，我们可以通过ps命令查看哨兵是否都正常启动，确保无误，我们再进入下一步。命令将其杀死，此时我们观察哨兵的日志就会看到它们进行故障转移，由此说明我们的哨兵模式架构部署成功。找下一个主节点，所以我们必须建立一个哨兵集群，这个哨兵集群我们必须从中选举出。首先解决第一个问题，由于哨兵挂了3个所以还剩两个，假如主节点挂了，由于。先主观下线，任意一个哨兵对主节点进行检测判断，主节点是否下线。，而哨兵只剩两个了，所以选不出哨兵的。命令从主库中获取从库的信息，从而与。
Redis篇——一篇文章带你彻底拿下Sentinel哨兵模式(自动选举老大的模式)技术点，超详细、保姆级别教程奉上，不要错过~
不积跬步无以至千里
12-08 2054
一、概述和实现逻辑主从切换技术的方法是，当主服务器宕机后，需要手动把一台从服务器通过命令切换为主服务器，这就需要人工干预，还会造成一段时间内服务不可用。这不是一种值得推荐的方式，更多的时候，我们会优先考虑哨兵模式！！！哨兵模式，是一个分布式系统：通俗的讲，就是一种谋朝篡位的自动版，能够在后台监控主机是否故障，如果故障了，会根据投票自动将从服务器转换为主服务器。用于监控和管理Redis实例的高可用性。在Redis Sentinel中，哨兵实例之间通过PING和PONG消息进行通信。
Redis-哨兵模式(sentinel)
爱笑的boy的博客
08-22 646
Redis-哨兵模式(sentinel)
redis 哨兵模式
07-27
Redis哨兵模式是一种用于监控Redis集群中Master状态的工具，它是Redis高可用解决方案的一部分。哨兵可以监视一个或多个Redis主服务器以及这些主服务器的所有从服务器。当某个主服务器宕机后，哨兵会将其中一个从...

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

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

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值