es快照和備份

時間  2020-09-14
標籤 快照 備份 简体版
原文   原文鏈接

註冊前要注意配置文件加上html

path.repo: ["/data/es_backup"]git

而後重啓esgithub

否則會報錯doesn't match any of the locations specified by path.repo because this setting is empty"json

 

註冊一個倉庫，存放快照，記住，這裏不是生成快照，只是註冊一個倉庫網絡

curl -XPUT 'http://*.*.*.*:9200/_snapshot/my_backup' -H 'Content-Type: application/json' -d '{
"type": "fs",
"settings": {
"location": "/data/es_backup",
"compress": true
}
}'app

 查看倉庫信息：curl

curl -XGET 'http://*.*.*.*:9200/_snapshot/my_backup?pretty'elasticsearch

恢復快照：分佈式

curl -XPOST "*.*.*.*:9200/_snapshot/my_backup/snapshot_1/_restore"-d '{
"indices": "index_1,index_2",
"ignore_unavailable": "true",
"include_global_state": false,
"rename_pattern": "index_(.+)",
"rename_replacement": "restored_index_$1" }'

建立所有快照,也能夠根據索引建立快照ide

curl -XPUT '*.*.*.*:9200/_snapshot/my_backup/snapshot_20171020?wait_for_completion=true&pretty'

刪除快照

刪除快照
curl -XDELETE '*.*.*.*:9200/_snapshot/my_backup/snapshot_20171020?pretty'
 
es單節點或者多節點集羣備份：

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

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

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

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

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

建立倉庫編輯

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

PUT _snapshot/my_backup 
{
    "type": "fs", 
    "settings": {
        "location": "/mount/backups/my_backup" 
    }
}

給咱們的倉庫取一個名字，在本例它叫 my_backup 。

咱們指定倉庫的類型應該是一個共享文件系統。

最後，咱們提供一個已掛載的設備做爲目的地址。

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

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

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

假設咱們有一個很是快的網絡，並且對額外的流量也很 OK，那咱們能夠增長這些默認值：

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 。這會更新已有倉庫的設置。

而後添加咱們的新設置。

快照全部打開的索引編輯

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

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

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

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

 

參考連接：https://www.elastic.co/guide/en/elasticsearch/reference/5.5/modules-snapshots.html

https://www.elastic.co/guide/cn/elasticsearch/guide/current/backing-up-your-cluster.html

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