Reindex如何实现索引重建？

1. 滚动索引 + 批量复制

Reindex存在的问题

1. 如果新的索引没有提前创建好，并指定字段类型，那么重建后的新索引类型极有可能会和旧的索引不一致，因为ES他会推断类型，而推断错误率从实战来说那是相当的高

Reindex能解决的问题

1. 字段类型设置错了
2. 旧的索引分片不合理，想重新分
3. 某批数据存错了，或只想保留具备指定特性或关键字的数据，可以根据条件来重建索引，筛选出符合条件的数据进行重建，

POST _reindex
{"source": {"index":"remind_test",   // 旧的源索引名称"query": {"term": {"summary": "java"   // 只重建包含java的数据}}},"dest":{"index": "remind_new"   // 重建后新索引的索引名称}
}

4. 指向要指定的字段，其余字段想删掉，也可以使用重建索引

POST _reindex
{"source": {"index":"remind_test",   // 旧的源索引名称"_source": ["id", "title", "name"]   // 只重建id, title, name字段，其余字段不要了，则重建后的新索引，只会有这3个字段},"dest":{"index": "remind_new"   // 重建后新索引的索引名称}
}

5. 多个索引库合并重建(即有多个索引，想把字段和数据整合到一个大索引中)
   == 注意： 如果多个索引中存在相同的文档id，合并后只会保留最后一个，因为会覆盖掉前面的==

POST _reindex
{"source": {"index":["remind_test_1", "remind_test_2", "remind_test_3"],   // 旧的多个源索引名称},"dest":{"index": "remind_new"   // 重建后新索引的索引名称}
}

6. 扩展：索引数据冲突如何解决： 使用conflicts参数

abort: 中止操作。如果复制中发生了冲突，即源索引的ID出现相同的，则会终止整个重建操作
proceed: 继续操作，不会更新与源索引ID冲突的文档，可能会导致目标索引中存在冲突的文档，会导致数据不一致，需要进行之后处理
overwrite: 覆盖操作，发生冲突时，直接覆盖，后面的覆盖前面的POST _reindex
{"source": {"conflicts": "proceed","index":["remind_test_1", "remind_test_2", "remind_test_3"],   // 旧的多个源索引名称},"dest":{"index": "remind_new"   // 重建后新索引的索引名称}
}

重建索引Remindex注意事项

1. reindex要求所有【源/旧】索引的所有文档启用_source
2. reindex新的索引一定要指定好mapping, shard(分片), replica(副本)数据， 旧索引的这些配置是不会赋值到新索引的

单索引数据量较大，数据同步速度比较慢时，如何处理

1. 在真正索引重建之前，最好在测试环境进行测试，防止在生产环境重建失败，导致多次重建消耗性能
2. 评估好重建后索引大小，硬件配置等可用存储等因素，确保重建后能过够成功
3. 增加资源，比如CPU, 内存等硬件信息，提高reindex操作效率
4. 为了避免磁盘IO瓶颈，在进行reindex时，可以通过将源索引和目标索引放在不同的磁盘上，或者使用更快的SSD提升速度
5. 在reindex时，可以将目标索引的刷新间隔设置改为-1， 从而避免不必要的刷新操作，提高reindex效率
6. 重点：如果单索引数据量大，在迁移前，将目标索引的副本数设置为0， 以加快同步速度，等到迁移后，再修改回来