最佳实践Elasticsearch-Snapshot-备份的使用方法

9次阅读

共计 3967 个字符，预计需要花费 10 分钟才能阅读完成。

简介： 常见的数据库都会提供备份的机制，以解决在数据库无奈应用的状况下，能够开启新的实例，而后通过备份来复原数据缩小损失。

魏彬，普翔科技 CTO，开源软件爱好者，中国第一位 Elastic 认证工程师，《Elastic 日报》和《ElasticTalk》社区我的项目发起人，被 elastic 中国公司授予 2019 年度合作伙伴架构师特地贡献奖。对 Elasticsearch、Kibana、Beats、Logstash、Grafana 等开源软件有丰盛的实践经验，为批发、金融、保险、证券、科技等泛滥行业的客户提供过征询和培训服务，帮忙客户在理论业务中找准开源软件的定位，实现从 0 到 1 的落地、从 1 到 N 的拓展，产生理论的业务价值。

原文链接：点击这里

常见的数据库都会提供备份的机制，以解决在数据库无奈应用的状况下，能够开启新的实例，而后通过备份来复原数据缩小损失。尽管 Elasticsearch 有良好的容灾性，但因为以下起因，其仍然须要备份机制。

1、数据灾备。在整个集群无奈失常工作时，能够及时从备份中复原数据。

2、归档数据。随着数据的积攒，比方日志类的数据，集群的存储压力会越来越大，不论是内存还是磁盘都要承当数据增多带来的压力，此时咱们往往会抉择只保留最近一段时间的数据，比方 1 个月，而将 1 个月之前的数据删除。如果你不想删除这些数据，以备后续有查看的需要，那么你就能够将这些数据以备份的模式归档。

3、迁徙数据。当你须要将数据从一个集群迁徙到另一个集群时，也能够用备份的形式来实现。

Elasticsearch 做备份有两种形式，

1、将数据导出成文本文件，比方通过 elasticdump、esm 等工具将存储在 Elasticsearch 中的数据导出到文件中。
2、以备份 elasticsearch data 目录中文件的模式来做快照，也就是 Elasticsearch 中 snapshot 接口实现的性能。

第一种形式绝对简略，在数据量小的时候比拟实用，当应答大数据量场景效率就大打折扣。

咱们明天就着重解说下第二种备份的形式，即 snapshot api 的应用。备份要解决备份到哪里、如何备份、何时备份和如何复原的问题，那么咱们接下来一个个解决。

在 Elasticsearch 中通过 repository 定义备份存储类型和地位，存储类型有共享文件系统、AWS 的 S3 存储、HDFS、微软 Azure 的存储、Google Cloud 的存储等，当然你也能够本人写代码实现国内阿里云的存储。咱们这里以最简略的共享文件系统为例，你也能够在本地做试验。

首先，你要在 elasticsearch.yml 的配置文件中注明能够用作备份门路 path.repo，如下所示：

path.repo: ["/mount/backups", "/mount/longterm_backups"]

配置好后，就能够应用 snapshot api 来创立一个 repository 了，如下咱们创立一个名为 my_backup 的 repository。

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

之后咱们就能够在这个 repository 中来备份数据了。

有了 repostiroy 后，咱们就能够做备份了，也叫快照，也就是记录当下数据的状态。如下所示咱们创立一个名为 snapshot_1 的快照。

PUT /_snapshot/my_backup/snapshot_1?wait_for_completion=true

wait_for_completion 为 true 是指该 api 在备份执行结束后再返回后果，否则默认是异步执行的，咱们这里为了立即看到成果，所以设置了该参数，线上执行时不必设置该参数，让其在后盾异步执行即可。

执行胜利后会返回如下后果，用于阐明备份的状况：

