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教程