1

当我运行 Nutch 并且链接不再存在时,我可以运行该readdb命令,它显示有标记为db_gone.

所以我运行 SolrClean 命令,它说:

SolrClean deleting a total of 1 documents

这是正确的,但没有从 Solr 中删除

帮助?

如果您想检查我的配置,那么我有一个博客,其中介绍了我自己的 Solr/Nutch 设置是如何配置的。

编辑

很有可能不仅仅是 SolrClean 命令不起作用,我觉得这与我的设置有关,其中没有提交删除?

这是为文档发出的删除请求 - 但文档存在:

INFO  - 2013-08-09 15:54:52.729; 
org.apache.solr.update.processor.LogUpdateProcessor; [collection1] webapp=/solr path=/update params={wt=javabin&version=2} 
{delete=file:/C:/Users/alamil/Documents/TextFiles/Y2012.doc 
(-1442903587791306752)]} 0 2

这是整个日志:

 INFO  - 2013-08-09 15:54:51.785; org.apache.solr.search.SolrIndexSearcher; Opening Searcher@f5331a main
INFO  - 2013-08-09 15:54:51.786; org.apache.solr.core.QuerySenderListener; QuerySenderListener sending requests to Searcher@f5331a main{StandardDirectoryReader(segments_7w:549:nrt _6j(4.3.1):C12/11 _6k(4.3.1):C12)}
INFO  - 2013-08-09 15:54:51.787; org.apache.solr.core.QuerySenderListener; QuerySenderListener done.
INFO  - 2013-08-09 15:54:51.787; org.apache.solr.update.DirectUpdateHandler2; end_commit_flush
INFO  - 2013-08-09 15:54:51.788; org.apache.solr.core.SolrCore; [collection1] Registered new searcher Searcher@f5331a main{StandardDirectoryReader(segments_7w:549:nrt _6j(4.3.1):C12/11 _6k(4.3.1):C12)}
INFO  - 2013-08-09 15:54:51.789; org.apache.solr.update.processor.LogUpdateProcessor; [collection1] webapp=/solr path=/update params={waitSearcher=true&commit=true&wt=javabin&waitFlush=true&version=2} {commit=} 0 903
INFO  - 2013-08-09 15:54:52.053; org.apache.solr.core.SolrCore; [collection1] webapp=/solr path=/select params={fl=id&q=id:[*+TO+*]&wt=javabin&version=2&rows=1} hits=13 status=0 QTime=1 
INFO  - 2013-08-09 15:54:52.355; org.apache.solr.core.SolrCore; [collection1] webapp=/solr path=/select params={fl=id&q=id:[*+TO+*]&wt=javabin&version=2&rows=1} hits=13 status=0 QTime=0 
INFO  - 2013-08-09 15:54:52.413; org.apache.solr.core.SolrCore; [collection1] webapp=/solr path=/select params={fl=id,boost,tstamp,digest&start=0&q=id:[*+TO+*]&wt=javabin&version=2&rows=13} hits=13 status=0 QTime=1 
INFO  - 2013-08-09 15:54:52.729; org.apache.solr.update.processor.LogUpdateProcessor; [collection1] webapp=/solr path=/update params={wt=javabin&version=2} {delete=[file:/C:/Users/alamil/Documents/TextFiles/Y2012.doc (-1442903587791306752)]} 0 2
INFO  - 2013-08-09 15:54:52.733; org.apache.solr.update.DirectUpdateHandler2; start commit{,optimize=false,openSearcher=true,waitSearcher=true,expungeDeletes=false,softCommit=false,prepareCommit=false}
INFO  - 2013-08-09 15:54:52.835; org.apache.solr.core.SolrDeletionPolicy; SolrDeletionPolicy.onCommit: commits:num=2
commit{dir=NRTCachingDirectory(org.apache.lucene.store.SimpleFSDirectory@C:\Users\alamil\Documents\Test\solr_home\data\index lockFactory=org.apache.lucene.store.NativeFSLockFactory@1ae0e7d; maxCacheMB=48.0 maxMergeSizeMB=4.0),segFN=segments_7w,generation=284,filenames=[_6j_1.del, _6k_Lucene41_0.pos, segments_7w, _6j.nvd, _6j_Lucene41_0.tim, _6j_Lucene41_0.tip, _6k.fdt, _6k.fnm, _6j_Lucene41_0.pos, _6j.nvm, _6k_Lucene41_0.doc, _6k_Lucene41_0.tim, _6k.si, _6j.si, _6k.nvd, _6k.fdx, _6j_Lucene41_0.doc, _6j.fdt, _6k.nvm, _6j.fdx, _6k_Lucene41_0.tip, _6j.fnm]
commit{dir=NRTCachingDirectory(org.apache.lucene.store.SimpleFSDirectory@C:\Users\alamil\Documents\Test\solr_home\data\index lockFactory=org.apache.lucene.store.NativeFSLockFactory@1ae0e7d; maxCacheMB=48.0 maxMergeSizeMB=4.0),segFN=segments_7x,generation=285,filenames=[_6j_1.del, _6k_Lucene41_0.pos, _6j.nvd, _6j_Lucene41_0.tim, _6j_Lucene41_0.tip, _6k.fdt, _6k.fnm, _6j_Lucene41_0.pos, _6j.nvm, _6k_Lucene41_0.doc, _6k_Lucene41_0.tim, _6k.si, _6j.si, _6k.nvd, _6k.fdx, segments_7x, _6j_Lucene41_0.doc, _6j.fdt, _6k.nvm, _6j.fdx, _6k_Lucene41_0.tip, _6j.fnm]
INFO  - 2013-08-09 15:54:52.835; org.apache.solr.core.SolrDeletionPolicy; newest commit = 285[_6j_1.del, _6k_Lucene41_0.pos, _6j.nvd, _6j_Lucene41_0.tim, _6j_Lucene41_0.tip, _6k.fdt, _6k.fnm, _6j_Lucene41_0.pos, _6j.nvm, _6k_Lucene41_0.doc, _6k_Lucene41_0.tim, _6k.si, _6j.si, _6k.nvd, _6k.fdx, segments_7x, _6j_Lucene41_0.doc, _6j.fdt, _6k.nvm, _6j.fdx, _6k_Lucene41_0.tip, _6j.fnm]
4

1 回答 1

1

获取 crawldb 的转储并找到状态为 db_gone 的 url,并在 solr 索引中检查这些 url。如果您正在进行新的爬网,您将不会在 Solr 索引中找到任何这些 url,因为 db_gone url 不被考虑用于索引。

现在,当我们运行 solrclean 命令时,nutch 会在 crawldb 中找到所有状态为 db_gone 的 url,并从 Solr 索引中删除所有这些 url。如果在 solr 索引中找到状态为 db_gone 的任何 url,则只有索引将被更改,否则索引将保持不变。

这可能发生在您的情况下。

注意:
仅在重新抓取的情况下,我们可能会发现一些在第一次抓取期间已经成功抓取并索引但在重新抓取阶段标记为 db_gone 的 url,因为这些 url 不再可用。因此,当我们运行 solrclean 命令时,这些 url 将从 solr index 中删除,并且 solr index 将被更改。

查看 SolrClean 类的源代码。
http://grepcode.com/file/repo1.maven.org/maven2/org.apache.nutch/nutch/1.3/org/apache/nutch/indexer/solr/SolrClean.java

希望对你有所帮助......

于 2013-08-22T15:54:41.957 回答