从库必须显式配置save才能支持断点续传，否则重启后只能全量同步；需确保dbfilename和dir可写、RDB相关配置主从一致，并通过redis-check-rdb校验文件有效性。
从库必须开启 save 配置才能支持断点续传
Redis 主从同步本身不依赖 RDB 文件，但「断点续传」（即从库重启后能接着上次复制位置继续同步）需要从库本地有完整的 RDB 快照作为复制起点。如果从库没配置 save，它不会生成 RDB 文件，重启后只能全量重同步，无法复用已有的复制偏移量。
常见错误现象：SYNC with master failed: -ERR Can't SYNC while not connected with my master 或从库日志反复出现 Full resync started，说明每次重启都在做全量同步。
-
save 900 1、save 300 10这类配置必须显式写在从库的redis.conf中，不能只靠主库配置或默认值 - 从库的
dbfilename和dir要确保路径可写，否则 RDB 写入失败，等同于没开启 - 若使用
replica-serve-stale-data no，从库在断连期间拒绝读请求，此时更需 RDB 支持快速恢复同步状态，否则服务空窗期拉长
repl-diskless-sync 关闭时，RDB 是唯一可用的传输载体
当 repl-diskless-sync no（默认值），主库会先将数据写入磁盘 RDB 文件，再把文件发给从库。此时从库收到的是完整 RDB，必须能落地并加载——这就要求从库自身也具备 RDB 解析与持久化能力，否则加载失败会导致同步中断。
典型问题：主库开启了 rdbcompression yes，但从库 Redis 版本低于 3.0（不支持 LZ4 解压），或从库 rdbchecksum yes 但传输过程被中间设备篡改校验和，都会导致 Failed to load RDB: Invalid argument。
- 主从 RDB 相关配置应尽量一致：
rdbcompression、rdbchecksum、dbfilename - 不要在从库禁用
rdb-save-incremental-fsync，它影响 RDB 落盘稳定性，尤其在高负载下易触发写失败 - 若网络带宽受限，宁可开
repl-diskless-sync yes，但也意味着从库必须有足够内存缓存整个 RDB 流，且无法断点续传
从库 RDB 不是“越多越好”，要匹配同步节奏
频繁生成 RDB 会加重从库 I/O 压力，尤其在大实例（>10GB）场景下，一次 SAVE 可能阻塞同步线程数秒，造成 master_repl_offset 滞后，进而触发超时重连。
观察点：通过 INFO replication 查看 master_sync_in_progress 是否长期为 1，或 latest_fork_usec 突增，往往对应 RDB fork 开销过大。
- 建议从库
save策略比主库宽松：例如主库save 60 10000，从库可设为save 300 1，只保底防崩溃，不追求实时性 - 禁用
save ""（即彻底关闭 RDB）不可取，哪怕只保留save 3600 1，也能覆盖大多数意外重启场景 - 若使用 AOF + RDB 混合持久化（
aof-use-rdb-preamble yes），从库仍需能解析 RDB 段，因此 RDB 能力不可绕过
哨兵/集群环境下，RDB 状态直接影响故障转移成功率
哨兵选主时，会优先选择 master_link_down_time 小、且 slave_repl_offset 接近主库的节点。但如果从库因未保存 RDB 导致重启后全量重同步，它的 slave_repl_offset 会长时间停滞在 0，被哨兵判定为“数据陈旧”，即使硬件资源更好也会被跳过。
更隐蔽的问题：某些运维脚本在部署从库时自动清空 dir 下所有文件，包括残留的 dump.rdb，这会让新启动的从库失去断点续传依据，哪怕配置了 save 也无济于事。
- 上线前检查
redis-cli -p <port> INFO persistence | grep rdb_last_bgsave_status</port>，确认值为ok - 监控项中必须包含
rdb_changes_since_last_save，数值长期为 0 可能意味着save实际未生效 - 不要依赖
CONFIG SET save "300 1"动态修改——该命令不生效，save只能通过配置文件加载
真正容易被忽略的不是“要不要开 RDB”，而是“RDB 文件是否真的被写出来、写对了、能被正确加载”。一次 redis-check-rdb dump.rdb 手动校验，比十次配置复查更管用。
