Redis主从同步之主库挂死解决方案

最新推荐文章于 2025-02-17 10:43:33 发布

转载最新推荐文章于 2025-02-17 10:43:33 发布 · 848 阅读

1 ·

CC 4.0 BY-SA版权

原文链接：http://www.cnblogs.com/st-st/p/10274146.html

文章标签：

#数据库

本文详细介绍了当Redis主库出现故障时，如何通过取消从库身份并重新设置为新的主库，实现快速的主从切换过程，确保服务的连续性和数据的一致性。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

Redis实现了主从同步，但是主库挂死了，如何处理

方案:切换主库的身份

# 连接从库
[root@localhost redis-4.0.12]# redis-cli -p 6380

# 取消从库身份
127.0.0.1:6380> slaveof no one

# 连接从库
[root@localhost redis-4.0.12]# redis-cli -p 6381

# 重新设置从库
127.0.0.1:6381> slaveof 127.0.0.1 6380

切换完成！

转载于:https://www.cnblogs.com/st-st/p/10274146.html

确定要放弃本次机会？

福利倒计时

: :

立减 ¥

普通VIP年卡可用

立即使用

weixin_30295091

关注关注

0
点赞
踩
1

收藏

觉得还不错? 一键收藏
0
评论
分享

复制链接

分享到 QQ

分享到新浪微博

扫一扫
举报

举报

redis主从同步延迟解决方案

计算机毕业论文源码，学生个人网页制作html源码。贴近用户做网络推广和互联网优化。

11-17

2020

如果在使用Redis时，发现访问延迟突然增大，如何进行排查？redis主从同步延迟解决方案 首先，第一步，建议你去查看一下Redis的慢日志。Redis提供了慢日志命令的统计功能，我们通过以下设置，就可以查看有哪些命令在执行时延迟比较大。首先设置Redis的慢日志阈值，只有超过阈值的命令才会被记录，这里的单位是微妙，例如设置慢日志的阈值为5毫秒，同时设置只保留最近1000条慢日志记录： # 命令执行超过5毫秒记录慢日志 CONFIG SET slowlog-log-slower-than 5000

数据同步：redis主从库如何实现数据一致？

m0_66925868的博客

01-16

1574

你可以设想一下，如果在上图中，不管是主库还是从库，都能接收客户端的写操作，那么，一个直接的问题就是：如果客户端对同一个数据（例如 k1）前后修改了三次，每一次的修改请求都发送到不同的实例上，在不同的实例上执行，那么，这个数据在这三个实例上的副本就不一致了（分别是 v1、v2 和 v3）。那么，一旦主从库完成了全量复制，它们之间就会一直维护一个网络连接，主库会通过这个连接将后续陆续收到的命令操作再同步给从库，这个过程也称为基于长连接的命令传播，可以避免频繁建立连接的开销。否则，新写的命令就会覆盖掉旧操作了。

参与评论您还未登录，请先登录后发表或查看评论

字节一面：Redis主节点宕机，如何处理？

公众号：微观技术

12-01

9578

大家好，我是Tom哥~今天跟大家聊下，如果Redis某个节点宕机了，要怎么处理？我们知道，Redis集群一般采用主从模式，主节点负责写，从节点负责读。从节点故障从节点主要提供读服务，为了分摊主服务器压力，一般会有多个从节点。如果是从节点故障，不算什么大问题，客户端把该故障节点屏蔽即可，仍可访问其他的主、从节点满足正常的业务功能。主节点故障如果是主节点宕机了，那就有点麻烦了，毕竟写操作是在主节点上，无法替代。这时候，我们要干一件事，从所有的从库节点中挑选一台做为主节点。这里要介绍下Sentienl 哨兵机制了

redis主库宕机后重启，主库和从库的数据丢失

qq_30908729的博客

10-11

1312

redis主库宕机后重启，主库和从库的数据丢失解决方法：假如主库127.0.0.1 6379，从库127.0.0.1 6380 1.在从数据库中执行SLAVEOF NO ONE命令，断开主从关系并且提升为主库继续服务； 2.http://www.yayihouse.com/yayishuwu/chapter/1629...

redis主从复制

博客的博客

10-14

686

⚪从服务器主动进行的操作当从服务器连接上主服务器之后，从服务器向主服务器发送进行数据同步的消息主服务器接到从服务器发送过来的同步消息，把主服务器数据进行持久化rdb文件，把rdb文件发送到从服务器，从服务器拿到rdb进行读取 ⚪主服务器主动进行的操作 3.每次主服务器进行写操作之后，和从服务器进行数据同步

Redis集群master节点挂掉之后的处理方式

weixin_47556601的博客

03-23

6656

