必须用CLUSTER FAILOVER TAKEOVER，因主节点硬件彻底损坏永久失联，CLUSTER FAILOVER（需主在线校验偏移量）和FORCE（仍需多数主投票）均失败；TAKEOVER单方面生成config epoch、接管槽位，不依赖任何外部共识。
必须用 CLUSTER FAILOVER TAKEOVER，且只能在目标从节点本地执行——其他方式会失败或被拒绝。
为什么 CLUSTER FAILOVER 和 CLUSTER FAILOVER FORCE 都不行
主节点硬件彻底损坏，意味着它已永久失联、无法响应任何心跳或复制请求。此时：
-
CLUSTER FAILOVER（无参数）会立即报错ERR Master is down or failed，因为它强制要求主节点在线并能通信，用于校验复制偏移量 -
CLUSTER FAILOVER FORCE虽跳过偏移量校验，但仍需向其他主节点广播选举请求；若集群多数主节点不可达（比如只剩 2 个节点在线），投票无法达成，命令会超时或静默失败 - 只有
TAKEOVER模式完全不依赖主节点和其他节点共识，由本节点单方面生成新配置纪元（config epoch）、接管全部所属槽位，并立即对外声明自己是新主
执行前必须验证的三件事
别急着敲命令——连错节点或状态不对会导致脑裂或拒绝服务：
- 确认当前节点确实是目标主节点的从节点：
redis-cli -p 6380 INFO replication | grep role输出必须是role:slave，且master_host和master_port不为空 - 检查主节点是否已被集群标记为
fail：redis-cli -p 6380 CLUSTER NODES中对应 master ID 的那一行，应含fail标记（不是pfail） - 确保该从节点本身状态正常：
redis-cli -p 6380 PING返回PONG，且redis-cli -p 6380 INFO cluster | grep cluster_state显示cluster_state:ok或fail（后者说明集群已感知故障，反而更安全）
TAKEOVER 后为什么其他节点不认新主？
常见现象：你在从节点上成功执行了 CLUSTER FAILOVER TAKEOVER，CLUSTER NODES 显示它已变成 master，但其他节点日志持续打印 Ignoring the gossip for ... because of an unknown node，客户端仍往旧地址发请求。
根本原因是配置纪元（config epoch）未被集群接受：
-
TAKEOVER生成的 config epoch 是本地自增的，可能小于集群当前最大 epoch，导致其他节点认为该变更“过期”而忽略 - 该节点不会主动向其他节点发送
UPDATE消息，也不会响应CLUSTER MEET或REPLICATE请求，直到你手动重启或执行CLUSTER RESET - 修复方法：先让存活节点尽可能多地上线，再在新主节点上执行
CLUSTER FORGET清除旧节点残留记录，然后用CLUSTER MEET重新握手；若只剩一个节点，则必须接受它成为唯一权威，客户端需直连该地址
执行后最易被忽略的点
硬件损坏场景下，TAKEOVER 不是终点，而是恢复起点：
- 新主节点的
redis.conf中cluster-config-file文件内容已更新，但旧主节点磁盘损坏，无法恢复；你必须把新主的配置文件备份出来，作为后续扩容或重建的基准 - 客户端连接字符串里写的还是旧主 IP:port，
MOVED重定向会失效（因为旧主永远不回来了），必须人工或通过配置中心更新所有应用的 Redis 地址 - 原主节点恢复后若直接加入集群，会被当作新节点处理，其数据将被清空并强制同步——所以务必先停掉它的进程，再决定是否重做从节点
