Elasticsearch 快照和恢復

快照及恢復

更新時間：2018-07-31 17:47:13

  

要備份您的阿里雲Elasticsearch集群，您可以使用 snapshot API。該API會拿到您的集群當前的狀態和數據，然后保存到一個共享倉庫里。這個備份過程是”智能”的。

您的第一個快照會是一個數據的完整拷貝，但所有后續的快照保留的是已存快照和新數據之間的差異。隨着您不時的對數據進行快照，備份也在增量的添加和刪除。這意味着后續備份會相當快速，因為它們只傳輸很小的數據量。

溫馨提示

如何使用快照方式，完成自建Elasticsearch遷移至阿里雲Elasticsearch，詳情請參見 OSS快照遷移Elasticsearch。

注意

本文代碼中的 <1>、<2>、<3> 這3個標記，用於標識位置，方便對指定位置代碼描述。實際執行對應代碼時，需去掉有包含這3個類型的標記。

創建倉庫

• 建議使用標准存儲類型OSS數據源（不支持歸檔存儲類型OSS）。
• <1> 此處的OSS，必須和您的阿里雲ES集群在同一個region中，下面的endpoint填的是這個 region 對應的內網地址 。詳情請參見 訪問域名和數據中心 中ECS訪問的內網Endpoint一欄。
• <2> 需要一個已經存在的OSS bucket。

1. PUT _snapshot/my_backup
2. {
3. "type": "oss",
4. "settings": {
5. "endpoint": "http://oss-cn-hangzhou-internal.aliyuncs.com", <1>
6. "access_key_id": "xxxx",
7. "secret_access_key": "xxxxxx",
8. "bucket": "xxxxxx", <2>
9. "compress": true
10. }
11. }

限制分塊大小

假設我們上傳的數據非常大, 我們可以限制snapshot過程中分塊的大小，超過這個大小，數據將會被分塊上傳到OSS中。

• <1> 注意用的是 POST 而不是 PUT，這會更新已有倉庫的設置。
• <2> base_path 設置倉庫的起始位置，默認為根目錄。

1. POST _snapshot/my_backup/ <1>
2. {
3. "type": "oss",
4. "settings": {
5. "endpoint": "http://oss-cn-hangzhou-internal.aliyuncs.com",
6. "access_key_id": "xxxx",
7. "secret_access_key": "xxxxxx",
8. "bucket": "xxxxxx",
9. "chunk_size": "500mb",
10. "base_path": "snapshot/" <2>
11. }
12. }

列出倉庫信息

1. GET _snapshot

• 也可以使用 GET _snapshot/my_backup 獲取指定倉庫的信息。

備份快照遷移

如果需要將快照遷移到另一個集群，只需要備份到OSS。然后再在新的集群上注冊一個快照倉庫(相同的OSS)，設置base_path的位置為備份文件所在的地方，然后執行恢復備份的命令即可。

快照所有打開的索引

一個倉庫可以包含多個快照，每個快照跟一系列索引相關（比如所有索引，一部分索引，或者單個索引）。當創建快照的時候，指定您感興趣的索引，然后給快照取一個唯一的名字。

快照命令

1. 讓我們從最基礎的快照命令開始：

   1. PUT _snapshot/my_backup/snapshot_1

   這個會備份所有打開的索引到 my_backup 倉庫下，並命名為 snapshot_1 的快照里。這個調用會立刻返回，然后快照會在后台運行。

2. 如果您希望在腳本中一直等待到完成，可通過添加 wait_for_completion 標記實現：

   1. PUT _snapshot/my_backup/snapshot_1?wait_for_completion=true

   這個會阻塞調用直到快照完成（如果是大型快照，會花很長時間才返回）。

快照指定索引

默認行為是備份所有打開的索引。如果您在用 Kibana，且考慮到磁盤空間大小因素，不想把所有診斷相關的 .kibana 索引都備份起來。

您可以在快照您的集群時，只備份您指定的索引：

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

這個快照命令，現在只會備份 index1 和 index2。

列出快照信息

有時您可能會忘記倉庫里的快照細節，特別是快照按時間划分命名的時候（比如 backup_2014_10_28）。

