Solr报错：从ZooKeeper获取分片leader时出现信息冲突求助

遇到这种Solr从ZooKeeper获取leader失败的冲突问题不用慌，这本质是Solr节点本地缓存的分片leader信息与ZooKeeper中存储的权威元数据不一致，通常由节点重启、网络波动或ZK元数据更新不及时引发。下面是具体的排查和解决步骤：

步骤1：确认冲突节点的状态 #

• 分别访问两个冲突地址的Solr系统信息接口：
  • http://xxxxx:9003/solr/collectionname_shard2_replica1/admin/info/system
  • http://xxxxxx:9006/solr/collectionname_shard2_replica1/admin/info/system
• 检查这两个节点是否正常运行，以及它们的分片、副本配置是否匹配。大概率其中一个节点已经下线、重启过或端口被修改，但本地状态未同步。

步骤2：强制节点同步ZK元数据 #

如果是本地缓存过期导致的问题，最简单的解决方式是让节点重新拉取ZK元数据：

1. 停止出现报错的Solr节点服务；
2. 删除该节点本地的Solr状态缓存，常见路径为data/<collection_name>/shard2/replica1/core.properties或data/zoo_data（不同Solr版本路径可能有差异，可根据自己的配置调整）；
3. 重启该Solr节点，它会自动从ZK拉取最新的元数据，纠正本地状态。

步骤3：手动修正ZK中的Leader信息（步骤2无效时使用） #

如果ZK中的元数据本身存在错误，需要手动干预：

1. 使用ZK客户端（如zkCli.sh）连接到ZK集群；
2. 定位到分片shard2的leader节点路径：/solr/collections/collectionname/shards/shard2/leader；
3. 查看该节点存储的内容，确认是否为错误的http://xxxxxx:9006/solr/collectionname_shard2_replica1/；
4. 如果该地址对应的节点已不存在或确实错误，执行删除命令：delete /solr/collections/collectionname/shards/shard2/leader；
5. 之后Solr Cloud会自动重新选举新的Leader，所有节点会同步最新的Leader信息。

步骤4：排查底层稳定性问题 #

为了避免后续再出现类似问题，建议检查：

• 所有Solr节点与ZK集群的网络连通性，确保无延迟或分区问题；
• ZK集群的日志，查看是否有元数据更新失败、节点会话超时等异常记录；
• 确保ZK集群有足够的节点数（至少3个），避免单点故障导致元数据不一致。

预防措施 #

• 重启Solr节点时遵循规范流程：先停止节点，清理本地缓存后再启动；
• 定期通过http://<solr_host>:<port>/solr/admin/collections?action=CLUSTERSTATUS检查集群状态，确认分片与Leader的一致性；
• 避免频繁重启节点，减少元数据不一致的概率。

从ZooKeeper获取leader失败，具体异常为org.apache.solr.common.SolrException: 分片shard2的leader信息存在冲突：本地状态显示为http://xxxxx:9003/solr/collectionname_shard2_replica1/，但ZooKeeper显示为http://xxxxxx:9006/solr/collectionname_shard2_replica1/，异常栈信息为at org.apache.solr.cloud.ZkController.getLeader(ZkController.java:1013) at org.apache.solr.cloud.ZkController.register(ZkController.java:940) at org.apache.solr.cloud.ZkController.register(ZkController.java:883) at org.apache.solr.core.ZkContainer$2....

内容的提问来源于stack exchange，提问作者S Basu