1

そのため、redis クラスターをテストしています。3 つのマスターと 3 つのスレーブのセットアップがあります。これで、ノードがハード障害 (マスターとスレーブの両方がダウン) に直面した場合でも、クラスターは引き続き機能し、障害が発生したノードによって提供されるハッシュ スロットを除外します。現在、このようなシナリオをテストしているときに、これらのハッシュ スロットによって提供されるキーを操作する読み取り/書き込みが例外で失敗することがわかりましたが、これは問題ありません (私は jedis を使用しています)。ただし、redis クラスターをキャッシュとして使用している場合は、これらのハッシュ スロットを他のノードで提供したいと考えています。redis-tribこの機能は、ユーティリティには存在しないようです。

./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.。元のノードを立ち上げることができないが、それらのハッシュスロットを他のノードで提供したいというシナリオに対処するための最良の方法は何ですか (古いノードでデータを失っても問題ないと仮定して)? 理想的には、そのノードを削除できるようなものです (クラスターからマスターとスレーブを削除し、それらのハッシュ スロットを他のノードに割り当てます)。

4

1 に答える 1

1

障害が発生したノードによって提供されていたすべてのスロットを接続可能なノードに追加することで、クラスターを修正します。アプローチはcluster addslotsコマンドを使用することですが、もちろん手動で行うのは難しいので、私たちのチームが開発したこのツールをお勧めします。

使用法 (シェル内):

# 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

その後、新しいノードは失敗したすべてのスロットを提供するため、クラスターの状態は OK になります。

于 2016-06-12T01:57:52.647 に答える