【问题标题】:solr query gives different numFound upon refreshingsolr 查询在刷新时给出不同的 numFound
【发布时间】:2020-08-18 20:52:21
【问题描述】:

我已经设置了具有 3 个节点、3 个副本和 10 个集合的 Solr 7.4 集群。

我面临一个问题,刷新 Solr 查询可能会产生不同的结果(返回的文档数(15581943))。此问题在所有集合中都可见。

我认为给定分片的副本不完全同步。

如何检查并解决此问题?

【问题讨论】:

  • shards.info=true 附加到您的查询中,并且响应应包含有关每个分片的numFound 值的信息。这应该告诉你哪个节点是问题。
  • .. 一个可能的建议是删除该特定分片,然后重新添加它。
  • @MatsLindh 非常感谢。我在使用shards.info = true 时发现了一个问题。为什么会出现这个问题?我怎样才能防止它发生?
  • 通常它应该被节点捕获。我会先尝试升级到最新版本的 Solr,并检查更改日志中是否有任何内容表明 htis 等问题已得到修复。我对 Solr Cloud 如何确定复制时间和复制内容的低级细节不够熟悉,无法说出更有用的信息,抱歉。
  • @MatsLindh 我找到了这个解决方案,我认为它很有用lucene.apache.org/solr/guide/7_4/…

标签: solr


【解决方案1】:

非常感谢@MatsLindh 我通过 min_rf 参数解决了这个问题。

Solr 支持更新请求上的可选 min_rf 参数,这会导致服务器在响应中为更新请求返回已实现的复制因子。对于上述示例场景,如果客户端应用程序包含 min_rf >= 1,则 Solr 将在 Solr 响应标头中返回 rf=1,因为请求仅在领导者上成功。更新请求仍将被接受,因为 min_rf 参数仅告诉 Solr 客户端应用程序希望知道更新请求所获得的复制因子是多少。换句话说,min_rf 并不意味着 Solr 将强制执行最小复制因子,因为 Solr 不支持回滚在副本子集上成功的更新。

在客户端,如果实现的复制因子低于可接受的水平,则客户端应用程序可以采取额外措施来处理降级状态。例如,客户端应用程序可能希望记录在集合状态降级时发送了哪些更新请求,然后在问题解决后重新发送更新。简而言之,min_rf 是一种可选机制,用于在集合处于降级状态时警告客户端应用程序接受了更新请求。

you can see more details in this link

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2019-02-06
    • 1970-01-01
    相关资源
    最近更新 更多