按索引文件夹备份、删除、恢复 Elasticsearch 索引答案

【问题标题】：Backing up, Deleting, Restoring Elasticsearch Indexes By Index Folder按索引文件夹备份、删除、恢复 Elasticsearch 索引
【发布时间】：2015-06-24 12:00:50
【问题描述】：

大部分 ElasticSearch 文档都讨论了通过 REST API 处理索引 - 是否有任何理由我不能简单地从磁盘中移动或删除索引文件夹？

【问题讨论】：

我知道这已经过时了，我参加聚会有点晚了，但是您应该使用 API 而不是直接使用文件系统的一个原因是因为 Elastic Search 通常作为具有多台机器的集群运行有数据的碎片。因此，很难获得涉及许多机器的索引的一致备份。 API 处理这个问题，这意味着由许多机器组成的集群以这样一种方式进行编排，以便您获得适当的数据备份。

标签： elasticsearch backup disk purge

【解决方案1】：

您可以在磁盘上移动数据到某个点 -

如果 Elasticsearch 正在运行，移动或删除索引绝不是一个好主意文件夹，因为 Elasticsearch 不会知道数据发生了什么，而您将在日志和索引中获得各种FileNotFoundExceptions 在您手动删除它们之前是红色的。

如果 Elasticsearch 没有运行，您可以将索引文件夹移动到另一个节点（例如例如，如果您要永久停用一个节点并且需要获取数据关闭），但是，如果删除或将文件夹移动到重启服务时Elasticsearch看不到，然后Elasticsearch 会不开心。这是因为 Elasticsearch 编写了所谓的集群状态到磁盘，在这个集群状态下，索引被记录，所以如果 ES 启动并期望找到索引“foo”，但您已删除“foo” index 目录，索引会一直保持红色状态，直到通过 REST API。

因此，我建议如果您想移动或删除个人从磁盘索引文件夹，尽可能使用 REST API，因为它是如果删除预期的文件夹，可能会使 ES 进入不愉快的状态找到一个索引。

编辑：我应该提到复制（用于备份）索引文件夹是安全的，从 Elasticsearch 的角度来看，因为它不会修改文件夹。有时人们这样做是为了在快照之外执行备份 & 恢复 API。

【讨论】：

【解决方案2】：

我使用这个过程：我关闭、备份，然后删除索引。

curl -XPOST "http://127.0.0.1:9200/*index_name*/_close"

在此之后，所有索引数据都在磁盘上并处于一致状态，并且无法写入。我复制存储索引的目录，然后删除它：

curl -XPOST "http://127.0.0.1:9200/*index_name*/_delete"

通过关闭索引，elasticsearch 停止对索引的所有访问。然后我发送一个命令来删除索引（以及磁盘上所有相应的文件）。

【讨论】：

执行上述步骤后如何从文件中恢复索引？