Question

所以今天我们遇到了一个令人不安的solr问题。重新启动整个集群后，其中一个分片停止能够索引/存储文档。在我们开始索引之前，我们没有提示这个问题（查询服务器看起来很好）。错误是：

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服务器的不同主机上运行。

我查了一下zookeeper日志，我看不到任何东西。

唯一的区别是在/ overseer_election / election文件夹中我看到这个特定服务器重复了3次，而另一个服务器只提到了两次。

  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

甚至不确定这是否相关。（是真的吗？）我们可以做其他检查的任何线索吗？

Answer 1

我们想通了！问题是码头没有真正停止，所以我们有两个运行过程，无论出于何种原因，这对阅读是好的，但不适合写作。

杀死旧的java进程解决了这个问题。

Answer 2

我们在2个条件下遇到过此错误。

条件1

在一个动物园管理员主机上，有一个孤儿的Zookeeper短暂节点 /overseer_elect/election。此临时节点关联的会话不再存在。

无法删除孤立的短暂节点。引起：https://issues.apache.org/jira/browse/ZOOKEEPER-2355

这个条件还会附带一个/overseer/queue目录，该目录被永远等待处理的队列项堵塞。

要解决此问题，您必须使用孤立的临时节点重新启动有问题的Zookeeper节点。

如果重启后您看到Still seeing conflicting information about the leader of shard shard1 for collection <name> after 30 seconds 您还需要重新启动Solr主机以解决问题。

条件2

原因：配置错误的systemd服务单元。如果您使用的是systemd，请确保正确配置Type=forking并PIDFile。

systemd没有正确跟踪PID，它认为服务已经死了，但它不是，并且在某些时候启动了2个服务。因为第二个服务无法启动（因为它们都不能在同一个端口上监听），它似乎只是处于一个失败状态挂起，或者无法启动该过程但只是弄乱了另一个solr通过在本地覆盖临时clustertate文件以某种方式进行处理。

Solr日志报告了OP发布的相同错误。

有趣的是，另一个症状是，zookeeper在/collections/<name>/leaders/shard1/leader中没有为我们的集合列出任何领导者，通常这个zk节点包含的内容如下：

{＆＃34;核心＆＃34;：＆＃34;收集-name_shard1_replica1＆＃34 ;, ＆＃34; core_node_name＆＃34;：＆＃34; core_node7＆＃34 ;, ＆＃34; BASE_URL＆＃34;：＆＃34; http://10.10.10.21:8983/solr＆＃34 ;, ＆＃34; NODE_NAME＆＃34;：＆＃34; 10.10.10.21：8983_solr＆＃34;}

但是群集上的节点完全丢失，并且有重复的solr实例尝试启动。

此错误也出现在Solr日志中： HttpSolrCall null:org.apache.zookeeper.KeeperException$SessionExpiredException: KeeperErrorCode = Session expired for /roles.json

要解决问题，请解决solr的killall实例（如果你知道它是安全的java），并重新启动solr服务。

Solr问题：ClusterState说我们是领导者，但在本地我们并不这么认为

2 个答案: