Elasitcsearch7.X 集群/索引备份与恢复实战

1、问题引出

ES中文社区中，有如下问题：

• 问题1： 存储数据，data目录从一个机器直接移到一台新的机器是否可以直接使用？

• 问题2： es升级时，data目录如果在外部路径，从低版本升级到高版本时，data目录是否直接可以使用？

• 问题3： 将一个旧的es数据(400多G)迁移到新的es中的时候直接将旧es的data目录下indices文件拷贝到新es的data下(大概花了一个晚上)，这种做法是否可取？

脑补一下，如果你遇到上述问题，你一般怎么解决？

2、问题分析

上述问题涉及到集群备份、索引数据备份、数据迁移、数据恢复等问题，而数据备份和恢复又分为：

• 1、ES Mapping&Setting 基础信息备份。

• 2、ES 全量数据备份。

• 3、ES 增量数据备份。

• 4、ES 数据恢复。

3、常见备份和恢复索引/集群方案

• 方案一：使用ES的快照和恢复功能进行备份和恢复。

该方案 适用于 ： 集群整体备份与迁移，包括： 全量、增量贝恩和恢复。

• 方案二：使用elasticdump迁移Mapping和数据。

该方案 适用于 ： 索引层面迁移数据或Mapping，支持： analyzer/Mapping/data的迁移操作。

相比于： reindex跨集群操作，elasticdump无需在ES集群的配置文件elasteicsearch.yml中设置授权迁移访问地址（白名单）。

• 方案三：使用reindex实行集群内部或跨集群同步数据。

该方案 适用于 :本地索引更新Mapping实现索引层面迁移，或者跨集群的索引迁移。

缺点： 如前所述，跨集群迁移需要elasticsearch.yml中加上ip白名单。

4、直接拷贝文件能不能实现集群备份呢？

官方文档指出： 你不能仅通过获取集群所有节点的数据目录副本来备份Elasticsearch集群。 Elasticsearch可能在运行时对其数据目录的内容进行更改； 复制其数据目录不能达到捕获其内容的一致快照的预期。

如果尝试通过拷贝文件备份还原集群，将会导致失败，会报文件损坏或丢失文件的错误。 或者，看似成功了，但却丢失了一些数据。

备份集群 的唯一可靠方法是使用快照和还原功能。

5、方案一：Elasticsearch快照和还原功能

5.1 快照注意事项

• 1、快照是从正在运行的Elasticsearch集群中获取的备份。

• 2、您可以创建单个索引或整个群集的快照，支持本地文件存储，以及远程第三方存储库存储（包括：S3，HDFS，Azure，Google Cloud Storage等）。

• 3、快照是 增量 创建的。 这意味着，当创建索引快照时，Elasticsearch避免复制任何已存储在存储库中的数据作为同一索引的早期快照的一部分。 因此，可以 非常频繁 地为集群创建快照。

• 4、如果您的集群启用了Elasticsearch安全功能，则在备份数据时，必须授权快照API调用。

• 5、在升级之前备份数据时，请记住，如果快照中包含与升级版本不兼容的版本中创建的索引，则可能导致升级后将无法还原快照。

• 6、兼容列表如下：

  在1.x中创建的索引快照可以恢复到2.x。

  在2.x中创建的索引快照可以恢复到5.x。

  在5.x中创建的索引快照可以恢复到6.x。

  在6.x中创建的索引快照可以恢复到7.x。

  反例：

  无法将在1.x中创建的索引快照还原到5.x或6.x，无法将在2.x中创建的索引快照还原到6.x或7.x，以及无法将在5.X创建的索引快照还原到7.x。

• 7、要保证还原的集群有足够的存储容量。

5.2 快照执行步骤

以下操作在windows10单节点集群环境ES7.2 Kibana7.2上执行，linux原理一致。

5.2.1 步骤1：配置快照存储路径及注册快照存储库

• 在elasticsearch中添加如下配置：

1 path.repo :  ["D:\\install\\elasticsearch-7.2.0-windows-x86_64\\elasticsearch-7.2.0\\backup"]

• 注册快照存储库（即设置存储路径）

1 PUT /_snapshot/my_backup

