lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Miller <markrmil...@gmail.com>
Subject Re: Solr cloud recovery, why does restarting leader need replicas?
Date Thu, 29 Nov 2012 19:15:08 GMT

On Nov 29, 2012, at 1:26 PM, Daniel Collins <danwcollins@gmail.com> wrote:

> Hi Mark,
> 
> I get that use case, if the non-leader dies, when it comes back it has to
> allow for recovery, that makes perfect sense.
> 
> I guess I was (naively!) assuming there was an optimized scenario if the
> leader dies, and is the first one to come back (is still therefore leader),
> there is no recovery to do as by definition no updates can have been made
> whilst the shard was inactive.
> 
> Aside: Interesting point about Solr only ack updates when they are on every
> replica, are you talking about when the records are removed from the
> transaction log?
> 
> My understanding was the the external "update" request completes as soon as
> the document has made it to the leader's transaction log (might not even
> have committed into the leader index), and the replicas then were pushed
> those updates as they became available.

No, currently it won't return until the update hits the replicas - its sent to replicas in
parallel.

> 
> If a single replica dies, the leader can still process update/add document
> requests, so it can't be waiting for replicas in that scenario?

There should be no wait if there are any nodes waiting in line to be leader - it should only
wait when a node comes up and realizes it's the leader and no one else was in line to be leader.

- Mark

> 
>> On Nov 28, 2012, at 11:58 AM, Mark Miller <markrmiller@gmail.com> wrote:
>> 
>> 
>> and we don't want to lose any updates.
>> 
>> 
>> That's probably somewhat inaccurate - in this case it's more about
>> consistency - we only ack updates once they are on every replica. So it's
>> not a lost updates issue, but a consistency issue.
>> 
>> The lost updates part is more like when you stop the cluster, than you
>> start an old shard or something before starting more recent shards - you
>> don't want that thing to become the leader because the other shards were
>> not up yet.
>> 
>> - Mark
>> 
>> 


Mime
View raw message