Solr 解决 NFS 问题

Question

我们的应用程序使用嵌入式 Solr 实例进行搜索。数据目录位于 NFS 上，我无法更改它。 Solr 的使用非常简单，只有一个线程定期更新索引，还有多个读取器线程——这些都在一个 java 进程中。不会发生其他 Solr 交互。

使用默认的“solrconfig.xml”，我有时会遇到“java.nio.channels.OverlappingFileLockException”。据我了解，原因实际上是“SimpleFSLockFactory”无法与 NFS 正常工作。

问题:

考虑到上面描述的应用场景(没有并发索引修改)，NoLockFactory 是不是应该就够了？使用 NoLockFactory 有什么缺点吗？如果我设置了 NoLockFactory，我会在错误日志中得到许多条目，上面写着“配置警告:锁被禁用”。为什么该消息会进入错误日志？这真的被认为是一个错误案例吗？为什么？

也许有比使用“NoLockFactory”更好的解决方案？

不确定这是否与 NFS 相关，但有时(非常罕见)我的索引被损坏，并且在尝试更新索引时出现很多“java.io.FileNotFoundException:_i.fdx”。除了手动删除整个索引目录并从头开始之外，别无他法。为什么会发生这种情况，是否有任何优雅的方法可以自动检测损坏的索引并进行恢复？

Answer 1

在 NFS 上存储索引很容易出现问题，但如果它必须在 NFS 上运行，我预测这个问题可能是由于没有使用 NFSv4，或者没有正确使用它。 NFSv4 是第一个支持的版本 锁定字节范围 、NFSv2 和 v3(较差)支持整个文件，并且不运行 portmap、rpc.lockd 和 rpc.statd - 这些锁可能只是建议性的(而不是强制性的)，但绝对不会涵盖字节范围锁定。

java.nio.channels.OverlappingFileLockException说

Unchecked exception thrown when an attempt is made to acquire a lock on a region of a file 
that overlaps a region already locked by the same Java virtual machine, or when another 
thread is already waiting to lock an overlapping region of the same file.

粗略搜索 Lucene 邮件列表会返回许多结果，这些结果似乎表明在 NFS 上使用 Lucene(以及，通过扩展，Solr)是 bad idea .

撇开锁定问题不谈，性能可能也会很差。

我知道这不是您希望的答案，但它是您需要的答案。