Hi Otis, Thanks for your answer.
On Thu, May 21, 2009 at 7:14 PM, Otis Gospodnetic <otis_gospodne...@yahoo.com> 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
