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

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

我们在两种情况下遇到过此错误。

条件1

在单个 Zookeeper 主机上，有一个孤立的 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 You will need to restart the Solrhosts as well to解决问题。

条件2

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

systemd 没有正确跟踪 PID，它认为该服务已死亡，但事实并非如此，并且在某个时刻启动了 2 个服务。因为第二个服务将无法启动（因为它们都无法在同一端口上侦听），所以它似乎只是处于挂起的失败状态，或者无法启动进程，但只是以某种方式搞乱了其他 solr 进程通过可能在本地覆盖临时集群状态文件。

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

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

{“core”：“collection-name_shard1_replica1”，“core_node_name”：“core_node7”，“base_url”：“ http://10.10.10.21:8983/solr ”，“node_name”：“10.10.10.21:8983_solr”}

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

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

要解决此问题，请终止 solr（或 java，如果您知道它是安全的）的所有实例，然后重新启动 solr 服务。

Answer 2

我们想通了！问题是 jetty 并没有真正停止，所以我们有 2 个正在运行的进程，无论出于何种原因，这对于读取来说都很好，但对于写入来说却不好。

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