Elasticsearch snapshot

我是王大你是谁
2,827 阅读4分钟

背景

虽然 Elasticsearch 有良好的容灾性，但是在以下情况还是需要备份机制：

  • 数据灾备：在集群出错时，可以及时从备份中恢复数据。
  • 归档数据：有些不断增加的数据暂时不用，但是以备后期查看而不想删除，则可以将这些数据进行备份归档。
  • 迁移数据：将数据从一个集群迁移到另一个集群时，也可以用备份的方式来实现。Elasticsearch 做备份有两种方式，一是将数据导出成文本文件，比如通过 elasticdump 、 esm 等工具将存储在 Elasticsearch 中的数据导出到文件中。二是以备份 Elasticsearch data 目录中文件的形式来做快照，也就是 Elasticsearch 中 snapshot 接口实现的功能。第一种方式相对简单，在数据量小的时候比较实用，当应对大数据量场景效率就大打折扣。接下来讲到的就是 snapshot api 的使用。

备份到哪里

在 Elasticsearch 中通过 repository 定义备份存储类型和位置，存储类型有共享文件系统、AWS 的 S3存储、HDFS 的存储等。

不管是哪种，你都要在 elasticsearch.yml 的配置文件中注明可以用作备份路径 path.repo：

path.repo: /usr/local/elasticsearch-7.3.0/data/backup

配置好后，就可以使用 snapshot api 来创建一个 repository 了，如下我们创建一个名为 es_backup 的 repository。

PUT /_snapshot/es_backup
{
  "type": "fs",
  "settings": {
    "location": "/usr/local/elasticsearch-7.3.0/data/backup"
  }
}

创建成功之后就可以在这个 repository 中备份数据了。

如何备份

备份也叫快照，也就是记录当下索引数据的状态，如下创建一个名叫 snapshot_0910 的快照：

PUT /_snapshot/es_backup/snapshot_0910

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

通过以下命令查看快照执行状态：

GET _snapshot/es_backup/snapshot_0910

结果如下：

{
  "snapshots" : [
    {
      "snapshot" : "snapshot_0910",
      "uuid" : "1rkfrgJsQMSWmVT0WePQ-Q",
      "version_id" : 7030099,
      "version" : "7.3.0",
      "indices" : [
        "blogs",
        "address_xc",
        "pattern",
        "student",
        "student2",
        "kibana_sample_data_flights",
        ".kibana_task_manager",
        "p_sc",
        ".kibana_1",
        "my_index"
      ],
      "include_global_state" : true,
      "state" : "SUCCESS",
      "start_time" : "2019-09-10T09:14:11.455Z",
      "start_time_in_millis" : 1568106851455,
      "end_time" : "2019-09-10T09:15:17.168Z",
      "end_time_in_millis" : 1568106917168,
      "duration_in_millis" : 65713,
      "failures" : [ ],
      "shards" : {
        "total" : 10,
        "failed" : 0,
        "successful" : 10
      }
    }
  ]
}

何时备份

通过上面的步骤我们成功创建了一个备份，但随着数据的新增，我们需要对新增的数据也做备份，那么我们如何做呢？方法很简单，只要再创建一个快照 snapshot_new 就可以了。

PUT /_snapshot/es_backup/snapshot_new?wait_for_completion=true

当执行完毕后，es_backup 目录体积变大了，这说明新数据备份进来了。如果在同一个 repository 中做多次 snapshot 时，Elasticsearch 会检查要备份的数据 segment 文件是否有变化，如果没有变化则不处理，否则只会把发生变化的 segment file 备份下来。这其实就实现了增量备份。

Elasticsearch 的资深用户应该了解 force merge 功能，即可以强行将一个索引的 segment file 合并成指定数目，这里要注意的是如果你主动调用 force merge api，那么 snapshot 功能的增量备份功能就失效了，因为 api 调用完毕后，数据目录中的所有 segment file 都发生变化了。

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

如何恢复

通过下面的 api，我们可以将 index_1 索引恢复到 restored_index_1 中。这个恢复过程完全是基于文件的，因此效率会比较高。

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

其他

由于 Elasticsearch 版本更新比较快，因此大家在做备份与恢复的时候，要注意版本问题，同一个大版本之间的备份与恢复是没有问题的，比如都是 5.1 和 5.6 之间可以互相备份恢复。但你不能把一个高版本的备份在低版本恢复，比如将 6.x 的备份在 5.x 中恢复。而低版本备份在高版本恢复有一定要求：

  • 5.x 可以在 6.x 恢复

  • 2.x 可以在 5.x 恢复

  • 1.x 可以在 2.x 恢复

参考

如果需要详细了解，可以去官网：www.elastic.co/guide/en/el…

avatar
文章
阅读
粉丝