ElasticSearchやらかし記録

トラブルの原因

AWSで開発機１のAMI作成する。
AMIから別インスタンス（開発機２）を作る。
＼(^o^)／クラスタに自動追加されてシャーディングされる。
※Elasticsearchのバージョンは1.7.5。2.x系では自動でノード追加されないためこの現象は発生しない。
教訓：AMIからインスタンスを作る時はセキュリティグループを分けて別ネットワーク扱いにして作った後、設定変更してから同一セキュリティグループに入れる。

開発機２のクラスタ名を変えてElasticSearch再起動
開発機１のElasticSearchのステータスがRedに！＼(^o^)／
開発機２はNoIndexに。
　＊クラスタとIndexがひも付けされてるのね。

とりあえず、Redステータスから回復させる（注意：間違ってます）

＊localhostではなく、プライベートIP(esmaster)でサービス稼働している。
curl -XGET http://esmaster:9200/_cat/shards
で
UNASSIGNED
になっているShardに対して

curl -XPOST 'esmaster:9200/_cluster/reroute' -d '{
    "commands": [{
        "allocate": {
            "index": "インデックス名",
            "shard": 1,
            "node": "gCPHfxxpTeim4DA8AFhESg",　＊Nodes Statでnodesで表示されるやつor「node.name」
            "allow_primary": 1
        }
    }]
}'

を実行していく。
これをやるとStatusはGreenになるが、データは無い状態になる。
結果、今まで５／５持ってたデータが２～３／５になる。
・・・あっかーん＼(^o^)／
Shardはデータの分割単位。コピーはReplica！

正しくは開発機２を同一クラスタに戻した状態からmoveコマンドでShardのノードを移動させないといけなかった。
https://www.elastic.co/guide/en/elasticsearch/reference/current/cluster-reroute.html

curl -XPUT 'esmaster:9200/_cluster/settings' -d '{
  "persistent": {
    "cluster.routing.allocation.enable": "none"
  }
}'

curl -XPUT 'esmaster:9200/_cluster/settings' -d '{
  "persistent": {
    "cluster.routing.allocation.enable": "all"
  }
}'

移動前にルーティングを止めて、移動作業が終わってノードを切り離したら再開させる操作も必要。

結局

Zookeeperのデータも壊れてテーブルが無い（hbase shellのlistコマンドで見えない）のに
org.apache.hadoop.hbase.TableExistsExceptionが発生するようになり、
ググッた情報を実行しても直らないので
hbase.zookeeper.property.dataDir
のパスを変更して対応。

こういう面倒くさいことになるので、AMIからのインスタンス作成時は気をつけましょう。