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

#やること
[前回](http://qiita.com/jun-1/items/11edfe8fae71a3e958ce)作ったElasticsearchのノードを上げ下げしてクラスタの動作を試してみます

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

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

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

```bash: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](https://qiita-image-store.s3.amazonaws.com/0/46832/c78d7f25-184e-11ca-32a6-9e80cf336b07.png)

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

```bash:CoreOS
curl -XPUT 'http://localhost:9201/twitter/tweet/1' -d '{
    "message" : "update from es1"
}' 
```
_versionが2になりました。

```json
{"_index":"twitter","_type":"tweet","_id":"1","_version":2,"created":false}
```

es2、es3にも変更が反映されています。

```bash:CoreOS
curl -XGET 'http://localhost:9202/twitter/tweet/1' 
```
```bash:CoreOS
curl -XGET 'http://localhost:9203/twitter/tweet/1'
```

```json
{"_index":"twitter","_type":"tweet","_id":"1","_version":2,"found":true,"_source":{
    "message" : "update from es1"
}}
```

#nodeを落としてみる

```bash:CoreOS
docker stop es2
```

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

![es2_down.png](https://qiita-image-store.s3.amazonaws.com/0/46832/d9d422ff-0e6f-5f8c-e3fa-5c480b6b207e.png)

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

![es2_down2.png](https://qiita-image-store.s3.amazonaws.com/0/46832/ef57fece-0f42-d3a7-e3d2-1add37db837c.png)

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

```bash:CoreOS
docker stop es1
```
```bash:CoreOS
curl -XPUT 'http://localhost:9203/twitter/tweet/1' -d '{
    "message" : "update from es3"
}'
```

更新されて_versionが3になりました。

```json
{"_index":"twitter","_type":"tweet","_id":"1","_version":3,"created":false}
```

続いてes3も落としてからes1,es2を上げてみます。

```bash:CoreOS
docker stop es3
```
```bash:CoreOS
docker start es1
```
```bash:CoreOS
docker start es2
```

こんな感じになりました。
![es12_recover.png](https://qiita-image-store.s3.amazonaws.com/0/46832/789d2d88-1893-dd38-7b7c-320d4400cc47.png)

この状態で検索すると
```bash:CoreOS
curl -XGET 'http://localhost:9201/twitter/tweet/1'
```

es1、es2は更新された時落ちていたので_versionは2のままです。

```json
{"_index":"twitter","_type":"tweet","_id":"1","_version":2,"found":true,"_source":{
    "message" : "update from es1"
}}
```

es3も復帰させます

```bash:CoreOS
docker start es3
```

もう一度検索すると

```bash:CoreOS
curl -XGET 'http://localhost:9203/twitter/tweet/1'
```
```json
{"_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の更新結果

```json
{"_index":"twitter","_type":"tweet","_id":"1","_version":3,"created":false}
```

es2の_versionはもちろん2

```json
{"_index":"twitter","_type":"tweet","_id":"1","_version":2,"found":true,"_source":{
    "message" : "update from es1"
}
```

es3は…

```json
{"_index":"twitter","_type":"tweet","_id":"1","_version":2,"found":true,"_source":{
    "message" : "update from es1"
}
```

**_version 2**

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

![es23_recover.png](https://qiita-image-store.s3.amazonaws.com/0/46832/579f40a8-8816-5d5a-eccb-fc11a824f5a2.png)

es2のshard2がプライマリでes3はレプリカだからから、マスタのデータが反映されるのかな

[ドキュメント](http://www.elasticsearch.org/guide/en/elasticsearch/guide/current/_add_an_index.html)にも

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