Ugh, after a mess of additional flailing around, it appears I just discovered that the Replicate Now form on the Replication Admin page does not work in the text-based browser 'links'. :(
Running /replication?command=fetchindex" with curl did the trick. Now everything is synced up. Thanks for your reply, Erick! Michael Della Bitta ------------------------------------------------ Appinions, Inc. -- Where Influence Isn’t a Game. http://www.appinions.com On Fri, Jun 29, 2012 at 1:51 PM, Erick Erickson <erickerick...@gmail.com> wrote: > 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
