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 正在恢复中，这个删除命令会停止恢复，同时删除所有已经恢复到集群里的数据。

转载于:https://www.cnblogs.com/kgdxpr/p/9522634.html