Question

有一天早上，我的Solr服务器突破了下面的这条消息，它没有自行恢复 - 不得不重新启动它 - 这是一个4.7.2已知的问题吗？

我的拓扑非常简单：单个Solr具有单个分片副本和嵌入式ZK（-zkrun）。

它是否与4.8修复有关：SOLR-5799：当注册为领导者时，如果存在现有的短暂注册，请等待一小段时间以查看它是否消失。（马克米勒）

ERROR - 2015-03-18 04:48:15.326; org.apache.solr.update.processor.DistributedUpdateProcessor; ClusterState says we are the leader, but locally we don't think so
INFO  - 2015-03-18 04:48:15.327; org.apache.solr.update.processor.LogUpdateProcessor; [quick-results-collection] webapp=/solr path=/update params={wt=javabin&version=2} {} 0 1
ERROR - 2015-03-18 04:48:15.328; org.apache.solr.common.SolrException; org.apache.solr.common.SolrException: ClusterState says we are the leader (http://9.70.210.149:8983/solr/quick-results-collection), 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.update.processor.LogUpdateProcessor.processAdd(LogUpdateProcessorFactory.java:100)
    at org.apache.solr.handler.loader.JavabinLoader$1.update(JavabinLoader.java:96)
    at org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$1.readOuterMostDocIterator(JavaBinUpdateRequestCodec.java:166)
    at org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$1.readIterator(JavaBinUpdateRequestCodec.java:136)
    at org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:225)
    at org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$1.readNamedList(JavaBinUpdateRequestCodec.java:121)
    at org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:190)
    at org.apache.solr.common.util.JavaBinCodec.unmarshal(JavaBinCodec.java:116)
    at org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec.unmarshal(JavaBinUpdateRequestCodec.java:173)
    at org.apache.solr.handler.loader.JavabinLoader.parseAndLoadDocs(JavabinLoader.java:106)
    at org.apache.solr.handler.loader.JavabinLoader.load(JavabinLoader.java:58)
    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)
    at org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:768)
    at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:415)
    at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:205)
    at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1419)

Answer 1

根据this link：

这可能是由多个共享相同状态的实例引起的目录，意味着磁盘上的内容不匹配（如果第二个实例旋转并写入它是它的奴隶当前的集群状态）以及zookeeper中的内容。

也许你有一个Jetty的例子仍然在你认为已经关闭的地方运行，但实际上并非如此。或者至少那是this person发现的：

问题是码头并没有真正停止，所以我们有2次跑步无论出于何种原因，这个过程都适合阅读但不适合写入。

这似乎不是一个非常常见的错误，所以很遗憾难以搜索。从我可以通过搜索邮件列表等来收集，有些人通过增加Zookeeper客户端的zkClientTimeout来解决问题。如果有一个潜在的任务需要很长时间，例如GC，那么这似乎特别有用。

Solr 4.7.2没有恢复 - ＆＃34; ClusterState说我们是领导者，但在本地我们不这么认为＆＃34;

1 个答案: