ES备份

Elasticsearch的备份和恢复

Posted in 后端 By KeenWon On 2014年12月10日 Views: 15,156

距离上次讲Elasticsearch的安装已经快一个半月了，做为一个半路出家的前端开发，简单的使用中也体验到了Elasticsearch的强大。目前在一个本身开发的小站点中，使用Elasticsearch索引了近200W简单数据，占用资源极小，搜索速度极快。下一步打算优化一下分词（目前使用的是标准分词器），因此想先备份一下，因而有了今天的文章。

 

备份

Elasticsearch的一大特色就是使用简单，api也比较强大，备份也不例外。简单来讲，备份分两步：一、建立一个仓库。二、备份指定索引。下面一步一步来：

 

一、建立一个仓库（creating the repository）

备份数据以前，要建立一个仓库来保存数据，仓库的类型支持Shared filesystem, Amazon S3, HDFS和Azure Cloud。下面以文件系统为例：

 

1. PUT http://127.0.0.1:9200/_snapshot/my_backup
2. {
3. "type": "fs",
4. "settings": {
5. "location": "/mount/backups/my_backup"
6. }
7. }

 

上面的代码，咱们建立了一个名叫my_backup 的备份，存放在本地的/mount/backups/my_backup 目录下。除了location 参数外，还能够经过max_snapshot_bytes_per_sec 和max_restore_bytes_per_sec 来限制备份和恢复时的速度，以下：

 

1. POST http://127.0.0.1:9200/_snapshot/my_backup/
2. {
3. "type": "fs",
4. "settings": {
5. "location": "/mount/backups/my_backup",
6. "max_snapshot_bytes_per_sec" : "50mb",
7. "max_restore_bytes_per_sec" : "50mb"
8. }
9. }

 

注意：第一段代码用的是PUT 请求，用来建立repository，第二段代码用的是POST 请求，来修改已经存在的repository。

 

二、备份索引

仓库建立好以后就能够开始备份了。一个仓库能够包含多个快照（snapshots），快照能够存全部的索引，部分索引或者一个单独的索引。能够给索引指定一个惟一的名字：

 

1. PUT http://127.0.0.1:9200/_snapshot/my_backup/snapshot_1

 

上面的代码会将全部正在运行的索引，备份到my_backup仓库下一个叫snapshot_1的快照中。上面的api会马上返回，而后备份工做在后台运行。若是你想api同步执行，能够加wait_for_completion 标志：

 

1. PUT http://127.0.0.1:9200/_snapshot/my_backup/snapshot_1?wait_for_completion=true

 

上面的方法会在备份完成后才返回，若是数据量大的话，会花很长时间。

若是只想备份部分索引的话，能够加上indices 参数：

 

1. PUT http://127.0.0.1:9200/_snapshot/my_backup/snapshot_2
2. {
3. "indices": "index_1,index_2"
4. }

 

三、删除备份

不要手动删除文件（Elasticsearch一向主张使用api操做，尤为是大集群中），删除snapshot_2：

 

1. DELETE http://127.0.0.1:9200/_snapshot/my_backup/snapshot_2

 

若是备份正在后台进行，也能够直接删除来取消这次备份。

 

四、查看备份信息

直接使用GET 请求便可：

 

1. GET http://127.0.0.1:9200/_snapshot/my_backup/snapshot_2

 

返回相似下面的值：

 

1. {
2. "snapshots": [
3. {
4. "snapshot": "snapshot_2",
5. "indices": [
6. ".marvel_2014_28_10",
7. "index1",
8. "index2"
9. ],
10. "state": "SUCCESS",
11. "start_time": "2014-09-02T13:01:43.115Z",
12. "start_time_in_millis": 1409662903115,
13. "end_time": "2014-09-02T13:01:43.439Z",
14. "end_time_in_millis": 1409662903439,
15. "duration_in_millis": 324,
16. "failures": [],
17. "shards": {
18. "total": 10,
19. "failed": 0,
20. "successful": 10
21. }
22. }
23. ]
24. }

 

若是要查看全部索引的信息，使用以下api：

 

1. GET http://127.0.0.1:9200/_snapshot/my_backup/_all

 

另外还有个一api能够看到更加详细的信息：

 

1. GET http://127.0.0.1:9200/_snapshot/my_backup/snapshot_3/_status

 

具体不说了，本身玩一下就知道了，详细内容能够查看官方的文档

 

恢复

备份好后，恢复就更容易了，恢复snapshot_1里的所有索引：

 

 

1. POST http://127.0.0.1:9200/_snapshot/my_backup/snapshot_1/_restore

 

这个api还有额外的参数：

 

 

1. POST http://127.0.0.1:9200/_snapshot/my_backup/snapshot_1/_restore
2. {
3. "indices": "index_1",
4. "rename_pattern": "index_(.+)",
5. "rename_replacement": "restored_index_$1"
6. }

 

参数indices 设置只恢复index_1索引，参数rename_pattern 和rename_replacement 用来正则匹配要恢复的索引，而且重命名。和备份同样，api会马上返回值，而后在后台执行恢复，使用wait_for_completion 标记强制同步执行。

另外可使用下面两个api查看状态：

 

 

1. GET http://127.0.0.1:9200/_recovery/restored_index_3
2. GET http://127.0.0.1:9200/_recovery/

 

若是要取消恢复过程（无论是已经恢复完，仍是正在恢复），直接删除索引便可：

 

 

1. DELETE http://127.0.0.1:9200/restored_index_3

 

更多内容参看官方文档。