中国好公司网站建设,购物网站建设好处,云南建设局网站,做网站要是要求吗Lucene有用的事务功能之一是索引持久性 #xff0c;它可以确保一旦成功调用IndexWriter.commit #xff0c;即使操作系统或JVM崩溃或断电#xff0c;或者您杀死-KILL JVM进程#xff0c;重启后索引也将保持完整#xff08;未损坏#xff09;#xff0c;并将反映崩溃前的… 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.forcefalse 仅对文件的字节进行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