2 {

3 "type" :  "fs" ,

4 "settings" : {

5 "location" :  "D:\\install\\elasticsearch-7.2.0-windows-x86_64\\elasticsearch-7.2.0\\backup"

6 }

7 }

5.2.2 步骤2：拍摄快照

步骤2.1： 全量备份——拍摄集群快照

想象成拍照的点击确认的那一刻。

1 PUT /_snapshot/my_backup/snapshot_cluster?wait_for_completion= true

执行返回结果核心包括：

1 快照索引信息

2 快照执行起始时间、持续时间

3 成功、失败分片数等

步骤2.2： 按需备份——拍摄索引快照

1 PUT /_snapshot/my_backup/snapshot_hamlet_index?wait_for_completion= true

2 {

3 "indices" :  "hamlet_*" ,

4 "ignore_unavailable" :  true ,

5 "include_global_state" :  false ,

6 "metadata" : {

7 "taken_by" :  "mingyi" ,

8 "taken_because" :  "backup before upgrading"

9 }

10 }

步骤2.3 增量备份——同步骤2.1

假设ES有实时数据持续写入，不同时间点会生成不同的快照。

步骤2.1, 2.2, 2.3 非串行执行，可以按需选择执行即可。

5.2.3 步骤3：恢复快照

• 步骤3.1 恢复索引快照

为验证效果，我们先执行了删除索引操作。

1 DELETE hamlet_*

2 POST /_snapshot/my_backup/snapshot_hamlet_index/_restore

执行成功后返回：

1 {

2 "accepted" :  true

3 }

• 步骤3.2 恢复集群快照

为验证效果，我们先执行了 DELETE * 删除全部索引（实际线上环境注意规避风险）

1 POST /_snapshot/my_backup/snapshot_cluster/_restore

5.3 快照常见操作

• 1、查看所有快照存储库

1 GET /_snapshot/_all

• 2、查看快照状态

1 GET /_snapshot/my_backup/snapshot_hamlet_index/_status

• 3、删除快照

1 DELETE /_snapshot/my_backup/snapshot_hamlet_index

6、方案二：elasticdump迁移

同mysql dump功能，严格讲elasticdump有导入、导出数据的功能。

背景：

• 192.168.1.1:9200 迁移源集群，

• 192.168.3.2:9200 迁移目的集群。

6.1 迁移Setting和Mapping等

1 elasticdump \

2 --input=http://192.168.1.1:9200/my_index \

3 --output=http://192.168.3.2:9200/my_index \

4 --type=analyzer

5 elasticdump \

6 --input=http://192.168.1.1:9200/my_index \

7 --output=http://192.168.3.2:9200/my_index \

8 --type=settings

9 elasticdump \

10 --input=http://192.168.1.1:9200/my_index \

11 --output=http://192.168.3.2:9200/my_index \

12 --type=mapping

6.2 迁移数据

1 elasticdump \

2 --input=http://192.168.1.1:9200/my_index \

3 --output=http://192.168.3.2:9200/my_index \

4 --type=data

细节参见： https://github.com/taskrabbit/elasticsearch-dump

7、最常见问题

7.1 多节点集群如何配置才能实现快照？

第一： 建立共享文件系统： 如 NFS共享 ，确定每一个节点挂载到指定路径，才能创建快照存储库。

第二： 在所有的主节点、数据节点都要配置相同的path.repo。

7.2 相同名称索引存在的情况下执行恢复快照？

会报错如下：

英文reason里面已经给出解决方案。

1 {

2 "error" : {

3 "root_cause" : [

4 {

5 "type" :  "snapshot_restore_exception" ,

6 "reason" :  "[my_backup:snapshot_cluster/_THlX1vMQvGmwxcRCmhnlA] cannot restore index [.kibana_task_manager] because an open index with same name already exists in the cluster. Either close or delete the existing index or restore the index under a different name by providing a rename pattern and replacement name"

7 }

8 ],

8、小结

本文依然比较基础，实战出真知。

针对开头问题，请留下您的思考。

推荐阅读：

重磅 | 死磕Elasticsearch方法论认知清单（2019国庆更新版）