apache - Solr 问题 : ClusterState says we are the leader, 但本地我们不这么认为

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)

我们在 jetty 上以集群模式(5 个分片)运行 Solr 4.7。每个分片运行在具有一台 Zookeeper 服务器的不同主机上。

我检查了 Zookeeper 日志，但看不到任何内容。

唯一的区别是，在/overser_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 。与该临时节点关联的 session 不再存在。

无法删除孤立的临时节点。原因: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 服务单元配置错误。确保您有Type=forking并有PIDFile如果您使用的是 systemd，则配置正确。

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

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

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

{"core":"集合名称_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 服务。