概要
由于历史原因，A产品数据入Es库中字段默认都是keyword并没有区分字段类型属性，随着业务发展，需要更多数据格式，原有的keyword满足不了新需求，所以问题来了，新老数据字段属性产生了冲突，如何安全高效解决这个问题是本文内容。
一、问题分析
通过报错信息可以确定，当聚合查询时有两个索引拥有两个不一样类型。
使用kibana进行查看两个索引mapping（出问题的mapping肯定是我新升级后产生索引mapping和升级前的对比），如下图所示发现两个索引mapping类型a、b字段都对应不上，keyword和long起了冲突，验证了报错信息，开始修复。
二、修复过程
1、方案设计
采用大数据数据迁移中比较常用的ABA的方式来实现，将A索引内容同步到B索引中（B修改后的mapping），删除A索引并新建A索引及mapping,将B索引中数据同步回到A索引中即可，注意重新建A索引mapping时一定要用正确的字段类型的mapping,否则就白同步了。
2、实际操作
2.1、评估数据同步时长
一般正常数据大概1G数据100w条左右，而es正常同步速度5000~6000条/秒，也就是说同步1G数据大概需要3分钟左右速度（不同数据大小、机器性能及Es设置会略有不同）。
执行如下命令来查看：GET cat/indices/test*
可以很轻松评估出索引同步时间大概需要多久，如果是生产环境这个很重要，因为你要以一个最优的速度实现同步同时还不能影响线上环境使用。
2.3、B索引及mapping的创建
因为我要修复test_01索引，还不能比当前索引大，索引我采用前面加0，那么就是创建test_001索引。
获取test_01索引的mapping，然后进行修改为正确类型。
- 执行命令：GET test_01/_mapping
- 修改获取后的mapping字段
- 执行命令：POST test_001/message/_mapping {内容}
注意：禁止创建比当前索引数字大情况索引，系统会进行增量索引时报异常！
2.4、数据同步【A->B】
将索引test_01同步到索引test_001,执行如下命令即可：
# copy index
POST _reindex?refresh&wait_for_completion=false
{
"source": {"index": "test_01"},
"dest": {"index": "test_001"}
}执行后会返回一个计划id
执行如下命令进行查看计划状态：
GET _tasks/M3duzBS0TdW4Sae8gmla7g:20187723082Total总数据，created当前同步条数
备注：当不记得这个计划id情况执行如下命令可获取：
GET _tasks?detailed=true&actions=*reindex2.5、A索引重构及数据同步【B->A】
在确认test_001索引数据同步完成，没有问题情况下
删除test_01索引，执行命令：DELETE test_01
创建test_01索引，执行命令：PUT test_01
test_001的mapping创建新索引test_01的mapping
执行恢复同步索引
# copy index
POST _reindex?refresh&wait_for_completion=false
{
"source": {"index": "test_001"},
"dest": {"index": "test_01"}
}2.6、同步速度的调整
由于现场环境复杂，所以说需要调整好相应速率及性能占用，避免影响正常生成使用。
通过如下命令来调整同步速度：其中红色为计划id，黄色为每秒条数
POST _reindex/M3duzBS0TdW4Sae8gmla7g:20187173464/_rethrottle?requests_per_second=1000
当你想结束计划时，执行如下命令即可：
POST _tasks/M3duzBS0TdW4Sae8gmla7g:20187723082/_cancel最后，别忘记删除test_001索引，全部操作完成
三、总结
1、在实际项目中可以去发现，当索引机制如果是对后面数字01和1不进行区分情况是可以只同步一次的，A索引数据同步到B索引，通过一些业务数据修改，是可以直接用B索引的没有问题，这个当然也是需要去亲力亲为去验证。
2、其实本篇文章虽然是说的两个字段属性冲突问题，但实际生产中可不仅可以同步字段属性，甚至做一些文本内容转换、数据格式转换、字段替换等等，可玩性和可拓展性很大。