大家好，今天分享Redis集群master节点挂掉之后的处理方式我们前面做的主从复制是这样的一个结构要改成这样将6303的主节点接到6302 127.0.0.1:6303> SLAVEOF 127.0.0.1 6302 OK 127.0.0.1:6303> 在6303上看，它的主节点变成了6302 127.0.0.1:6303> INFO replication # Replication role:slave master_host:127.0.0.1 master_p

Redis哨兵机制：主库挂了，如何不间断服务？

香农三定律的博客

12-01

1640

Redis哨兵机制：主库挂了，如何不间断服务？引言哨兵机制的基本流程主从级联模式分担全量复制时的主库压力主从库间网络断了怎么办引言如果主库发生故障了，那就直接会影响到从库的同步，因为从库没有相应的主库可以进行数据复制操作了。如果客户端发送的都是读操作请求，那还可以由从库继续提供服务，这在纯读的业务场景下还能被接受。但是，一旦有写操作请求了，按照主从库模式下的读写分离要求，需要由主库来完成写操作。此时，也没有实例可以来服务客户端的写操作请求了。如果主库挂了，我们就需要运行一个新主库，比如说把一个从库

Redis主从同步异常问题记录

baidu_mtc的博客

01-27

4355

2015.7.31 10.36.14.*网段的TOR故障一小时，网络故障恢复后，redis nj多个从主从同步异常：

Redis主从复制技术：理论基础、运行逻辑与应用场景

禅与计算机程序设计的艺术

10-29

1230

主从复制就是将主节点(master)的数据复制到从节点(slave)，让多个节点承载用户的请求。1. 数据冗余:主节点的数据都会同步到从节点上，所以多个节点都会有相同数据，从而实现数据冗余。2. 故障恢复:主节点出现故障后，从节点可以继续承载用户的请求，做到服务上的冗余。3. 负载均衡:主从复制机制实现主节点接收用户写请求，从节点承载用户读请求，对于读多写少的场景，这种机制可以大大提高redis的并发量。4. 高负载:主从复制+哨兵机制可以实现高负载，这点后文会介绍到。

Redis数据同步：主从库是如何实现数据一致的

Pert的博客

11-16

2699

我们学习了 AOF 和 RDB，如果 Redis 发生了宕机，它们可以分别通过回放日志和重新读入 RDB 文件的方式恢复数据，从而保证尽量少丢失数据，提升可靠性。不过，即使用了这两种方法，也依然存在服务不可用的问题。比如说，我们在实际使用时只运行了一个 Redis 实例，那么，如果这个实例宕机了，它在恢复期间，是无法服务新来的数据存取请求的。那我们总说的 Redis 具有高可靠性，又是什么意思呢？，将一份数据同时保存在多个实例上。

Redis主库挂了后如何不间断服务---哨兵机制

ggh0314的博客

03-26

484

Redis 主从集群中，哨兵机制是实现主从库自动切换的关键机制，它有效地解决了主从复制模式下主库故障的问题。哨兵其实就是一个运行在特殊模式下的 Redis 进程，主从库实例运行的同时，它也在运行。哨兵主要负责的就是三个任务：监控、选主（选择主库）和通知。监控是指哨兵进程在运行时，周期性地给所有的主从库发送 PING 命令，检测它们是否仍然在线运行，如果主库没有在规定时间内响应哨兵的 PING 命令，哨兵就会判定主库下线，然后开始自动切换主库的流程。哨兵机制通常会采用多实例组成的集群模式进行部署，

Redis笔记 --主从复制

qq_41644234的博客

03-17

1097

Redis笔记 --主从复制Redis主从复制1.主从同步1.1.概念1.2 原理1.2.1 全量同步1.2.2 增量同步1.2.3 Redis主从同步策略1.3特点1.4演示1.4.1准备工作1.4.2 启动服务1.4.3测试1.5 缺点2.哨兵模式2.1 特点2.2 工作机制3.Cluster模式3.1Cluster模式介绍3.2实现原理3.3 特点4.应用场景 Redis主从复制通过持久化功能，Redis保证了即使在服务器重启的情况下也不会丢失（或少量丢失）数据，但是由于数据是存储在一台服务器上的

Redis集群主从复制原理

brushli的专栏

04-18

1145

如果从服务器之前已复制过某个主服务器，那么从服务器在开始一次新的复制时将向主服务器发送PSYNC 命令。当从服务器断线并重新连上一个主服务器时，从服务器将向当前连接的主服务器发送之前保存的运行ID： ·如果从服务器保存的ID和当前连接的主服务器的运行ID相同，那么说明从服务器断线之前复制的就是当前连接的这个主服务器，主服务器可以尝试执行部分重同步操作；·如果从服务器保存的ID和当前连接的主服务器的运行ID不同，则从服务器断线之前复制的不是当前连接的这个主服务器，主服务器就将对从服务器执行完整重同步操作。