1. 直接對倉庫和快照名發起一個 GET 請求，獲得單個快照信息：

   1. GET _snapshot/my_backup/snapshot_2

   返回的響應中包括快照相關的各種信息：

   1. {
   2. "snapshots": [
   3. {
   4. "snapshot": "snapshot_1",
   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. }

2. 可以使用 _all 占位符，替換掉具體的快照名稱，獲取一個倉庫中所有快照的完整列表：

   1. GET _snapshot/my_backup/_all

刪除快照

可對倉庫/快照名稱，發一個DELETE命令的 HTTP 調用，來刪除所有不再有用的舊快照：

1. DELETE _snapshot/my_backup/snapshot_2

使用 API 來刪除快照很重要，而不能使用其他機制（比如手動刪除）。因為快照是增量的，有可能很多快照依賴於過去的段。delete API 知道哪些數據還在被更多近期快照使用，然后會只刪除不再被使用的段。

注意

如果您做了一次人工文件刪除，您將會面臨備份嚴重損壞的風險，因為您刪除的可能是還在使用中的數據。

監控快照進度

該wait_for_completion 標記，提供了基礎監控形式。如果您需要對中等規模的集群做快照恢復時，可能會不夠用。以下2個 API 會給您提供有關快照狀態更詳細的信息。

1. 您可以給快照 ID 執行一個 GET，類似上面獲取一個特定快照的信息操作：

   1. GET _snapshot/my_backup/snapshot_3

   如果您調用這個命令時，快照還在進行中。您會看到它什么時候開始，運行了多久等等信息。

   注意

   這個 API 用的是快照機制相同的線程池，如果您在快照非常大的分片，狀態更新的間隔會很大，因為 API 在競爭相同的線程池資源。

2. 更好的方案是拽取 _status API 數據：

   1. GET _snapshot/my_backup/snapshot_3/_status

   以下為_status API 返回的詳細統計信息：

   1. {
   2. "snapshots": [
   3. {
   4. "snapshot": "snapshot_3",
   5. "repository": "my_backup",
   6. "state": "IN_PROGRESS", <1>
   7. "shards_stats": {
   8. "initializing": 0,
   9. "started": 1, <2>
   10. "finalizing": 0,
   11. "done": 4,
   12. "failed": 0,
   13. "total": 5
   14. },
   15. "stats": {
   16. "number_of_files": 5,
   17. "processed_files": 5,
   18. "total_size_in_bytes": 1792,
   19. "processed_size_in_bytes": 1792,
   20. "start_time_in_millis": 1409663054859,
   21. "time_in_millis": 64
   22. },
   23. "indices": {
   24. "index_3": {
   25. "shards_stats": {
   26. "initializing": 0,
   27. "started": 0,
   28. "finalizing": 0,
   29. "done": 5,
   30. "failed": 0,
   31. "total": 5
   32. },
   33. "stats": {
   34. "number_of_files": 5,
   35. "processed_files": 5,
   36. "total_size_in_bytes": 1792,
   37. "processed_size_in_bytes": 1792,
   38. "start_time_in_millis": 1409663054859,
   39. "time_in_millis": 64
   40. },
   41. "shards": {
   42. "0": {
   43. "stage": "DONE",
   44. "stats": {
   45. "number_of_files": 1,
   46. "processed_files": 1,
   47. "total_size_in_bytes": 514,
   48. "processed_size_in_bytes": 514,
   49. "start_time_in_millis": 1409663054862,
   50. "time_in_millis": 22
   51. }
   52. },
   53. ...
   • <1> 一個正在運行的快照，會顯示 IN_PROGRESS 作為狀態。

   • <2> 這個特定快照有一個分片還在傳輸（另外四個已經完成）。

     響應包括快照的總體狀況，但也包括下鑽到每個索引和每個分片的統計值。這個給您展示了有關快照進展的非常詳細的視圖。分片可以在不同的完成狀態：

     INITIALIZING：分片在檢查集群狀態看看自己是否可以被快照。這個一般是非常快的。

     STARTED：數據正在被傳輸到倉庫。

     FINALIZING：數據傳輸完成；分片現在在發送快照元數據。

     DONE：快照完成！

     FAILED：快照處理的時候碰到了錯誤，這個分片/索引/快照不可能完成了。檢查您的日志獲取更多信息。

取消快照

如果您想取消一個快照，可以在任務進行中的時候，執行以下刪除快照命令：

1. DELETE _snapshot/my_backup/snapshot_3

這個會中斷快照進程。然后刪除倉庫里進行到一半的快照。

從快照恢復

1. 如果您已備份過數據，執行恢復操作相對比較簡單，只要在您希望恢復回集群的快照 ID 后面加上 _restore 即可：

   1. POST _snapshot/my_backup/snapshot_1/_restore

   默認行為是把這個快照里存有的所有索引都恢復。如果 snapshot_1 包括五個索引，這五個都會被恢復到我們集群里。和 snapshot API 一樣，我們也可以選擇希望恢復具體哪個索引。

2. 還有附加的選項用來重命名索引。這個選項允許您通過模式匹配索引名稱，然后通過恢復進程提供一個新名稱。如果您想在不替換現有數據的前提下，恢復老數據來驗證內容，或者做其他處理，這個選項很有用。讓我們從快照里恢復單個索引並提供一個替換的名稱：

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

   這個會恢復 index_1 到您集群里，但是重命名成了 restored_index_1 。

   • <1> 只恢復 index_1 索引，忽略快照中存在的其余索引。
   • <2> 查找所提供的模式能匹配上的正在恢復的索引。
   • <3> 然后把它們重命名成替代的模式。

3. 和快照類似， restore 命令也會立刻返回，恢復進程會在后台進行。如果您更希望您的 HTTP 調用阻塞直到恢復完成，添加 wait_for_completion 標記：

   1. POST _snapshot/my_backup/snapshot_1/_restore?wait_for_completion=true

監控恢復操作

從倉庫恢復數據借鑒了 Elasticsearch 里已有的現行恢復機制。在內部實現上，從倉庫恢復分片和從另一個節點恢復是等價的。

如果您想監控恢復的進度，您可以使用 recovery API。這是一個通用目的的 API，用來展示您集群中移動着的分片狀態。

1. 這個 API 可以為您在恢復的指定索引單獨調用：

   1. GET restored_index_3/_recovery

2. 或者查看您集群里所有索引，可能包括跟您的恢復進程無關的其他分片移動：

   1. GET /_recovery/

   輸出會跟這個類似（注意，根據您集群的活躍度，輸出可能會非常多！）：

   1. {
   2. "restored_index_3" : {
   3. "shards" : [ {
   4. "id" : 0,
   5. "type" : "snapshot", <1>
   6. "stage" : "index",
   7. "primary" : true,
   8. "start_time" : "2014-02-24T12:15:59.716",
   9. "stop_time" : 0,
   10. "total_time_in_millis" : 175576,
   11. "source" : { <2>
   12. "repository" : "my_backup",
   13. "snapshot" : "snapshot_3",
   14. "index" : "restored_index_3"
   15. },
   16. "target" : {
   17. "id" : "ryqJ5lO5S4-lSFbGntkEkg",
   18. "hostname" : "my.fqdn",
   19. "ip" : "10.0.1.7",
   20. "name" : "my_es_node"
   21. },
   22. "index" : {
   23. "files" : {
   24. "total" : 73,
   25. "reused" : 0,
   26. "recovered" : 69,
   27. "percent" : "94.5%" <3>
   28. },
   29. "bytes" : {
   30. "total" : 79063092,
   31. "reused" : 0,
   32. "recovered" : 68891939,
   33. "percent" : "87.1%"
   34. },
   35. "total_time_in_millis" : 0
   36. },
   37. "translog" : {
   38. "recovered" : 0,
   39. "total_time_in_millis" : 0
   40. },
   41. "start" : {
   42. "check_index_time" : 0,
   43. "total_time_in_millis" : 0
   44. }
   45. } ]
   46. }
   47. }
   • <1> type 字段告訴您恢復的本質；這個分片是在從一個快照恢復。
   • <2> source 哈希描述了作為恢復來源的特定快照和倉庫。
   • <3> percent 字段讓您對恢復的狀態有個概念。這個特定分片目前已經恢復了 94% 的文件，它就快完成了。

輸出會列出所有目前正在經歷恢復的索引，然后列出這些索引里的所有分片。每個分片里會有啟動/停止時間、持續時間、恢復百分比、傳輸字節數等統計值。

取消恢復

您可以通過刪除正在恢復的索引，取消一個恢復。因為恢復進程其實就是分片恢復，發送一個 刪除索引 API 修改集群狀態，就可以停止恢復進程。比如：

1. DELETE /restored_index_3

如果 restored_index_3 正在恢復中，這個刪除命令會停止恢復，同時刪除所有已經恢復到集群里的數據。