SolrCloud DIH索引异常：处理数与查询数不符及主节点选举缓慢

问题描述 #

1. DIH索引完成后显示已获取并处理10万条文档，但/select查询仅返回99999条，随机缺失部分文档，且solr.log无相关报错；
2. 主副本节点宕机后，新主节点选举耗时过长。

环境信息 #

• solr-9.0.0
• openjdk-11.0.2
• 堆内存：默认配置
• 部署：Jetty服务器，SolrCloud含4个实例，搭配3个Zookeeper实例

重现步骤 #

1. 启动SolrCloud集群（4实例）与ZK集群（3实例）；
2. 配置DIH从SQL Server导入数据：SQL表存储TXT文件路径，通过自定义Transformer读取文件内容导入Solr；
3. 创建集合：1分片，副本因子2（1个NRT副本、1个TLOG副本），集群内2个实例为主副本，2个为非主副本；
4. 导入约10万条文档（多数<10KB，约100条为10-60MB）；
5. 索引过程中重启2个不同分片的非索引发起节点，模拟主副本宕机验证容错性。

排查方案 #

针对DIH计数与查询结果不符的问题 #

• 验证TLOG完整性：检查主副本和TLOG副本的tlog文件（路径：server/solr/<collection>/shard<replica>/data/tlog），搜索缺失文档的ID，确认是否存在对应的日志记录。若缺失，说明该文档未写入TLOG，可能是节点宕机时刚好在处理该文档；
• 排查自定义Transformer静默失败：在Transformer代码中添加详细日志，记录每个文档的处理开始、结束状态，尤其是10-60MB的大文件，检查是否有处理中断但未抛出异常的情况（比如内存不足导致线程终止）；
• 确认DIH提交策略：查看DIH配置中的提交参数（如commitWithin、maxDocsPerCommit），确认最后一批文档是否触发了自动提交。手动执行/update?commit=true后重新查询，若缺失文档出现，说明最后一批提交未触发；
• 检查分片一致性：调用/replication?command=details API，查看主副本与TLOG副本的同步状态，确认是否有文档未完成同步，或主副本本身存在数据丢失。

针对主节点选举耗时过长的问题 #

• 检查ZooKeeper集群状态：查看ZK日志（zookeeper.out）是否有超时、连接异常，用zkServer.sh status确认ZK节点角色（leader/follower）正常，确保ZK集群网络延迟低、无丢包；
• 调整Solr选举参数：在solr.xml中修改选举相关参数，比如缩短leaderVoteWait（默认10秒）、调整leaderVoteRetries，减少选举等待时间；
• 监控节点资源负载：索引大文件时易导致CPU、内存、磁盘IO耗尽，引发节点假死，导致ZK会话未及时过期延迟选举。监控节点资源使用率，必要时调整堆内存（如增大-Xmx）、优化大文件索引逻辑；
• 排查网络稳定性：用ping、traceroute测试Solr节点间及Solr与ZK间的网络连通性，排除网络延迟、丢包导致的选举消息传递缓慢。

内容的提问来源于stack exchange，提问作者Rushi Kadivar