如何重命名集群中的索引？

一尘不染

如何重命名集群中的索引？

elasticsearch

我需要重命名集群中的几个索引（它们的名称必须更改，我不能使用alias）。

我看到没有支持的方法来执行此操作，我发现最接近的方法是重命名索引的目录，我在集群中尝试了此方法。

该集群有3台计算机A，B并且C分片在每台计算机上复制。我关闭了上elasticsearch
A，改名/var/lib/elasticsearch/security/nodes/0/indices/oldindexname到/var/lib/elasticsearch/security/nodes/0/indices/newindexname并重新启动A。

群集的状态为黄色，elasticsearch正在做一些魔术来恢复正确的状态。过了一段时间我最终

oldindexname正在使用和完全复制（由回收B和C我猜的）
newindexname 可用（我可以搜索它），但是头插件显示其分片处于“未分配”状态，并且显示为灰色（未复制）

在恢复过程中security.log显示以下消息：

[2015-02-20 11:02:33,461][INFO ][gateway.local.state.meta ] [A.example.com] dangled index directory name is [newindexname], state name is [oldindexname], renaming to directory name

虽然newindexname是可搜索的，但它肯定不是处于正常状态。

我通过删除恢复到先前的状态newindexname。群集恢复为绿色，没有任何“未分配”条目。

鉴于此，如何在群集中重命名oldindexname为newindexname？

注：
最终的解决方案我心目中是滚动复制oldindex到newindex并删除oldindex之后。这将需要时间，因此，如果有更直接的解决方案，那就太好了。

阅读 271

2020-06-22

共1个答案

一尘不染

从ElasticSearch 7.4开始，重命名索引的最佳方法是使用新引入的Clone Index
API复制索引，然后使用Delete Index
API删除原始索引。

与出于相同目的而使用Snapshot API或Reindex API相比，Clone Index API的主要优势是速度，因为Clone Index
API可以将段从源索引硬链接到目标索引，而无需重新处理其任何内容（在显然，支持硬链接的文件系统；否则，将在文件系统级别复制文件，这比其他方法要有效得多。克隆索引还保证目标索引在每个点上都与源索引相同（也就是说，与Reindex方法相反，无需手动复制设置和映射），并且不需要配置本地快照目录。

旁注：
尽管此过程比以前的解决方案要快得多，但仍意味着需要停机。在实际的用例中，有必要对重命名索引进行辩护（例如，作为拆分，收缩或备份工作流的一个步骤），但是重命名索引不应成为日常操作的一部分。如果您的工作流程需要频繁的索引重命名，那么您应该考虑使用索引别名。

下面是完整的操作序列索引重命名的例子source_index来target_index。可以使用某些ElasticSearch特定控制台执行该任务，例如Kibana中集成的控制台。请参见要点，以获取本示例的替代版本，curl而不是使用Elastic
Search控制台。

# Make sure the source index is actually open
POST /source_index/_open

# Put the source index in read-only mode
PUT /source_index/_settings
{
  "settings": {
    "index.blocks.write": "true"
  }
}

# Clone the source index to the target name, and set the target to read-write mode
POST /source_index/_clone/target_index
{
  "settings": {
    "index.blocks.write": null 
  }
}

# Wait until the target index is green;
# it should usually be fast (assuming your filesystem supports hard links).
GET /_cluster/health/target_index?wait_for_status=green&timeout=30s

# If it appears to be taking too much time for the cluster to get back to green,
# the following requests might help you identify eventual outstanding issues (if any)
GET /_cat/indices/target_index
GET /_cat/recovery/target_index
GET /_cluster/allocation/explain

# Delete the source index
DELETE /source_index

2020-06-22