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>，它会向主库发起同步；但主库已不可达，而从库又没启用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 是空的；如果从库恰好在这个时间点做全量同步，它拿到的就是空快照
真正容易被忽略的点是：从库的“数据可靠性”不继承自主库，而完全取决于它自身的持久化配置和同步历史。主库关持久化本身不直接让从库变空，但它剥夺了整个集群的数据兜底能力——一旦任一节点重启，就暴露了这个脆弱性。
