不可行——从库默认禁止任何持久化操作，save/bgsave 命令直接报错；其 rdb/aof 必须与主库一致，自行生成会破坏复制一致性，且源码层面硬编码只读模式，缺失 repl-id/repl-offset 元信息。
Redis 从库开启 RDB 持久化是否可行？
不可行——从库默认禁止任何持久化操作，save、bgsave 命令直接报错 ERR This instance has cluster-announce-ip set, and is read-only（或类似只读提示），哪怕你关了 slave-read-only no 也没用。Redis 的设计逻辑是：从库的 RDB/AOF 文件必须与主库完全一致，不能自行生成。强行绕过会破坏复制一致性，甚至导致重启后无法加载数据。
为什么不能让从库独立执行 bgsave？
根本原因在复制协议层：replication 过程中，从库不维护自己的 dirty 计数器，也不触发 save 条件判断；它的 rdbSaveInfo 结构体被硬编码为只读模式。即使你 hack 源码注释掉校验，生成的 dump.rdb 也会缺失 repl-id 和 repl-offset 元信息，下次同步时主库可能拒绝部分重传，或者从库加载失败报 Wrong RDB checksum。
-
save配置项在从库上被忽略，redis.conf里写save 60 1000对从库无效 -
CONFIG SET save ""或CONFIG SET stop-writes-on-bgsave-error no不影响该限制 - 从库的
INFO persistence中rdb_bgsave_in_progress永远为0，rdb_last_save_time始终是主库上次保存时间
真正能转移 IO 压力的替代方案
想把落盘压力从主库挪走，只能放弃“从库自己持久化”的思路，改用外部工具 + 时间错峰：
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 用
redis-cli --rdb定期从从库拉取当前内存快照：redis-cli -h slave-host -p 6379 --rdb /backup/dump_$(date +%s).rdb，这是安全的二进制导出，不触发从库内部bgsave - 避免高峰时段执行：主库写入密集时，
--rdb仍会短暂阻塞从库网络读（约几十毫秒），建议在业务低谷跑 - 注意文件权限和磁盘空间：该命令由客户端发起，生成文件在本地，不是从库服务器上
- 不能替代 AOF：
--rdb只导出 RDB，若主库开了 AOF，这个快照不含最后几秒命令，需配合redis-check-rdb校验完整性
主库关闭持久化后的风险点
如果真按标题设想“关闭主库落盘”，等于把所有可靠性押在内存和网络上。一旦主库进程崩溃或机器断电，且没有提前配置 appendonly yes 或 save，数据就彻底丢失——从库此时只是个只读副本，它自己没存任何持久化文件，也无法回滚到某个时间点。
更隐蔽的问题是：某些云 Redis 服务（如阿里云 Tair、腾讯云 CRS）会强制开启主库 AOF，并禁止关闭，此时所谓“关闭主库落盘”在管理控制台根本不可选。
