昨日の「そういえば 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_unavailable
や include_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)」もデータとして入っているね。
これでバックアップ+リストアの基本的な流れは把握できた気がする。