Solrcloud副本在更新后立即进入恢复模式

Question

我们有一个solr云服务器集群，在我们的压力环境中每个分片中有10个分片和4个副本。在我们的产品环境中，每个碎片中将有10个碎片和15个复制品。我们当前的提交设置如下

    *<autoSoftCommit>
        <maxDocs>500000</maxDocs>
        <maxTime>180000</maxTime>
    </autoSoftCommit>
    <autoCommit>
        <maxDocs>2000000</maxDocs>
        <maxTime>180000</maxTime>
        <openSearcher>false</openSearcher>
    </autoCommit>*

我们索引了大约9000万个文档。我们有两种不同的方法来索引文档 a）完整索引。索引9000万个文档需要4个小时，搜索者的文档速率大约是每秒6000个 b）增量索引。索引增量变化需要一个小时。大约有300万次变化，搜索者的文档率达到每秒2500次

我们有两个集合search1和search2。当我们进行完整索引时，我们在search2集合中执行此操作，而search1正在为实时流量提供服务。完成后，我们使用别名交换集合，以便search2集合提供实时流量，而search1可用于下一次完整索引运行。 当我们进行增量索引时，我们会在为实时流量提供服务的search1集合中执行此操作。

我们所有的搜索者都有12 GB的RAM可用，并拥有四核Intel（R）Xeon（R）CPU X5570 @ 2.93GHz 我们在触发索引时发现了以下问题。 在我们触发14个并行主机上的索引后大约10分钟内，副本进入恢复模式。所有碎片都会发生这种情况。在大约20分钟内，越来越多的副本开始进入恢复模式。大约半小时后，除领导者外的所有复制品都处于恢复模式。我们无法限制索引负载，因为这会增加我们的整体索引时间。因此，要解决此问题，我们会在触发索引之前删除所有副本，然后在索引完成后将其添加回来。

当我们进行增量索引时，我们观察到复制品进入恢复的相同行为。我们无法在增量索引期间删除副本，因为它还提供实时流量。我们试图限制我们的索引速度，但群集仍然会恢复。

如果我们离开集群，当索引完成时，它最终会在一段时间后恢复。我们的测试显示，由于它正在为实时流量提供服务，因此我们不能让这些副本进入恢复模式，因为它也会降低搜索性能。

我们尝试过不同的提交设置，如下所示

a）没有自动软提交，没有自动硬提交和提交触发     在索引结束时  b）没有自动软提交，是自动硬     在索引结束时提交和提交
c）是自动软提交，没有自动硬提交
d）是自动软提交，是自动硬提交
 e）针对上述提交的不同频率设置

不幸的是，以上所有都会产生相同的行为。复制品仍在恢复中 我们将zookeeper超时从30秒增加到5分钟，问题仍然存在。 有没有可以解决这个问题的设置？

Answer 1

垃圾收集暂停可能超过clientTimeout，导致Zookeeper连接中断，导致无限循环恢复。

频繁的优化，提交或更新，以及调整不佳的段合并配置可能会在恢复时导致过多的开销。这种开销会导致恢复循环。

最后，我们的组织在恢复期间似乎遇到了某种类型的错误。这种情况很少见，但似乎在网络连接抖动或不可靠的时候发生。 Zookeeper断开连接会触发恢复，恢复会激活内存，有时甚至会导致内存不足。

更新 小心图形查询

组织我在Solr的图表查询中经历了有经验的暂停。图形查询是提前输入插件/组件的一部分。当有人为提前输入提交长字符串时，图形查询变得复杂，并导致大量内存使用和gc暂停。