やること
前回作ったElasticsearchのノードを上げ下げしてクラスタの動作を試してみます
コンテナにタグを付ける
念のため、今の時点に戻せるようにタグを付けてコミットしておきます。
docker commit es1 trial/elasticsearch:es1
docker commit es2 trial/elasticsearch:es2
docker commit es3 trial/elasticsearch:es3
するとこんなかんじになります。
docker images
REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE
trial/elasticsearch es3 d43217d45f7a 12 seconds ago 1.053 GB
trial/elasticsearch es2 7953b31c5dc5 24 seconds ago 1.053 GB
trial/elasticsearch es1 0a370f5374cd 45 seconds ago 1.053 GB
trial/elasticsearch latest 9fff2c9d245d 5 hours ago 1.053 GB
dockerfile/elasticsearch latest 9677843d1d34 2 weeks ago 1.051 GB
クラスタの状況
前回登録したデータはshard 2 に入っているようです。
更新してみる
shard 2 はes3にマスター、es2にレプリカがあるので、es1に対して更新クエリを投げてみます。
curl -XPUT 'http://localhost:9201/twitter/tweet/1' -d '{
"message" : "update from es1"
}'
_versionが2になりました。
{"_index":"twitter","_type":"tweet","_id":"1","_version":2,"created":false}
es2、es3にも変更が反映されています。
curl -XGET 'http://localhost:9202/twitter/tweet/1'
curl -XGET 'http://localhost:9203/twitter/tweet/1'
{"_index":"twitter","_type":"tweet","_id":"1","_version":2,"found":true,"_source":{
"message" : "update from es1"
}}
nodeを落としてみる
docker stop es2
es2の持っていたレプリカがなくなったので、一旦cluster healthがredになりますが
その後、es1とes3に再配置されました
さらにes1も落としてから、データを更新してみます。
docker stop es1
curl -XPUT 'http://localhost:9203/twitter/tweet/1' -d '{
"message" : "update from es3"
}'
更新されて_versionが3になりました。
{"_index":"twitter","_type":"tweet","_id":"1","_version":3,"created":false}
続いてes3も落としてからes1,es2を上げてみます。
docker stop es3
docker start es1
docker start es2
こんな感じになりました。
この状態で検索すると
bash:CoreOS
curl -XGET 'http://localhost:9201/twitter/tweet/1'
es1、es2は更新された時落ちていたので_versionは2のままです。
{"_index":"twitter","_type":"tweet","_id":"1","_version":2,"found":true,"_source":{
"message" : "update from es1"
}}
es3も復帰させます
docker start es3
もう一度検索すると
curl -XGET 'http://localhost:9203/twitter/tweet/1'
{"_index":"twitter","_type":"tweet","_id":"1","_version":2,"found":true,"_source":{
"message" : "update from es1"
}
_version:2 !?
es3への更新が巻き戻ってる
不整合が起きた場合は多数決で決まったりする?
落とし方を変えて実験
実験方法
- es1、es2を落とす
- es3を更新
- es3を落とす
- es2を復帰
- es3を復帰
- 検索
es3の更新結果
{"_index":"twitter","_type":"tweet","_id":"1","_version":3,"created":false}
es2の_versionはもちろん2
{"_index":"twitter","_type":"tweet","_id":"1","_version":2,"found":true,"_source":{
"message" : "update from es1"
}
es3は…
{"_index":"twitter","_type":"tweet","_id":"1","_version":2,"found":true,"_source":{
"message" : "update from es1"
}
_version 2
てことは、今こうなってるから
es2のshard2がプライマリでes3はレプリカだからから、マスタのデータが反映されるのかな
ドキュメントにも
A replica shard is just a copy of a primary shard. Replicas are used to provide redundant copies of your data to protect against hardware failure, and to serve read requests like searching or retrieving a document.
レプリカは単なるプライマリのコピーって書いてあるしそういうことかな。
まとめ
- プライマリとレプリカのデータが整合性がとれていない場合はプライマリが優先される(と思う)
- Docker便利!!