[jira] [Commented] (SOLR-5495) Recovery strategy for leader partitioned from replica case.

["Mark Miller (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/SOLR-5495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13830709#comment-13830709 ] 

Mark Miller commented on SOLR-5495:
-----------------------------------

In this case, the only real communication path is through zookeeper.

Couple ideas I have thought about - seems tricky in general though:

* have the leader publish the replica as down - this is tricky because the replica may be publishing it's own states - perhaps we publish it with a special marker, and the overseer will not write a new state for that replica until one is published acking that it has seen the marker and acted accordingly?

* have a zk queue that leaders can publish to, asking for a recovery - replicas monitor the queue and check it at startup - if they are in it, they enter recovery and remove the queue entry - Overseer could also periodically clear the queue

Just a quick 30 sec dump of some initial thoughts...looking for other ideas and may offer some more myself.

> Recovery strategy for leader partitioned from replica case.
> -----------------------------------------------------------
>
>                 Key: SOLR-5495
>                 URL: https://issues.apache.org/jira/browse/SOLR-5495
>             Project: Solr
>          Issue Type: Bug
>            Reporter: Mark Miller
>
> We need to work out a strategy for the case of:
> Leader and replicas can still talk to ZooKeeper, Leader cannot talk to replica.
> We punted on this in initial design, but I'd like to get something in.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org