从节点会被误删数据是因为默认可写且未启用slave-read-only yes，导致flushall等命令可直接执行清空数据，叠加主节点误删触发全量同步会进一步扩散风险；必须在主从节点均配置rename-command flushall ""并开启slave-read-only yes，且重启生效、统一验证路径与配置。
从节点为什么会被误删数据
从节点本身不会主动删数据，但一旦被人为执行 FLUSHALL、FLUSHDB 或 CONFIG SET dbfilename 等命令，就会清空自身数据——而它又默认接受写命令（除非显式配置只读），这就埋下隐患。更危险的是，如果主节点被误删后触发全量同步，从节点会跟着一起变空。
必须开启 slave-read-only yes 配置
这是防误删的第一道防线。不设这个，从节点默认可写，SET、DEL、FLUSHDB 全部能执行，等于白搭主从架构。
-
slave-read-only是从节点配置项，不是主节点的；它控制的是“本节点是否允许客户端写入”，和复制方向无关 - 配置生效后，所有写命令返回
(error) READONLY You can't write against a read only slave. - 注意：该配置在 Redis 2.6+ 默认为
yes，但旧版本或 Docker 镜像可能覆盖为no，务必检查 - 验证方式：
redis-cli -p 6380 CONFIG GET slave-read-only，返回1才算开
禁用从节点上的高危命令更稳妥
光靠只读还不够——管理员或跳板机仍可能连上从节点并执行 FLUSHALL，只要没配权限限制，命令就能跑。所以得叠加命令重命名。
Redis 8.2.3
下载
Redis 8.2.3 是一款安全优先的高性能键值存储系统。该版本紧急修复了可能引发远程代码执行（RCE）的高危漏洞（CVE-2025-62507），并解决了 HyperLogLog 及 Cuckoo Filter 等数据结构在特定场景下的崩溃问题。建议所有用户立即升级，以保障生产环境的系统稳定与数据安全。
- 在从节点的
redis.conf中加这两行（放在 SECURITY 区域）：rename-command FLUSHALL ""rename-command FLUSHDB "" - 重启从节点才生效；热重载
CONFIG REWRITE不支持rename-command - 别漏掉
CONFIG：它能改dir、dbfilename，间接导致下次启动加载空 RDB，建议也重命名：rename-command CONFIG "config_disabled" - 如果用了 ACL（Redis 6.0+），
rename-command仍优先于 ACL，两者可共存，但不要只依赖 ACL
主节点也要同步加固，否则从节点保不住
从节点再安全，也挡不住主节点被误删后触发的全量同步。主节点一旦执行 FLUSHALL，所有从节点会在下一次 SYNC 中被强制覆盖为空。
- 主节点同样要配
rename-command FLUSHALL ""和rename-command FLUSHDB "" - 主节点禁用
CONFIG同样关键：否则有人CONFIG SET save ""关掉持久化，再崩溃重启就真没了 - 主节点启用
min-slaves-to-write可降低风险：比如设为1，表示至少 1 个从节点在线才允许写，避免脑裂时旧主继续接收脏写 - 所有节点（主+从+哨兵）的配置必须统一，尤其 Docker 或 K8s 环境下，容易漏掉某台从节点没挂载新 conf
真正麻烦的不是单点误操作，而是配置没对齐、重启没落实、路径没验证——比如你以为改了 redis.conf，结果 Redis 加载的是 /usr/local/etc/redis.conf，而你编辑的是 /etc/redis/redis.conf。
