Redis集群异常：(error) CLUSTERDOWN Hash slot not served

redis集群机器在出现故障后重新启动后，尝试获取某个redis键时出现下面异常：

10.98.17.249:7001> get aaaaa
(error) CLUSTERDOWN Hash slot not served

上面这种异常是因为集群异常导致hash槽丢失，没法获取到集群中hash槽分配信息导致的。
首先，我们看一下redis集群状态：

10.98.17.249:7001> cluster info
cluster_state:fail
cluster_slots_assigned:0
cluster_slots_ok:0
cluster_slots_pfail:0
cluster_slots_fail:0
cluster_known_nodes:1
cluster_size:0
cluster_current_epoch:0
cluster_my_epoch:0
cluster_stats_messages_sent:0
cluster_stats_messages_received:0

通过上面的信息知道，当前集群处于fail状态，所以要先让集群互相发现，就是在集群中任何一个机器上面执行 cluster meet 命令：

10.98.17.249:7001> cluster meet 10.98.17.249 7002
OK
10.98.17.249:7001> cluster meet 10.98.17.249 7003
OK
10.98.17.249:7001> cluster meet 10.98.17.249 7004
OK
10.98.17.249:7001> cluster meet 10.98.17.249 7005
OK
10.98.17.249:7001> cluster meet 10.98.17.249 7006
OK

接下来就要执行hash槽分配命令，在集群中重新分配hash槽：

[root@localhost ~]# redis-cli --cluster fix 10.98.17.249:7001 -a 123456

上面的命令执行后，会看到控制台输出下面这种信息：

>>> Covering slot 152 with 10.98.17.249:7006
>>> Covering slot 6250 with 10.98.17.249:7001
>>> Covering slot 10625 with 10.98.17.249:7004
>>> Covering slot 15200 with 10.98.17.249:7006
......

等等上面这种输出的信息完成后，再次登录集群看一下集群状态：

10.98.17.249:7001> cluster info
cluster_state:ok
cluster_slots_assigned:16384
cluster_slots_ok:16384
cluster_slots_pfail:0
cluster_slots_fail:0
cluster_known_nodes:5
cluster_size:3
cluster_current_epoch:162
cluster_my_epoch:158
cluster_stats_messages_ping_sent:441
cluster_stats_messages_pong_sent:461
cluster_stats_messages_meet_sent:4
cluster_stats_messages_update_sent:3
cluster_stats_messages_sent:909
cluster_stats_messages_ping_received:461
cluster_stats_messages_pong_received:445
cluster_stats_messages_auth-req_received:6
cluster_stats_messages_update_received:5
cluster_stats_messages_received:917
total_cluster_links_buffer_limit_exceeded:0

发现集群状态已经ok了，再看一下节点信息：

10.98.17.249:7001> cluster nodes
8edb8b800da75d84ed79a2feb72296ac09706539 10.98.17.249:7004@17004 master - 0 1723769807087 161 connected 3-4 16-17 24 31 41 45 48 51 62 79 83 90 93 95 100 116 131-132 139 151 173-175 177 187 190 ...... 16323-16324 16331 16337 16344 16348 16356 16359 16365 16369 16379-16381
ff6ede071b1e3cac047ccb92113fa67878fcfee5 10.98.17.249:7005@17005 slave a091c8e684f69607d44409bdc98774f1de4e6001 0 1723769806082 158 connected
a091c8e684f69607d44409bdc98774f1de4e6001 10.98.17.249:7001@17001 myself,master - 0 1723769806000 158 connected 1 7 10 23 25-26 37 39 42 46 49-50 55-56 59 63-64 66 68 71 73 81 86-87 89 92 94 96 ...... 16345 16347 16349 16352 16361-16362 16364 16366 16373 16377-16378 16382
6bd59d133e00b461a9c3be9632c2a6e3b2aa44b2 10.98.17.249:7002@17002 slave 8edb8b800da75d84ed79a2feb72296ac09706539 0 1723769807589 161 connected
4388087e9b5e363d1b6e8cf3ef2b04e218672587 10.98.17.249:7003@17003 slave 7a531959c72d23ac88647303da8b1ce349fa283e 0 1723769808092 162 connected
7a531959c72d23ac88647303da8b1ce349fa283e 10.98.17.249:7006@17006 master - 0 1723769807589 162 connected 0 2 5-6 8-9 11-15 18-22 27-30 32-36 38 40 43-44 47 52-54 57-58 60-61 65 67 69-70 72 ...... 16353-16355 16357-16358 16360 16363 16367-16368 16370-16372 16374-16376 16383

hash槽也已经重新分配，验证redis命令应该可以正常执行。