Redis Cluster のリシャーディングとorphaned masterの話 - CyberAgent エンジニア Advent Calendar 2014 2日目

redis_cluster.md

Redis Cluster のリシャーディングとorphaned masterの話

（2019/04 追記 こちらの情報は非常に古く、またRC版での結果となります。記録として残していますが参考になさらないでください）

CyberAgent エンジニア Advent Calendar 2014 2日目です。

昨日に引き続き、秋葉原ラボの柿島が担当します。仕事ではHadoopクラスタの運用を中心に、秋葉原ラボのインフラ/ミドルウェアまわりを担当しています。今年はHadoop、mesos、Aerospikeと分散型のシステムを触る機会が多い1年でした。

この記事のテーマはRedis Clusterです。Redis Clusterが使えるようになるRedis 3.0.0は10月にRC1がリリースされました。2015年のQ1にstableリリースを目指しているようです。

そのRedis Clusterについて次の2つの内容を書きます。

1. リシャーディング機能がありがたいという話
2. orphaned masterの判定アルゴリズムが以前検証したときと変わっていたという話

Redis Clusterのドキュメントはこちらです。

• Redis cluster tutorial
• Redis cluster Specification (work in progress)

これらのプレゼン資料も参考になります。

• Salvatore Sanfilippo – How Redis Cluster works, and why - NoSQL matters Barcelona 2014
• Redis Cluster a pragmatic approach to distribution ※PDF、ちょっと情報は古め

試した環境はいずれもCentOS6.5です。

使用したRedisのバージョンは次のようになっています。

• (1) では、Redis 3.0.0 RC1 (version 2.9.101)
• (2) では、Redis 3.0.0 RC1 (version 2.9.101)とRedis 3.0.0 beta-3 (Redis 2.9.52)

(1) リシャーディング機能がありがたいという話

以前担当していたアメーバなうというサービスでは、ユーザのタイムラインをRedisのソート済みセットで表現していましたが、ユーザ数の増加に伴うRedisのメモリ使用量の増加に悩まされたりしていました。

同僚のスライドでいうとこんな時期でした。

Redisととあるシステム

Redis Clusterを使うことで、メモリ使用量の増加に対して、マスターを追加してリシャーディングすることが可能です。

なお、Redisのインストール方法は省略します。クラスタの構築から話を始めます。ここでは、redis-node01からredis-node04までの4台を使用します。ドキュメントでは最小構成としてマスター3台、スレーブ3台の6台を推奨していますが、いまはシャーディングの話だけのため4台のみ使用します。

ホスト名	IP
redis-node01	192.168.0.1
redis-node02	192.168.0.2
redis-node03	192.168.0.3
redis-node04	192.168.0.4

ドキュメントによる必要最低限の設定は以下となります。

port 7000
cluster-enabled yes
cluster-config-file nodes.conf
cluster-node-timeout 5000
appendonly yes

この記事では以下の設定で動かしています。

daemonize yes
pidfile /var/run/redis/redis.pid
port 6379
loglevel debug
logfile /var/log/redis/redis.log
maxmemory 8gb
maxmemory-policy allkeys-lru
dbfilename dump.rdb
rdbcompression yes
rdbchecksum yes
save 900 1
save 300 10
save 60 10000
dir /var/lib/redis/
appendonly yes
appendfilename "appendonly.aof"
appendfsync everysec
auto-aof-rewrite-percentage 0
auto-aof-rewrite-min-size 64mb
aof-rewrite-incremental-fsync yes
cluster-enabled yes
cluster-config-file nodes.conf
cluster-node-timeout 15000

プロセスの起動前には、limits.confを変更して起動ユーザのnofileを増やすことや、BGSAVEのためにカーネルパラメータで、vm.overcommit_memory = 1を設定しておくのを忘れずにしましょう。

redis-node01のredisを起動します。

起動時のログ

3174:M 29 Nov 16:08:50.518 * No cluster configuration found, I'm cb32e6cdaa17540aed5a7ed8cfa906effb484691
								_._
					_.-``__ ''-._
			_.-``    `.  `_.  ''-._           Redis 2.9.101 (00000000/0) 64 bit
	.-`` .-```.  ```\/    _.,_ ''-._
