其实某种意义上Elasticsearch也可以认为是一种noSQL数据库,我们的产品把他作为日志存储使用,于是自然而然就有了备份的需求。
21世纪还有公司这么玩,我也是醉了。
备份:
curl -X PUT "http://127.0.0.1:9200/_snapshot/log_backup" -d '{"type":"fs","settings":{"location":"/tmp/logb/"}}'
curl -X DELETE "http://127.0.0.1:9200/_snapshot/log_backup/back1"
curl -X PUT "http://127.0.0.1:9200/_snapshot/log_backup/back1?wait_for_completion=true" -d '{"indices":"runlog","ignore_unavailable":"true"}'
- 第一句:建立一个备份
- 第二句:删掉现有的备份,其实这一步是可选的,但是这是个自动化的脚本,所以在备份之前,就把之前的备份无条件删掉了
- 第三句:执行备份,备份index为runlog
恢复:
curl -X PUT "http://127.0.0.1:9200/_snapshot/itemlog_backup" -d '{"type":"fs","settings":{"location":"/tmp/logb/"}}'
curl -X POST "http://127.0.0.1:9200/runlog/_close"
curl -X POST "http://127.0.0.1:9200/_snapshot/log_backup/back1/_restore" -d '{"indices":"runlog"}'
curl -X POST "http://127.0.0.1:9200/runlog/_open"
- 第一句:建立一个备份,其实这一步应该也是可选的,只是为了防止备份不存在导致报错
- 第二句:关掉索引
- 第三局:执行恢复
- 第四句:开启索引
如果不执行_close和_open,则会报如下错误:
{
"error": "SnapshotRestoreException[[log_backup:back1] cannot restore index [runlog] because it's open]",
"status": 500
}