从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
602392714
清零编程群