关于长索引重建期间的最佳实践/编程，我们有一个一般性的问题。这个问题不是“solr specific”的，它同样适用于原始Lucene或任何其他类似的索引工具/库/黑匣子。
问题
在长时间重建索引后确保Solr/Lucene索引“绝对最新”的最佳做法是什么，即，如果在12个小时的索引重建过程中，用户具有添加/更改/删除db记录或文件(PDF的)，您如何确保重建索引最终“包括”这些更改？
上下文
在Solr中建立索引的大型数据库和文件系统(例如pdfs)多核solr实例，其中core0用于“搜索”，而所有添加/更改/删除的core1用于“重建”。 Core1是“临时核心”。 重建结束后，我们将“core1”移动到“core0”，因此搜索和更新与新重建的db 背道而驰
当前方法
重建过程查询数据库和/或遍历文件系统以查找“所有数据库记录”或“所有文件”。如果在查询/文件系统遍历末尾出现新的db记录/pdf，则重建将“获取”新的db记录/pdf。 (例如，查询是“按element_id从元素顺序中选择*”。如果我们保持结果集为开放状态(即，而不是一次全部构建一个大列表)，那么结果集将包括末尾添加的条目。新文件被添加到“末尾”(新文件夹或新文件)，文件遍历将包括这些文件。重建将不会“获得”以下内容:对重建过程已经处理过的数据库记录/文档的更改或删除，“只是重新索引”
提议的方法
在Solr客户端中跟踪(即通过db表)在db/文件系统中发生的所有添加/更改/删除在重建结束时(但在交换核心之前)，请处理以下更改:即，从索引中删除所有已删除的记录/pdf，为所有更新和附加内容重新索引
跟随
是否有更好的方法 solt是否有任何魔术手段将core0“融合”到core1中
谢谢 有很多方法可以使这只猫皮肤化。...我猜想，在core1(也称为“在甲板上”的核心)的长时间索引过程中，您正在针对已经填充的core0(又称为“事件”的核心)运行用户查询。 。
如果您可以分辨出发生了什么变化，为什么不更新Live Core？如果您可以对实时核心和PDF的文件系统运行查询以找出哪些文档已更新和删除，则只需对实时核心进行所有操作，然后放弃此脱机过程即可。这将是最简单的...。只需将pdf的更新时间放入您的solr文档中，以检测哪些已更改。如果solr中不存在pdf，则添加它。保留一个Solr文档ID列表，最后，可以删除所有没有匹配的PDF的文档。同时，您仍然可以获取实时更新。您可以代理传入的实时更新并对其进行复用(？)，以便它们同时到达Core1和Core0。我建立了一个简单的代理接口(interface)，发现它非常简单。这样，您所有的更新都将同时到达两个核心，而您无需进行任何“对帐”。 最后，您可以合并两个核心:http://wiki.apache.org/solr/MergingSolrIndexes#Merging_Through_CoreAdmin我真的不知道会发生什么，但是如果您有两个具有相同ID的文档，或者一个核心中不存在一个文档，而另一个核心中存在一个文档……我假设这都是一个加法过程，但是您需要对此进行深入研究。
喜欢听听这是怎么回事!