SolrCloud与Solr主从复制

本周我遇到了一个关于Solr索引的问题：

今天，几乎每一个请求都会出现这种错误，我创建了一个JIRA问题，因为我认为这是一个bug

正如您所看到的，最后是由于Solr主从复制失败，现在我不知道我们是否应该考虑迁移到SolrCloud，因为Solr主从复制似乎不适合我们的要求：

• 索引大小：~2000万个文档，~9GB
• 约1200次更新/分钟
• 约10000个查询/分钟（分布在2个从属服务器上），更多类似于此，RealTimeGet，TermVectorComponent，SearchHandler

如果有人能帮我回答以下问题，我将不胜感激：

• 迁移到索尔克劳德是否明智？它会对复制性能产生影响吗
• 在这种情况下，什么会有更好的性能？在每台服务器中维护索引的副本，还是使用碎片服务器
• 为确保高可用性，您建议使用多少个碎片和副本

亲切问候,

---

维克多

好吧，你所有问题的答案取决于你到底想从索尔克劳德那里得到什么

• 是的，最好改用solrcloud，因为它提供了高可用性、可扩展性和近实时搜索以及自动化的热复制。但这些功能的代价是性能略有下降（即使在配置良好的集群中，您也需要注意）
• 我建议您使用共享配置，以允许solr为您维护索引数据（我相信，如果您这样做，您将为TechOps人员带来微笑）。这将减少人为错误和资源需求
• 上一个问题的答案完全取决于您的云部署。您应该尝试使用2个碎片2个副本配置，然后创建测试部署以确保它满足您的需要。如果没有，请尝试使用碎片和副本计数的不同组合，直到您得到您想要的（我知道它的痛苦！）

---

最后，别忘了估计您未来的增长（未来几年您将向集群添加多少数据），请记住您应该决定碎片和副本

如果您可以稍等，Solr 5将在明年推出，它有一系列积极的变化，进一步支持SolrCloud。IMO 4.x对SolrCloud的支持需要大量的进一步维护，所以如果您可以等待，我将等待。同时决定如何切分也很糟糕。我在阅读了本文后解决了这个问题，我可以理解，根据我们的要求（索引重、查询重），软提交时间配置错误，我们有太多的软提交，但我们不需要实时提供数据。因此，正如文章所建议的，我尝试将软提交间隔设置得很长，但硬提交间隔设置得很小，在我的例子中是15秒。此外，通过发送包含多个项目的“批量”更新消息来优化索引过程，而不是为每个被索引的项目发送一个请求，选择更好的策略缓存查询结果，有助于减少solr服务器中的负载，并提高所提供服务的总体质量