Elasticsearch的快照

時間  2019-11-07
標籤 elasticsearch 快照 欄目 日誌分析 简体版
原文   原文鏈接

使用不管哪一個存儲數據的軟件，按期備份你的數據都是很重要的。 Elasticsearch 副本提供了高可靠性；它們讓你能夠容忍零星的節點丟失而不會中斷服務。node

可是，副本並不提供對災難性故障的保護。對這種狀況，你須要的是對集羣真正的備份——在某些東西確實出問題的時候有一個完整的拷貝。docker

要備份你的集羣，你可使用 snapshot API。這個會拿到你集羣裏當前的狀態和數據而後保存到一個共享倉庫裏。這個備份過程是"智能"的。你的第一個快照會是一個數據的完整拷貝，可是全部後續的快照會保留的是已存快照和新數據之間的差別。隨着你不時的對數據進行快照，備份也在增量的添加和刪除。這意味着後續備份會至關快速，由於它們只傳輸很小的數據量。json

要使用這個功能，你必須首先建立一個保存數據的倉庫。有多個倉庫類型能夠供你選擇：網絡

  • 共享文件系統，好比 NAS
  • Amazon S3
  • HDFS (Hadoop 分佈式文件系統)
  • Azure Cloud

建立倉庫

讓我部署一個共享 文件系統倉庫：app

PUT _snapshot/my_backup 
{
    "type": "fs", 
    "settings": {
        "location": "/mount/backups/my_backup" 
    }
}
  1. 給咱們的倉庫取一個名字，在本例它叫 my_backup 。
  2. 咱們指定倉庫的類型應該是一個共享文件系統。
  3. 最後，咱們提供一個已掛載的設備做爲目的地址。

注意：共享文件系統路徑必須確保集羣全部節點均可以訪問到。異步

這步會在掛載點建立倉庫和所需的元數據。還有一些其餘的配置你可能想要配置的，這些取決於你的節點、網絡的性能情況和倉庫位置：elasticsearch

max_snapshot_bytes_per_sec
當快照數據進入倉庫時，這個參數控制這個過程的限流狀況。默認是每秒 20mb 。
max_restore_bytes_per_sec
當從倉庫恢復數據時，這個參數控制何時恢復過程會被限流以保障你的網絡不會被佔滿。默認是每秒 `20mb`。分佈式

POST _snapshot/my_backup/ 
{
    "type": "fs",
    "settings": {
        "location": "/mount/backups/my_backup",
        "max_snapshot_bytes_per_sec" : "50mb", 
        "max_restore_bytes_per_sec" : "50mb"
    }
}

注意咱們用的是 POST 而不是 PUT 。這會更新已有倉庫的設置。
而後添加咱們的新設置。工具

快照全部打開的索引

一個倉庫能夠包含多個快照。 每一個快照跟一系列索引相關（好比全部索引，一部分索引，或者單個索引）。當建立快照的時候，你指定你感興趣的索引而後給快照取一個惟一的名字。oop

讓咱們從最基礎的快照命令開始：

PUT _snapshot/my_backup/snapshot_1

這個會備份全部打開的索引到 my_backup 倉庫下一個命名爲 snapshot_1 的快照裏。這個調用會馬上返回，而後快照會在後臺運行。

一般你會但願你的快照做爲後臺進程運行，不過有時候你會但願在你的腳本中一直等待到完成。這能夠經過添加一個 wait_for_completion 標記實現：

PUT _snapshot/my_backup/snapshot_1?wait_for_completion=true

這個會阻塞調用直到快照完成。注意大型快照會花很長時間才返回。

快照指定索引

默認行爲是備份全部打開的索引。 不過若是你在用 Marvel，你不是真的想要把全部診斷相關的 .marvel索引也備份起來。可能你就壓根沒那麼大空間備份全部數據。

這種狀況下，你能夠在快照你的集羣的時候指定備份哪些索引：

PUT _snapshot/my_backup/snapshot_2
{
    "indices": "index_1,index_2"
}

這個快照命令如今只會備份 index1 和 index2 了。

列出快照相關的信息

一旦你開始在你的倉庫裏積攢起快照了，你可能就慢慢忘記裏面各自的細節了 ——特別是快照按照時間劃分命名的時候（好比， backup_2014_10_28 ）。

要得到單個快照的信息，直接對倉庫和快照名發起一個 GET 請求：

GET _snapshot/my_backup/snapshot_2

