redis 11.哨兵模式(实现步骤，主机下线从机选举主机机制)

Redis哨兵模式：监控故障切换主库详解
最新推荐文章于 2024-06-30 06:15:00 发布
原创 最新推荐文章于 2024-06-30 06:15:00 发布 · 5.3w 阅读 · 3 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#redis

本文详细介绍了Redis哨兵模式的概念，包括如何通过哨兵监控主从切换过程。步骤涉及配置sentinel.conf，启动监控并演示主机故障后的自动切换。重点在于理解如何设置和操作以确保高可用性。

文章目录

1.1 哨兵模式概念

后台监控主机是否故障，如果故障了根据投票数自动将从库转换为主库

1.2 使用步骤

(1) 3个节点为一主二从模式：
在这里插入图片描述
(2) 自定义的/myredis目录下新建sentinel.conf文件,配置哨兵,填写内容

sentinel monitor mymaster 127.0.0.1 6379 1
sentinel auth-pass mymaster 123456

mymaster为监控对象起的服务器名称， 1 为至少有多少个哨兵同意迁移的数量

(3) 启动哨兵
执行

redis-sentinel  /myredis/sentinel.conf

在这里插入图片描述

(4) 当主机挂掉，从机选举中产生新的主机
(大概10秒左右可以看到哨兵窗口日志，切换了新的主机)
在这里插入图片描述
原主机重启后会变为从机
在这里插入图片描述
重启原主机
在这里插入图片描述

哪个从机会被选举为主机呢？
在这里插入图片描述

  根据优先级别
  优先级在redis.conf中默认：值越小优先级越高
在这里插入图片描述
偏移量是指获得原主机数据最全的
每个redis实例启动后都会随机生成一个40位的runid

