Solr 1.4 企业搜索服务器建议对核心副本进行大量更新，然后将其交换为主核心。我正在执行以下步骤：

1. 创建准备核心：
2. 执行索引更新，然后在准备核心上提交/优化。
3. 交换主核心和预备核心：
4. 卸载准备核心：

我遇到的问题是，步骤 1 中创建的核心中没有任何数据。如果我要对所有东西和厨房水槽进行完整索引，那就没问题，但如果我只想更新文档的（大）子集 - 这显然是行不通的。

（我可以合并核心，但我想做的一部分是删除所有已删除的文档，而不尝试列出它们。）

我缺少一些 CREATE 操作标志吗？这CoreAdmin 的 Solr Wiki 页面 http://wiki.apache.org/solr/CoreAdmin细节上有点稀疏。

可能的解决方案：复制

solr-user 上的有人建议使用复制。要在这种情况下使用它（据我理解）需要以下步骤：

1. 根据 MA​​IN 核心的配置创建一个新的 PREP 核心
2. 将 MAIN 核心的配置更改为 master
3. 将 PREP 核心的配置更改为从属
4. 原因/等待同步？
5. 更改 PREP 核心的配置，使其不再是从属核心
6. 执行索引更新，然后在 PREP 核心上提交/优化。
7. 交换 PREP 和 MAIN 核心

一个更简单的基于复制的设置是配置一个始终是主节点的永久 PREP 核心。然后，MAIN 核心（根据需要位于任意数量的服务器上）可以成为 PREP 核心的从属核心。索引可以根据需要在 PREP 核心上快速或缓慢地进行。

可能的解决方案：永久PREP核心和双重更新

我想到的另一个想法是（也涉及永久的 PREP 核心）：

1. 执行索引更新，然后在 PREP 核心上提交/优化。
2. 交换 PREP 和 MAIN 核心。
3. 重新执行索引更新，然后提交/优化现在的 PREP 核心。它现在拥有与 MAIN 核心相同的数据（理论上），并将存在，为下一次索引操作做好准备。

我创建了克隆操作的想法，该操作对索引和配置数据进行文件系统复制，然后创建一个新的。存在一些锁定问题，并且您必须具有对索引的文件系统访问权限，但它确实有效。这确实给了你一个很好的副本，你可以用它来处理配置文件。

我想得越多，你可以创建一个新的核心，然后执行以下操作：

从主命令强制在从设备上获取索引：http://slave_host:port/solr/replication?command=fetchindex http://slave_host:port/solr/replication?command=fetchindex可以传递额外的属性“masterUrl”或其他属性，例如“压缩”（或标记中指定的任何其他参数）以从主服务器进行一次性复制。这消除了在从机中对主机进行硬编码的需要。

并从生产版本中填充新版本，然后应用更新，然后交换回来！