全量复制触发时，Redis主节点必须生成RDB文件，因为从节点初次连接或断连太久后无法仅靠增量命令追上主节点，主节点需将当前完整数据集打包成RDB文件传给从节点以保证状态一致。
全量复制触发时，Redis主节点为什么必须生成RDB文件
因为从节点初次连接或断连太久后无法仅靠增量命令追上主节点，主节点只能把当前完整数据集打包成 RDB 文件传过去——这是唯一能保证从节点状态与主节点某一时刻完全一致的方式。不走 RDB，就无法建立可靠的一致性起点。
这个 RDB 不是读取磁盘上已有的文件，而是主节点在内存中实时 fork 出子进程，由子进程将当前内存快照写入临时 dump.rdb（路径由 dir 和 dbfilename 配置决定），再通过网络发送给从节点。
- 如果主节点正在执行
SAVE或另一个BGSAVE，新的全量同步会排队等待，直到前一个完成 - 若配置了
repl-diskless-sync yes，主节点可跳过磁盘，直接通过 socket 把 RDB 流发给从节点，避免磁盘 I/O 瓶颈，但要求从节点支持（repl-diskless-sync-delay控制等待时间） - fork 失败（比如内存碎片严重、可用虚拟内存不足）会导致全量同步失败，错误日志里会出现
Can't save in background: fork: Cannot allocate memory
如何判断当前是否正在发生全量复制
看主节点的 INFO replication 输出里的 master_repl_offset 和从节点的 slave_repl_offset 是否长期不更新；更直接的是查 INFO persistence 中的 rdb_bgsave_in_progress 是否为 1，同时 INFO replication 里出现 loading:1 表示从节点正在加载 RDB。
- 主节点执行
redis-cli -p 6379 INFO replication | grep sync，若看到master_sync_in_progress:1，说明正处在全量同步中 - 从节点日志中出现
SYNC with master succeeded后紧跟着MASTER REPLICA sync: receiving streamed RDB from master，就是全量同步正在进行 - 注意：
master_sync_in_progress:1只表示“同步请求已接受”，不等于 RDB 已开始生成；真正 fork 子进程的时机在确认从节点身份和能力之后
fork 子进程生成 RDB 的实际开销在哪
不是 RDB 文件大小本身，而是 fork 调用那一刻的内存页表拷贝（Copy-on-Write）。即使你只存了 100MB 数据，如果 Redis 占用 4GB 内存且碎片率高，fork 仍可能卡顿数秒甚至失败。
- Linux kernel 会为每个内存页维护引用计数，fork 时只复制页表项，不立即复制物理内存，但大量写操作会触发 COW 分配新页，加剧内存压力
-
vm.overcommit_memory = 1是推荐设置，否则 fork 在某些内核版本下会因内存检查失败而拒绝执行 - 使用
top观察redis-server进程的VIRT（虚拟内存）和RES（常驻内存）差值大，往往意味着写时复制开销高，容易拖慢 fork
从节点加载 RDB 期间能否提供服务
默认不能。从节点在加载 RDB 时处于 loading:1 状态，所有客户端请求都会收到 LOADING Redis is loading the dataset in memory 错误。只有加载完成后才切换为 connected 并开始接收主节点的增量命令。
- 可通过配置
replica-serve-stale-data yes让从节点在加载 RDB 时继续响应旧数据（即加载前最后一次的状态），但这不是强一致性保障 - 如果从节点启用了 AOF，加载完 RDB 后还会重放 AOF 缓冲区中的命令，这段时间也处于不可服务状态
- 大 RDB + 慢磁盘（如机械盘）会让 loading 时间显著延长，建议监控
loading:1持续时间，超过阈值需告警
真正麻烦的不是 RDB 生成或传输本身，而是 fork 的不可控性和加载期的服务中断——这两点在容量规划和故障演练里最容易被绕开。