Redis 哨兵模式的选举算法是什么？
yonggeit的博客
09-15 729
总之，Redis 哨兵模式通过多个 Sentinel 节点的协作，实现了对主节点的自动监控、故障检测和故障转移，提高了 Redis 集群的可用性和可靠性。Sentinel 节点更新配置。
聊聊Redis哨兵选举与故障转移的实现
禅与计算机程序设计的艺术
07-16 1214
上一篇文章我们将哨兵主观下线的核心流程都分析完成，这一篇我们将接着之前的思路，将哨兵获取客观下线结果并结合raft协议完成哨兵leader选举完成故障转移的流程分析完成，希望对你有帮助。因为近期收到很多读者的私信，所以也专门创建了一个交流群，感兴趣的读者可以通过上方的公众号获取笔者的联系方式完成好友添加，点击备注。因为近期收到很多读者的私信，所以也专门创建了一个交流群，感兴趣的读者可以通过上方的公众号获取笔者的联系方式完成好友添加，点击备注。下线的看法，如果累加到的哨兵对于下线的看法大于或者等于我们配置。
Redis哨兵的选举细节
z1547497656的博客
05-24 1539
Redis哨兵的选举细节1、sdown和odown转换2、哨兵集群的自动发现3、slave配置的自动纠正4、slave->master选举算法5、quorum和majority6、configuration epoch7、configuraiton传播 1、sdown和odown转换 sdown和odown两种失败状态 sdown是主观宕机，就一个哨兵如果自己觉得一个master宕机了，那么就是主观宕机 odown是客观宕机，如果quorum数量的哨兵都觉得一个master宕机了，那么就是客观宕机 s
一文读懂Redis的哨兵机制
qq_41066066的博客
08-01 610
大家好，我是memo，这几天正在看<<Redis设计与实现>>这本书籍，看到了哨兵机制这块知识点，相信大家在面试中或多或少都会遇到。为此，我做了小笔记，巩固知识。 什么是哨兵机制 哨兵机制（sentinel） 是Redis解决高可用的一种解决方案：它是由一个或者多个sentinel 实例组成的一个sentinel 系统。如图所示： 上图显示sentinel系统监控着master节点和slave节点，并且slave节点与master节点存在数据复制功能。那么问题来了： sent.
Redis哨兵模式原理剖析，监控、选主
m0_67614284的博客
05-04 2085
为什么需要客观下线机制？ 因为当前哨兵节点探测对方没有得到响应，很有可能这两个机器之间的网络发生了故障，而 Master 节点本身没有任何问题，此时就认为 Master 故障是不正确的。 为了解决上述问题，客观下线应运而生，Sentinel一般会集群部署，引入多个哨兵实例一起来判断，就可以避免单个哨兵因为自身网络状况不好，而误判主库下线的情况。 假设我们有N个哨兵实例，如果有N/2+1个实例判断主库“主观下线”，此时把节点标记为“客观下线”，此时就可以做主从切换了。 4.选举哨兵领导者？ =========
redis集群选举机制
热门推荐
祈雨v的博客
02-02 2万+
概要 当redis集群的主节点故障时，Sentinel集群将从剩余的从节点中选举一个新的主节点，有以下步骤： 故障节点主观下线 故障节点客观下线 Sentinel集群选举Leader Sentinel Leader决定新主节点 选举过程 1、主观下线 Sentinel集群的每一个Sentinel节点会定时对redis集群的所有节点发心跳包检测节点是否正常。如果一个节点在down-after-m...
Redis 哨兵模式
skystep的博客
07-06 1224
Redis 主从模式是一主多从，从节点宕机还有其他的备份，但是主节点宕机了，必然引起系统的故障。为了解决这个问题，Redis 提供了哨兵模式，监控主从模式中的所有节点，如果主节点宕机，会选举从节点重新成为主节点。使整个主从服务正常运行。 Redis 提供了哨兵机制来实现主从集群的自动故障恢复。其主要起到的作用如下：Sentinel 基于心跳机制监测服务状态，每个一秒向集群中的每个实例发送 ping 命令。一旦发现主节点故障， sentinel 需要在从节点选择新的主节点，选择依据：当选中其中一个从节点为新
【Redis 系列】redis 学习十一，redis 的哨兵模式详解和实战
m0_37322399的博客
04-10 874
上一次我们说到的主从复制是这样搭建的 主机可以读，可以写 从机只能读，不能写 想一想，那么我们是不是也可以这样呢？ 多个 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,
Redis 16 哨兵模式
天河有尽后为涯，星海无边前作岸。
06-08 428
主从切换技术的操作是：当主机宕机后，需要手动把一台从机切换为主机。这就需要人工干预，费事费力，还会造成一段时间内服务不可用。这不是一种推荐的方式，更多时候，我们优先考虑哨兵模式。Redis 从2.8开始正式提供了Sentinel(哨兵)架构来解决这个问题。它是“谋朝篡位”的自动版，能够后台监控主机是否故障，如果故障了根据投票数自动将从机转换为主机。哨兵模式是一种特殊的模式，首先 Redis 提供了哨兵的命令，哨兵是一个独立的进程，它会独立运行。
【redis】redis哨兵模式
wosixiaokeai的博客
06-30 1559
确保所有哨兵实例都知道其他哨兵实例的地址和端口，以便它们可以相互通信和协作。这通常通过在哨兵配置文件中添加。命令指定要监控的主节点的名称、IP地址、端口和quorum值（即认为主节点已不可用的哨兵数量）。指定哨兵在多长时间内没有收到主节点的响应后，将其标记为不可用。指定故障转移过程中，哨兵等待其他哨兵响应的最长时间。配置一个Redis主节点和至少一个从节点。对于每个哨兵实例，创建一个配置文件（通常是。在Redis的配置文件（通常是。对于每个哨兵节点，你需要一个。3、启动哨兵和Redis节点。
redis哨兵选举机制
zh_nanfang的博客
08-18 5429
1、在redis启动的时候，进行选举2、在leader节点宕机之后，进行选举。
Redis哨兵模式中的选举算法：Raft vs Paxos
TaloyerG的博客
12-12 4003
哨兵模式是在主从模式的基础上，引入了哨兵（sentinel）节点，用于监控主节点和从节点的运行状态，并在主节点发生故障时，自动将一个从节点升级为新的主节点，实现主节点的自动故障转移。哨兵模式可以提高Redis的可用性和容错性，是实现Redis高可用的一种常用方式。自动故障转移，无需人工干预，减少了服务中断和数据丢失的风险集群监控，可以实时感知主从节点的健康状况，及时发现和处理异常情况配置中心，可以提供主节点的动态发现和通知服务，方便客户端的连接和切换。
REDIS（六）-哨兵模式的实现
huange7的博客
08-05 732
快速了解REDIS哨兵模式实现原理,了解REDIS哨兵模式，看这篇就够了！
redis 哨兵(sentinel)模式实现
王加伦的技术分享
08-10 526
Redis 哨兵(sentinel)模式实现 之前搭建的主从复制(读写分离)在主节点宕机后，从节点依然提供数据读，但是不能进行数据写操作。 需要手动将某个从节点切换成主节点才行，哨兵模式就是解决这个手动操作的问题。 当一个集群中的master失效之后，sentinel可以选举出一个新的master继续工作，然后通过发布订阅模式通知其他从服务器，修改配置切换主节点。 核心配置 sentinel.conf # 保护模式 protected-mode no # 配置端口 port 26379 # 以守护进程模式启
Redis哨兵模式（Sentinel、1主2从3哨兵6台服务器配置实战、客户端调用、日志解析、主观下线、客观下线、仲裁、脑裂问题、哨兵长与从节点投票选举过程与原理）
weixin_42100387的博客
06-24 4187
Redis哨兵模式（Sentinel、1主2从3哨兵6台服务器配置实战、客户端调用、日志解析、主观下线、客观下线、仲裁、脑裂问题、哨兵长与从节点投票选举过程与原理）
Redis篇——一篇文章带你彻底拿下Sentinel哨兵模式(自动选举老大的模式)技术点，超详细、保姆级别教程奉上，不要错过~
我热爱学习，也乐于分享。无论是科技前沿的洞见，还是生活中的小技巧，我都会在这里与你分享。我相信，知识就是力量，而分享则能让这份力量得到更好的传递。
12-08 3442
一、概述和实现逻辑主从切换技术的方法是，当主服务器宕机后，需要手动把一台从服务器通过命令切换为主服务器，这就需要人工干预，还会造成一段时间内服务不可用。这不是一种值得推荐的方式，更多的时候，我们会优先考虑哨兵模式！！！哨兵模式，是一个分布式系统：通俗的讲，就是一种谋朝篡位的自动版，能够在后台监控主机是否故障，如果故障了，会根据投票自动将从服务器转换为主服务器。用于监控和管理Redis实例的高可用性。在Redis Sentinel中，哨兵实例之间通过PING和PONG消息进行通信。
【Redis7】 Redis7 哨兵（重点：哨兵运行流程和选举原理）
爱干饭的猿的博客
04-20 1663
本文重点介绍Redis7 哨兵，重点：哨兵运行流程和选举原理。
Redis的哨兵机制
m0_75227031的博客
04-13 1345
Redis服务器需要按照可读可写的方式打开这个AOF文件，而这个文件对于root之外的用户只有读权限，因此serveice redis-server start启动的Redis服务器无法打开这个文件就启动失败（通过service redis-server start 启动的Redis服务器（主要是怕通过root启动Redis，权限太高，一旦Redis被黑客攻破，后果就比较严重）是通过一个Redis这样的用户来启动的）此时，就需要程序员/运维手工的恢复主节点（redis哨兵：自动的对挂了的主节点进行替换）
因为哨兵机制变为从机的redis如何从新变为主机
最新发布
07-17
<think>我们正在讨论Redis哨兵模式下如何手动或自动地将从节点提升为主节点。根据引用[1]，哨兵的主要功能之一就是在主数据库出现故障时自动将从数据库升级为主数据库。但用户可能遇到需要手动提升的情况，例如维护或测试。 引用[3]展示了一个手动切换主节点的例子：在目标从节点上执行`slaveof no one`和`config set slave-read-only no`命令。然而，在哨兵模式下，直接操作节点可能绕过哨兵，导致哨兵无法正确感知集群状态。因此，正确的方法应通过哨兵自身机制实现。 解决方案如下： ### 一、自动故障转移（哨兵标准行为） 当主节点故障时，哨兵集群会自动执行以下流程： 1. **主观下线（SDOWN）**：单个哨兵检测到主节点不可达 2. **客观下线（ODOWN）**：多个哨兵（通常需超过配置的法定人数）确认主节点不可达 3. **选举领导者哨兵**：通过Raft算法选举出负责故障转移的哨兵 4. **选择新主节点**：根据规则（如优先级、复制偏移量等）选择最合适的从节点 5. **提升新主节点**： - 向目标从节点发送`SLAVEOF NO ONE` - 配置其他从节点复制新主节点 - 更新旧主节点配置（若恢复）为从节点 > 整个过程无需人工干预，但可通过哨兵API或命令监控状态。 ### 二、手动故障转移（强制提升） 当需要**主动切换**主节点时（如维护），应使用哨兵命令而非直接操作Redis节点： #### 步骤1：连接任意哨兵节点 ```bash redis-cli -h <哨兵IP> -p <哨兵端口> (通常26379) ``` #### 步骤2：执行故障转移命令 ```bash # 强制切换当前主节点（不模拟故障） SENTINEL failover <主节点名称> # 示例：将主节点mymaster切换 SENTINEL failover mymaster ``` #### 步骤3：验证新主节点 ```bash SENTINEL get-master-addr-by-name mymaster ``` ### 三、指定目标从节点提升 若需指定特定从节点为新主节点，需两步操作： #### 1. 提升目标节点优先级 在Redis配置文件中设置（需重启）： ```ini # 默认优先级100，值越小优先级越高 slave-priority 50 # 设置比当前主节点更低的值 ``` 或动态修改（临时生效）： ```bash # 连接目标从节点 redis-cli -h <目标从节点IP> CONFIG SET slave-priority 1 ``` #### 2. 触发故障转移 ```bash # 通过哨兵触发 SENTINEL failover mymaster ``` > 哨兵会选择优先级最高的从节点（数值最小）提升。 ### 四、绕过哨兵的手动提升（应急方案） > ⚠️ 仅当哨兵完全失效时使用，否则会破坏集群状态一致性 1. **在目标从节点执行**： ```bash SLAVEOF NO ONE # 停止复制，成为主节点 CONFIG SET slave-read-only no # 关闭只读模式 ``` 2. **其他从节点指向新主**： ```bash SLAVEOF <新主节点IP> <端口> ``` 3. **修改哨兵配置**： 更新所有哨兵实例的监控配置指向新主节点。 ### 五、验证主节点状态 使用引用[2]提供的脚本验证： ```bash ./redis-master-check.sh 192.168.137.51 7002 XXXXXXXX ``` 输出`is master Redis`即成功。 --- ### 关键注意事项 1. **数据一致性**：确保目标从节点数据最新（比较`INFO replication`中的`slave_repl_offset`） 2. **哨兵法定人数**：故障转移需多数哨兵达成共识，部署至少3个哨兵实例[^1] 3. **客户端重连**：切换后客户端应通过哨兵重新获取主节点地址 > 生产环境优先采用自动故障转移，手动操作仅用于特殊场景。 --- §§相关问题§§ 1. Redis哨兵如何判断主节点客观下线？ 2. 如何配置Redis哨兵的故障转移策略？ 3. Redis哨兵与集群模式的区别是什么？ 4. 如何监控Redis哨兵的状态？ 5. Redis主从复制延迟过高会导致什么问题？ [^1]: Redis哨兵通过分布式共识确保故障转移的可靠性，官方建议至少部署3个哨兵实例。 [^2]: 通过脚本验证节点角色是运维中的常用手段。 [^3]: 直接操作节点仅作为最后手段，会破坏哨兵集群状态。</think>### Redis哨兵模式下从节点重新提升为主节点指南 在Redis哨兵模式中，当主节点故障时，哨兵会自动选举新的主节点。但某些场景下需要手动将原主节点（因故障恢复后变为从节点）重新提升为主节点。以下是详细操作流程： --- #### 一、自动选举机制（哨兵默认行为） 哨兵集群通过以下流程自动选举新主节点： 1. **主观下线**：单个哨兵检测到主节点不可达 2. **客观下线**：多个哨兵（超过`quorum`数量）确认主节点故障 3. **领导者选举**：哨兵通过Raft算法选举领导者哨兵 4. **从节点选举**：根据规则选择新主节点： - 优先级（`slave-priority`配置值） - 复制偏移量（数据最新者优先） - Run ID字典序（作为最后仲裁） 5. **故障转移**：领导者哨兵执行： ```bash SLAVEOF NO ONE # 提升新主节点 SLAVEOF <new_master> # 重定向其他从节点 ``` > 引用[1]说明哨兵核心功能是自动监控和主从切换[^1] --- #### 二、手动提升操作（强制指定主节点） 当需要手动指定节点为主节点时： ##### 方法1：通过哨兵命令（推荐） ```bash # 1. 连接任意哨兵节点 redis-cli -h <sentinel_ip> -p 26379 # 2. 强制故障转移并指定目标节点 SENTINEL failover <master_name> # 常规故障转移 SENTINEL FORCE-FAILOVER <master_name> # 强制转移（忽略状态检查） # 3. 验证主节点 SENTINEL get-master-addr-by-name <master_name> ``` ##### 方法2：直接操作Redis节点（应急方案） ```bash # 在目标节点执行（192.168.1.12） 127.0.0.1:6379> SLAVEOF NO ONE # 解除从属关系 127.0.0.1:6379> CONFIG SET slave-read-only no # 关闭只读模式 # 在其他从节点指向新主 127.0.0.1:6380> SLAVEOF 192.168.1.12 6379 ``` > 引用[3]展示了直接操作节点的方法[^3]，但需同步更新哨兵配置 --- #### 三、验证主节点状态 使用检测脚本验证角色： ```bash #!/bin/bash # redis-master-check.sh if [ -z "$(redis-cli -h $1 -p $2 INFO replication | grep 'role:master')" ]; then echo -e "\033[31m$1:$2 is not master\033[0m" else echo -e "\033[32m$1:$2 is master\033[0m" fi ``` 执行示例： ```bash $ ./redis-master-check.sh 192.168.1.12 6379 # 输出：192.168.1.12:6379 is master Redis ``` > 引用[2]提供了主节点检测脚本[^2] --- #### 四、关键注意事项 1. **数据一致性**：确保目标节点数据最新（比较`INFO replication`中的`slave_repl_offset`） 2. **哨兵配置更新**：手动操作后需在所有哨兵节点执行： ```bash SENTINEL RESET <master_name> ``` 3. **优先级设置**：通过配置文件永久提升选举权重： ```ini # redis.conf slave-priority 10 # 值越小优先级越高（默认100） ``` 4. **客户端重连**：应用需重新获取主节点地址（通过`SENTINEL masters`查询） --- ### 故障转移流程示意图 ```mermaid graph TD A[主节点故障] --> B[哨兵检测SDOWN] B --> C{多个哨兵确认ODOWN?} C -->|是| D[选举领导者哨兵] D --> E[选择最佳从节点] E --> F[执行SLAVEOF NO ONE] F --> G[通知其他节点复制新主] G --> H[客户端重定向] ``` > 生产环境建议优先依赖哨兵自动机制，手动操作仅用于特殊维护场景[^1]。 ---
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

但行益事莫问前程

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

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

余额充值