Question

我有一个5核solr 1.4 master，使用solr复制复制到另一个5核solr，如here所述。所有写操作都是针对主设备完成的，并间歇性地复制到从设备。这是使用以下顺序完成的：

承诺每个主核心
在每个从属核心上复制
优化每个从属核心
承诺每个奴隶核心

我遇到的问题是，奴隶似乎在保留旧的索引文件并占用更多的磁盘空间。例如，在3次复制之后，主核心数据目录如下所示：

$ du -sh *
145M    index

但是同一核心的slave上的数据目录如下所示：

$ du -sh *
300M    index
144M    index.20100621042048
145M    index.20100629035801
4.0K    index.properties
4.0K    replication.properties

这是index.properties的内容：

#index properties
#Tue Jun 29 15:58:13 CDT 2010
index=index.20100629035801

和replication.properties：

#Replication details
#Tue Jun 29 15:58:13 CDT 2010
replicationFailedAtList=1277155032914
previousCycleTimeInSeconds=12
timesFailed=1
indexReplicatedAtList=1277845093709,1277155253911,1277155032914
indexReplicatedAt=1277845093709
replicationFailedAt=1277155032914
lastCycleBytesDownloaded=150616512
timesIndexReplicated=3

此从属服务器的solrconfig.xml包含默认删除策略：

[...]
<mainIndex>
    <unlockOnStartup>false</unlockOnStartup>
    <reopenReaders>true</reopenReaders>
    <deletionPolicy class="solr.SolrDeletionPolicy">
        <str name="maxCommitsToKeep">1</str>
        <str name="maxOptimizedCommitsToKeep">0</str>
    </deletionPolicy>
</mainIndex>
[...]

我错过了什么？

Answer 1

在奴隶上提交和优化是没用的。由于所有写操作都是在主服务器上完成的，因此它是唯一可以进行这些操作的地方。

这可能是导致问题的原因：由于您对从属设备进行了额外的提交和优化，因此它会在从属设备上保留更多提交点。但这只是猜测，应该更容易理解主服务器和从服务器上的完整solrconfig.xml会发生什么。

Answer 2

在slave上完成的优化导致索引的大小加倍。将创建优化单独索引段以将原始索引重写为优化期间提到的段数（默认值为1）。最佳做法是偶尔优化，不要在任何事件中调用它（运行cron作业或其他东西）并仅在master而不是slave时进行优化。奴隶将通过复制获得这些新的细分。您不应该在slave上提交，索引重新加载将在复制后处理从属服务器上新文档的可用性。

Answer 3

我确定在完全重新加载主服务器后复制时，额外的索引。*目录似乎被遗忘了。 “完全重新加载”的意思是停止主控，删除[core] / data / *下的所有内容，重新启动（此时solr创建一个新索引），索引所有文档，然后复制。

基于一些额外的测试，我发现删除其他索引*目录（除了[core] /data/index.properties中指定的目录之外）似乎是安全的。如果我对这种解决方法不满意，我可能会在完全重新加载主服务器之后第一次复制之前决定清空从属索引（停止;删除数据/ *;启动）。

为什么我的solr slave索引会继续增长？

3 个答案: