Solr分片处于recovery状态但副本均为active，分片不可用求解决方案

针对你遇到的Solr 6.5.1集群中shard2状态显示recovery但所有副本都是active，导致分片无法正常执行查询或索引操作的问题，我分享几个经过生产环境验证的解决步骤：

1. 先通过Solr API强制刷新集合状态 #

首先尝试官方推荐的集合重载操作，让Solr重新同步集群状态：

curl -X POST "http://任意Solr节点IP:8983/solr/admin/collections?action=RELOAD&name=Master&wt=json"

执行后等待1-2分钟，再通过Solr Admin UI的Cloud页面，或者调用/admin/collections?action=CLUSTERSTATUS&collection=Master接口查看集群状态，确认shard2是否恢复为active。

2. 检查ZooKeeper中的集群元数据 #

如果重载操作无效，大概率是ZK存储的集群状态元数据和实际副本状态不一致：

• 连接到ZK集群：

./zkCli.sh -server your_zk_host:2181  # 替换为你的ZK节点地址

• 获取当前集群状态：

get /solr/clusterstate.json

找到shard2对应的节点，确认它的state字段确实是recovery。

• 务必先备份原元数据：把获取到的内容保存到本地文件（比如clusterstate_backup.json），防止操作失误破坏集群。

3. 手动修正ZK中的分片状态 #

修改备份的clusterstate_backup.json文件，将shard2的state值从recovery改为active，然后将修改后的内容重新写入ZK：

set /solr/clusterstate.json "$(cat clusterstate_backup_modified.json)"

设置完成后，再次查看集群状态，确认分片状态是否更新。

4. 重新选举分片Leader（可选） #

如果以上操作后问题仍存在，可以尝试强制重新选举shard2的Leader，同步状态信息：

curl -X POST "http://任意Solr节点IP:8983/solr/admin/collections?action=REASSIGNLEADER&collection=Master&shard=shard2&wt=json"

5. 检查Solr节点日志排查根源 #

如果所有操作都无效，建议查看shard2两个副本所在节点的solr.log，搜索shard2或recovery相关的日志，看看是否有异常（比如ZK连接超时、文件系统权限问题、recovery过程中某个步骤卡住），这些日志能帮你定位问题根源，避免以后重复出现。

注意事项 #

• 操作ZK元数据前一定要备份，避免破坏整个集群状态；
• 执行API操作时，确保使用的集合名正确（你的集合名是Master，从副本名Master_shard2_replica2可判断）；
• 生产环境建议在低峰期操作，减少对业务的影响。

内容的提问来源于stack exchange，提问作者Mark Sholund