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

Question

我们有一个 solr 云服务器集群，在我们的压力环境中，每个分片中有 10 个分片和 4 个副本。在我们的 prod 环境中，我们将在每个分片中有 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) 上述提交的不同频率设置

不幸的是，以上所有结果都产生了相同的行为。副本仍在恢复中
我们将 zookeeper 超时从 30 秒增加到 5 分钟，但问题仍然存在。
有什么设置可以解决这个问题吗？

Answer 1

Garbage Collection 暂停可能会超过 clientTimeout，导致 Zookeeper 连接中断，从而导致无限循环恢复。

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

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

更新 当心图表查询

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