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 的可用 RAM，并拥有四核 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 暂停。