As Daniel says, there's no information available in step 4 for that node to know it's out of date.
"Don't do that" isn't very helpful. I think the only recovery strategy I can think of offhand is to reindex from some time T prior to step <1>... Best, Erick On Wed, Nov 27, 2013 at 6:07 AM, Daniel Collins <danwcoll...@gmail.com>wrote: > I think when a replica becomes leader, it tries to sync *from* all the > other replicas to see if anyone else is more up to date than it is, then it > syncs back out *to* the replicas. But that probably won't happen in your > case, since when replica1 comes back (step 4) it is the only contender, so > it can't sync then. > > So I know Solr has support for 2-way sync, but whether it will happen in > step 5 (when the other replica comes back up), I'm not honestly sure... > Would need to delve into the code to check. > > > On 27 November 2013 09:19, adfel70 <adfe...@gmail.com> wrote: > > > I'm sorry, I forgot to write the problem. > > > > > > adfel70 wrote > > > 1. take one of the replicas of shard1 down(it doesn't matter which one) > > > 2. continue indexing documents(that's important for this scenario) > > > 3. take down the second replica of shard1(now the shard is down and we > > > cannot index anymore) > > > 4. take the replica from step 1 up(that's important that this replica > > will > > > go up first) > > > 5. take the replica from step 3 up > > > > after the second replica is up, it has data that the first replica > doesn't > > have(step 2, we continued to index while the first replica was down), I > > need > > to know if there is a way that the second replica tell the first one that > > it > > has data to sync with him... > > > > > > > > > > -- > > View this message in context: > > > http://lucene.472066.n3.nabble.com/syncronization-between-replicas-tp4103046p4103477.html > > Sent from the Solr - User mailing list archive at Nabble.com. > > >
