雑文発散

«前の日記(2014-11-13) 最新 次の日記(2014-11-15)» 編集
過去の日記

2014-11-14 [長年日記]

[Elasticsearch] Elasticsearch のスナップショットからデータをリストアする

昨日の「そういえば Elasticsearch のバックアップ・リストアってどうなんだっけ?」からの続き。

スナップショットの取得はできたけど、そいつのリストアについては試していなかったので、やってみる。

スナップショットを取得する

現時点での webindex のドキュメント数を見ておこう。220 レコードだ。

% c`url -XGET 'http://localhost:9200/_cat/count/webindex'
1415918806 07:46:46 220

あれ、そんなもんかな。もっと日記の数は多いと思うけど。。。あ、もしかして、maxAccessCount を 200 にしていたから、そいつで制限かかってるのかな。これは別の話として調べよう。

じゃあ、スナップショットを取得する。対象のインデックスは webindex のみにしておく。

$ curl -XPUT 'http://localhost:9200/_snapshot/backup/snapshot_3' -d @snapshot_webindex.json
{"accepted":true}

snapshot_webindex.json の中身については、昨日と同じ。

{
  "indices": "webindex"
}

取得できたかどうかの確認。

% curl -XGET 'http://localhost:9200/_snapshot/backup/snapshot_3?pretty'
{
  "snapshots" : [ {
    "snapshot" : "snapshot_3",
    "indices" : [ "webindex" ],
    "state" : "SUCCESS",
    "start_time" : "2014-11-13T23:03:04.236Z",
    "start_time_in_millis" : 1415919784236,
    "end_time" : "2014-11-13T23:03:09.182Z",
    "end_time_in_millis" : 1415919789182,
    "duration_in_millis" : 4946,
    "failures" : [ ],
    "shards" : {
      "total" : 5,
      "failed" : 0,
      "successful" : 5
    }
  } ]
}

成功(SUCCESS)している。

インデックスを削除する

では、インデックス webindex の削除していく。うまく削除できたのか?を確認するために、まずは存在を cat API で確認しておく。

% curl -XGET 'http://localhost:9200/_cat/indices/webindex'
yellow webindex 5 1 229 28 4.3mb 4.3mb

削除の実行。

% curl -XDELETE 'http://localhost:9200/webindex'
{"acknowledged":true}

削除されたかを確認。

% curl -XGET 'http://localhost:9200/_cat/indices/webindex'
【何も出力されない】

無事に削除された模様。

リストアを実行する

ではスナップショットからのリストアを試してみる。普通にやると全てのインデックスをリストアする動作になるそうなので、ここでもインデックス名を指定してやる。

あと、どうやら「一部のみ」を対象にする場合は、indices でインデックスを指定する他に、ingore_unavailableinclude_global_state も設定しておいた方が良いみたいだな。リストアだけでなく、スナップショットの取得時にも設定した方が良さそうなので、こういう指定にしてみる。

{
  "indices": "webindex",
  "ignore_unavailable": true,
  "include_global_state": false
}

マニュアルに載っているサンプルだと、ignore_unavailable の値が "true" となっているんだけど、、、これ文字列としての "true" なのかなぁ?

なんか違う気がするので、自分では文字列ではなく、boolean の true として実行してみよう。

% curl -XPOST 'http://localhost:9200/_snapshot/backup/snapshot_3/_restore' -d @snapshot_webindex.json
{"accepted":true}

リストアの実行は、取得したスナップショットの URL の最後に _restore を付けて、POST するみたいだ。ここは PUT じゃなくて POST なんだな。なんでだろう。。。

この実行そのものは、URL のオブジェクト(?)に対して直接影響を与えるものではないから?なのかな。たぶん、REST の思想をいまひとつ理解していないからピンとこないんだな、きっと。ここも自分の課題だな。

リストア後の状態を見てみる

インデックス webindex の存在確認をしてみると、存在していた。

% curl -XGET 'http://localhost:9200/_cat/indices/webindex'
yellow webindex 5 1 231 23 2mb 2mb

ステータスが yellow なのは、レプリケーションされていないから。1台でテストしているので、これは仕方ない。

リストア中の表示は(見れていなかったけど)、ここが red になるらしい。存在はしているけど、まだ使えない状態。通常であれば、red → yellow → green と変わっていくようだ。

次はインデックス内のドキュメント数を調べてみる。

% curl -XGET 'http://localhost:9200/_cat/count/webindex'
1415922689 08:51:29 231

231 になっていた。あれ、最初は 220 だったはず。。。

あ、Web クローラーを止めてなかったので、もしかしたらインデックスがリストアされた後でドキュメントが追加されてしまったのかも。。。

検索もしてみよう。クローラーを設定した時と同じクエリで試してみる。

% curl -XGET 'http://localhost:9200/webindex/suzuki_tdiary_net/_search?q=title:elasticsearch&fields=title&pretty=true'

結果もちゃんと出てきた。昨日の日記のタイトル「そういえば Elasticsearch のバックアップ・リストアってどうなんだっけ? - 雑文発散(2014-11-13)」もデータとして入っているね。

これでバックアップ+リストアの基本的な流れは把握できた気がする。