Clocks on the separate machines are irrelevant, so don't worry about that bit.
The index version _starts out_ as a timestamp as I understand it, but from there on when you change the index and commit it should just bump up NOT get a new timestamp. 1> it's strange that the version on the master when you committed. _Unless_ you didn't actually change the index. A commit doesn't do anything at all without some underlying change to the index, not even bump the index version I don't think. But you should be seeing the very last digits change on commit _if_ there have been underlying changes. 2> It looks like you somehow changed the index on the slave at some point. Did you update the index there sometime independent of the master? Even though when you fire up the slave for the first time, it gets a default timestamp of right now, it's changed to the version that corresponds to the master on the first replication. 3> Blowing away the index on the slave should have worked _if_ you removed the index directory. Just issuing a delete on *:* wouldn't do much. when I want to be absolutely, completely sure I've gotten rid of an index, I shut down the sever and rm -rf <solr_home>/data/index (you can also just rmdir -rf <solr_home>/data). It's important that you remove the _directory_, not just the contents of <solr_home>/data/index. Bottom line: I suspect something else happened in the mean-time that changed the underlying slave timestamp that got you into this situation, perhaps you directly updated the slave index sometime? Best Erick On Fri, Jun 29, 2012 at 12:54 PM, Michael Della Bitta <michael.della.bi...@appinions.com> wrote: > Nevermind, I realized that my master index was not tickling the index > version number when a commit or optimize happened. I gave in and nuke > and paved it, and now it seems fine. > > Is there any known reason why this would happen, so I can avoid this > in the future? > > Thanks, > > > Michael Della Bitta > > ------------------------------------------------ > Appinions, Inc. -- Where Influence Isn’t a Game. > http://www.appinions.com > > > On Fri, Jun 29, 2012 at 10:42 AM, Michael Della Bitta > <michael.della.bi...@appinions.com> wrote: >> Hi, I'm having trouble with replication on a brand new rollout of 3.6. >> >> Basically I've traced it to the slave always thinking the index it >> creates when it warms up is newer than what's on the master, no matter >> what I do... deleting the slave's index, committing or optimizing on >> the master, etc. I can see the replication request come in on the >> master, but nothing happens, presumably because of the Index Version >> discrepancy. >> >> The clocks of the two machines are within 3 seconds of one another, >> but I don't know if that's significant. >> >> Actually, I'm having trouble figuring out how Index Version is >> calculated at all, and before I dive into the source, I thought I'd >> ask here. My slave is saying Index Version 1340979968338, Generation >> 1, and my master says Index Version 1340052708476, Generation 83549. >> >> Anybody have any ideas? >> >> Thanks, >> >> Michael Della Bitta >> >> ------------------------------------------------ >> Appinions, Inc. -- Where Influence Isn’t a Game. >> http://www.appinions.com
