从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