Redis主节点宕机，如何处理？

wzlsunice88的博客

12-09

4399

Redis主节点宕机，如何处理？原创 Tom哥微观技术 2021-12-01 12:01 大家好，我是Tom哥~ 今天跟大家聊下，如果Redis某个节点宕机了，要怎么处理？我们知道，Redis集群一般采用主从模式，主节点负责写，从节点负责读。从节点故障从节点主要提供读服务，为了分摊主服务器压力，一般会有多个从节点。如果是从节点故障，不算什么大问题，客户端把该故障节点屏蔽即可，仍可访问其他的主、从节点满足正常的业务功能。主节点故障如果是主节点宕机了，那就有点麻烦了..

Redis节点挂了其内部会执行什么操作

longgelaile的博客

02-17

573

主节点挂掉时，系统会自动触发故障转移，从节点会被提升为新的主节点，保证系统继续提供服务。此时，Redis 会尽量保持数据的一致性和可用性。从节点挂掉时，不会影响数据的写入操作，但会影响读请求的负载分担。Redis 会继续正常运行，只是在没有足够的从节点时可能会增加主节点的压力。数据一致性：在 Redis 中，主从复制是最终一致性的模型。为了保证数据的持久性和一致性，Redis 提供了 RDB 和 AOF 等持久化机制。

Redis-master节点宕机后的处理方式

m0_54714490的博客

11-05

2120

在redis集群中，每个节点各司其职，有的当老大，有的当小弟，老大负责写，小弟负责读。但是如果老大挂了，这些小弟就群龙无首了，我们的服务就会崩盘，谁都不愿意这种事情发生，所以我们需要了解当master节点挂了之后redis的处置方式。如果第三项都一样，那么其实选哪个slave都一样，因为他们的数据都是最新的，都可以成为主节点，那么这时候就根据他们的id判断，id越小优先级越高。我们应该从slave节点中选举出一个新的master节点，并且让原来的slave节点的老大都变成这个新的老大。这里我们有一套标准。

Redis中主、从库宕机如何恢复

JineD的博客

09-22

581

1、什么是哨兵哨兵是对Redis的系统的运行情况的监控，它是一个独立进程，功能有二个：监控主数据库和从数据库是否运行正常；主数据出现故障后自动将从数据库转化为主数据库； 2、原理单个哨兵的架构：多个哨兵的架构：多个哨兵，不仅同时监控主从数据库，而且哨兵之间互为监控。多个哨兵，防止哨兵单点故障。 3、环境当前处于一主多从的环境中： 4、设置哨兵启动哨兵进程首先需要创建哨兵配置文件： vimsentinel.conf 输入内容： .

Redis主从结构，主库宕机挂了，怎么办

weixin_30856725的博客

02-21

1087

前提：现在有主从结构，主库没有配置持久化，从库配置AOF。场景1：哪一天主库突然宕了，怎么办？非常危险的动作：重新启动主库。要知道这样一来，最坏情况数据将全部丢失。因为主库没有配置持久化，所以主库的data目录只有从库连接主库请求resync的时候做快照留下来的dump.rdb文件。如果重启主库，主库会按照data目录下的dump.rdb来恢复数据。因此，如果从库是从最开始就配置好了的...

Redis学习（九）redis主从架构宕机问题解决

最新发布

06-11

