How to rename an index in a cluster in elasticsearch

在Elasticsearch中，索引的名称一旦创建之后是不能直接修改的，但是您可以通过创建索引的别名（alias）或重新索引（reindexing）的方法来间接"重命名"索引。

方法一：使用别名（Alias）

虽然不能直接重命名索引，但是您可以给索引创建一个或多个别名，这样可以通过新的别名来访问原有的索引。

创建别名的步骤如下：

1. 使用POST或者PUT请求为现有索引创建别名：

json
POST /_aliases
{
  "actions": [
    {
      "add": {
        "index": "原始索引名",
        "alias": "新的别名"
      }
    }
  ]
}

1. 确认别名已被创建，并可以通过它访问数据。

2. 可选的，您可以删除旧的索引名，但这样做前要确保所有写入和读取操作都已经切换到了新的别名。

方法二：重新索引（Reindexing）

如果您需要更彻底地改名，可以使用重新索引的方法。这涉及到将旧索引中的数据复制到一个新的索引中，然后您可以根据需要删除旧的索引。

重新索引的步骤如下：

1. 创建新的索引，并指定所需的设置和映射。

2. 使用 _reindex API 将旧索引的数据复制到新索引：

json
POST /_reindex
{
  "source": {
    "index": "旧索引名"
  },
  "dest": {
    "index": "新索引名"
  }
}

1. 在重新索引完成后，确保新索引已正确地包含了所有的数据。

2. 更新所有应用程序和服务，以使用新的索引名称。

3. 删除旧的索引（如果确定不再需要）：

json
DELETE /旧索引名

注意： 重命名索引（特别是重新索引）是一个可能会消耗时间和资源的过程，对于大型索引或生产环境，需要谨慎进行，并考虑到可能的停机时间、数据一致性问题以及对正在进行的查询和索引操作的影响。在生产环境中，可能需要在低流量时段进行此操作，并确保有完整的备份以防万一出错。

Another approach to renaming or updating index mappings in an Elasticsearch cluster is to use Logstash for reindexing. Here is a Logstash 2.1 configuration example:

json
input {
  elasticsearch {
    hosts => ["es01.example.com", "es02.example.com"]
    index => "old-index-name"
    size => 500
    scroll => "5m"
  }
}
filter {
  mutate {
    remove_field => [ "@version" ]
  }
  date {
    "match" => [ "custom_timestamp", "MM/dd/YYYY HH:mm:ss" ]
    target => "@timestamp"
  }
}
output {
  elasticsearch {
    hosts => ["es01.example.com", "es02.example.com" ]
    manage_template => false
    index => "new-index-name"
  }
}

To rename an index, you can use the Elasticsearch snapshot module.

First, you must take a snapshot of the index. When restoring the index, you can specify the new name during the restore process.

json
POST /_snapshot/my_backup/snapshot_1/_restore
{
  "indices": "jal",
  "ignore_unavailable": "true",
  "include_global_state": false,
  "rename_pattern": "jal",
  "rename_replacement": "jal1"
}

rename_replacement: the new index name where the backed-up data is stored.

Starting from Elasticsearch 7.4, the best way to rename indices is to use the newly introduced clone index API to clone the index and then use the delete index API to remove the original index.

Compared to using the snapshot API or reindex API for the same purpose, the main advantage of the clone index API is speed, because it hard-links segments from the source index to the target index without reprocessing any content. On systems that support hard links, this is efficient; otherwise, files are copied at the filesystem level, which is still more efficient than alternatives. The clone index operation also guarantees that the target index is identical to the source index at every point (i.e., no manual copying of settings and mappings is required, unlike the reindex method), and it does not require configuring a local snapshot directory.

Note: Although this process is significantly faster than previous solutions, it still involves downtime. There are practical use cases where renaming indices is justified (e.g., as part of a splitting, shrinking, or backup workflow), but renaming indices should not be part of routine operations. If your workflow requires frequent index renaming, consider using index aliases.

The following is a complete sequence of operations to rename an index from source_index to target_index. It can be executed using some Elasticsearch-specific consoles, such as the console integrated in Kibana. See this gist for an alternative version using curl instead of the Elasticsearch console.

shell
# 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