Are documents arriving, but your index is empty? Looking at that log, everything appears to have happened fine, except the replication handler has put the index in a directory with a suffix:
WARNING: New index directory detected: old=null new=/solr/cores/bpr/selekta/data/index.20130121090342477 Jan 23, 2013 7:16:08 AM org.apache.solr.core.CachingDirectoryFactory get INFO: return new directory for /solr/cores/bpr/selekta/data/index.20130121090342477 forceNew:false Once you look in that dir, how do things look? Upayavira On Wed, Jan 23, 2013, at 10:45 AM, Marcin Rzewucki wrote: > OK, check this link: http://pastebin.com/qMC9kDvt > > > On 23 January 2013 11:35, Upayavira <u...@odoko.co.uk> wrote: > > > Hmm, don't see it. Not sure if attachments make it to this list. > > Perhaps put it in a pastebin and include a link if too long to include > > in an email? > > > > > > > > Upayavira > > > > > > > > > > > > On Wed, Jan 23, 2013, at 10:28 AM, Marcin Rzewucki wrote: > > > > Hi, > > > > Previously, I took the lines related to collection I tested. Maybe some > > interesting part was missing. I'm sending the full log this time. > > > > It ends up with: > > > > INFO: Finished recovery process. core=ofac > > > > The issue I described is related to collection called "ofac". I hope > > the log is meaningful now. > > > > It is trying to do the replication, but it seems to not know which > > files to download. > > > > Regards. > > On 23 January 2013 10:39, Upayavira <[1]u...@odoko.co.uk> wrote: > > > > the first stage is identifying whether it can sync with transaction > > > > logs. It couldn't, because there's no index. So the logs you have shown > > > > make complete sense. It then says 'trying replication', which is what I > > > > would expect, and the bit you are saying has failed. So the interesting > > > > bit is likely immediately after the snippet you showed. > > > > > > > > > > > > > > > > Upayavira > > > > > > > > On Wed, Jan 23, 2013, at 07:40 AM, Marcin Rzewucki wrote: > > > > OK, so I did yet another test. I stopped solr, removed whole "data/" > > > > dir and started Solr again. Directories were recreated fine, but > > > > missing files were not downloaded from leader. Log is attached (I > > > > took the lines related to my test with 2 lines of context. I hope it > > > > helps.). I could find the following warning message: > > > > Jan 23, 2013 7:16:08 AM org.apache.solr.update.PeerSync sync > > > > INFO: PeerSync: core=ofac url=http://<replica_host>:8983/solr START > > > > replicas=[http://<leader_host>:8983/solr/ofac/] nUpdates=100 > > > > Jan 23, 2013 7:16:08 AM org.apache.solr.update.PeerSync sync > > > > WARNING: no frame of reference to tell of we've missed updates > > > > Jan 23, 2013 7:16:08 AM org.apache.solr.cloud.RecoveryStrategy > > > > doRecovery > > > > INFO: PeerSync Recovery was not successful - trying replication. > > > > core=ofac > > > > So it did not know which files to download ?? Could you help me to > > > > solve this problem ? > > > > Thanks in advance. > > > > Regards. > > > > On 22 January 2013 23:06, Yonik Seeley <[1][2]yo...@lucidworks.com> > > wrote: > > > > On Tue, Jan 22, 2013 at 4:37 PM, Marcin Rzewucki > > > > <[2][3]mrzewu...@gmail.com> wrote: > > > > > Sorry, my mistake. I did 2 tests: in the 1st I removed just index > > > > directory > > > > > and in 2nd test I removed both index and tlog directory. Log lines > > > > I've > > > > > sent are related to the first case. So Solr could read tlog directory > > > > in > > > > > that moment. > > > > > Anyway, do you have an idea why it did not download files from leader > > > > ? > > > > For your 1st test, if you only deleted the index and not the > > > > transaction logs, Solr will look at the transaction logs to try and > > > > determine if it is up to date or not (by comparing with peers). > > > > If you want to clear out all the data, remove the entire data > > > > directory. > > > > -Yonik > > > > [3][4]http://lucidworks.com > > > > > > > > References > > > > > > > > 1. mailto:[5]yo...@lucidworks.com > > > > 2. mailto:[6]mrzewu...@gmail.com > > > > 3. [7]http://lucidworks.com/ > > > > References > > > > 1. mailto:u...@odoko.co.uk > > 2. mailto:yo...@lucidworks.com > > 3. mailto:mrzewu...@gmail.com > > 4. http://lucidworks.com/ > > 5. mailto:yo...@lucidworks.com > > 6. mailto:mrzewu...@gmail.com > > 7. http://lucidworks.com/ > >
