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

 

更多內容參看官方文檔。