(    '      ,       .-`  | `,    )     Running in cluster mode
|`-._`-...-` __...-.``-._|'` _.-'|     Port: 6379
|    `-._   `._    /     _.-'    |     PID: 3174
	`-._    `-._  `-./  _.-'    _.-'
|`-._`-._    `-.__.-'    _.-'_.-'|
|    `-._`-._        _.-'_.-'    |           http://redis.io
	`-._    `-._`-.__.-'_.-'    _.-'
|`-._`-._    `-.__.-'    _.-'_.-'|
|    `-._`-._        _.-'_.-'    |
	`-._    `-._`-.__.-'_.-'    _.-'
			`-._    `-.__.-'    _.-'
					`-._        _.-'
							`-.__.-'

3174:M 29 Nov 16:08:50.529 # Server started, Redis version 2.9.101
3174:M 29 Nov 16:08:50.529 * The server is now ready to accept connections on port 6379
3174:M 29 Nov 16:08:51.519 - 0 clients connected (0 slaves), 1158232 bytes in use

各ノードは初回起動時にNode IDと呼ばれるユニークな文字列が決まります。ログでは"I'm cb32e6cdaa17540aed5a7ed8cfa906effb484691"と表示されていますが、この"cb32e6cdaa17540aed5a7ed8cfa906effb484691"の部分がNode IDです。ノード同士はこのNode IDを用いてお互いを識別します。 自動で生成されるclusterの設定ファイル（この記事ではnodes.conf）にもこのNode IDが記録されています。このファイルは自動で生成されるもので、管理者が変更するものではありません。

クラスタの設定ファイルを見てみましょう。なお、myselfとはredis-node01でファイルを見た場合は、redis-node01のことを示します。

[hoge_user@redis-node01 ~]$ cat /var/lib/redis/nodes.conf
cb32e6cdaa17540aed5a7ed8cfa906effb484691 :0 myself,master - 0 0 0 connected
vars currentEpoch 0 lastVoteEpoch 0

CLUSTER NODESコマンドでもこの情報が確認できます。これ以降、設定ファイルではなく、このコマンドを使って確認をしていきます。

[hoge_user@redis-node01 ~]$ redis-cli cluster nodes
cb32e6cdaa17540aed5a7ed8cfa906effb484691 :6379 myself,master - 0 0 0 connected

redis-node02、redis-node03も同様に起動して、確認します。

[hoge_user@redis-node02 ~]$ redis-cli cluster nodes
b9b102e4bc6cb6e8129c2c4d0c2a5487d3ceec83 :6379 myself,master - 0 0 0 connected

[hoge_user@redis-node03 ~]$ redis-cli cluster nodes
1f9e83b2812b35f501b3ac8fe37e8b14a0d633f1 :6379 myself,master - 0 0 0 connected

この時点では各ノードはお互いを認識していません。 redis-tribユーティリティを使用してクラスタを作成します。

[hoge_user@redis-node01 ~]$ redis-trib.rb create 192.168.0.1:6379 192.168.0.2:6379 192.168.0.3:6379
>>> Creating cluster
Connecting to node 192.168.0.1:6379: OK
Connecting to node 192.168.0.2:6379: OK
Connecting to node 192.168.0.3:6379: OK
>>> Performing hash slots allocation on 3 nodes...
Using 3 masters:
192.168.0.1:6379
192.168.0.2:6379
192.168.0.3:6379
M: cb32e6cdaa17540aed5a7ed8cfa906effb484691 192.168.0.1:6379
	slots:0-5460 (5461 slots) master
M: b9b102e4bc6cb6e8129c2c4d0c2a5487d3ceec83 192.168.0.2:6379
	slots:5461-10922 (5462 slots) master
M: 1f9e83b2812b35f501b3ac8fe37e8b14a0d633f1 192.168.0.3:6379
	slots:10923-16383 (5461 slots) master
Can I set the above configuration? (type 'yes' to accept): 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 192.168.0.1:6379)
M: cb32e6cdaa17540aed5a7ed8cfa906effb484691 192.168.0.1:6379
	slots:0-5460 (5461 slots) master
M: b9b102e4bc6cb6e8129c2c4d0c2a5487d3ceec83 192.168.0.2:6379
	slots:5461-10922 (5462 slots) master
M: 1f9e83b2812b35f501b3ac8fe37e8b14a0d633f1 192.168.0.3:6379
	slots:10923-16383 (5461 slots) master
[OK] All nodes agree about slots configuration.
>>> Check for open slots...
>>> Check slots coverage...
[OK] All 16384 slots covered.

clusterの作成後、CLUSTER INFOで表示されるcluster_stateはokとなります。

CLUSTER INFO

[hoge_user@redis-node01 ~]$ redis-cli cluster info
cluster_state:ok
cluster_slots_assigned:16384
cluster_slots_ok:16384
cluster_slots_pfail:0
cluster_slots_fail:0
cluster_known_nodes:3
cluster_size:3
cluster_current_epoch:3
cluster_my_epoch:1
cluster_stats_messages_sent:384
cluster_stats_messages_received:384

ここでslotというものがでてきます。Redis Clusterはコンシステントハッシュを使っておらず、Hash slotと呼ばれる方法でデータのシャーディングをしています。 slotは全部で16384あって、0-16383まで存在するslotを各マスターが分担して担当することになります。キーとslotの対応は以下の計算できまります。

HASH_SLOT = CRC16(key) mod 16384

この例では以下の担当範囲になっています。

slotのレンジ	担当するマスター
0-5460	redis-node01
5461-10922	redis-node02
10923-16383	redis-node03

16384のslotがあるのですが、16384台までスケールできるかというとそれは難しいようで、推奨では最大1000台程度までとされています。

slotのレンジの担当はCLUSTER NODESコマンドやCLUSTER SLOTSコマンドで確認することができます。

CLUSER NODES

[hoge_user@redis-node01 ~]$ redis-cli cluster nodes
b9b102e4bc6cb6e8129c2c4d0c2a5487d3ceec83 192.168.0.2:6379 master - 0 1417246343455 2 connected 5461-10922
1f9e83b2812b35f501b3ac8fe37e8b14a0d633f1 192.168.0.3:6379 master - 0 1417246344457 3 connected 10923-16383
cb32e6cdaa17540aed5a7ed8cfa906effb484691 192.168.0.1:6379 myself,master - 0 0 1 connected 0-5460

CLUSTER SLOTS

[hoge_user@redis-node01 ~]$ redis-cli cluster slots
1) 1) (integer) 5461
	2) (integer) 10922
	3) 1) "192.168.0.2"
			2) (integer) 6379
2) 1) (integer) 10923
	2) (integer) 16383
	3) 1) "192.168.0.3"
			2) (integer) 6379
3) 1) (integer) 0
	2) (integer) 5460
	3) 1) "192.168.0.1"
			2) (integer) 6379

データが空ではつまらないので、下記のサンプルプログラムなどを使用してデータを追加します。

$ git clone https://github.com/antirez/redis-rb-cluster.git
$ cd redis-rb-cluster/
$ ruby example.rb 192.168.0.1 6379　# 途中で止める場合は Ctrl + C

この例では1000万件登録しました。この時点で各マスターが持っているキー数、消費しているmemoryはこんな感じです。

持っているキーの数

[hoge_user@redis-node01 ~]$ redis-cli info | grep "db.*:key"
db0:keys=3333345,expires=0,avg_ttl=0

[hoge_user@redis-node02 ~]$ redis-cli info | grep "db.*:key"
db0:keys=3333511,expires=0,avg_ttl=0

[hoge_user@redis-node03 ~]$ redis-cli info | grep "db.*:key"
db0:keys=3333145,expires=0,avg_ttl=0

消費しているメモリ量

[hoge_user@redis-node01 ~]$ redis-cli info | grep "used_memory"
used_memory:692506352
used_memory_human:660.43M
used_memory_rss:714514432
used_memory_peak:692514592
used_memory_peak_human:660.43M
used_memory_lua:33792

[hoge_user@redis-node02 ~]$ redis-cli info | grep "used_memory"
used_memory:692531552
used_memory_human:660.45M
used_memory_rss:714526720
used_memory_peak:692565680
used_memory_peak_human:660.48M
used_memory_lua:33792

[hoge_user@redis-node03 ~]$ redis-cli info | grep "used_memory"
used_memory:692426528
used_memory_human:660.35M
used_memory_rss:714518528
used_memory_peak:692426528
used_memory_peak_human:660.35M
used_memory_lua:33792

ここでredis-node04を新たにマスターとして追加してみます。まず、redis-node04のredisを起動させます。次に、redis-tribユーティリティを使ってredis-node04をマスターとしてクラスタに追加します。なお、redis-tribユーティリティではコマンドによっては引数に、クラスタ内の1台を指定する必要があります。ここではredis-node01を指定しています。これ以降も指定が必要な場合は、redis-node01を指定しています。

redis-node04をマスターとして追加

$ redis-trib.rb add-node 192.168.0.4:6379 192.168.0.1:6379
>>> Adding node 192.168.0.4:6379 to cluster 192.168.0.1:6379
Connecting to node 192.168.0.1:6379: OK
Connecting to node 192.168.0.2:6379: OK
Connecting to node 192.168.0.3:6379: OK
>>> Performing Cluster Check (using node 192.168.0.1:6379)
M: cb32e6cdaa17540aed5a7ed8cfa906effb484691 192.168.0.1:6379
	slots:0-5460 (5461 slots) master
	0 additional replica(s)
M: b9b102e4bc6cb6e8129c2c4d0c2a5487d3ceec83 192.168.0.2:6379
	slots:5461-10922 (5462 slots) master
	0 additional replica(s)
M: 1f9e83b2812b35f501b3ac8fe37e8b14a0d633f1 192.168.0.3:6379
	slots:10923-16383 (5461 slots) master
	0 additional replica(s)
[OK] All nodes agree about slots configuration.
>>> Check for open slots...
>>> Check slots coverage...
[OK] All 16384 slots covered.
Connecting to node 192.168.0.4:6379: OK
>>> Send CLUSTER MEET to node 192.168.0.4:6379 to make it join the cluster.
[OK] New node added correctly.

ただしマスターを追加しただけでは、slotの割当ては行われません。

[hoge_user@redis-node01 ~]$ redis-cli cluster nodes
b9b102e4bc6cb6e8129c2c4d0c2a5487d3ceec83 192.168.0.2:6379 master - 0 1417250094749 2 connected 5461-10922
1f9e83b2812b35f501b3ac8fe37e8b14a0d633f1 192.168.0.3:6379 master - 0 1417250095752 3 connected 10923-16383
3c8ab7e14bbd785505e091cdedba2fff1773b6b0 192.168.0.4:6379 master - 0 1417250096753 0 connected
cb32e6cdaa17540aed5a7ed8cfa906effb484691 192.168.0.1:6379 myself,master - 0 0 1 connected 0-5460

redis-tribユーティリティを使ってリシャーディングを行います。マスターは4つとなるので全体の1/4である4096のslotを他の3つのマスターから移動させます。

[hoge_user@redis-node01 ~]$ redis-trib.rb reshard 192.168.0.1:6379
Connecting to node 192.168.0.1:6379: OK
Connecting to node 192.168.0.2:6379: OK
Connecting to node 192.168.0.3:6379: OK
Connecting to node 192.168.0.4:6379: OK
>>> Performing Cluster Check (using node 192.168.0.1:6379)
M: cb32e6cdaa17540aed5a7ed8cfa906effb484691 192.168.0.1:6379
	slots:0-5460 (5461 slots) master
	0 additional replica(s)
M: b9b102e4bc6cb6e8129c2c4d0c2a5487d3ceec83 192.168.0.2:6379
	slots:5461-10922 (5462 slots) master
	0 additional replica(s)
M: 1f9e83b2812b35f501b3ac8fe37e8b14a0d633f1 192.168.0.3:6379
	slots:10923-16383 (5461 slots) master
	0 additional replica(s)
M: 3c8ab7e14bbd785505e091cdedba2fff1773b6b0 192.168.0.4:6379
	slots: (0 slots) master
	0 additional replica(s)
[OK] All nodes agree about slots configuration.
>>> Check for open slots...
>>> Check slots coverage...
[OK] All 16384 slots covered.
How many slots do you want to move (from 1 to 16384)? 4096
What is the receiving node ID? 3c8ab7e14bbd785505e091cdedba2fff1773b6b0
Please enter all the source node IDs.
	Type 'all' to use all the nodes as source nodes for the hash slots.
	Type 'done' once you entered all the source nodes IDs.
Source node #1:all

リシャーディングのプラン（どのslotをどのマスターに新しく担当させるか）が表示されるので、提示されたプランに了承をするとリシャーディングがはじまります。

Ready to move 4096 slots.
	Source nodes:
		M: cb32e6cdaa17540aed5a7ed8cfa906effb484691 192.168.0.1:6379
	slots:0-5460 (5461 slots) master
	0 additional replica(s)
		M: b9b102e4bc6cb6e8129c2c4d0c2a5487d3ceec83 192.168.0.2:6379
	slots:5461-10922 (5462 slots) master
	0 additional replica(s)
		M: 1f9e83b2812b35f501b3ac8fe37e8b14a0d633f1 192.168.0.3:6379
	slots:10923-16383 (5461 slots) master
	0 additional replica(s)
	Destination node:
		M: 3c8ab7e14bbd785505e091cdedba2fff1773b6b0 192.168.0.4:6379
	slots: (0 slots) master
	0 additional replica(s)
	Resharding plan:
		Moving slot 5461 from b9b102e4bc6cb6e8129c2c4d0c2a5487d3ceec83
		Moving slot 5462 from b9b102e4bc6cb6e8129c2c4d0c2a5487d3ceec83
		Moving slot 5463 from b9b102e4bc6cb6e8129c2c4d0c2a5487d3ceec83
		Moving slot 5464 from b9b102e4bc6cb6e8129c2c4d0c2a5487d3ceec83
		Moving slot 5465 from b9b102e4bc6cb6e8129c2c4d0c2a5487d3ceec83
		Moving slot 5466 from b9b102e4bc6cb6e8129c2c4d0c2a5487d3ceec83
		（略）
		Moving slot 12287 from 1f9e83b2812b35f501b3ac8fe37e8b14a0d633f1
Do you want to proceed with the proposed reshard plan (yes/no)? yes
（略）
Moving slot 12286 from 192.168.0.3:6379 to 192.168.0.4:6379: ....................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................
Moving slot 12287 from 192.168.0.3:6379 to 192.168.0.4:6379: ......................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................

リシャーディング後のクラスタは次のようになりました。0-1364、5461-6826、10923-12287の3つのレンジがredis-node04に割当てられたことが確認できます。

slotのレンジ	担当するマスター
1365-5460	redis-node01
6827-10922	redis-node02
12288-16383	redis-node03
0-1364、5461-6826、10923-12287	redis-node04

CLUSTER NODES

[hoge_user@redis-node01 ~]$ redis-cli cluster nodes
b9b102e4bc6cb6e8129c2c4d0c2a5487d3ceec83 192.168.0.2:6379 master - 0 1417252139985 2 connected 6827-10922
1f9e83b2812b35f501b3ac8fe37e8b14a0d633f1 192.168.0.3:6379 master - 0 1417252138983 3 connected 12288-16383
3c8ab7e14bbd785505e091cdedba2fff1773b6b0 192.168.0.4:6379 master - 0 1417252140987 4 connected 0-1364 5461-6826 10923-12287
cb32e6cdaa17540aed5a7ed8cfa906effb484691 192.168.0.1:6379 myself,master - 0 0 1 connected 1365-5460

CLUSTER SLOTS

[hoge_user@redis-node01 ~]$ redis-cli cluster slots
1) 1) (integer) 6827
	2) (integer) 10922
	3) 1) "192.168.0.2"
			2) (integer) 6379
2) 1) (integer) 12288
	2) (integer) 16383
	3) 1) "192.168.0.3"
			2) (integer) 6379
3) 1) (integer) 0
	2) (integer) 1364
	3) 1) "192.168.0.4"
			2) (integer) 6379
4) 1) (integer) 5461
	2) (integer) 6826
	3) 1) "192.168.0.4"
			2) (integer) 6379
5) 1) (integer) 10923
	2) (integer) 12287
	3) 1) "192.168.0.4"
			2) (integer) 6379
6) 1) (integer) 1365
	2) (integer) 5460
	3) 1) "192.168.0.1"
			2) (integer) 6379

キー数やメモリ使用量も確認してみます。

キーの数

[hoge_user@redis-node01 ~]$ redis-cli info | grep "db.*:key"
db0:keys=2500042,expires=0,avg_ttl=0

[hoge_user@redis-node02 ~]$ redis-cli info | grep "db.*:key"
db0:keys=2499800,expires=0,avg_ttl=0

[hoge_user@redis-node03 ~]$ redis-cli info | grep "db.*:key"
db0:keys=2500002,expires=0,avg_ttl=0

[hoge_user@redis-node04 ~]$ redis-cli info | grep "db.*:key"
db0:keys=2500157,expires=0,avg_ttl=0

メモリ使用量

[hoge_user@redis-node01 ~]$  redis-cli info | grep "used_memory"
used_memory:528111728
used_memory_human:503.65M
used_memory_rss:714522624
used_memory_peak:692525568
used_memory_peak_human:660.44M
used_memory_lua:33792

[hoge_user@redis-node02 ~]$  redis-cli info | grep "used_memory"
used_memory:528080672
used_memory_human:503.62M
used_memory_rss:714534912
used_memory_peak:692565680
used_memory_peak_human:660.48M
used_memory_lua:33792

[hoge_user@redis-node03 ~]$  redis-cli info | grep "used_memory"
used_memory:528071008
used_memory_human:503.61M
used_memory_rss:714526720
used_memory_peak:692444856
used_memory_peak_human:660.37M
used_memory_lua:33792

[hoge_user@redis-node04 ~]$  redis-cli info | grep "used_memory"
used_memory:488084528
used_memory_human:465.47M
used_memory_rss:504807424
used_memory_peak:488084528
used_memory_peak_human:465.47M
used_memory_lua:33792

このように1台あたりの担当するslotの数、強いてはメモリ使用量やリクエスト数を減らすことができます。

なお、リシャーディングが終わったらクラスタのチェックも実施しておきましょう。

[hoge_user@redis-node01 ~]$ redis-trib.rb check 192.168.0.1:6379
Connecting to node 192.168.0.1:6379: OK
Connecting to node 192.168.0.2:6379: OK
Connecting to node 192.168.0.3:6379: OK
Connecting to node 192.168.0.4:6379: OK
>>> Performing Cluster Check (using node 192.168.0.1:6379)
M: cb32e6cdaa17540aed5a7ed8cfa906effb484691 192.168.0.1:6379
	slots:1365-5460 (4096 slots) master
	0 additional replica(s)
M: b9b102e4bc6cb6e8129c2c4d0c2a5487d3ceec83 192.168.0.2:6379
	slots:6827-10922 (4096 slots) master
	0 additional replica(s)
M: 1f9e83b2812b35f501b3ac8fe37e8b14a0d633f1 192.168.0.3:6379
	slots:12288-16383 (4096 slots) master
	0 additional replica(s)
M: 3c8ab7e14bbd785505e091cdedba2fff1773b6b0 192.168.0.4:6379
	slots:0-1364,5461-6826,10923-12287 (4096 slots) master
	0 additional replica(s)
[OK] All nodes agree about slots configuration.
>>> Check for open slots...
>>> Check slots coverage...
[OK] All 16384 slots covered.

(2) orphaned masterの判定アルゴリズムが以前検証したときと変わっていたという話

次はサーバのダウンに関するお話です。Redis Clusterにはorphaned masterという考え方があります。orphaned masterとは、スレーブを持たずに稼働しているマスターのことです。冗長性がないため、運用上このorphaned masterがいるとよくない状態です。

このorphaned masterを判定するするアルゴリズムが、以前Beta3で検証したときとRC1では変わっていたためそれについて話します。（正確にはRC1ではなく3.0.0-beta8から変更されたようです。

このあとの話ではredis-node01からnode09、redis2-node01からnode09の18台が登場します。

ホスト名	IP	Redisのバージョン
redis-node0[1-9]	192.168.0.[1-9]	Redis 3.0.0 RC1 (version 2.9.101)
redis2-node0[1-9]	192.168.1.[1-9]	Redis 3.0.0 beta-3 (Redis 2.9.52)

まずは、(1)でredis-node0[1-4]を使って構築したクラスタはそのまま使います。

これらのマスターにredis-node0[5-8]をスレーブとして追加します。スレーブの追加にもredis-tribユーティリティを使用します。

redis-node01にredis-node05をスレーブとして追加

$ redis-trib.rb add-node --slave --master-id cb32e6cdaa17540aed5a7ed8cfa906effb484691 192.168.0.5:6379 192.168.0.1:6379

redis-node02にredis-node06をスレーブとして追加

$ redis-trib.rb add-node --slave --master-id b9b102e4bc6cb6e8129c2c4d0c2a5487d3ceec83 192.168.0.6:6379 192.168.0.1:6379

redis-node03にredis-node07をスレーブとして追加

$ redis-trib.rb add-node --slave --master-id 1f9e83b2812b35f501b3ac8fe37e8b14a0d633f1 192.168.0.7:6379 192.168.0.1:6379

redis-node04にredis-node08をスレーブとして追加

$ redis-trib.rb add-node --slave --master-id 3c8ab7e14bbd785505e091cdedba2fff1773b6b0 192.168.0.8:6379 192.168.0.1:6379

スレーブ追加後のクラスタの状態は次のように変わります。

CLUSTER NODES

[hoge_user@redis-node01 ~]$ redis-cli cluster nodes
64ce4c563c0121404b9feca802c3ce0b90f5bd2f 192.168.0.6:6379 slave b9b102e4bc6cb6e8129c2c4d0c2a5487d3ceec83 0 1417258820361 2 connected
b9b102e4bc6cb6e8129c2c4d0c2a5487d3ceec83 192.168.0.2:6379 master - 0 1417258818858 2 connected 6827-10922
753a4ad737c45ee7576a50563ecffd76e26156da 192.168.0.5:6379 slave cb32e6cdaa17540aed5a7ed8cfa906effb484691 0 1417258821865 1 connected
1f9e83b2812b35f501b3ac8fe37e8b14a0d633f1 192.168.0.3:6379 master - 0 1417258819861 6 connected 12288-16383
7f4c81aa67ad6b782089dcd35a367b0240c14379 192.168.0.8:6379 slave 3c8ab7e14bbd785505e091cdedba2fff1773b6b0 0 1417258816452 4 connected
04e4fbc837d1ccf0ceda5fb6629e6d4f38c9b67d 192.168.0.7:6379 slave 1f9e83b2812b35f501b3ac8fe37e8b14a0d633f1 0 1417258820862 6 connected
3c8ab7e14bbd785505e091cdedba2fff1773b6b0 192.168.0.4:6379 master - 0 1417258817854 4 connected 0-1364 5461-6826 10923-12287
cb32e6cdaa17540aed5a7ed8cfa906effb484691 192.168.0.1:6379 myself,master - 0 0 1 connected 1365-5460

CLUSTER SLOTS

[hoge_user@redis-node01 ~]$ redis-cli cluster slots
1) 1) (integer) 6827
	2) (integer) 10922
	3) 1) "192.168.0.2"
			2) (integer) 6379
	4) 1) "192.168.0.6"
			2) (integer) 6379
2) 1) (integer) 12288
	2) (integer) 16383
	3) 1) "192.168.0.3"
			2) (integer) 6379
	4) 1) "192.168.0.7"
			2) (integer) 6379
3) 1) (integer) 0
	2) (integer) 1364
	3) 1) "192.168.0.4"
			2) (integer) 6379
	4) 1) "192.168.0.8"
			2) (integer) 6379
4) 1) (integer) 5461
	2) (integer) 6826
	3) 1) "192.168.0.4"
			2) (integer) 6379
	4) 1) "192.168.0.8"
			2) (integer) 6379
5) 1) (integer) 10923
	2) (integer) 12287
	3) 1) "192.168.0.4"
			2) (integer) 6379
	4) 1) "192.168.0.8"
			2) (integer) 6379
6) 1) (integer) 1365
	2) (integer) 5460
	3) 1) "192.168.0.1"
			2) (integer) 6379
	4) 1) "192.168.0.5"
			2) (integer) 6379

slotのレンジ	担当するマスター	スレーブ1台目
1365-5460	redis-node01	redis-node05
6827-10922	redis-node02	redis-node06
12288-16383	redis-node03	redis-node07
0-1364、5461-6826、10923-12287	redis-node04	redis-node08

各slotにはマスターとスレーブの2台が存在するようになりました。これで、マスターがダウンしてもスレーブがマスターに昇格することができます。最低限の冗長構成となっていることがわかります。しかしながら各slotはそれぞれ1台ダウンしただけで冗長性が無くなってしまいます。

ここでredis-node04にredis-node09をスレーブとして追加します。

$ redis-trib.rb add-node --slave --master-id 3c8ab7e14bbd785505e091cdedba2fff1773b6b0 192.168.0.9:6379 192.168.0.1:6379

クラスタの状態は次のようになります。

CLUSTER NODES

[hoge_user@redis-node01 ~]$ redis-cli cluster nodes
64ce4c563c0121404b9feca802c3ce0b90f5bd2f 192.168.0.6:6379 slave b9b102e4bc6cb6e8129c2c4d0c2a5487d3ceec83 0 1417259026318 2 connected
b9b102e4bc6cb6e8129c2c4d0c2a5487d3ceec83 192.168.0.2:6379 master - 0 1417259028322 2 connected 6827-10922
263f6ba1e8a916088645375f8a1ca4913ac057e3 192.168.0.9:6379 slave 3c8ab7e14bbd785505e091cdedba2fff1773b6b0 0 1417259030407 4 connected
753a4ad737c45ee7576a50563ecffd76e26156da 192.168.0.5:6379 slave cb32e6cdaa17540aed5a7ed8cfa906effb484691 0 1417259029324 1 connected
1f9e83b2812b35f501b3ac8fe37e8b14a0d633f1 192.168.0.3:6379 master - 0 1417259024314 6 connected 12288-16383
7f4c81aa67ad6b782089dcd35a367b0240c14379 192.168.0.8:6379 slave 3c8ab7e14bbd785505e091cdedba2fff1773b6b0 0 1417259028322 4 connected
04e4fbc837d1ccf0ceda5fb6629e6d4f38c9b67d 192.168.0.7:6379 slave 1f9e83b2812b35f501b3ac8fe37e8b14a0d633f1 0 1417259024815 6 connected
3c8ab7e14bbd785505e091cdedba2fff1773b6b0 192.168.0.4:6379 master - 0 1417259027321 4 connected 0-1364 5461-6826 10923-12287
cb32e6cdaa17540aed5a7ed8cfa906effb484691 192.168.0.1:6379 myself,master - 0 0 1 connected 1365-5460

CLUSTER SLOTS

[hoge_user@redis-node01 ~]$ redis-cli cluster slots
1) 1) (integer) 6827
	2) (integer) 10922
	3) 1) "192.168.0.2"
			2) (integer) 6379
	4) 1) "192.168.0.6"
			2) (integer) 6379
2) 1) (integer) 12288
	2) (integer) 16383
	3) 1) "192.168.0.3"
			2) (integer) 6379
	4) 1) "192.168.0.7"
			2) (integer) 6379
3) 1) (integer) 0
	2) (integer) 1364
	3) 1) "192.168.0.4"
			2) (integer) 6379
	4) 1) "192.168.0.8"
			2) (integer) 6379
	5) 1) "192.168.0.9"
			2) (integer) 6379
4) 1) (integer) 5461
	2) (integer) 6826
	3) 1) "192.168.0.4"
			2) (integer) 6379
	4) 1) "192.168.0.8"
			2) (integer) 6379
	5) 1) "192.168.0.9"
			2) (integer) 6379
5) 1) (integer) 10923
	2) (integer) 12287
	3) 1) "192.168.0.4"
			2) (integer) 6379
	4) 1) "192.168.0.8"
			2) (integer) 6379
	5) 1) "192.168.0.9"
			2) (integer) 6379
6) 1) (integer) 1365
	2) (integer) 5460
	3) 1) "192.168.0.1"
			2) (integer) 6379
	4) 1) "192.168.0.5"
			2) (integer) 6379

slotのレンジ	担当するマスター	スレーブ1台目	スレーブ2台目
1365-5460	redis-node01	redis-node05
6827-10922	redis-node02	redis-node06
12288-16383	redis-node03	redis-node07
0-1364、5461-6826、10923-12287	redis-node04	redis-node08	redis-node09

この構成ではredis-node04とredis-node08に加えて、redis-node09も0-1364、5461-6826、10923-12287のslotを持つようになったため、0-1364、5461-6826、10923-12287のslotの範囲の冗長性が高まったということはわかると思います。

さて、この構成でredis-node03のスレーブであるredis-node07がダウンするとどうなるでしょうか。redis-node07のプロセスをkillしてしばらくするとクラスタは次のような状態になります。

CLUSTER NODES

[hoge_user@redis-node01 ~]$ redis-cli cluster nodes
64ce4c563c0121404b9feca802c3ce0b90f5bd2f 192.168.0.6:6379 slave b9b102e4bc6cb6e8129c2c4d0c2a5487d3ceec83 0 1417259192671 2 connected
b9b102e4bc6cb6e8129c2c4d0c2a5487d3ceec83 192.168.0.2:6379 master - 0 1417259196687 2 connected 6827-10922
263f6ba1e8a916088645375f8a1ca4913ac057e3 192.168.0.9:6379 slave 1f9e83b2812b35f501b3ac8fe37e8b14a0d633f1 0 1417259197424 6 connected
753a4ad737c45ee7576a50563ecffd76e26156da 192.168.0.5:6379 slave cb32e6cdaa17540aed5a7ed8cfa906effb484691 0 1417259193676 1 connected
1f9e83b2812b35f501b3ac8fe37e8b14a0d633f1 192.168.0.3:6379 master - 0 1417259197692 6 connected 12288-16383
7f4c81aa67ad6b782089dcd35a367b0240c14379 192.168.0.8:6379 slave 3c8ab7e14bbd785505e091cdedba2fff1773b6b0 0 1417259191669 4 connected
04e4fbc837d1ccf0ceda5fb6629e6d4f38c9b67d 192.168.0.7:6379 slave,fail 1f9e83b2812b35f501b3ac8fe37e8b14a0d633f1 1417259170906 1417259166600 6 disconnected
3c8ab7e14bbd785505e091cdedba2fff1773b6b0 192.168.0.4:6379 master - 0 1417259194679 4 connected 0-1364 5461-6826 10923-12287
cb32e6cdaa17540aed5a7ed8cfa906effb484691 192.168.0.1:6379 myself,master - 0 0 1 connected 1365-5460

CLUSTER SLOTS

[hoge_user@redis-node01 ~]$ redis-cli cluster slots
1) 1) (integer) 6827
	2) (integer) 10922
	3) 1) "192.168.0.2"
			2) (integer) 6379
	4) 1) "192.168.0.6"
			2) (integer) 6379
2) 1) (integer) 12288
	2) (integer) 16383
	3) 1) "192.168.0.3"
			2) (integer) 6379
	4) 1) "192.168.0.9"
			2) (integer) 6379
3) 1) (integer) 0
	2) (integer) 1364
	3) 1) "192.168.0.4"
			2) (integer) 6379
	4) 1) "192.168.0.8"
			2) (integer) 6379
4) 1) (integer) 5461
	2) (integer) 6826
	3) 1) "192.168.0.4"
			2) (integer) 6379
	4) 1) "192.168.0.8"
			2) (integer) 6379
5) 1) (integer) 10923
	2) (integer) 12287
	3) 1) "192.168.0.4"
			2) (integer) 6379
	4) 1) "192.168.0.8"
			2) (integer) 6379
6) 1) (integer) 1365
	2) (integer) 5460
	3) 1) "192.168.0.1"
			2) (integer) 6379
	4) 1) "192.168.0.5"
			2) (integer) 6379

slotのレンジ	担当するマスター	スレーブ1台目	スレーブ2台目
1365-5460	redis-node01	redis-node05
6827-10922	redis-node02	redis-node06
12288-16383	redis-node03	redis-node07 redis-node09
0-1364、5461-6826、10923-12287	redis-node04	redis-node08	redis-node09

redis-node09がredis-node04のスレーブからredis-node03のスレーブに変わっていることがわかります。redis-node03がorphaned masterと判定されたことで、スレーブを多く持つredis-node04のスレーブのうちredis-node09がredis-node03にマスターを切り替えました。redis-node09のログを見るとその様子が記録されています。

redis-node09のログ

2711:S 29 Nov 20:06:27.840 * FAIL message received from cb32e6cdaa17540aed5a7ed8cfa906effb484691 about 04e4fbc837d1ccf0ceda5fb6629e6d4f38c9b67d
2711:S 29 Nov 20:06:27.900 # Migrating to orphaned master 1f9e83b2812b35f501b3ac8fe37e8b14a0d633f1
2711:S 29 Nov 20:06:27.900 # Connection with master lost.
2711:S 29 Nov 20:06:27.900 * Caching the disconnected master state.
2711:S 29 Nov 20:06:27.900 * Discarding previously cached master state.
2711:S 29 Nov 20:06:28.902 * Connecting to MASTER 192.168.0.3:6379
2711:S 29 Nov 20:06:28.902 * MASTER <-> SLAVE sync started
2711:S 29 Nov 20:06:28.902 * Non blocking connect for SYNC fired the event.
2711:S 29 Nov 20:06:28.903 * Master replied to PING, replication can continue...
2711:S 29 Nov 20:06:28.903 * Partial resynchronization not possible (no cached master)
2711:S 29 Nov 20:06:28.904 * Full resync from master: 83b327f352d1b6be93b5d48962262e4153bb46f6:1415
2711:S 29 Nov 20:06:30.863 * MASTER <-> SLAVE sync: receiving 42205850 bytes from master
2711:S 29 Nov 20:06:31.239 * MASTER <-> SLAVE sync: Flushing old data
2711:S 29 Nov 20:06:37.037 * MASTER <-> SLAVE sync: Loading DB in memory
2711:S 29 Nov 20:07:00.147 * MASTER <-> SLAVE sync: Finished with success

この機能は、同時ダウンに対しては効果はないですが、1台ずつのスレーブのダウンであれば、他のマスターに多くスレーブを追加しておくことで自動的に冗長性を保つようにマスターを変更するというありがたい挙動です。

さて、今回の本題はここからとなります。いまはスレーブのダウンについてお話しましたが、マスターがダウンしたときの挙動がBeta8を境に変わっています。まずは、RC1のバージョンから試すためにredis-node07を起動してクラスタに戻します。

redis-node07が復帰したあとのクラスタは次のようになりました。

CLUSTER NODES

[hoge_user@redis-node01 ~]$ redis-cli cluster nodes
64ce4c563c0121404b9feca802c3ce0b90f5bd2f 192.168.0.6:6379 slave b9b102e4bc6cb6e8129c2c4d0c2a5487d3ceec83 0 1417260052458 2 connected
b9b102e4bc6cb6e8129c2c4d0c2a5487d3ceec83 192.168.0.2:6379 master - 0 1417260052458 2 connected 6827-10922
263f6ba1e8a916088645375f8a1ca4913ac057e3 192.168.0.9:6379 slave 1f9e83b2812b35f501b3ac8fe37e8b14a0d633f1 0 1417260049452 6 connected
753a4ad737c45ee7576a50563ecffd76e26156da 192.168.0.5:6379 slave cb32e6cdaa17540aed5a7ed8cfa906effb484691 0 1417260052959 1 connected
1f9e83b2812b35f501b3ac8fe37e8b14a0d633f1 192.168.0.3:6379 master - 0 1417260046446 6 connected 12288-16383
7f4c81aa67ad6b782089dcd35a367b0240c14379 192.168.0.8:6379 slave 3c8ab7e14bbd785505e091cdedba2fff1773b6b0 0 1417260047949 4 connected
04e4fbc837d1ccf0ceda5fb6629e6d4f38c9b67d 192.168.0.7:6379 slave 1f9e83b2812b35f501b3ac8fe37e8b14a0d633f1 0 1417260050519 6 connected
3c8ab7e14bbd785505e091cdedba2fff1773b6b0 192.168.0.4:6379 master - 0 1417260051457 4 connected 0-1364 5461-6826 10923-12287
cb32e6cdaa17540aed5a7ed8cfa906effb484691 192.168.0.1:6379 myself,master - 0 0 1 connected 1365-5460

CLUSTER SLOTS

[hoge_user@redis-node01 ~]$ redis-cli cluster slots
1) 1) (integer) 6827
	2) (integer) 10922
	3) 1) "192.168.0.2"
			2) (integer) 6379
	4) 1) "192.168.0.6"
			2) (integer) 6379
2) 1) (integer) 12288
	2) (integer) 16383
	3) 1) "192.168.0.3"
			2) (integer) 6379
	4) 1) "192.168.0.7"
			2) (integer) 6379
	5) 1) "192.168.0.9"
			2) (integer) 6379
3) 1) (integer) 0
	2) (integer) 1364
	3) 1) "192.168.0.4"
			2) (integer) 6379
	4) 1) "192.168.0.8"
			2) (integer) 6379
4) 1) (integer) 5461
	2) (integer) 6826
	3) 1) "192.168.0.4"
			2) (integer) 6379
	4) 1) "192.168.0.8"
			2) (integer) 6379
5) 1) (integer) 10923
	2) (integer) 12287
	3) 1) "192.168.0.4"
			2) (integer) 6379
	4) 1) "192.168.0.8"
			2) (integer) 6379
6) 1) (integer) 1365
	2) (integer) 5460
	3) 1) "192.168.0.1"
			2) (integer) 6379
	4) 1) "192.168.0.5"
			2) (integer) 6379

slotのレンジ	担当するマスター	スレーブ1台目	スレーブ2台目
1365-5460	redis-node01	redis-node05
6827-10922	redis-node02	redis-node06
12288-16383	redis-node03	redis-node09	redis-node07
0-1364、5461-6826、10923-12287	redis-node04	redis-node08

redis-node03のマスターに複数台のスレーブがいます。この状態で別のマスターであるredis-node02をダウンさせてみます。するとこのような状態になります。

CLUSER NODES

[hoge_user@redis-node01 ~]$ redis-cli cluster nodes
64ce4c563c0121404b9feca802c3ce0b90f5bd2f 192.168.0.6:6379 master - 0 1417314114231 16 connected 6827-10922
b9b102e4bc6cb6e8129c2c4d0c2a5487d3ceec83 192.168.0.2:6379 master,fail - 1417314026125 1417314019913 11 disconnected
753a4ad737c45ee7576a50563ecffd76e26156da 192.168.0.5:6379 slave cb32e6cdaa17540aed5a7ed8cfa906effb484691 0 1417314113226 1 connected
1f9e83b2812b35f501b3ac8fe37e8b14a0d633f1 192.168.0.3:6379 master - 0 1417314115233 6 connected 12288-16383
67db87881ef99f37579fe26cc817e575d95c5a56 192.168.0.9:6379 slave 1f9e83b2812b35f501b3ac8fe37e8b14a0d633f1 0 1417314112220 6 connected
7f4c81aa67ad6b782089dcd35a367b0240c14379 192.168.0.8:6379 slave 3c8ab7e14bbd785505e091cdedba2fff1773b6b0 0 1417314110216 15 connected
04e4fbc837d1ccf0ceda5fb6629e6d4f38c9b67d 192.168.0.7:6379 slave 1f9e83b2812b35f501b3ac8fe37e8b14a0d633f1 0 1417314115733 6 connected
3c8ab7e14bbd785505e091cdedba2fff1773b6b0 192.168.0.4:6379 master - 0 1417314116234 15 connected 0-1364 5461-6826 10923-12287
cb32e6cdaa17540aed5a7ed8cfa906effb484691 192.168.0.1:6379 myself,master - 0 0 1 connected 1365-5460

※connect数は無視してください

CLUSER SLOTS

[hoge_user@redis-node01 ~]$ redis-cli cluster slots
1) 1) (integer) 6827
	2) (integer) 10922
	3) 1) "192.168.0.6"
			2) (integer) 6379
2) 1) (integer) 12288
	2) (integer) 16383
	3) 1) "192.168.0.3"
			2) (integer) 6379
	4) 1) "192.168.0.7"
			2) (integer) 6379
	5) 1) "192.168.0.9"
			2) (integer) 6379
3) 1) (integer) 0
	2) (integer) 1364
	3) 1) "192.168.0.4"
			2) (integer) 6379
	4) 1) "192.168.0.8"
			2) (integer) 6379
4) 1) (integer) 5461
	2) (integer) 6826
	3) 1) "192.168.0.4"
			2) (integer) 6379
	4) 1) "192.168.0.8"
			2) (integer) 6379
5) 1) (integer) 10923
	2) (integer) 12287
	3) 1) "192.168.0.4"
			2) (integer) 6379
	4) 1) "192.168.0.8"
			2) (integer) 6379
6) 1) (integer) 1365
	2) (integer) 5460
	3) 1) "192.168.0.1"
			2) (integer) 6379
	4) 1) "192.168.0.5"
			2) (integer) 6379

slotのレンジ	担当するマスター	スレーブ1台目	スレーブ2台目
1365-5460	redis-node01	redis-node05
6827-10922	redis-node02 redis-node06	redis-node06
12288-16383	redis-node03	redis-node09	redis-node07
0-1364、5461-6826、10923-12287	redis-node04	redis-node08

redis-node06がマスターに昇格したもののスレーブのいないマスターとなってしまいました。6827-10922のslotは冗長性がなくなっています。

では、Beta8より前のバージョンではどういう挙動だったか確認をします。ここではredis2-node[0-9]を使って、Beta3のクラスタを構築しました。redis2-node04には、redis2-node08とredis2-node09の2つのスレーブを作ってあります。なお、CLUSTER SLOTSコマンドはこのバージョンでは存在しません。

CLUSTER NODES

[hoge_user@redis2-node01 ~]$ redis-cli cluster nodes
3984a3502e09133c61e99958b8f4689539ae989d 192.168.1.2:6379 master - 0 1417307758036 1 connected 6827-10922
03de4dcdaafd763b578c5407196ace595ae7dad8 :0 myself,master - 0 0 2 connected 1365-5460
80669807941510b572c2e4acf02d3e55cb3fd92a 192.168.1.8:6379 slave 2a19e4f22ffc736b8614a0204ed7173c8137b327 0 1417307754029 3 connected
b872eab4f8bffe270c6b4b9538a7eaa839e381a5 192.168.1.5:6379 slave 03de4dcdaafd763b578c5407196ace595ae7dad8 0 1417307755032 2 connected
c2be4be4922124aeeada69bc34f3dcd1595c844c 192.168.1.6:6379 slave 3984a3502e09133c61e99958b8f4689539ae989d 0 1417307752525 1 connected
2a19e4f22ffc736b8614a0204ed7173c8137b327 192.168.1.4:6379 master - 0 1417307753527 3 connected 0-1364 5461-6826 10923-12287
02b93adfb381ce611d0619a7805716208dcc2e70 192.168.1.9:6379 slave 2a19e4f22ffc736b8614a0204ed7173c8137b327 0 1417307756032 3 connected
532f8b23172f290c74b2752a303641ff8ca816bd 192.168.1.3:6379 master - 0 1417307756533 0 connected 12288-16383
ed4a0b13657711601dade0d3bb13e4c8388e624b 192.168.1.7:6379 slave 532f8b23172f290c74b2752a303641ff8ca816bd 0 1417307757034 0 connected

slotのレンジ	担当するマスター	スレーブ1台目	スレーブ2台目
1365-5460	redis2-node01	redis2-node05
6827-10922	redis2-node02	redis2-node06
12288-16383	redis2-node03	redis2-node07
0-1364、5461-6826、10923-12287	redis2-node04	redis2-node08	redis2-node09

reds2-node02をダウンさせてみます。まずはredis2-node06がマスターに昇格します。

CLUSTER NODES

[hoge_user@redis2-node01 ~]$ redis-cli cluster nodes
3984a3502e09133c61e99958b8f4689539ae989d 192.168.1.2:6379 master,fail - 1417307816351 1417307814149 1 disconnected
03de4dcdaafd763b578c5407196ace595ae7dad8 :0 myself,master - 0 0 2 connected 1365-5460
80669807941510b572c2e4acf02d3e55cb3fd92a 192.168.1.8:6379 slave 2a19e4f22ffc736b8614a0204ed7173c8137b327 0 1417307839236 3 connected
b872eab4f8bffe270c6b4b9538a7eaa839e381a5 192.168.1.5:6379 slave 03de4dcdaafd763b578c5407196ace595ae7dad8 0 1417307838232 2 connected
c2be4be4922124aeeada69bc34f3dcd1595c844c 192.168.1.6:6379 master - 0 1417307834219 5 connected 6827-10922
2a19e4f22ffc736b8614a0204ed7173c8137b327 192.168.1.4:6379 master - 0 1417307837230 3 connected 0-1364 5461-6826 10923-12287
02b93adfb381ce611d0619a7805716208dcc2e70 192.168.1.9:6379 slave 2a19e4f22ffc736b8614a0204ed7173c8137b327 0 1417307834721 3 connected
532f8b23172f290c74b2752a303641ff8ca816bd 192.168.1.3:6379 master - 0 1417307835224 0 connected 12288-16383
ed4a0b13657711601dade0d3bb13e4c8388e624b 192.168.1.7:6379 slave 532f8b23172f290c74b2752a303641ff8ca816bd 0 1417307837730 0 connected

slotのレンジ	担当するマスター	スレーブ1台目	スレーブ2台目
1365-5460	redis2-node01	redis2-node05
6827-10922	redis2-node02 redis2-node06	redis2-node06
12288-16383	redis2-node03	redis2-node07
0-1364、5461-6826、10923-12287	redis2-node04	redis2-node08	redis2-node09

その後、reds2-node06がorphaned masterとなるので、redis2-node09がスレーブとなります。

[hoge_user@redis2-node01 ~]$ redis-cli cluster nodes
3984a3502e09133c61e99958b8f4689539ae989d 192.168.1.2:6379 master,fail - 1417307816351 1417307814149 1 disconnected
03de4dcdaafd763b578c5407196ace595ae7dad8 :0 myself,master - 0 0 2 connected 1365-5460
80669807941510b572c2e4acf02d3e55cb3fd92a 192.168.1.8:6379 slave 2a19e4f22ffc736b8614a0204ed7173c8137b327 0 1417307839236 3 connected
b872eab4f8bffe270c6b4b9538a7eaa839e381a5 192.168.1.5:6379 slave 03de4dcdaafd763b578c5407196ace595ae7dad8 0 1417307838232 2 connected
c2be4be4922124aeeada69bc34f3dcd1595c844c 192.168.1.6:6379 master - 0 1417307840237 5 connected 6827-10922
2a19e4f22ffc736b8614a0204ed7173c8137b327 192.168.1.4:6379 master - 0 1417307837230 3 connected 0-1364 5461-6826 10923-12287
02b93adfb381ce611d0619a7805716208dcc2e70 192.168.1.9:6379 slave c2be4be4922124aeeada69bc34f3dcd1595c844c 0 1417307834721 5 connected
532f8b23172f290c74b2752a303641ff8ca816bd 192.168.1.3:6379 master - 0 1417307835224 0 connected 12288-16383
ed4a0b13657711601dade0d3bb13e4c8388e624b 192.168.1.7:6379 slave 532f8b23172f290c74b2752a303641ff8ca816bd 0 1417307837730 0 connected

slotのレンジ	担当するマスター	スレーブ1台目	スレーブ2台目
1365-5460	redis2-node01	redis2-node05
6827-10922	redis2-node02 redis2-node06	redis2-node06 redis2-node09
12288-16383	redis2-node03	redis2-node07
0-1364、5461-6826、10923-12287	redis2-node04	redis2-node08	redis2-node09

個人的にはこのBeta3での挙動のほうが好みです。

Githubでコードの変更を追ってみると、orphaned masterの判定の条件が1つ増えていることがわかります。

Beta3での条件式

https://github.com/antirez/redis/blob/3.0.0-beta3/src/cluster.c#L2742

RC1での条件式（正確にはBeta8から変更されています）

https://github.com/antirez/redis/blob/3.0.0-rc1/src/cluster.c#L3006-L3010

当該コミット

https://github.com/antirez/redis/commit/c5bd330f9ec700a2e42d4b70d7cb0833920f8454#diff-bd24e7e53a0479358a1ef2fc2fe7af66

過去に1つもスレーブを持ったことの無いマスターはorphaned masterと判定されなくなったようです。 昇格したばかりのマスターは過去にスレーブを持っていたわけではないのでokslaveは0でも、node->numslavesが0のため、orphaned masterと判定されないようです。

実はBeta3のときにとあるシステムでRedis Clusterを導入して半年くらい稼働しています。

マスター3台、スレーブ6台の9台構成で動かしています。Stableになったら置き換えようという話を以前チームでしていたのですが…どうしようかな！

以前検証された方は罠にはまるかもしれないですよというお話でした。では！