SolrClean не удаляет из Solr

Когда я запускаю Nutch и ссылки больше нет, я могу запустить команду readdb, и она показывает мне, что есть URL-адреса, помеченные как 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]

person Allan Macmillan    schedule 20.08.2013    source источник
comment
Я предполагаю, что изменение не commited, я знаю, что было изменение билет на совершение фиксации как вариант   -  person Srikanth Venugopalan    schedule 20.08.2013
comment
Нет флага для совершения действия, поэтому, если оно его не совершает, я понятия не имею, как бы я поступил.   -  person Allan Macmillan    schedule 20.08.2013


Ответы (1)


Возьмите дамп crawldb, найдите URL-адреса со статусом db_gone и проверьте эти URL-адреса в индексе solr. Если вы выполняете новое сканирование, вы не найдете ни одного из этих URL-адресов в своем индексе Solr, поскольку URL-адреса db_gone не учитываются для индексации.

Теперь, когда мы запускаем команду solrclean, nutch находит все URL-адреса со статусом db_gone в crawldb и удаляет все эти URL-адреса из индекса Solr. Если какой-либо URL-адрес со статусом db_gone найден в индексе solr, тогда будет изменен только индекс, в противном случае индекс останется неизменным.

Это может происходить в вашем случае.

Примечание.
Только в случае повторного сканирования мы можем обнаружить некоторые URL-адреса, которые уже успешно просканированы и проиндексированы во время первого сканирования, но помечены как db_gone на этапе повторного сканирования, поскольку эти URL-адреса больше не доступны. Таким образом, эти URL-адреса будут удалены из индекса solr, когда мы запустим команду solrclean, и индекс solr будет изменен.

Ознакомьтесь с исходным кодом класса SolrClean.
http://grepcode.com/file/repo1.maven.org/maven2/org.apache.nutch/nutch/1.3/org/apache/nutch/indexer/solr/SolrClean.java

Надежда вам помогла....

person GS Majumder    schedule 22.08.2013
comment
Да, я понимаю, как работает команда SolrClean, которая ищет URL-адреса со статусом DB_GONE и удаляет эти документы из Solr. Проблема может быть не столько в команде SolrClean, сколько, возможно, моя установка не позволяет удалить удаление, потому что она распознает, что есть 1 документ для удаления. - person Allan Macmillan; 23.08.2013
comment
Nutch выбирает 1 документ для удаления только из crawl_db, он не будет проверять индекс solr, присутствует ли документ в индексе solr или нет. Если выбранный документ отсутствует в индексе solr, ничего не будет удалено. Но вы можете найти журнал, показывающий SolrClean: удаление 1 документа. Этот журнал не всегда означает, что 1 документ будет удален из индекса Solr. Если документ присутствует в индексе solr, то будет удален только он. - person GS Majumder; 23.08.2013
comment
Да, дело в том, что этот документ определенно находится в Solr. Я проверил журнал и посмотрел запрос на удаление, который он выдает, и он относится к документу, присутствующему в индексе Solr. - person Allan Macmillan; 23.08.2013
comment
Можете ли вы поделиться своим журналом solr после запуска SolrClean. - person GS Majumder; 23.08.2013