Solr 4.7.2 не восстанавливается - «ClusterState говорит, что мы лидер, но локально мы так не думаем»

Question

Однажды утром мой Solr-сервер сломался с этим сообщением ниже, он не восстановился сам по себе - пришлось перезапустить это - это проблема, известная в 4.7.2?

Моя топология очень проста: одиночный Solr с единственной осколочной копией и встроенным ZK (-zkrun).

Не может быть связано с исправлением 4,8: ​​SOLR-5799: При регистрации в качестве лидера, если существует существующая эфемерная регистрация, подождите немного, чтобы узнать, не исчезнет ли она. (Mark Miller)

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 работает процессы, по какой причине это было хорошо для чтения, но не для письма.

Это, кажется, не очень распространенная ошибка, поэтому ее, к сожалению, трудно найти. Из того, что я могу почерпнуть из поиска файлов списков рассылки и т. П., Некоторые люди решили проблему, увеличив zkClientTimeout для клиента Zookeeper. Это особенно полезно, если основная задача занимает много времени, например, GC.