当前位置: 首页 > 工具软件 > S3 Plugin > 使用案例 >

Elasticsearch 备份数据到 AWS S3

戚飞雨
2023-12-01

基本概念

使用 Elasticsearch Snapshot 时需要有一些基本概念澄清,他不是拿指定的 Indices 文件做个压缩包丢在 S3 完事,他是有控制的。

snapshot 结构

Elasticsearch 的 snapshot 是由其自身控制的,整个系统保持了一个如下的从下到上的控制结构,他们具备包含关系:

snapshot --> repository --> single snapshot --> indices

snapshot

这里将 snapshot 单独列出,是因为在 Elasticsearch 中 snapshot 独占性工作的,他更像是一个管道,任何一个 repository 在工作的时候是排他的,虽然他并不阻止 indices 的写入。
repository
这个仓库应该是一组 snapshot 备份的集合,也可以认为是一个目标的选择。在一个 Elasticsearch 系统中你可以根据自己的意愿设定不同的 Repository。

Single snapshot

这个指的是在 Repository 中我们进行的每个备份内容,他更像一个集合,包含了这次 snapshot 中所有的 Indices。

Indices

在一个 snapshot 当中,可以包含多个 Indices 文件内容。他可以在执行 snapshot 的时候用 pattern 识别,也可以一个一个的指定。

S3 插件

如果要想让 Elasticsearch 备份到 S3 当中需要单独安装一个插件 S3 Repository Plugin。

Repository

在正常执行 _snapshot 以前,需要先建立好自己的 Repository。具体操作可以参考 S3 Repository Plugin 完成 S3 的配置操作。

其中 AWS 的账户口令控制不必非要写在系统的 YAML 配置文件中,直接在创建 Repository 的设定用起来会更加灵活。获取 Repository 的时候,系统会自动屏蔽账户信息部分。

AWS IAM

这个稍微复杂一点,也可能是我们对 AWS IAM 并不熟悉。按照 Elastic 官方给出的 Recommanded S3 Permissions 直接配置即可。

Recommanded S3 Permissions:
https://www.elastic.co/guide/en/elasticsearch/plugins/current/repository-s3-repository.html#repository-s3-permissions

这里他需要获取到 AWS S3 Bucket 的列表权限,因为他会放置自己的一些控制文件进入,并且还需要进行比对操作。

如果你需要备份不同的 ES 系统到一个 AWS S3 Bucket 一定要分配到不同的目录当中,因为 Elasticsearch 的那些控制文件会导致他们之间冲突。这里可以参考这个 S3 Permissions 的说明中后面一个 IAM 配置说明即可。

snapshot 操作

当 Repository 做好后,就可以直接执行 _snapshot 操作了。具体的操作方法可以参考 Snapshot and Restore 部分的说明了。指令比 _search 不知道简单多少倍.

如果你执行的时候,其他的 snapshot 正在执行,你会得到一个 503: Service Unavailable 的错误信息。这就是上面说的 snapshot 执行的独占性,哪怕不同的 repository 之间也不能并行。

S3 中文件的作用

Elasticsearch 在 S3 中创建 snapshot 的时候,会形成一些辅助文件,帮他管理 snapshot 内容。

最坑爹是 Elasticsearch 并不在自己的 Indices 当中创建备份信息,而是将所有这些信息都放在了 S3 当中。当然熟悉后也明白,这么做的好处是,可以让另一个 ES 系统通过同样的 Repository 配置读取这些 S3 中的内容。

备份配置步骤

需要安装的插件 (推荐每台es节点都安装,并重启服务)

 /opt/elasticsearch/bin/elasticsearch-plugin install repository-s3

配置访问S3账号与密码

#ACCESS-KEY
/opt/elasticsearch/bin/elasticsearch-keystore add s3.client.default.access_key
 
         AKIAJLFDDDDDDDDDDDDD
 
#SECRET-KEY
/opt/elasticsearch/bin/elasticsearch-keystore add s3.client.default.secret_key
 
         nHr5vFTxCBI6CbRgNGDAAAAAAAAAA

删除key 信息:

/opt/elasticsearch/bin/elasticsearch-keystore remove s3.client.default.access_key
 
/opt/elasticsearch/bin/elasticsearch-keystore remove s3.client.default.secret_key

Amazon S3存储库实例如下:

curl -XPUT 'http://localhost:9200/_snapshot/backup'  -H 'Content-Type: application/json' -d '{ "type": "s3", "settings": { "bucket": "pte-es-backup", } }'       

参数名词解释:

Type: 仓库类型 
Setting: 仓库的额外信息 
Bucket: 存储桶名称

不同的ES版本支持的region参考:

Region: AWS Region 
Access_key: 访问秘钥 
Secret_key: 私有访问秘钥

使用上面的命令,创建一个仓库(s3-backup),并且还创建了存储桶(esbackup),返回{"acknowledged":true} 信息证明创建成功。

确认备份仓库是否创建成功:

curl -XPOST http://localhost:9200/_snapshot/backup/_verify?pretty
 
{
  "nodes" : {
    "Uz61yrDjRXy-otyYiwLXtA" : {
      "name" : "172.17.5.152"
    },
    "JgrZMa9CTRuoV1cezEeXuQ" : {
      "name" : "172.17.5.153"
    },
    "z_BLa4u1SZWt5gA4oZRpOA" : {
      "name" : "172.17.5.196"
    }
  }
}

查看刚创建的存储仓库:

    curl -XGET localhost:9200/_snapshot/backup?pretty

查看所有的存储桶:

    curl -XGET localhost:9200/_snapshot/_all?pretty

备份索引

创建好存储仓库之后就可以开始备份了。一个仓库可以包含多个快照(snapshots),快照可以存所有的索引或者部分索引,当然也可以存储一个单独的索引。(要注意的一点就是快照只会备份open状态的索引,close状态的不会备份)

备份所有索引

curl -XPUT http://127.0.0.1:9200/_snapshot/backup/snapshot_all

上面的代码会将所有正在运行的open状态的索引,备份到backup仓库下一个叫snapshot_all的快照中。上面的api会立刻返回{"accepted":true},然后备份工作在后台运行。

如果你想api同步执行,可以加wait_for_completion 标志:

curl -XPUT http://127.0.0.1:9200/_snapshot/backup/snapshot_all?wait_for_completion=true

上面的方法会在备份完全完成后才返回,如果快照数据量大的话,会花很长时间。

备份部分索引

默认是备份所有open状态的索引,如果你想只备份某些或者某个索引,可以指定indices参数来完成

curl -XPUT 'http://localhost:9200/_snapshot/backup/index-kjh-201712' -H 'Content-Type: application/json' -d '{ "indices": "index-kjh-2017.12" }'
备份多索引方法:
{
   "indices": "products,index_1,index_2",
   "ignore_unavailable": true,
   "include_global_state": false
}

indices: 需要备份的索引 
ignore_unavailable: 如果索引不存在,则略过。 
include_global_state: 为了让同一个snapshot可以恢复到多个不同的cluster,这里设置成false。之所以是false,是因为我们不想把global cluster state备份进snapshot

查看快照信息

curl -XGET 'http://localhost:9200/_snapshot/backup/_all'?pretty

curl -XGET 'http://localhost:9200/_snapshot/backup/index-kjh-201712?'pretty

查看快照信息,只需要发起GET请求就好:
详细信息:

 
    {
      "snapshot" : "index-kjh-201712",
      "uuid" : "mQPVTiYlR_Wc2ftR7OIrZw",
      "version_id" : 6010099,
      "version" : "6.1.0",
      "indices" : [
        "index-kjh-2017.12"
      ],
      "state" : "SUCCESS",              <============总体状况
      "start_time" : "2018-01-04T11:15:04.974Z",
      "start_time_in_millis" : 1515064504974,
      "end_time" : "2018-01-04T11:15:07.658Z",
      "end_time_in_millis" : 1515064507658,
      "duration_in_millis" : 2684,
      "failures" : [ ],
      "shards" : {
        "total" : 5,
        "failed" : 0,
        "successful" : 5
      }
    }
  ]
}

快照总体状况:

上面信息深入每和每个实例统计数据。这给你一个令人难以置信的详细视图快照是如何进展的。碎片可以以不同的方式完成:

INITIALIZING: 集群的碎片是检查状态是否可以快照。这通常是非常快。 
STARTED:数据被转移到存储库。 
FINALIZING:数据传输完成;碎片现在发送快照的元数据。 
DONE:快照完成。 
FAILED:在快照过程中错误的出处,这碎片/索引/快照无法完成。检查你的日志以获取更多信息。

恢复索引数据:

curl -XPOST 'http://localhost:9200/_snapshot/backup/index-kjh-201712/_restore

查看恢复状态:

GET http://127.0.0.1:9200/_recovery/index-kjh-201712
GET http://127.0.0.1:9200/_recovery/

删除一个快照存储桶:

curl -XDELETE localhost:9200/_snapshot/backup/index-kjh-201712?pretty
{
  "acknowledged" : true
}

部分恢复:

默认情况下,如果一个或多个索引在快照中没有可用的分片,整个恢复操作将失败。可以通过设置部分恢复为true,以恢复这些索引。注意:在这种情况下,只有成功的分片快照被恢复,丢失的分片将被重建为空的。

恢复到另一个集群

快照存储的信息不依赖于特定的集群或集群名称。因此,可以恢复到另一个集群。这需要在新的集群上注册快照包含的存储介质,并启动恢复过程。新集群不必具有相同的大小或者拓扑,但是,新集群的版本要与所创建的快照的版本一样或者更高。

可以减少索引副本以恢复成更小的集群。

如果原始集群的索引使用分片分配过滤被分配到特定节点,同样的规则将在新集群中强制执行。因此,如果新的集群不包含与该索引恢复的分配属性的适当节点,该索引将不会恢复成功的,除非这些索引在恢复操作过程中分配设置被更改。

恢复操作也支持wait_for_completion参数,会阻止客户端一直到操作完成。这是获知关于操作完成的最简单方法。

同一时刻,只允许执行一个快照或者一个恢复操作。

恢复操作使用标准的分片恢复机制。因此,当前运行的任何恢复操作可通过删除正在恢复的索引来中止。该操作的结果将会把删除索引的数据从集群中清除。

跨集群恢复步骤如下:

clusterA —— 配置s3备份环境----clusterA执行备份到S3存储桶 
clusterB —— 配置s3备份环境(指向clusterA备份存储桶)----clusterB执行恢复操作

 类似资料: