从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 openPOST /source_index/_open# Put the source index in read-only modePUT /source_index/_settings{ "settings": { "index.blocks.write": "true" }}# Clone the source index to the target name, and set the target to read-write modePOST /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_indexGET /_cat/recovery/target_indexGET /_cluster/allocation/explain# Delete the source indexDELETE /source_index
