Solr 解决 NFS 问题

Question

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

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

问题：

1. 鉴于上面描述的应用场景（没有并发索引修改），NoLockFactory应该不够吗？使用 NoLockFactory 有什么缺点吗？如果我设置 NoLockFactory，我会在错误日志中看到许多条目，说“配置警告：锁定已禁用”。为什么该消息会进入错误日志？这真的被认为是一个错误案例吗？为什么？

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

3. 不确定这是否与 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。

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

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