<think>嗯，用户这次的问题很明确，就是要知道Redis主从同步延迟的具体获取方法。之前已经解释过redis_connected_slave_lag_seconds这个指标的本质，现在需要提供更具体的操作指导。用户引用的几篇文档很有参考价值。引用[1]展示了通过inforeplication命令查看复制状态的实际输出，其中master_link_status和slave_repl_offset都是关键字段。引用[4]详细描述了主从同步的全过程，这对理解延迟产生的原理很有帮助。而引用[3]提到kill主库的操作，其实是在演示哨兵模式下的故障转移场景。用户似乎是个运维工程师，正在搭建Redis高可用方案。ta特别关注redis_connected_slave_lag_seconds这个监控指标，说明ta需要将延迟量化并纳入监控系统。考虑到生产环境需求，除了基础命令查询外，更要重点说明如何集成到Prometheus这样的专业监控体系中。从技术实现看，获取延迟本质就是解析inforeplication输出。但需要强调两点：第一，lag字段的单位是秒但实际精度可能不足1秒；第二，如果主库突然宕机，从库的lag值会停留在故障时的数值不再更新。在组织回复时，应该把命令行操作放在前面满足即时需求，然后是Prometheus集成方案满足长期监控需求。监控配置部分要特别说明指标命名差异问题——不同exporter可能使用redis_replication_slave_lag_seconds或redis_connected_slave_lag_seconds这样的名称。对了，引用[2]提到的主库压力问题也要提醒用户。当延迟升高时，盲目调整同步参数可能适得其反，应该优先排查网络和负载问题。这点可以放在实践建议部分。最后的相关问题设计要延续用户对Redis高可用的关注方向。哨兵集群部署是自然延伸，内存和连接数监控则是配套措施，而同步优化参数则直接解决延迟问题。</think> 以下是 Redis 主从同步延迟的具体获取方法及操作指南，结合关键命令、监控工具和实践建议： --- ### 一、核心命令：实时获取延迟（秒级） **通过 `INFO replication` 命令获取：** ```bash redis-cli info replication | grep -E "lag|seconds_ago" ``` **输出示例（关键字段解析）：** ```bash master_link_status:up # 主从连接状态（up/down） master_last_io_seconds_ago:0 # 主从最后一次通信的秒数（0 表示实时） slave_repl_offset:552188 # 从库当前复制偏移量（需与主库对比） master_repl_offset:552188 # 主库当前复制偏移量（需与从库对比） lag:0 # 延迟秒数（核心指标） ``` **计算实际延迟**： - **方法1**：直接读取 `lag` 值（若显示 `lag=N`，则延迟为 N 秒）[^1][^4]。 - **方法2**：若 `lag` 未显式输出，计算主从偏移量差值： ```bash # 获取主库偏移量（在主库执行） master_offset=$(redis-cli -h MASTER_IP info replication | grep "master_repl_offset" | cut -d':' -f2) # 获取从库偏移量（在从库执行） slave_offset=$(redis-cli info replication | grep "slave_repl_offset" | cut -d':' -f2) # 计算延迟（需结合主库每秒写入量） delay_seconds=$(( (master_offset - slave_offset) / master_ops_per_second )) ``` --- ### 二、监控工具集成方案 #### 方案1：Prometheus + Redis Exporter **配置步骤**： 1. **安装 Exporter**： ```bash docker run -d --name redis_exporter -p 9121:9121 oliver006/redis_exporter ``` 2. **配置 Prometheus 抓取**（`prometheus.yml`）： ```yaml scrape_configs: - job_name: 'redis_slave_lag' static_configs: - targets: ['REDIS_SLAVE_IP:9121'] # 从库的 Exporter 地址 metrics_path: '/scrape' params: target: ['redis://REDIS_SLAVE_IP:6379'] # 从库的 Redis 地址 ``` 3. **在 Grafana 中查看指标**： - 核心指标名：`redis_replication_slave_lag_seconds`（直接对应 `lag` 值）[^4] - 设置阈值告警（如 `>5` 秒触发警告） #### 方案2：Zabbix 监控 **通过内置模板获取**： 1. 使用官方模板 `Template DB Redis`。 2. 监控项：`redis.replication.lag`（单位：秒）。 --- ### 三、关键实践建议 1. **延迟优化配置**（`redis.conf`）： ```bash repl-backlog-size 1gb # 增大复制缓冲区（默认 1MB） repl-timeout 120 # 超时时间调至 120 秒（避免网络波动误判） repl-disable-tcp-nodelay no # 启用 TCP 实时传输（减少延迟）[^4] ``` 2. **高延迟排查方向**： - **网络带宽**：检查主从节点间 `ping` 延迟与丢包率。 - **从库负载**：监控从库 CPU/内存，避免 `bgsave` 阻塞复制线程[^4]。 - **主库写入暴增**：限制客户端写入速率（如 `redis-cli --eval rate_limiter.lua`）。 --- ### 四、延迟指标解读 | 指标名称 | 安全范围 | 风险场景 | |------------------------------|-----------|----------------------| | `lag`（秒） | < 1 秒 | > 5 秒（需告警）[^1] | | `master_last_io_seconds_ago` | < 2 秒 | > 10 秒（连接异常） | | 主从偏移量差值 (offset_diff) | < 1000 | 持续增长（数据不同步）[^4] | > 📌 **注**：当 `lag=0` 且 `master_link_status=up` 时，主从处于实时同步状态（理想情况）[^1]。 --- ### 总结 - **命令优先**：`INFO replication` 是基础验证手段（`lag` 字段即延迟秒数）[^1][^4]。 - **生产必备**：通过 Prometheus 的 `redis_replication_slave_lag_seconds` 实现自动化监控[^4]。 - **调优核心**：增大 `repl-backlog-size` 可抵御瞬时写入高峰，结合网络优化降低延迟。 ---