如果出现硬故障,如何在redis群集中恢复特定节点的哈希槽?

时间:2016-05-24 14:13:22

标签: redis jedis redis-cluster

所以我正在测试redis集群。我有3个主人和3个奴隶的设置。现在,如果节点面临硬故障(主节点和从节点都关闭),则集群仍然可以正常工作,除非故障节点提供服务的散列插槽。现在,在测试这样的场景时,我发现对这些哈希槽服务的密钥进行操作的读/写操作会因异常而失败,这很好(我使用的是jedis btw)。但是,如果我使用redis群集作为缓存,我希望这些哈希槽由其他节点提供服务。 ./redis-trib.rb reshard实用程序中似乎没有此功能。

由于[ERR] Not all #{ClusterHashSlots} slots are covered by nodes../redis-trib.rb del-node失败,我无法重新启动群集以移动这些哈希位置。我也无法从群集中删除节点,因为[ERR] Node #{node} is not empty! Reshard data away and try again.失败并显示{{1}}。那么,最好的方法是处理我无法启动原始节点但希望这些散列槽由其他节点提供服务的场景(假设我在旧节点上丢失数据时甚至没问题)?理想情况下,可以删除该节点(集群中的主节点和从节点,并将这些散列插槽分配给其他节点)。

1 个答案:

答案 0 :(得分:1)

它通过将故障节点所服务的所有插槽添加到某些可连接节点来修复集群。方法是使用cluster addslots命令,但当然手动操作很难,所以我建议我们的团队开发tool

用法(在shell中):

# it requires Python2.7; install it via pip
pip install redis-trib

# suppose one of the accessible nodes is serving at 172.0.0.1:7000
# start a cluster-mode Redis that is not involved in any cluster
# suppose its address is 172.0.0.5:8000
redis-trib.py rescue --existing-addr 172.0.0.1:7000 --new-addr 172.0.0.5:8000

之后,新节点将为所有失败的插槽提供服务,以便集群状态变为正常。