You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-user@lucene.apache.org by adfel70 <ad...@gmail.com> on 2013/11/25 13:21:15 UTC

syncronization between replicas

Hi,

We currently running tests on solr to find as many problems in our solr
environment so we can be ready for these kind of problems in production,
anyway we found an edge case and have few questions about it. 

We have one collection with two shards, each shard with replica factor 2.
we are sending docs to the index and everything is okay, now the scenario:
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

The regular synchronization flow is that the leader synchronize the other
replica, but I'm pretty sure this is a known issue, is there a way to do a
two way synchronization or do you have any other solution for me?

thanks



--
View this message in context: http://lucene.472066.n3.nabble.com/syncronization-between-replicas-tp4103046.html
Sent from the Solr - User mailing list archive at Nabble.com.

Re: syncronization between replicas

Posted by Erick Erickson <er...@gmail.com>.
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 <da...@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 <ad...@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.
> >
>

Re: syncronization between replicas

Posted by Daniel Collins <da...@gmail.com>.
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 <ad...@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.
>

Re: syncronization between replicas

Posted by adfel70 <ad...@gmail.com>.
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.

Re: syncronization between replicas

Posted by adfel70 <ad...@gmail.com>.
anyone?



--
View this message in context: http://lucene.472066.n3.nabble.com/syncronization-between-replicas-tp4103046p4103455.html
Sent from the Solr - User mailing list archive at Nabble.com.