Redis集群重启后槽位丢失，根本原因是nodes.conf未正确落盘或被覆盖；该文件是集群元数据唯一本地持久化载体，记录节点ID、拓扑及槽位映射，需确保路径可写、权限正确、cluster-enabled运行时为yes，并通过cluster meet/addslots等显式建立集群关系。
Redis集群重启后槽位丢失，不是集群“自己崩了”，而是节点没把集群配置写进磁盘 —— nodes.conf 文件没落盘或被覆盖，槽位映射关系就没了。
nodes.conf 是否被正确写入磁盘
Redis 集群每个节点会自动生成并维护一个 nodes.conf 文件（默认与 redis.conf 同目录），里面存着本节点 ID、其他节点地址、以及最重要的：当前节点负责哪些 slot（0–16383）。这个文件是集群元数据的唯一本地持久化载体。
常见错误现象：
- 重启后
redis-cli --cluster check报错ERR Invalid node address specified或显示所有节点都标为fail -
cat nodes.conf发现文件为空、只有本节点信息、或时间戳比上次启动还旧 - 日志里有
Failed to open nodes.conf: Permission denied或Can't update nodes.conf
实操建议：
- 确认
redis.conf中设置了cluster-config-file nodes.conf，且路径可写（比如不是/etc/redis/nodes.conf而是/var/lib/redis/nodes.conf） - 检查该文件属主和权限：
ls -l nodes.conf，必须和 redis 进程运行用户一致（如redis:redis），且至少有-rw- - 启动时加
--loglevel verbose，观察日志是否出现Writing to nodes.conf和nodes.conf updated；若无，说明写入被跳过或失败 - 不要手动编辑
nodes.conf—— 它由 Redis 自动管理；手动改完再启，大概率被覆盖回旧状态
redis.conf 中 cluster-enabled 是否生效
cluster-enabled yes 是集群模式开关，但它只在进程启动时读取一次。如果配置文件里写的是 yes，但运行时查出来是 no，那集群根本没真正启用，自然也不会生成/更新 nodes.conf。
实操建议：
- 用
redis-cli config get cluster-enabled查运行时值，不是看配置文件 —— 有人改了redis.conf却忘了CONFIG REWRITE或没重载服务 - 若返回
"no"，检查是否有include其他配置文件覆盖了该值，或 systemd 服务文件里用了--cluster-enabled no这类命令行参数强行关闭 - 确认没在
redis.conf中误写成cluster-enabled true（只认yes/no）
节点重启前是否执行过 cluster meet / addslots / replicate
集群拓扑不是靠“启动就自动发现”建立的。nodes.conf 只保存已成功交互过的节点关系。如果只是把所有节点拉起来，但没用 redis-cli --cluster create 或手动 cluster meet 把它们连成一张网，每个节点的 nodes.conf 就只有自己，slot 也就没人分配。
实操建议：
- 集群初始化必须显式执行
redis-cli --cluster create（或等价的cluster meet+cluster addslots+cluster replicate） - 重启后若 slot 为空，先用
redis-cli cluster nodes看输出是否含多个节点及master/slave标识；若只有单行且带myself，说明集群未形成 - 不要依赖“上次跑过，这次应该还在”——
nodes.conf不同步、不备份、不跨节点共享，每个节点独立维护
最易被忽略的一点：nodes.conf 不受 RDB/AOF 控制，它完全独立于数据持久化机制。即使你 AOF 开得再严、RDB 备份再勤，只要 nodes.conf 没写成功或路径错了，集群元数据就归零。每次部署或升级后，务必手动验证 cluster nodes 输出和 nodes.conf 文件内容是否一致。
