Reindex如何实现索引重建？
- 滚动索引 + 批量复制
Reindex存在的问题
- 如果新的索引没有提前创建好，并指定字段类型，那么重建后的新索引类型极有可能会和旧的索引不一致，因为ES他会推断类型，而推断错误率从实战来说那是相当的高
Reindex能解决的问题
- 字段类型设置错了
- 旧的索引分片不合理，想重新分
- 某批数据存错了，或只想保留具备指定特性或关键字的数据，可以根据条件来重建索引，筛选出符合条件的数据进行重建，
POST _reindex
{"source": {"index":"remind_test", // 旧的源索引名称"query": {"term": {"summary": "java" // 只重建包含java的数据}}},"dest":{"index": "remind_new" // 重建后新索引的索引名称}
}
- 指向要指定的字段，其余字段想删掉，也可以使用重建索引
POST _reindex
{"source": {"index":"remind_test", // 旧的源索引名称"_source": ["id", "title", "name"] // 只重建id, title, name字段，其余字段不要了，则重建后的新索引，只会有这3个字段},"dest":{"index": "remind_new" // 重建后新索引的索引名称}
}
- 多个索引库合并重建(即有多个索引，想把字段和数据整合到一个大索引中)
== 注意： 如果多个索引中存在相同的文档id，合并后只会保留最后一个，因为会覆盖掉前面的==
POST _reindex
{"source": {"index":["remind_test_1", "remind_test_2", "remind_test_3"], // 旧的多个源索引名称},"dest":{"index": "remind_new" // 重建后新索引的索引名称}
}
- 扩展：索引数据冲突如何解决： 使用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注意事项
- reindex要求所有【源/旧】索引的所有文档启用_source
- reindex新的索引一定要指定好mapping, shard(分片), replica(副本)数据， 旧索引的这些配置是不会赋值到新索引的
单索引数据量较大，数据同步速度比较慢时，如何处理
- 在真正索引重建之前，最好在测试环境进行测试，防止在生产环境重建失败，导致多次重建消耗性能
- 评估好重建后索引大小，硬件配置等可用存储等因素，确保重建后能过够成功
- 增加资源，比如CPU, 内存等硬件信息，提高reindex操作效率
- 为了避免磁盘IO瓶颈，在进行reindex时，可以通过将源索引和目标索引放在不同的磁盘上，或者使用更快的SSD提升速度
- 在reindex时，可以将目标索引的刷新间隔设置改为-1， 从而避免不必要的刷新操作，提高reindex效率
- 重点：如果单索引数据量大，在迁移前，将目标索引的副本数设置为0， 以加快同步速度，等到迁移后，再修改回来
