Redis

关注公众号 jb51net

关闭
首页 > 数据库 > Redis > redis slaveof命令执行清库重新同步

解读redis slaveof命令执行后为什么需要清库重新同步

作者:学会了没

这篇文章主要介绍了redis slaveof命令执行后为什么需要清库重新同步,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐教

在 Redis 中,执行 SLAVEOF(或 REPLICAOF)命令后,从节点需要清空现有数据并重新同步的主要原因如下:

1. 保证数据一致性

核心目标:确保从节点的数据与主节点 完全一致

问题场景

2. 全量同步的触发条件

当从节点执行 SLAVEOF 连接到主节点时,Redis 会触发以下两种同步机制:

(1) 全量同步(Full Sync)

触发条件

操作流程

  1. 主节点生成当前数据的 RDB 快照,发送给从节点。
  2. 从节点清空自身数据,加载 RDB 文件。
  3. 主节点将生成 RDB 期间的新写入命令缓存,待 RDB 传输完成后发送给从节点(增量同步)。

(2) 部分同步(Partial Sync)

触发条件

操作流程

  1. 主节点直接发送从节点缺失的增量命令(无需清空数据)。
  2. 从节点应用这些命令,追上主节点状态。

3. 清空数据的必要性

从节点需要以主节点的 RDB 快照为基准重建数据集,若保留原有数据,会导致数据不一致。

# 示例:从节点加载 RDB 前自动执行 FLUSHALL
[从节点日志]
MASTER <-> REPLICA sync: Flushing old data

增量命令是基于从节点已有的数据状态追加的,因此保留数据是安全的。

4. 数据一致性的风险

场景风险
不清空数据 + 全量同步主节点 RDB 数据与从节点旧数据混合,导致键覆盖、过期时间错乱等问题。
不清空数据 + 部分同步仅当复制 ID 和偏移量匹配时安全,否则数据可能不完整或逻辑冲突。

如何避免全量同步(减少清库开销)

(1) 合理配置 repl-backlog-size

# 主节点配置(redis.conf)
repl-backlog-size 64mb  # 根据业务写入量调整

(2) 避免频繁主从切换

(3) 持久化复制 ID 和偏移量

# 从节点配置(redis.conf)
repl-diskless-sync no  # 启用磁盘备份(默认)

示例:同步流程的日志分析

(1) 全量同步日志

# 主节点日志
[19042] 01 Jan 12:00:00.123 * Replica 127.0.0.1:6380 asks for synchronization
[19042] 01 Jan 12:00:00.123 * Full resync requested by replica 127.0.0.1:6380
[19042] 01 Jan 12:00:00.123 * Starting BGSAVE for SYNC with target: disk

# 从节点日志
[19043] 01 Jan 12:00:00.125 * MASTER <-> REPLICA sync started
[19043] 01 Jan 12:00:00.125 * MASTER <-> REPLICA sync: Flushing old data
[19043] 01 Jan 12:00:00.125 * MASTER <-> REPLICA sync: Loading DB in memory

(2) 部分同步日志

# 主节点日志
[19042] 01 Jan 12:00:00.123 * Replica 127.0.0.1:6380 requests partial resynchronization
[19042] 01 Jan 12:00:00.123 * Partial resynchronization request accepted

# 从节点日志
[19043] 01 Jan 12:00:00.125 * MASTER <-> REPLICA sync: Master accepted a Partial Resynchronization

总结

以上为个人经验,希望能给大家一个参考,也希望大家多多支持脚本之家。

您可能感兴趣的文章:
阅读全文