redis从库数据清空并非自动发生，而是因主库关闭持久化后宕机，从库重启时无本地rdb/aof文件可加载，且未配置自身持久化，导致以空数据集启动；若曾同步过flushall或生成空快照，亦会固化为空状态。

Redis 主库关闭持久化后挂掉，从库数据清空不是“自动发生”的结果，而是由主从同步机制 + 重启恢复逻辑共同导致的——关键在于：从库在主库宕机后重启时，找不到可加载的持久化文件，又没开启自己的持久化，最终加载了一个空数据集。

主库关闭持久化后挂掉，从库为什么加载不到数据

Redis 从库本身不主动持久化（除非显式配置），它依赖两种方式获得初始数据：

• 全量同步时，主库 bgsave 生成 dump.rdb 发送给从库（若主库没开启 RDB 或 AOF，bgsave 仍会执行，但生成的是当前内存快照）
• 从库自身重启时，会尝试加载本地的 dump.rdb 或 appendonly.aof 文件恢复

但如果主库关闭了所有持久化（save 全注释 + appendonly no），且运行中又挂掉（如 kill -9 或断电），那么：

• 主库没有留下任何 .rdb 或 .aof 文件
• 从库在后续某次重启时，发现本地 dump.rdb 不存在或为空（比如之前没成功同步过，或被手动删过），就会以空数据集启动
• 此时如果从库配置了 replicaof <master><port></port></master>，它会向主库发起同步；但主库已不可达，而从库又没启用 replica-serve-stale-data yes（默认是 yes），它可能拒绝服务，但更常见的是：它根本没机会加载旧数据，因为压根没存过

从库是否开启持久化决定了它“有没有底牌”

从库是否清空，本质取决于它自己有没有可靠的本地持久化文件。注意几个关键配置项：

Redis Skill - 高性能缓存管理

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

下载

• save 配置是否注释？若注释，bgsave 不再自动触发 → 从库重启无 .rdb 可载
• appendonly 是否为 yes？若为 no，且 AOF 文件不存在或被截断，就无法回放命令
• dir 和 dbfile 路径是否可写？权限错误会导致 bgsave 失败但无报错，静默丢失备份
• 从库是否曾成功完成过一次全量同步？只有那次同步完成后，它才可能在本地落盘一个有效的 dump.rdb

典型误操作链：主库关持久化 → 主库 crash → 从库也未配持久化 → 运维重启从库 → 从库加载不到任何文件 → 启动为空实例 → 客户端读到空数据。

为什么 flushall 在无持久化主库上等于“删库跑路”

这个行为会直接传导到从库，而且比想象中更彻底：

• 主库执行 flushall，会把清空命令通过复制流发给所有从库（即使主库没开 AOF）
• 从库收到后立即执行，内存清空；若此时从库也没开持久化，它本地的 dump.rdb 还是旧的（不会自动重写），但下次重启时，只要没来得及 bgsave，就只能加载那个旧快照——等等，不对：如果主库刚 flushall 就挂，从库同步完清空命令后，它的内存已是空的；若此时你手动对从库执行 bgsave，生成的就是一个空 dump.rdb；之后重启，自然加载空数据
• 更隐蔽的是：flushall 触发主库自动生成 RDB（即使 save 配置被禁用），但这个 RDB 是空的；如果从库恰好在这个时间点做全量同步，它拿到的就是空快照

真正容易被忽略的点是：从库的“数据可靠性”不继承自主库，而完全取决于它自身的持久化配置和同步历史。主库关持久化本身不直接让从库变空，但它剥夺了整个集群的数据兜底能力——一旦任一节点重启，就暴露了这个脆弱性。