這個會返回一個小響應，包括快照相關的各類信息：

{
   "snapshots": [
      {
         "snapshot": "snapshot_1",
         "indices": [
            ".marvel_2014_28_10",
            "index1",
            "index2"
         ],
         "state": "SUCCESS",
         "start_time": "2014-09-02T13:01:43.115Z",
         "start_time_in_millis": 1409662903115,
         "end_time": "2014-09-02T13:01:43.439Z",
         "end_time_in_millis": 1409662903439,
         "duration_in_millis": 324,
         "failures": [],
         "shards": {
            "total": 10,
            "failed": 0,
            "successful": 10
         }
      }
   ]
}

要獲取一個倉庫中全部快照的完整列表，使用 _all 佔位符替換掉具體的快照名稱：

GET _snapshot/my_backup/_all

刪除快照

最後，咱們須要一個命令來刪除全部再也不有用的舊快照 。這隻要對倉庫/快照名稱發一個簡單的 DELETEHTTP 調用：

DELETE _snapshot/my_backup/snapshot_2

用 API 刪除快照很重要，而不能用其餘機制（好比手動刪除，或者用 S3 上的自動清除工具）。由於快照是增量的，有可能不少快照依賴於過去的段。delete API 知道哪些數據還在被更多近期快照使用，而後會只刪除再也不被使用的段。

可是，若是你作了一次人工文件刪除，你將會面臨備份嚴重損壞的風險，由於你在刪除的是可能還在使用中的數據。

監控快照進度

wait_for_completion 標記提供了一個監控的基礎形式，但哪怕只是對一箇中等規模的集羣作快照恢復的時候，它都真的不夠用。
另外兩個 API 會給你有關快照狀態更詳細的信息。首先你能夠給快照 ID 執行一個 `GET`，就像咱們以前獲取一個特定快照的信息時作的那樣：

GET _snapshot/my_backup/snapshot_3

若是你調用這個命令的時候快照還在進行中，你會看到它何時開始，運行了多久等等信息。不過要注意，這個 API 用的是快照機制相同的線程池。若是你在快照很是大的分片，狀態更新的間隔會很大，由於 API 在競爭相同的線程池資源。

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

GET _snapshot/my_backup/snapshot_3/_status

_status API 馬上返回，而後給出詳細的多的統計值輸出：

