Lucene有用的事务功能之一是索引持久性 ，它可以确保一旦成功调用IndexWriter.commit ，即使操作系统或JVM崩溃或断电，或者您杀死-KILL JVM进程，重启后索引也将保持完整（未损坏），并将反映崩溃前的最后一次成功提交。

当然，这仅在硬件运行状况良好且IO设备正确实现fsync（在操作系统要求时刷新其写缓存）的情况下才有效。 如果您遇到数据丢失的问题，例如内存，IO或CPU路径中的静默位翻转器，则得益于Lucene 4.8.0和Lucene中提供的新的端到端校验和功能 （ LUCENE-2446 ）现在在索引或CheckIndex期间也将检测到该CheckIndex 。 这类似于ZFS文件系统的块级校验和，但并不是每个人都使用ZFS（呵呵），因此Lucene现在在文件系统之上进行自己的校验和验证。

确保通过调用IndexWriterConfig.setCheckIntegrityAtMerge启用合并期间的校验和验证。 将来，我们希望删除该选项，并始终在合并时验证校验和，并且我们已经针对LUCENE-5580中的默认存储字段格式和LUCENE-5602中的 （很快）术语向量格式以及设置低级IO API，以便其他编解码器组件也可以使用LUCENE-5583 （适用于Lucene 4.8.0）做到这一点。

FileDescriptor.sync和fsync

在后台，当您调用IndexWriter.commit ，Lucene将收集自上次提交以来所有新写入的文件名，并在每个文件名上调用FileDescriptor.sync以确保所有更改都移至稳定的存储中。

从本质上讲 ， fsync是一项复杂的操作，因为操作系统必须从其IO缓冲区高速缓存中清除与指定文件关联的所有脏页，并与基础IO设备一起使用以确保其写入高速缓存也得以刷新，并且也可以正常工作文件系统以确保其完整性得以保留。 您可以单独同步文件的字节或元数据，也可以同步包含文件的目录。
这篇博客文章很好地说明了挑战。

最近，我们一直在仔细研究Lucene的这些部分，所有这些注意都发现了一些令人兴奋的问题！

在LUCENE-5570 （将在Lucene 4.7.2中修复）中，我们发现FSDirectory实现中的fsync实现能够引入新的0字节文件。 通常，这本身并不是问题，因为IndexWriter不应同步未创建的文件。 但是，当IndexWriter或使用Lucene的应用程序中存在错误时，它会加剧调试（例如，直接删除不应删除的索引文件）。 在这些情况下，这么长时间后才发现这些0字节的文件很混乱，而不是在IndexWriter尝试对它们进行同步时命中FileNotFoundException 。

在LUCENE-5588 （要在Lucene 4.8.0中修复）中，我们意识到我们还必须同步包含索引的目录，否则在操作系统崩溃或断电时，该目录可能不会链接到新创建的文件，或者您将无法通过文件名查找文件。 这显然很重要，因为Lucene会列出目录以查找所有提交点（ segments_N文件），并且当然还会按文件名打开文件。

由于Lucene不依赖文件元数据（例如访问时间和修改时间），因此很容易使用fdatasync （或Java中的FileChannel.force（false） ）仅对文件的字节进行fsync。 但是，这是一种优化，目前我们专注于错误。 此外，这可能不会很快，因为如果文件长度已更改，则元数据仍必须由fdatasync进行同步，这在Lucene中通常是这样，因为我们仅在写入时才追加到文件（我们删除了Indexoutput.seek在LUCENE-4399中 ）。

在LUCENE-5574 （自Lucene 4.7.2起修复）中，我们发现关闭时接近实时的读取器可以删除文件，即使从中打开的写入器已关闭。 通常，这本身就不是问题，因为只要使用Lucene的API且自己不要修改索引文件，Lucene就会一次写入（一次不写入同一文件名）。 但是，如果通过将文件复制到索引中来实现自己的索引复制，并且如果您不首先关闭近实时读取器，则关闭它们可能会删除刚复制的文件。

在任何给定的索引会话期间，Lucene都会写入并关闭许多文件，合并后会删除许多文件， IndexWriter.commit ，直到以后，当应用程序最终调用IndexWriter.commit ， IndexWriter才会按顺序重新打开新创建的文件获取FileDescriptor，以便我们对其进行fsync 。

这种方法（关闭原始文件，然后再打开以进行同步），而不是从不关闭原始文件并同步您用于写入的相同文件句柄，这种方法可能是冒险的： FileDescriptor.sync的javadocs有点模糊关于这种方法是否安全。 但是，当我们查看Unix / Posix上的fsync和Windows上的FlushFileBuffers的文档时，他们清楚地表明这种做法很好，因为打开文件描述符实际上仅是确定要同步哪个文件的缓冲区所必需的。 很难想象会有一个操作系统单独跟踪哪个打开的文件描述符对文件进行了哪些更改。 但是，出于偏执狂或谨慎起见，我们还在探索LUCENE-3237上可能的补丁程序，以仅同步最初打开的文件。

测试fsync确实有效

在应用程序对IndexWriter.commit的调用与物理定律之间的所有这些复杂层之间，确保了很少的磁体被翻转或少数电子被移动到NAND单元中的微小浮动栅中 ，我们如何才能可靠地测试整个序列抽象实际上是有效的吗？

在Lucene的随机测试框架中，我们有一个称为MockDirectoryWrapper的不错的Directory实现。 它可以执行各种令人讨厌的事情，例如引发随机异常，有时会减慢某些文件的打开，关闭和写入速度，拒绝删除仍在打开的文件（例如Windows），在仍然有打开的文件时拒绝关闭等。随着时间的推移，它帮助我们发现了各种有趣的错误。

它关闭时要做的另一件事是通过随机破坏任何未压缩的文件来模拟操作系统崩溃或断电，然后确认索引没有破坏。 这对于捕获Lucene错误很有用，而在我们应该按时未能调用fsync的情况下，但它不会捕获我们在FSDirectory类中实现sync的错误，例如令人沮丧的LUCENE-3418 （最初出现在Lucene 3.1中，最后出现在在Lucene 3.4中修复）。

因此，为了捕获此类错误，我创建了一个基本的测试设置，使用了一个简单的Insteon 开/关设备以及我很久以前创建的与Insteon设备进行交互的自定义​​Python绑定。 我已经在家里的所有地方使用这些设备来控制灯光和电器，因此将其用于Lucene是我的两个爱好的完美结合！

该脚本永远循环，首先更新源代码，进行编译，检查索引是否损坏，然后开始进行索引设置并在设置中进行一些随机化，最后等待几分钟，然后切断电源。 然后，它恢复电源，等待机器再次响应，然后再次启动。

到目前为止，已经完成了80个电源循环，而且还没有损坏。 好消息！

为了“测试测试人员”，我尝试临时更改fsync使其不执行任何操作，实际上，经过几次迭代，索引已损坏。 因此，实际上测试设置似乎“有效”。

目前，该测试在带有ext4文件系统的旋转磁铁硬盘上使用Linux。 这只是一个开始，但是总比没有对Lucene的fsync进行适当的测试要好。 随着时间的流逝，我希望测试操作系统，文件系统，IO硬件等的不同组合。

翻译自: https://www.javacodegeeks.com/2014/04/testing-lucenes-index-durability-after-crash-or-power-loss.html