Dockerで簡単にElasticsearchのクラスタを試してみる 2

  • 13
    いいね
  • 0
    コメント
この記事は最終更新日から1年以上が経過しています。

やること

前回作ったElasticsearchのノードを上げ下げしてクラスタの動作を試してみます

コンテナにタグを付ける

念のため、今の時点に戻せるようにタグを付けてコミットしておきます。

CoreOS
docker commit es1 trial/elasticsearch:es1
CoreOS
docker commit es2 trial/elasticsearch:es2
CoreOS
docker commit es3 trial/elasticsearch:es3

するとこんなかんじになります。

CoreOS
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 に入っているようです。

cluster.png

更新してみる

shard 2 はes3にマスター、es2にレプリカがあるので、es1に対して更新クエリを投げてみます。

CoreOS
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にも変更が反映されています。

CoreOS
curl -XGET 'http://localhost:9202/twitter/tweet/1' 
CoreOS
curl -XGET 'http://localhost:9203/twitter/tweet/1'
{"_index":"twitter","_type":"tweet","_id":"1","_version":2,"found":true,"_source":{
    "message" : "update from es1"
}}

nodeを落としてみる

CoreOS
docker stop es2

es2の持っていたレプリカがなくなったので、一旦cluster healthがredになりますが

es2_down.png

その後、es1とes3に再配置されました

es2_down2.png

さらにes1も落としてから、データを更新してみます。

CoreOS
docker stop es1
CoreOS
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を上げてみます。

CoreOS
docker stop es3
CoreOS
docker start es1
CoreOS
docker start es2

こんな感じになりました。
es12_recover.png

この状態で検索すると
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も復帰させます

CoreOS
docker start es3

もう一度検索すると

CoreOS
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への更新が巻き戻ってる

不整合が起きた場合は多数決で決まったりする?

落とし方を変えて実験

実験方法

  1. es1、es2を落とす
  2. es3を更新
  3. es3を落とす
  4. es2を復帰
  5. es3を復帰
  6. 検索

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

てことは、今こうなってるから

es23_recover.png

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便利!!