重新加载 SOLR 核心或使用提交更新以刷新复制的索引文件？答案

【问题标题】：Reload SOLR core or update with commit to refresh the replicated index files?重新加载 SOLR 核心或使用提交更新以刷新复制的索引文件？
【发布时间】：2014-09-14 09:37:45
【问题描述】：

我使用 rsync 复制索引文件。我发现我必须提出以下要求 http://server.com:8080/solr4/core-name/update?commit=true

使 Slave 上的 index/gen 版本与 Master 上的版本匹配。但是，在 Slave 上更新 commit=true 需要很长时间。是否有任何其他方法可以使 Slave 上的同步索引文件可供搜索？

【问题讨论】：

标签： solr replication

【解决方案1】：

如果您正在执行手动复制（而不是真正的复制支持或 SolrCloud），您应该真的使用snap*-tools，而不是自己通过 rsync 来完成。这些将确保索引在更改时被复制，并在文件被同步时will make the index reader reopen the index。

最后一部分是需要提交的原因：在当前索引阅读器关闭并与新文件交换之前，新文件不可用。

【讨论】：

我希望，但我不能简单地升级以使用 SOLR 云。我一直在使用 4.1 并手动分片一段时间，我认为 4.1 存在一个已知错误，如果从节点轮询主节点，则会复制整个索引。这就是我尝试使用 rsync 的原因。
标准 HTTP 复制不需要 SolrCloud，这比 rsync 容易得多。快照程序/快照程序/等。如果您真的不想进行 http 复制（您应该这样做），则它们构建在 rsync 之上，因此请直接使用它们而不是 rsync。
我们一直在使用标准 HTTP 复制，直到我们认识到它每次都在每个分片上复制整个 500GB 索引并且它总是失败，因为它花费了太长时间。更不用说它导致主分片上的磁盘 IO 非常高，因此没有任何东西可以搜索。关于 snappuller/snapshooter，我认为这些脚本已被弃用？
是的，它们已被弃用，因为建议使用 HTTP 复制。没有什么可以阻止您使用它们，我建议您这样做而不是自己进行 rsync（因为它们是围绕使用 rsync 构建的）。 HTTP 复制应该只复制实际更改的文件，但取决于您如何提交，mergefactor 和优化可以是每个文件。