1

ある朝、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)
4

1 に答える 1

2

このリンクによると：

これは、複数のインスタンスが同じ状態ディレクトリを共有していることが原因である可能性があります。つまり、ディスク上の内容 (2 番目のインスタンスがスピンアップし、現在のクラスター状態のスレーブであると書き込む場合) と Zookeeper に存在する内容との間に不一致があることを意味します。

シャットダウンされたと思っていたが、実際にはシャットダウンされていなかった Jetty のインスタンスがまだ実行されている可能性があります。または、少なくともそれはこの人が発見したものです:

問題は、jetty が実際には停止しなかったため、実行中のプロセスが 2 つあったことでした。何らかの理由で、これは読み取りには問題ありませんが、書き込みには問題ありませんでした。

あまりよくあるエラーではないようで、残念ながら探すのが大変です。メーリング リストなどを調べてみるとzkClientTimeout、Zookeeper クライアントを増やすことで問題を解決した人もいます。これは、GC などの基本的なタスクに時間がかかる場合に特に役立つようです。

于 2015-03-19T21:21:54.697 に答える