{
   "snapshots": [
      {
         "snapshot": "snapshot_3",
         "repository": "my_backup",
         "state": "IN_PROGRESS", 
         "shards_stats": {
            "initializing": 0,
            "started": 1, 
            "finalizing": 0,
            "done": 4,
            "failed": 0,
            "total": 5
         },
         "stats": {
            "number_of_files": 5,
            "processed_files": 5,
            "total_size_in_bytes": 1792,
            "processed_size_in_bytes": 1792,
            "start_time_in_millis": 1409663054859,
            "time_in_millis": 64
         },
         "indices": {
            "index_3": {
               "shards_stats": {
                  "initializing": 0,
                  "started": 0,
                  "finalizing": 0,
                  "done": 5,
                  "failed": 0,
                  "total": 5
               },
               "stats": {
                  "number_of_files": 5,
                  "processed_files": 5,
                  "total_size_in_bytes": 1792,
                  "processed_size_in_bytes": 1792,
                  "start_time_in_millis": 1409663054859,
                  "time_in_millis": 64
               },
               "shards": {
                  "0": {
                     "stage": "DONE",
                     "stats": {
                        "number_of_files": 1,
                        "processed_files": 1,
                        "total_size_in_bytes": 514,
                        "processed_size_in_bytes": 514,
                        "start_time_in_millis": 1409663054862,
                        "time_in_millis": 22
                     }
                  },
                  ...

一個正在運行的快照會顯示 IN_PROGRESS 做爲狀態。

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

響應包括快照的整體情況，但也包括下鑽到每一個索引和每一個分片的統計值。這個給你展現了有關快照進展的很是詳細的視圖。分片能夠在不一樣的完成狀態：

INITIALIZING  分片在檢查集羣狀態看看本身是否能夠被快照。這個通常是很是快的。
STARTED  數據正在被傳輸到倉庫。
FINALIZING  數據傳輸完成；分片如今在發送快照元數據。
DONE  快照完成！
FAILED  快照處理的時候碰到了錯誤，這個分片/索引/快照不可能完成了。檢查你的日誌獲取更多信息。

取消一個快照

最後，你可能想取消一個快照或恢復。 由於它們是長期運行的進程，執行操做的時候一個筆誤或者過錯就會花很長時間來解決——並且同時還會耗盡有價值的資源。

要取消一個快照，在他進行中的時候簡單的刪除快照就能夠：

DELETE _snapshot/my_backup/snapshot_3

這個會中斷快照進程。而後刪除倉庫裏進行到一半的快照。

從快照恢復

一旦你備份過了數據，恢復它就簡單了：只要在你但願恢復回集羣的快照 ID 後面加上 _restore 便可：

POST _snapshot/my_backup/snapshot_1/_restore

默認行爲是把這個快照裏存有的全部索引都恢復。若是 snapshot_1 包括五個索引，這五個都會被恢復到咱們集羣裏。 和 snapshot API 同樣，咱們也能夠選擇但願恢復具體哪一個索引。

還有附加的選項用來重命名索引。這個選項容許你經過模式匹配索引名稱，而後經過恢復進程提供一個新名稱。若是你想在不替換現有數據的前提下，恢復老數據來驗證內容，或者作其餘處理，這個選項頗有用。讓咱們從快照裏恢復單個索引並提供一個替換的名稱：

POST /_snapshot/my_backup/snapshot_1/_restore
{
    "indices": "index_1", 
    "rename_pattern": "index_(.+)", 
    "rename_replacement": "restored_index_$1" 
}
  1. 只恢復 index_1 索引，忽略快照中存在的其他索引。
  2. 查找所提供的模式能匹配上的正在恢復的索引。
  3. 而後把它們重命名成替代的模式。

這個會恢復 index_1 到你及羣裏，可是重命名成了 restored_index_1 。

和快照相似， restore 命令也會馬上返回，恢復進程會在後臺進行。若是你更但願你的 HTTP 調用阻塞直到恢復完成，添加 wait_for_completion 標記：

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

 

監控恢復操做

從倉庫恢復數據借鑑了 Elasticsearch 裏已有的現行恢復機制。 在內部實現上，從倉庫恢復分片和從另外一個節點恢復是等價的。
若是你想監控恢復的進度，你可使用 recovery API。這是一個通用目的的 API，用來展現你集羣中移動着的分片狀態。
這個 API 能夠爲你在恢復的指定索引單獨調用：

GET restored_index_3/_recovery

或者查看你集羣裏全部索引，可能包括跟你的恢復進程無關的其餘分片移動：

GET /_recovery/

輸出會跟這個相似（注意，根據你集羣的活躍度，輸出可能會變得很是囉嗦！）

{
  "restored_index_3" : {
    "shards" : [ {
      "id" : 0,
      "type" : "snapshot", 
      "stage" : "index",
      "primary" : true,
      "start_time" : "2014-02-24T12:15:59.716",
      "stop_time" : 0,
      "total_time_in_millis" : 175576,
      "source" : { 
        "repository" : "my_backup",
        "snapshot" : "snapshot_3",
        "index" : "restored_index_3"
      },
      "target" : {
        "id" : "ryqJ5lO5S4-lSFbGntkEkg",
        "hostname" : "my.fqdn",
        "ip" : "10.0.1.7",
        "name" : "my_es_node"
      },
      "index" : {
        "files" : {
          "total" : 73,
          "reused" : 0,
          "recovered" : 69,
          "percent" : "94.5%" 
        },
        "bytes" : {
          "total" : 79063092,
          "reused" : 0,
          "recovered" : 68891939,
          "percent" : "87.1%"
        },
        "total_time_in_millis" : 0
      },
      "translog" : {
        "recovered" : 0,
        "total_time_in_millis" : 0
      },
      "start" : {
        "check_index_time" : 0,
        "total_time_in_millis" : 0
      }
    } ]
  }
}
  1. type 字段告訴你恢復的本質；這個分片是在從一個快照恢復。
  2. source 哈希描述了做爲恢復來源的特定快照和倉庫。
  3. percent 字段讓你對恢復的狀態有個概念。這個特定分片目前已經恢復了 94% 的文件；它就快完成了。

輸出會列出全部目前正在經歷恢復的索引，而後列出這些索引裏的全部分片。每一個分片裏會有啓動/中止時間、持續時間、恢復百分比、傳輸字節數等統計值。

取消一個恢復

要取消一個恢復，你須要刪除正在恢復的索引。 由於恢復進程其實就是分片恢復，發送一個 刪除索引 API 修改集羣狀態，就能夠中止恢復進程。好比：

DELETE /restored_index_3

若是 restored_index_3 正在恢復中，這個刪除命令會中止恢復，同時刪除全部已經恢復到集羣裏的數據。

 

 

備份：

第一步，建立倉庫

其實就是建立一個備份存儲的目的倉庫，支持FileSystem、Amazon S三、Azure Cloud、HDFS

建立命令以下：

PUT _snapshot/my_backup  
{  
  "type": "fs",  
  "settings": {  
    "location": "/home/docker/back"  
  }  
}

首先給到咱們的一個信息是，命令都是經過http協議進行，因此ES的備份是ES運行時進行的，並非單純的系統級的文件拷貝，備份前請先啓動ES

命令執行後報錯：

"reason": "[my_backup] location [/mount/backups/my_backup] doesn't match any of the locations specified by path.repo because this setting is empty"

翻找資料發現作備份的location fs須要在elasticsearch.yml中配置一下，增長一行：

path.repo: ["/home/docker/back"]

修改配置後重啓ES，再運行上面命令，成功。

這裏Settings裏有幾個默認參數須要瞭解下：

compress，是否壓縮，默認爲是。

max_restore_bytes_per_sec，節點恢復速率。默認40mb/s。

max_snapshot_bytes_per_sec，每一個節點快照速率。默認40mb/s。

能夠用以下命令修改默認參數：

POST _snapshot/my_backup/  
{  
  "type": "fs",  
  "settings": {  
    "compress": true,  
    "location": "/home/docker/back",  
    "max_snapshot_bytes_per_sec" : "50mb",  
    "max_restore_bytes_per_sec" : "50mb"  
  }  
}

倉庫建立完畢後，咱們去location的位置去看一眼，裏面目前仍是空的。

第二步，備份索引

本質是在剛纔的倉庫裏建立快照，快照能夠指定一個或多個索引進行備份，默認是所有索引，同一個倉庫能夠建立多個快照。

備份過程也分爲同步和異步，默認是異步，備份在後臺執行，能夠經過wait_for_completion=true參數設定爲同步。

異步方式備份所有索引

PUT _snapshot/my_backup/snapshot_all

同步方式備份部分索引

PUT _snapshot/my_backup/snapshot_entity?wait_for_completion=true  
{  
  "indices": "index_entity"  
}

這步執行後location下真正增長了快照文件。

第三步，查看備份信息

GET _snapshot/my_backup/snapshot_all

返回以下：

{  
  "snapshots": [  
    {  
      "snapshot": "snapshot_all",  
      "uuid": "4LWRo_WbR5mzFlZ6ozuDrg",  
      "version_id": 5060199,  
      "version": "5.6.1",  
      "indices": [  
        "my_index",  
        "applog",  
        "index_entity",  
        "index1",  
        ".kibana"  
      ],  
      "state": "SUCCESS",  
      "start_time": "2017-11-03T02:34:17.832Z",  
      "start_time_in_millis": 1509676457832,  
      "end_time": "2017-11-03T02:34:18.537Z",  
      "end_time_in_millis": 1509676458537,  
      "duration_in_millis": 705,  
      "failures": [],  
      "shards": {  
        "total": 21,  
        "failed": 0,  
        "successful": 21  
      }  
    }  
  ]  
}

其實這個跟上面同步備份時的返回是同樣的，此命令主要用來查看異步備份執行結果。

第四部，刪除廢棄備份快照

DELETE _snapshot/my_backup/snapshot_applog

恢復：

恢復命令比較簡單，就是選擇一個快照執行_restore就能夠了也是默認異步執行，經過wait_for_completion=true能夠改爲同步執行，以下：

POST _snapshot/my_backup/snapshot_entity/_restore

但執行後報錯以下：

reason": "[my_backup:snapshot_entity/hxNnq8CsRAm3Yi8IvD0ZeA] cannot restore index [index_entity] because it's open"

再去尋找資料，發下索引在被回覆時須要先關閉，不然索引的寫操做會影響恢復，因而關閉索引：

POST index_entity/_close

再執行恢復命令

POST _snapshot/my_backup/snapshot_entity/_restore

成功。恢復好後記得打開索引

POST index_entity/_open

若是要從一個大快照中只恢復部分索引，命令以下：

POST _snapshot/my_backup/snapshot_all/_restore  
{  
  "indices": "index_entity"  
}
相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程