Aha, I see. Perhaps you can post the error message/stack trace? As for the sanity check, I bet a call to http://host:port/solr/replication?command=indexversion could be used ensure only newer versions of the index are being pulled. We'll see what Paul says when he wakes up. :)
Otis -- Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch ----- Original Message ---- > From: Damien Tournoud <dam...@tournoud.net> > To: solr-user@lucene.apache.org > Sent: Thursday, May 21, 2009 1:26:30 PM > Subject: Re: No sanity checks before replicating files? > > Hi Otis, > > Thanks for your answer. > > On Thu, May 21, 2009 at 7:14 PM, Otis Gospodnetic > wrote: > > Interesting, this is similar to my suggestion to another person I just > > replied > to here on solr-user. > > Have you actually run into this problem? I haven't tried it, but I'd think > the first next replication (copying index from s1 to s2) would not > necessarily > fail, but would simply overwrite any changes that were made on s2 while it > was > serving as the master. Is that not what happens? > > No it doesn't. For some reason, Solr download all the files of the > index, but fails to commit the changes locally. At the next poll, the > process restarts. Not only does this clogs the network, but it also > unnecessarily uses resources on the newly promoted slave, until we > change its configuration. > > > If that's what happens, then I think what you'd simply have to do is to: > > > > 1) bring s1 back up, but don't make it a master immediately > > 2) take away the master role from s2 > > 3) make s1 copy the index from s2, since s2 might have a more up to date > > index > now > > 4) make s1 the master > > Once s2 is the master, we want it to stay this way. We will reassign > s1 as the slave at a later stage, when resources allows. What worries > me is that strange behavior of Solr 1.4 replication when the "slave" > index is fresher then the "master" one. > > Damien
