记一次ES的索引迁移

2020-08-04 本文已影响0人 mysia

由于公司需要统一整合ES服务，最近开始着手迁移。迁移方案主要分为物理迁移、本地升级、逻辑迁移三种。

物理迁移，就是冷拷ES数据到新集群，适合可以停机升级的业务；
本地升级，是在原集群上升级，不涉及到数据迁移，但也是需要停机的；
逻辑迁移，使用迁移工具从老集群将数据迁移到新集群，同时业务双写；

逻辑迁移的工具有很多，因为我们提供ES服务的同时，也提供了logstash的服务。所以逻辑迁移采用了logstash作为数据迁移工具。

前期迁移的几套集群没出现问题，速度很稳定。但是遇到了一套ES集群，启用了IK分词，问题就来了。

原集群的版本是6.4.2，使用了IK分词，版本是6.4.2。新集群的版本是6.8.0，IK使用的也是对应的6.8.0版本。但是迁移数据的过程中出现了问题。

[2020-08-03T13:56:10,894][WARN ][logstash.outputs.elasticsearch] Could not index event to Elasticsearch. {:status=>400, :action=>["index", {:_id=>"91889274", :_index=>"toutiao", :_type=>"news", :routing=>nil}, #<LogStash::Event:0x5fc60d63>], :response=>{"index"=>{"_index"=>"toutiao", "_type"=>"news", "_id"=>"91889274", "status"=>400, "error"=>{"type"=>"illegal_argument_exception", "reason"=>"startOffset must be non-negative, and endOffset must be >= startOffset, and offsets must not go backwards startOffset=6398,endOffset=6399,lastStartOffset=6400 for field 'content'"}}}}

看到这个报错，首先怀疑的是logstash或者ik的配置有问题，排查了一下，发现一切正常。询问业务人员，核对数据时发现双写也有部分数据没有写进去。这样就排除了logstash的问题，报错应该是ik导致的。

到github上看了一下ik的issue，结果发现好多人都有这个问题。原因是，ik更新重复中文分词的计数策略，导致大文本的分词会出现上述问题。

既然定位了问题，是版本更新导致，那么新版本是否能解决问题呢？看了下6.8系列的release note，发现并没有相关信息，于是考虑回滚版本。最终选择了6.6.1版本的ik，解决了上述问题。

这里还涉及到一个问题，6.6.1版本的ik，如何部署到6.8.0版本的ES集群呢？

其实，在一个大版本下（比如6.x），ik没有太大的差异，只需要更改依赖文件即可。

# vim plugin-descriptor.properties

description=IK Analyzer for Elasticsearch
version=6.6.1
name=analysis-ik
classname=org.elasticsearch.plugin.analysis.ik.AnalysisIkPlugin
java.version=1.8
elasticsearch.version=6.6.1

将version和elasticsearch.version改为相应版本就可以了，比如我的版本是6.8.0，那么如下：

# vim plugin-descriptor.properties

description=IK Analyzer for Elasticsearch
version=6.8.0
name=analysis-ik
classname=org.elasticsearch.plugin.analysis.ik.AnalysisIkPlugin
java.version=1.8
elasticsearch.version=6.8.0

修改完之后，替换原有集群的ik，重启各节点就可以了。

记一次ES的索引迁移

猜你喜欢

热点阅读