redis集群每个节点必须使用独立pvc，通过statefulset的volumeclaimtemplates实现；storageclass需设reclaimpolicy: retain；首次部署需清理nodes.conf，确保cluster_state:ok后再启用持久化。
Redis集群节点的RDB/AOF文件必须挂载到独立PVC，不能共用
Redis集群每个节点（redis-server）需要独立的持久化路径，否则多个Pod写同一份RDB/AOF会触发数据覆盖或校验失败。K8s里最稳妥的方式是为每个StatefulSet副本分配专属PVC——StatefulSet天生支持volumeClaimTemplates，自动为redis-0、redis-1等生成带序号的PVC。
常见错误是把所有Pod挂到同一个PVC（比如用Deployment + 共享PV），结果启动时redis-server报Failed opening .rdb for saving: Permission denied，其实是多个进程同时尝试ftruncate和fsync导致文件锁冲突。
- StatefulSet中必须用
volumeClaimTemplates，不能用volumes直接引用已有PVC - StorageClass需支持
ReadWriteOnce（多数云盘/本地存储默认如此），ReadWriteMany反而容易引发AOF重写竞争 - 挂载路径建议设为
/data，并在redis.conf里显式指定dir /data和dbfilename dump.rdb，避免读取默认/var/lib/redis
redis.conf里必须关闭AOF重写自动触发，改用BGREWRITEAOF手动控制
K8s Pod重启或滚动更新时，如果AOF重写（auto-aof-rewrite-percentage）恰好被触发，可能因磁盘IO波动导致重写失败，留下损坏的appendonly.aof.tmp文件，下次启动直接报Bad file format reading the append only file。
真实场景中，AOF重写应由运维脚本或Operator在低峰期主动调用BGREWRITEAOF命令，而非依赖配置项自动触发。
- 在ConfigMap注入的
redis.conf中设auto-aof-rewrite-percentage 0彻底禁用自动重写 -
appendonly yes必须开启，否则AOF文件不会生成；但aof-load-truncated yes建议打开，防止网络中断导致AOF尾部截断后无法启动 - 不要把
appendonly.aof和dump.rdb放在不同挂载点——PVC只挂一个/data目录最安全
PVC的StorageClass必须设置reclaimPolicy: Retain，否则删StatefulSet会丢数据
默认StorageClass的reclaimPolicy是Delete，一旦删除StatefulSet，关联PVC会被自动清理，下一次重建时虽然PVC名字一样（如redis-data-redis-0），但底层PV已被销毁，新PVC绑定的是空PV——RDB/AOF全没了。
Redis 8.2.3 是一款安全优先的高性能键值存储系统。该版本紧急修复了可能引发远程代码执行（RCE）的高危漏洞（CVE-2025-62507），并解决了 HyperLogLog 及 Cuckoo Filter 等数据结构在特定场景下的崩溃问题。建议所有用户立即升级，以保障生产环境的系统稳定与数据安全。
这不是Redis的问题，是K8s存储回收策略的硬规则。哪怕你用了本地存储（hostPath），只要PV没设Retain，删资源就等于删数据。
- 创建StorageClass时明确写
reclaimPolicy: Retain，别依赖集群默认值 - 删集群前务必先
kubectl get pv确认对应PV状态是Released还是Bound；Released说明数据还在，可手动kubectl patch pv xxx -p '{"spec":{"persistentVolumeReclaimPolicy":"Retain"}}'再回收 - 若用
local类型StorageClass，PV必须提前静态创建并绑定到具体Node，动态供给不适用
集群初始化阶段不能靠PVC自动恢复，得先等主从关系稳定再启持久化
Redis集群刚部署时，各节点互相CLUSTER MEET握手期间，如果某个Pod从PVC加载了旧RDB，而其他节点还没完成槽位分配，会导致LOADING Redis is loading the dataset in memory卡住，集群始终cluster_state:fail。
根本原因是RDB里的cluster-config-file（如nodes.conf）记录的是上一次集群拓扑，和当前实际节点ID、IP不一致，Redis拒绝加载。
- 首次部署集群时，在InitContainer里加
rm -f /data/nodes.conf，强制节点用当前配置重新生成 - 非首次升级：保留
nodes.conf但清空dump.rdb和appendonly.aof，等CLUSTER INFO显示cluster_state:ok后再手动SAVE或BGREWRITEAOF - 检查点：进Pod执行
redis-cli cluster info | grep cluster_state，必须是ok才允许应用写入
持久化不是开个PVC就完事——节点身份、集群状态、文件时效性三者必须对齐，缺一不可。很多人卡在cluster_state:fail却只盯着PVC权限看，其实问题早藏在nodes.conf里了。
