Redis 5.0 を用いたクラスタ構築と検証
こんにちは、shirobrak です.
業務で Redis を使う必要があったので, Redis について勉強した際の備忘録.
現在（2018年10月25日時点）, Redis の最新版（ stable版 ）は 5.0.
Redis3系の記事は多くあるが, 4系や5の記事はあまり見当たらなかったので誰かの参考になれば.
目次
Redis Cluster の構築
Redis 公式のドキュメントにチュートリアルはあるので, それをやってみる.
ここでは1台のサーバ内で, 推奨最低構成の master:3, replica:3 のクラスタを組んでみる.
今回, 検証に使った動作環境はこちらからダウンロード可能です.
環境作るの面倒臭い方は, git clone して使ってください.
環境構築
Redis のインストール
最新版のredisは remi を用いてインストールできる.
sudo yum install redis --enablerepo=remi
構築準備
どこでもいいのでテスト用ディレクトリを作成
mkdir cluster-test
今回はサーバが1台なのでポート番号を分けてプロセスを立ち上げる.
ここでは, 6ノード分のconf置き場を作成する.
cd cluster-test mkdir 7000 7001 7002 7003 7004 7005
それぞれのディレクトリに以下の内容の redis.conf を作成しておく.
最小設定なので, 必要に応じて書き足してください.
./cluster-test/7000/redis.conf
port 7000 cluster-enabled yes cluster-config-file nodes.conf cluster-node-timeout 5000 appendonly yes
./cluster-test/7001/redis.conf
port 7001 cluster-enabled yes cluster-config-file nodes.conf cluster-node-timeout 5000 appendonly yes
という感じで, 各ディレクトリに redis.conf を作成する.
作成後はこんな感じになってるはず.
├── redis-cluster-test │ ├── 7000 │ │ └── redis.conf │ ├── 7001 │ │ └── redis.conf │ ├── 7002 │ │ └── redis.conf │ ├── 7003 │ │ └── redis.conf │ ├── 7004 │ │ └── redis.conf │ ├── 7005 │ └── redis.conf
クラスタ構築
ターミナルで6つウィンドウを用意して, 6つの Redis Server を立ち上げる.
ターミナル1
cd 7000 `redis-server ./redis.conf
ターミナル2
cd 7001 `redis-server ./redis.conf
... 省略
クラスタに属しているノードを確認したいときは以下のようにする.
ちなみに, これでも確認可能.
redis-cli -p 7000 cluster nodes
[vagrant@localhost ~]$ redis-cli -p 7000 127.0.0.1:7000> CLUSTER NODES 481f08ecdf24559588595d0b032a598b64c23041 127.0.0.1:7000@17000 myself,master - 0 1540694251000 8 connected
上記の 481f08ecdf24559588595d0b032a598b64c23041 はノードIDと呼ばれ,
クラスタ内でノードを識別する識別子となる.
各ノードのクラスタ状況を確認してみると...
[vagrant@localhost ~]$ redis-cli -p 7001 cluster nodes 68eb37a2663b80d3999a38090e5fc2d882fc6ca3 127.0.0.1:7001@17001 myself,master - 0 1540694291000 2 connected [vagrant@localhost ~]$ redis-cli -p 7002 cluster nodes dc8b5514c200b6ffddc2458b56e3368e6e0d0d74 127.0.0.1:7002@17002 myself,master - 0 1540694378000 7 connected [vagrant@localhost ~]$ redis-cli -p 7003 cluster nodes 96ea1b167d92fe1e6cf1447f730d6a3dd9327716 127.0.0.1:7003@17003 myself,master - 0 1540694331000 12 connected [vagrant@localhost ~]$ redis-cli -p 7004 cluster nodes b3e4e258d2b05d70667491c1aefaf6bcee518f45 127.0.0.1:7004@17004 myself,master - 0 1540694342000 11 connected [vagrant@localhost ~]$ redis-cli -p 7005 cluster nodes 0e72d1716dd2028834afddc0a1adb0c503b56d74 127.0.0.1:7005@17005 myself,master - 0 1540694349000 6 connected
このようになっており, 見てわかる通りそれぞれのノードは個別に動いていて, この時点ではまだ1つのクラスタとして動作していない.
6つのノードを関連づけクラスタを構築するには, 下記のコマンドを打つ.
--cluster-replicas は一つのノードに最低でも何個レプリカを作成するかを指定するオプション.
今回は Master:3, Replica:3 なので1でok.
redis-cli --cluster create 127.0.0.1:7000 127.0.0.1:7001 127.0.0.1:7002 \ 127.0.0.1:7003 127.0.0.1:7004 127.0.0.1:7005 --cluster-replicas 1
実際にコマンドを実行すると...
[vagrant@localhost cluster-test]$ redis-cli --cluster create 127.0.0.1:7000 127.0.0.1:7001 127.0.0.1:7002 \ 127.0.0.1:7003 127.0.0.1:7004 127.0.0.1:7005 --cluster-replicas 1 >>> Performing hash slots allocation on 6 nodes... Master[0] -> Slots 0 - 5460 Master[1] -> Slots 5461 - 10922 Master[2] -> Slots 10923 - 16383 Adding replica 127.0.0.1:7003 to 127.0.0.1:7000 Adding replica 127.0.0.1:7004 to 127.0.0.1:7001 Adding replica 127.0.0.1:7005 to 127.0.0.1:7002 >>> Trying to optimize slaves allocation for anti-affinity [WARNING] Some slaves are in the same host as their master M: 9ff3142c0773b4817686edaa120539ede09f8319 127.0.0.1:7000 slots:[0-5460] (5461 slots) master M: 3180dd7bac761d5de07592415d2f1b4383d1079b 127.0.0.1:7001 slots:[5461-10922] (5462 slots) master M: 391822fc5159c9a3ca8d2133f35a321fe34c44d0 127.0.0.1:7002 slots:[10923-16383] (5461 slots) master S: e8536ebc6bc668b8947860df2e37d04062fda1da 127.0.0.1:7003 replicates 9ff3142c0773b4817686edaa120539ede09f8319 S: 65dd42de699bf51edecc8767a2cb58d45a908bc1 127.0.0.1:7004 replicates 3180dd7bac761d5de07592415d2f1b4383d1079b S: 596a047bd99cc2f0988cb5bcd2d37f7ca83fa170 127.0.0.1:7005 replicates 391822fc5159c9a3ca8d2133f35a321fe34c44d0 Can I set the above configuration? (type 'yes' to accept): yes
こんな感じでクラスタ組みますよっていうのが出るので, yes を入力.
>>> Nodes configuration updated >>> Assign a different config epoch to each node >>> Sending CLUSTER MEET messages to join the cluster Waiting for the cluster to join .... >>> Performing Cluster Check (using node 127.0.0.1:7000) M: 9ff3142c0773b4817686edaa120539ede09f8319 127.0.0.1:7000 slots:[0-5460] (5461 slots) master 1 additional replica(s) S: e8536ebc6bc668b8947860df2e37d04062fda1da 127.0.0.1:7003 slots: (0 slots) slave replicates 9ff3142c0773b4817686edaa120539ede09f8319 S: 596a047bd99cc2f0988cb5bcd2d37f7ca83fa170 127.0.0.1:7005 slots: (0 slots) slave replicates 391822fc5159c9a3ca8d2133f35a321fe34c44d0 M: 3180dd7bac761d5de07592415d2f1b4383d1079b 127.0.0.1:7001 slots:[5461-10922] (5462 slots) master 1 additional replica(s) M: 391822fc5159c9a3ca8d2133f35a321fe34c44d0 127.0.0.1:7002 slots:[10923-16383] (5461 slots) master 1 additional replica(s) S: 65dd42de699bf51edecc8767a2cb58d45a908bc1 127.0.0.1:7004 slots: (0 slots) slave replicates 3180dd7bac761d5de07592415d2f1b4383d1079b [OK] All nodes agree about slots configuration. >>> Check for open slots... >>> Check slots coverage... [OK] All 16384 slots covered.
これでクラスタ構築完了.
先ほどの方法で 7000 のクラスタ状況を確認してみると,
6つのノードで Master:3, Replica:3 のクラスタが組まれていることが確認できる.
[vagrant@localhost cluster-test]$ redis-cli -p 7000 cluster nodes 9ff3142c0773b4817686edaa120539ede09f8319 127.0.0.1:7000@17000 myself,master - 0 1540722444000 1 connected 0-5460 e8536ebc6bc668b8947860df2e37d04062fda1da 127.0.0.1:7003@17003 slave 9ff3142c0773b4817686edaa120539ede09f8319 0 1540722444744 4 connected 596a047bd99cc2f0988cb5bcd2d37f7ca83fa170 127.0.0.1:7005@17005 slave 391822fc5159c9a3ca8d2133f35a321fe34c44d0 0 1540722444000 6 connected 3180dd7bac761d5de07592415d2f1b4383d1079b 127.0.0.1:7001@17001 master - 0 1540722445813 2 connected 5461-10922 391822fc5159c9a3ca8d2133f35a321fe34c44d0 127.0.0.1:7002@17002 master - 0 1540722444000 3 connected 10923-16383 65dd42de699bf51edecc8767a2cb58d45a908bc1 127.0.0.1:7004@17004 slave 3180dd7bac761d5de07592415d2f1b4383d1079b 0 1540722444544 5 connected
図にするとこんな感じ.
Redis Cluster へのデータ書き込み&読み取り
前提条件
現在, 上記の図のようなクラスタが組まれているとする.
Redis CLI による Redis Cluster へのデータ投入
redis では データが格納される Slot が key によって決まっているため, 仮に, 以下のようなコマンドでデータを投入しようとすると...
[vagrant@localhost ~]$ redis-cli -p 7005 set hello world (error) MOVED 866 127.0.0.1:7000
以下のように, key hello は, 127.0.0.1:7000 に格納される値ですよ, とエラーが返却される.
[vagrant@localhost cluster-test]$ redis-cli -p 7000 set hello world (error) MOVED 866 127.0.0.1:7005
データを取得したいときも同様なエラーが出る.
[vagrant@localhost ~]$ redis-cli -p 7005 get hello (error) MOVED 866 127.0.0.1:7000
クラスタにデータを挿入する際は, -c という cluster mode でデータを挿入してやると,
自動的に格納すべきノードへリダイレクトされデータが格納できる.
オプションコマンドについては, redis-cli --help 等で確認できる.
# --help による出力 -c Enable cluster mode (follow -ASK and -MOVED redirections).
オプションをつけてコマンドを発行すると...
[vagrant@localhost ~]$ redis-cli -c -p 7005 127.0.0.1:7005> set hello world -> Redirected to slot [866] located at 127.0.0.1:7000 OK
ちゃんとリダイレクトされてデータが格納されていることが分かる.
PHPによる Redis Cluster へのデータ投入
業務では, Laravel から Redis に接続する予定なので,
まずは Laravel でも推奨されている PHP製のクライアントである predis を使ってデータを投入してみる.
以下に, 10000個のデータを投入するプログラムを記す（適当
<?php require './vendor/autoload.php'; $params = [ 'tcp://127.0.0.1:7000', 'tcp://127.0.0.1:7001', 'tcp://127.0.0.1:7002', 'tcp://127.0.0.1:7003', 'tcp://127.0.0.1:7004', 'tcp://127.0.0.1:7005' ]; $options = ['cluster' => 'redis']; $client = new Predis\Client($params, $options); $set_num = 10000; for($i=0;$i<$set_num;$i++){ $key = "key".strval($i); $value = "hoge".strval($i); $res = $client->executeRaw(['SET', $key, $value]); } ?>
predis は Redis Cluster に対応しているので,
$options = ['cluster' => 'redis'];
のように, オプションを指定して Clientインスタンスを作成すると,
$params で指定したノード群からランダムにノードを選択しアクセスしてくれる.
つまり, 先述した MOVED 等のエラーを考慮しなくてもいい実装になっている.
まず, データ投入前のDBが空な事を確認する.
ちなみに, Redis 内のデータを全て消したいときは各ノードで, flushdb をしてやれば良い.
[vagrant@localhost predis]$ redis-cli -c -p 7000 dbsize (integer) 0 [vagrant@localhost predis]$ redis-cli -c -p 7001 dbsize (integer) 0 [vagrant@localhost predis]$ redis-cli -c -p 7002 dbsize (integer) 0
そして上記のプログラムを実行してやると...
[vagrant@localhost predis]$ redis-cli -c -p 7000 dbsize (integer) 3331 [vagrant@localhost predis]$ redis-cli -c -p 7001 dbsize (integer) 3340 [vagrant@localhost predis]$ redis-cli -c -p 7002 dbsize (integer) 3329
と, ちゃんと10000個のデータが格納されている事が分かる.
ちゃんとクラスタを組む事で, Write が分散されてることも分かる.
今回はキャッシュ的な使い方で Redis を使用する予定なので,
GET key してキャッシュないものは新しく追加する, みたいな処理を書いてみた.
<?php require './vendor/autoload.php'; $params = [ 'tcp://127.0.0.1:7000', 'tcp://127.0.0.1:7001', 'tcp://127.0.0.1:7002', 'tcp://127.0.0.1:7003', 'tcp://127.0.0.1:7004', 'tcp://127.0.0.1:7005' ]; $options = ['cluster' => 'redis']; $insertedDataNumber = 0; $readableDataNumber = 0; try{ $client = new Predis\Client($params, $options); $set_num = 10000; for($i=0;$i<$set_num;$i++){ $key = "key".strval($i); $res = $client->executeRaw(['GET', $key]); if($res){ $readableDataNumber++; // print("{ key : ".$key.", value : ".$res." }\n"); }else{ $value = "hoge".strval($i); $client->executeRaw(['SET', $key, $value]); //print("inserted: "."{ key : ".$key.", value : ".$value." }\n"); $insertedDataNumber++; } } print("ReadableData : ".$readableDataNumber.", InsertedData : ".$insertedDataNumber."\n"); }catch(Predis\Connection\ConnectionException $e){ print("Predis Connection Error \n"); }catch(Exception $e){ print($e); } ?>
まず現時点での実行結果.
[vagrant@localhost predis]$ php read.php ReadableData : 10000, InsertedData : 0
すでに先ほど投入したデータが10000件入っていることが分かる.
ここから, Node7000 に格納されているデータを消す.
[vagrant@localhost predis]$ redis-cli -c -p 7000 127.0.0.1:7000> flushdb OK 127.0.0.1:7000> [vagrant@localhost predis]$ redis-cli -c -p 7000 dbsize (integer) 0
もう一度実行.
[vagrant@localhost predis]$ php read.php ReadableData : 6669, InsertedData : 3331
ちゃんと3331個のキーが新しく追加されているので一応正しく動いているっぽい.
Redis Cluster の動作検証
構築した Redisクラスタ の挙動を確認していく.
便宜上, ポート番号Xを使用しているノードを NodeX とすると
現在, クラスタ構成は次の図のようになっている.
Case1. Master が1台停止する
ここでは Node7000 が停止すると, Node7003 が昇格することを確かめる.
7000のプロセスを kill 等を用いて停止させ, クラスタ状況を確認すると...
[vagrant@localhost cluster-test]$ redis-cli -p 7003 cluster nodes 596a047bd99cc2f0988cb5bcd2d37f7ca83fa170 127.0.0.1:7005@17005 slave 391822fc5159c9a3ca8d2133f35a321fe34c44d0 0 1540724281090 6 connected e8536ebc6bc668b8947860df2e37d04062fda1da 127.0.0.1:7003@17003 myself,master - 0 1540724280000 7 connected 0-5460 3180dd7bac761d5de07592415d2f1b4383d1079b 127.0.0.1:7001@17001 master - 0 1540724282115 2 connected 5461-10922 391822fc5159c9a3ca8d2133f35a321fe34c44d0 127.0.0.1:7002@17002 master - 0 1540724282115 3 connected 10923-16383 65dd42de699bf51edecc8767a2cb58d45a908bc1 127.0.0.1:7004@17004 slave 3180dd7bac761d5de07592415d2f1b4383d1079b 0 1540724281502 5 connected 9ff3142c0773b4817686edaa120539ede09f8319 127.0.0.1:7000@17000 master,fail - 1540724272015 1540724271300 1 disconnected
狙い通り, Node7003 が Master に昇格している事がわかる.
ここから Node7000 を立ち上げると...
[vagrant@localhost cluster-test]$ redis-cli -p 7003 cluster nodes 596a047bd99cc2f0988cb5bcd2d37f7ca83fa170 127.0.0.1:7005@17005 slave 391822fc5159c9a3ca8d2133f35a321fe34c44d0 0 1540724326163 6 connected e8536ebc6bc668b8947860df2e37d04062fda1da 127.0.0.1:7003@17003 myself,master - 0 1540724326000 7 connected 0-5460 3180dd7bac761d5de07592415d2f1b4383d1079b 127.0.0.1:7001@17001 master - 0 1540724326570 2 connected 5461-10922 391822fc5159c9a3ca8d2133f35a321fe34c44d0 127.0.0.1:7002@17002 master - 0 1540724324596 3 connected 10923-16383 65dd42de699bf51edecc8767a2cb58d45a908bc1 127.0.0.1:7004@17004 slave 3180dd7bac761d5de07592415d2f1b4383d1079b 0 1540724325000 5 connected 9ff3142c0773b4817686edaa120539ede09f8319 127.0.0.1:7000@17000 slave e8536ebc6bc668b8947860df2e37d04062fda1da 0 1540724326570 7 connected
となり, Node7000 が Node7003 の Replica として紐づいている事がわかる.
Case2. Master が2台が同時停止する
Redis Cluster では何かやるときに 全Master の過半数の賛成が得られる状態でなければならない.
Master:3, Replica:3 のクラスタでは, Master が2台停止すると過半数を保つ事はできないのでクラスタが崩壊する.
ここでは, Node7001 と Node7002 を同時に停止するとクラスタ崩壊をおこす事を確認する.
[vagrant@localhost cluster-test]$ redis-cli -p 7000 cluster nodes 65dd42de699bf51edecc8767a2cb58d45a908bc1 127.0.0.1:7004@17004 slave 3180dd7bac761d5de07592415d2f1b4383d1079b 0 1540724435595 5 connected 3180dd7bac761d5de07592415d2f1b4383d1079b 127.0.0.1:7001@17001 master,fail? - 1540724426709 1540724426505 2 disconnected 5461-10922 9ff3142c0773b4817686edaa120539ede09f8319 127.0.0.1:7000@17000 myself,master - 0 1540724434000 8 connected 0-5460 596a047bd99cc2f0988cb5bcd2d37f7ca83fa170 127.0.0.1:7005@17005 slave 391822fc5159c9a3ca8d2133f35a321fe34c44d0 0 1540724435292 6 connected e8536ebc6bc668b8947860df2e37d04062fda1da 127.0.0.1:7003@17003 slave 9ff3142c0773b4817686edaa120539ede09f8319 0 1540724435000 8 connected 391822fc5159c9a3ca8d2133f35a321fe34c44d0 127.0.0.1:7002@17002 master,fail? - 1540724427616 1540724427303 3 disconnected 10923-16383 [vagrant@localhost cluster-test]$ redis-cli -p 7000 get hoge (error) CLUSTERDOWN The cluster is down
上記のように, Node7001 と Node7002 に紐づいている Replica が昇格せず,
クラスタ崩壊していることがわかる.
この状態からクラスタを復旧するには Node7001 と Node7002 をそのまま再起動してやれば良い.
すると...
[vagrant@localhost cluster-test]$ redis-cli -p 7000 cluster nodes 65dd42de699bf51edecc8767a2cb58d45a908bc1 127.0.0.1:7004@17004 slave 3180dd7bac761d5de07592415d2f1b4383d1079b 0 1540724534000 5 connected 3180dd7bac761d5de07592415d2f1b4383d1079b 127.0.0.1:7001@17001 master - 0 1540724535673 2 connected 5461-10922 9ff3142c0773b4817686edaa120539ede09f8319 127.0.0.1:7000@17000 myself,master - 0 1540724534000 8 connected 0-5460 596a047bd99cc2f0988cb5bcd2d37f7ca83fa170 127.0.0.1:7005@17005 slave 391822fc5159c9a3ca8d2133f35a321fe34c44d0 0 1540724535468 6 connected e8536ebc6bc668b8947860df2e37d04062fda1da 127.0.0.1:7003@17003 slave 9ff3142c0773b4817686edaa120539ede09f8319 0 1540724534285 8 connected 391822fc5159c9a3ca8d2133f35a321fe34c44d0 127.0.0.1:7002@17002 master - 0 1540724535000 3 connected 10923-16383
無事, Master に復帰している事がわかる.
これは nodes.conf に直前のクラスタ構成が書き込まれているおかげ？だと思われる. （要勉強
Case3. Master と紐づく Replica が同時または連続で停止する
Redis Cluster では, それぞれのノードに Replica が1つしかない場合,
他のノードに Replica を移動するができない.
つまり, Master とそれに紐づく Replica が停止すれば
そのノードに割り当てられていた Slot を扱う Master がいなくなりクラスタが崩壊する.
今回は Node7000 と Node7003 を連続して停止させて確認する.
まず, Node7000 を停止する. 当然 Node7003 が Master に昇格する.
[vagrant@localhost cluster-test]$ redis-cli -p 7001 cluster nodes e8536ebc6bc668b8947860df2e37d04062fda1da 127.0.0.1:7003@17003 master - 0 1540724683747 9 connected 0-5460 65dd42de699bf51edecc8767a2cb58d45a908bc1 127.0.0.1:7004@17004 slave 3180dd7bac761d5de07592415d2f1b4383d1079b 0 1540724683000 5 connected 3180dd7bac761d5de07592415d2f1b4383d1079b 127.0.0.1:7001@17001 myself,master - 0 1540724683000 2 connected 5461-10922 391822fc5159c9a3ca8d2133f35a321fe34c44d0 127.0.0.1:7002@17002 master - 0 1540724682526 3 connected 10923-16383 596a047bd99cc2f0988cb5bcd2d37f7ca83fa170 127.0.0.1:7005@17005 slave 391822fc5159c9a3ca8d2133f35a321fe34c44d0 0 1540724682737 6 connected 9ff3142c0773b4817686edaa120539ede09f8319 127.0.0.1:7000@17000 master,fail - 1540724675623 1540724674000 8 disconnected
ここから, Node7003 を停止する.
[vagrant@localhost cluster-test]$ redis-cli -p 7001 cluster nodes e8536ebc6bc668b8947860df2e37d04062fda1da 127.0.0.1:7003@17003 master,fail - 1540724729177 1540724727512 9 disconnected 0-5460 65dd42de699bf51edecc8767a2cb58d45a908bc1 127.0.0.1:7004@17004 slave 3180dd7bac761d5de07592415d2f1b4383d1079b 0 1540724738002 5 connected 3180dd7bac761d5de07592415d2f1b4383d1079b 127.0.0.1:7001@17001 myself,master - 0 1540724736000 2 connected 5461-10922 391822fc5159c9a3ca8d2133f35a321fe34c44d0 127.0.0.1:7002@17002 master - 0 1540724739000 3 connected 10923-16383 596a047bd99cc2f0988cb5bcd2d37f7ca83fa170 127.0.0.1:7005@17005 slave 391822fc5159c9a3ca8d2133f35a321fe34c44d0 0 1540724739534 6 connected 9ff3142c0773b4817686edaa120539ede09f8319 127.0.0.1:7000@17000 master,fail - 1540724675623 1540724674000 8 disconnected
となり, クラスタ崩壊を起こしていることがわかる.
ここから復旧する際, Node7000 を最初に復旧すると,
最新の nodes.conf には Node7000 は Node7003 の Replica である
と記載されているので, 下記のように fail している Node7003 の Replica として復帰してしまっていることが分かる.
特にエラーも起きないので問題ないのかもしれないが...
[vagrant@localhost cluster-test]$ redis-cli -p 7001 cluster nodes e8536ebc6bc668b8947860df2e37d04062fda1da 127.0.0.1:7003@17003 master,fail - 1540724729177 1540724727512 9 disconnected 0-5460 65dd42de699bf51edecc8767a2cb58d45a908bc1 127.0.0.1:7004@17004 slave 3180dd7bac761d5de07592415d2f1b4383d1079b 0 1540724834902 5 connected 3180dd7bac761d5de07592415d2f1b4383d1079b 127.0.0.1:7001@17001 myself,master - 0 1540724835000 2 connected 5461-10922 391822fc5159c9a3ca8d2133f35a321fe34c44d0 127.0.0.1:7002@17002 master - 0 1540724836600 3 connected 10923-16383 596a047bd99cc2f0988cb5bcd2d37f7ca83fa170 127.0.0.1:7005@17005 slave 391822fc5159c9a3ca8d2133f35a321fe34c44d0 0 1540724835969 6 connected 9ff3142c0773b4817686edaa120539ede09f8319 127.0.0.1:7000@17000 slave e8536ebc6bc668b8947860df2e37d04062fda1da 0 1540724836499 9 connected
この後, Node7003 を復帰させてやれば問題なくクラスタが復活する.
[vagrant@localhost cluster-test]$ redis-cli -p 7001 cluster nodes e8536ebc6bc668b8947860df2e37d04062fda1da 127.0.0.1:7003@17003 master - 0 1540724921000 9 connected 0-5460 65dd42de699bf51edecc8767a2cb58d45a908bc1 127.0.0.1:7004@17004 slave 3180dd7bac761d5de07592415d2f1b4383d1079b 0 1540724921415 5 connected 3180dd7bac761d5de07592415d2f1b4383d1079b 127.0.0.1:7001@17001 myself,master - 0 1540724920000 2 connected 5461-10922 391822fc5159c9a3ca8d2133f35a321fe34c44d0 127.0.0.1:7002@17002 master - 0 1540724920610 3 connected 10923-16383 596a047bd99cc2f0988cb5bcd2d37f7ca83fa170 127.0.0.1:7005@17005 slave 391822fc5159c9a3ca8d2133f35a321fe34c44d0 0 1540724920409 6 connected 9ff3142c0773b4817686edaa120539ede09f8319 127.0.0.1:7000@17000 slave e8536ebc6bc668b8947860df2e37d04062fda1da 0 1540724920000 9 connected
なので, Node7003 を先に復旧させて, Node7000 を復旧させるのが良いのだろうか？
Redis Cluster の復旧方法についてはもう少し調査が必要だと思われる.
参考文献
以下, 参考文献一覧.
