由于公司需要統(tǒng)一整合ES服務(wù)，最近開始著手遷移。遷移方案主要分為物理遷移、本地升級、邏輯遷移三種。
- 物理遷移，就是冷拷ES數(shù)據(jù)到新集群，適合可以停機升級的業(yè)務(wù)；
- 本地升級，是在原集群上升級，不涉及到數(shù)據(jù)遷移，但也是需要停機的；
- 邏輯遷移，使用遷移工具從老集群將數(shù)據(jù)遷移到新集群，同時業(yè)務(wù)雙寫；
邏輯遷移的工具有很多，因為我們提供ES服務(wù)的同時，也提供了logstash的服務(wù)。所以邏輯遷移采用了logstash作為數(shù)據(jù)遷移工具。
前期遷移的幾套集群沒出現(xiàn)問題，速度很穩(wěn)定。但是遇到了一套ES集群，啟用了IK分詞，問題就來了。
原集群的版本是6.4.2，使用了IK分詞，版本是6.4.2。新集群的版本是6.8.0，IK使用的也是對應(yīng)的6.8.0版本。但是遷移數(shù)據(jù)的過程中出現(xiàn)了問題。
[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的配置有問題，排查了一下，發(fā)現(xiàn)一切正常。詢問業(yè)務(wù)人員，核對數(shù)據(jù)時發(fā)現(xiàn)雙寫也有部分數(shù)據(jù)沒有寫進去。這樣就排除了logstash的問題，報錯應(yīng)該是ik導致的。
到github上看了一下ik的issue，結(jié)果發(fā)現(xiàn)好多人都有這個問題。原因是，ik更新重復中文分詞的計數(shù)策略，導致大文本的分詞會出現(xiàn)上述問題。
既然定位了問題，是版本更新導致，那么新版本是否能解決問題呢？看了下6.8系列的release note，發(fā)現(xiàn)并沒有相關(guān)信息，于是考慮回滾版本。最終選擇了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改為相應(yīng)版本就可以了，比如我的版本是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，重啟各節(jié)點就可以了。
