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, 以加快同步速度,等到迁移后,再修改回来