问题描述
所以今天我们遇到了一个令人不安的 solr 问题.在整个集群重新启动后，分片之一将停止索引/存储文档.直到我们开始编制索引(查询服务器看起来不错)之前，我们才对这个问题有所暗示.错误是:
So today we run into a disturbing solr issue.After a restart of the whole cluster one of the shard stop being able to index/store documents.We had no hint about the issue until we started indexing (querying the server looks fine).The error is:
2014-05-19 18:36:20,707 ERROR o.a.s.u.p.DistributedUpdateProcessor [qtp406017988-19] ClusterState says we are the leader, but locally we don't think so
2014-05-19 18:36:20,709 ERROR o.a.s.c.SolrException [qtp406017988-19] org.apache.solr.common.SolrException: ClusterState says we are the leader (http://x.x.x.x:7070/solr/shard3_replica1), but locally we don't think so. Request came from null
at org.apache.solr.update.processor.DistributedUpdateProcessor.doDefensiveChecks(DistributedUpdateProcessor.java:503)
at org.apache.solr.update.processor.DistributedUpdateProcessor.setupRequest(DistributedUpdateProcessor.java:267)
at org.apache.solr.update.processor.DistributedUpdateProcessor.processAdd(DistributedUpdateProcessor.java:550)
at org.apache.solr.handler.loader.JsonLoader$SingleThreadedJsonLoader.processUpdate(JsonLoader.java:126)
at org.apache.solr.handler.loader.JsonLoader$SingleThreadedJsonLoader.load(JsonLoader.java:101)
at org.apache.solr.handler.loader.JsonLoader.load(JsonLoader.java:65)
at org.apache.solr.handler.UpdateRequestHandler$1.load(UpdateRequestHandler.java:92)
at org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:74)
at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:1916)
我们在码头上以集群模式(5 个分片)运行 Solr 4.7.每个分片在不同的主机上运行，有一个 zookeeper 服务器.
We run Solr 4.7 in Cluster mode (5 shards) on jetty.Each shard run on a different host with one zookeeper server.
我查看了zookeeper的日志，我看不到任何东西.
I checked the zookeeper log and I cannot see anything there.
唯一的区别是在/overser_election/election 文件夹中我看到这个特定的服务器重复了3 次，而另一个服务器只提到了两次.
The only difference is that in the /overseer_election/election folder I see this specific server repeated 3 times, while the other server are only mentioned twice.
45654861x41276x432-x.x.x.x:7070_solr-n_00000003xx
74030267x31685x368-x.x.x.x:7070_solr-n_00000003xx
74030267x31685x369-x.x.x.x:7070_solr-n_00000003xx
甚至不确定这是否相关.(是真的吗?)知道我们可以做哪些其他检查吗?
Not even sure if this is relevant. (Can it be?)Any clue what other check can we do?
推荐答案
我们想通了！问题是码头并没有真正停止，所以我们有 2 个正在运行的进程，无论出于何种原因，这都适合读取但不适合写入.
We figured out!The issue was that jetty didn't really stop so we had 2 running processes, for whatever reason this was fine for reading but not for writing.
杀死旧的 java 进程解决了这个问题.
Killing the older java process solved the issue.
这篇关于Solr 问题:ClusterState 说我们是领导者，但本地我们不这么认为的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！