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

Posted 2021-05-04

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

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

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

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

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

不幸的是，以上所有产生相同的行为。副本仍在进行恢复我们已将动物园管理员超时从30秒增加到5分钟并且问题仍然存在。有什么设置可以解决这个问题吗？

答案

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

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

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

更新当心图形查询

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