I may be missing something but let me go back to your original statements: 1) You build the index once per week from scratch 2) You replicate this from master to slave.
My understanding of the way replication works is that it's meant to only send along files that are new and if any files named the same between the master and slave have different sizes then this is a "corruption" of sorts and do this index.<timestamp> and send the full thing down. This, I think, explains your index.<timestamp> issue although why the old index/ directory isn't being deleted i'm not sure about. This is why I was asking about OS details, file system details etc (perhaps something else is locking that directory preventing Java from deleting it?) The second issue is the index generation which is governed by commits and is represented by looking at the last few characters in the segments_XX file. When the slave downloads the index and does the copy of the new files, it does a commit to force a new searcher hence why the slave generation will be +1 from the master. The index "version" is a timestamp and it may be the case that the version represents the point in time when the index was downloaded to the slave? In general, it shouldn't matter about these details because replication is only triggered if the master's version > slave's version and the clocks that all servers use are synched to some common clock. Caveat however in my answer is that I have yet to try 4.1 as this is next on my TODO list so maybe I'll run into the same problem :-) but I wanted to provide some info as I just recently dug through the replication code to understand it better myself. Cheers Amit On Wed, Feb 13, 2013 at 11:57 PM, Bernd Fehling < bernd.fehl...@uni-bielefeld.de> wrote: > OK then index generation and index version are out of count when it comes > to verify that master and slave index are in sync. > > What else is possible? > > The strange thing is if master is 2 or more generations ahead of slave > then it works! > With your logic the slave must _always_ be one generation ahead of the > master, > because the slave replicates from master and then does an additional commit > to recognize the changes on the slave. > This implies that the slave acts as follows: > - if the master is one generation ahaed then do an additional commit > - if the master is 2 or more generations ahead then do _no_ commit > OR > - if the master is 2 or more generations ahead then do a commit but don't > change generation and version of index > > Can this be true? > > I would say "not really". > > Regards > Bernd > > > Am 13.02.2013 20:38, schrieb Amit Nithian: > > Okay so then that should explain the generation difference of 1 between > the > > master and slave > > > > > > On Wed, Feb 13, 2013 at 10:26 AM, Mark Miller <markrmil...@gmail.com> > wrote: > > > >> > >> On Feb 13, 2013, at 1:17 PM, Amit Nithian <anith...@gmail.com> wrote: > >> > >>> doesn't it do a commit to force solr to recognize the changes? > >> > >> yes. > >> > >> - Mark > >> > > >