{
  "snapshots": [
    {
      "snapshot": "snapshot_1",
      "uuid": "52Lr4aFuQYGjMEv5ZFeFEg",
      "version_id": 6030099,
      "version": "6.3.0",
      "indices": [
        ".monitoring-kibana-6-2018.05.30",
        ".monitoring-es-6-2018.05.28",
        ".watcher-history-7-2018.05.30",
        ".monitoring-beats-6-2018.05.29",
        "metricbeat-6.2.4-2018.05.28",
        ".monitoring-alerts-6",
        "metricbeat-6.2.4-2018.05.30"
      ],
      "include_global_state": true,
      "state": "SUCCESS",
      "start_time": "2018-05-31T12:45:57.492Z",
      "start_time_in_millis": 1527770757492,
      "end_time": "2018-05-31T12:46:15.214Z",
      "end_time_in_millis": 1527770775214,
      "duration_in_millis": 17722,
      "failures": [],
      "shards": {
        "total": 28,
        "failed": 0,
        "successful": 28
      }
    }
  ]
}

返回后果的参数意义都是比拟直观的，比方 indices 指明此次备份波及到的索引名称，因为咱们没有指定须要备份的索引，这里备份了所有索引；state 指明状态；duration_in_millis 指明备份工作执行时长等。

咱们能够通过 GET _snapshot/my_backup/snapshot_1 获取 snapshot_1 的执行状态。

此时如果去 /mount/backups/my_backup 查看，会发现外面多了很多文件，这些文件其实都是基于 elasticsearch data 目录中的文件生成的压缩存储的备份文件。大家能够通过 du -sh . 命令看一下该目录的大小，不便后续做比照。

通过下面的步骤咱们胜利创立了一个备份，但随着数据的新增，咱们须要对新增的数据也做备份，那么咱们如何做呢？办法很简略，只有再创立一个快照 snapshot_2 就能够了。

PUT /_snapshot/my_backup/snapshot_2?wait_for_completion=true

当执行结束后，你会发现 /mount/backups/my_backup 体积变大了。这阐明新数据备份进来了。要阐明的一点是，当你在同一个 repository 中做屡次 snapshot 时，elasticsearch 会查看要备份的数据 segment 文件是否有变动，如果没有变动则不解决，否则只会把发生变化的 segment file 备份下来。这其实就实现了增量备份。

Elasticsearch 的资深用户应该理解 force merge 性能，即能够强行将一个索引的 segment file 合并成指定数目，这里要留神的是如果你被动调用 force merge api，那么 snapshot 性能的增量备份性能就生效了，因为 api 调用结束后，数据目录中的所有 segment file 都发生变化了。

另一个就是备份机会的问题，尽管 snapshot 不会占用太多的 cpu、磁盘和网络资源，但还是倡议大家尽量在闲时做备份。

所谓“养兵千日，用兵一时”，咱们该演练下备份的成绩，将其复原进去。通过调用如下 api 即可疾速实现复原性能。

POST /_snapshot/my_backup/snapshot_1/_restore?wait_for_completion=true
{
  "indices": "index_1",
  "rename_replacement": "restored_index_1"
}

通过下面的 api，咱们能够将 index_1 索引复原到 restored_index_1 中。这个复原过程齐全是基于文件的，因而效率会比拟高。

尽管咱们这里演示的是在同一个集群做备份与复原，你也能够在另一个集群上连贯该 repository 做复原。咱们这里就不做阐明了。

因为 Elasticsearch 版本更新比拟快，因而大家在做备份与复原的时候，要留神版本问题，同一个大版本之间的备份与复原是没有问题的，比方都是 5.1 和 5.6 之间能够相互备份复原。但你不能把一个高版本的备份在低版本复原，比方将 6.x 的备份在 5.x 中复原。而低版本备份在高版本复原有肯定要求：

1、5.x 能够在 6.x 复原
2、2.x 能够在 5.x 复原
3、1.x 能够在 2.x 复原

其余跨大版本的降级都是不可用的，比方 1.x 的无奈在 5.x 复原。这里次要起因还是 Lucene 版本问题导致的，每一次 ES 的大版本升级都会随同 Lucene 的大版本，而 Lucene 的版本是尽量保障向前兼容，即新版能够读旧版的文件，但版本逾越太多，无奈实现兼容的状况也在劫难逃了。

本文只是简略对 snapshot 性能做了一个演示，心愿这足够引起你的趣味。如果你想进一步深刻的理解该性能，比方备份的时候如何指定局部索引、如何查问备份和还原的进度、如何跨集群复原数据、如何备份到 HDFS 等，
能够具体浏览官网手册
https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-snapshots.html