主服务器必须启用RDB或AOF持久化，禁用会导致重启后全量数据丢失；从服务器可关闭RDB但AOF需谨慎；主从AOF重写须错开；哨兵模式下所有候选主节点均须开启持久化。

主服务器必须开启RDB或AOF，不能关闭

主服务器关闭持久化是危险操作，尤其在自动拉起场景下会导致全量数据丢失。比如主节点崩溃重启后无数据，从节点同步时会清空自身数据——这不是理论风险，而是已验证的故障链。

• 必须启用至少一种持久化：RDB（save 规则非注释）或 AOF（appendonly yes）
• 禁用所有 save 行 + appendonly no = 等同于关闭持久化，严禁在线上主节点出现
• 若只用 AOF，需确认 appendfsync 不为 no；若只用 RDB，至少保留一条如 save 60 1000
• 主节点配置中不要设 save "" 或 dbfilename /dev/null 这类伪禁用手段

从服务器可以关闭RDB，但AOF要谨慎关

从节点不承担写请求，RDB快照对它不是必须的；但AOF关掉后，一旦从节点重启且没RDB文件，就只能靠主节点同步恢复——而主节点可能还没完成全量同步，导致短暂不可读。

Redis Skill - 高性能缓存管理

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

• 可关闭 RDB：save "" 或注释全部 save 行
• AOF 建议保持开启，尤其当从节点也承担只读流量时；若关闭，必须确保 slaveof 配置生效且网络稳定
• 从节点的 appendfsync 可设为 no（依赖 OS 刷盘），因写入仅来自主节点复制流，非客户端直连
• 注意：从节点开启 AOF 后，重启时仍会先加载 AOF 文件，而非等待主节点同步

主从都开AOF时，重写时机要错开

AOF重写（BGREWRITEAOF）会触发子进程和磁盘IO高峰，主从同时执行可能压垮磁盘带宽或CPU，拖慢复制延迟。

• 主节点重写由 auto-aof-rewrite-percentage 和 auto-aof-rewrite-min-size 控制，建议设宽松些（如 100 和 64mb）
• 从节点应禁用自动重写：auto-aof-rewrite-percentage 0，改由运维定期手动触发（避开业务高峰）
• 不要在主节点刚完成重写后立刻在从节点手动重写，间隔至少 5 分钟
• 监控 redis_aof_last_rewrite_time_sec 指标，避免连续重写

哨兵模式下，持久化配置要和故障转移逻辑对齐

哨兵选主时只看 info replication 中的 connected_slaves 和 master_link_status，不校验持久化状态——但切换后新主若没持久化，等于把风险转嫁过去。

• 所有候选主节点（即可能被哨兵提拔的节点）必须启用持久化，且配置一致
• 哨兵配置里 sentinel down-after-milliseconds 要大于主节点 RDB bgsave 的典型耗时，否则可能误判主节点宕机
• 若用 AOF，确保 appendonly yes 在所有节点配置中显式写出，不能靠继承默认值
• 切记：哨兵不会阻止你把一个没开持久化的节点设为 master，但它会放大这个错误的后果

主从复制本身不解决单点故障，持久化才是数据不丢的底线。很多人调通了 slaveof 就以为高可靠了，结果发现重启后全空——问题往往不在复制协议，而在持久化开关被悄悄关掉了。