No, you look at wrong collection. I told you I have couple of collections
in Solr. I guess some messages may overlap each other. The one for which I
did test (index recovery) is called "ofac" and that fails. Besides, Solr
sometimes adds suffix to index directory internally and it is not a bug.
The lines which are interesting are:
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
Jan 23, 2013 7:16:08 AM org.apache.solr.cloud.RecoveryStrategy doRecovery
and after a while:
Jan 23, 2013 7:16:11 AM org.apache.solr.update.UpdateLog bufferUpdates
INFO: Starting to buffer updates. FSUpdateLog{state=ACTIVE,* tlog=null*}
Jan 23, 2013 7:16:11 AM org.apache.solr.cloud.RecoveryStrategy replicate
*INFO: Attempting to replicate from http://<leader_host>:8983/solr/ofac/.
core=ofac*
Jan 23, 2013 7:16:11 AM org.apache.solr.client.solrj.impl.HttpClientUtil
createClient
INFO: Creating new http client,
config:maxConnections=128&maxConnectionsPerHost=32&followRedirects=false
Jan 23, 2013 7:16:11 AM org.apache.solr.client.solrj.impl.HttpClientUtil
createClient
INFO: Creating new http client,
config:connTimeout=5000&socketTimeout=20000&allowCompression=false&maxConnections=10000&maxConnectionsPerHost=10000
Jan 23, 2013 7:16:11 AM org.apache.solr.handler.SnapPuller <init>
INFO: No value set for 'pollInterval'. Timer Task not started.
Jan 23, 2013 7:16:11 AM org.apache.solr.core.SolrDeletionPolicy onInit
INFO: SolrDeletionPolicy.onInit: commits:num=1
commit{dir=<indexdir>,segFN=segments_1,generation=1,filenames=[segments_1]
Jan 23, 2013 7:16:11 AM org.apache.solr.core.SolrDeletionPolicy
updateCommits
INFO: newest commit = 1
Jan 23, 2013 7:16:11 AM org.apache.solr.update.DirectUpdateHandler2 commit
INFO: start
commit{flags=0,_version_=0,optimize=false,openSearcher=true,waitSearcher=true,expungeDeletes=false,softCommit=false}
Jan 23, 2013 7:16:11 AM org.apache.solr.core.SolrDeletionPolicy onCommit
INFO: SolrDeletionPolicy.onCommit: commits:num=2
commit{dir=<indexdir>,segFN=segments_1,generation=1,filenames=[segments_1]
commit{dir=<indexdir>,segFN=segments_2,generation=2,filenames=[segments_2]
Jan 23, 2013 7:16:11 AM org.apache.solr.core.SolrDeletionPolicy
updateCommits
INFO: newest commit = 2
Jan 23, 2013 7:16:11 AM org.apache.solr.search.SolrIndexSearcher <init>
INFO: Opening Searcher@192aaffb main
Jan 23, 2013 7:16:11 AM org.apache.solr.schema.IndexSchema readSchema
INFO: default search field in schema is cmpy_lstd
Jan 23, 2013 7:16:11 AM org.apache.solr.core.QuerySenderListener newSearcher
INFO: QuerySenderListener sending requests to
Searcher@192aaffbmain{StandardDirectoryReader(segments_2:2)}
Jan 23, 2013 7:16:11 AM org.apache.solr.update.DirectUpdateHandler2 commit
INFO: end_commit_flush
Jan 23, 2013 7:16:11 AM org.apache.solr.core.QuerySenderListener newSearcher
INFO: QuerySenderListener done.
Jan 23, 2013 7:16:11 AM org.apache.solr.core.SolrCore registerSearcher
INFO: [ofac] Registered new searcher
Searcher@192aaffbmain{StandardDirectoryReader(segments_2:2)}
Jan 23, 2013 7:16:11 AM org.apache.solr.cloud.RecoveryStrategy replay
*INFO: No replay needed. core=ofac*
Jan 23, 2013 7:16:11 AM org.apache.solr.cloud.RecoveryStrategy doRecovery
*INFO: Replication Recovery was successful - registering as Active.
core=ofac*
But recovery was not successful. Index was not downloaded from leader. It's
empty.
On 23 January 2013 12:22, Upayavira <u...@odoko.co.uk> wrote:
> 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/
> > >
>
