You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@mesos.apache.org by "Ilya Pronin (JIRA)" <ji...@apache.org> on 2018/01/03 19:20:00 UTC

[jira] [Commented] (MESOS-7973) Non-leading VOTING replica catch-up

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

Ilya Pronin commented on MESOS-7973:
------------------------------------

Documentation patches:
https://reviews.apache.org/r/64921/
https://reviews.apache.org/r/64922/
https://reviews.apache.org/r/64923/

> Non-leading VOTING replica catch-up
> -----------------------------------
>
>                 Key: MESOS-7973
>                 URL: https://issues.apache.org/jira/browse/MESOS-7973
>             Project: Mesos
>          Issue Type: Improvement
>          Components: replicated log
>            Reporter: Ilya Pronin
>            Assignee: Ilya Pronin
>             Fix For: 1.5.0
>
>
> Currently it is not possible to perform consistent reads from non-leading replicas due to the fact that if a non-leading replica is partitioned it may miss some log positions and will not make any attempt to “fill” those holes.
> If a non-leading replica could catch-up missing log positions it would be able to serve eventually consistent reads to the framework. This would make it possible to do additional work on non-leading framework replicas (e.g. offload some reading from a leader to standbys or reduce failover time by keeping in-memory storage represented by the log “hot”).
> Design doc: https://docs.google.com/document/d/1dERXJeAsi3Lnq9Akt82JGWK4pKNeJ6k7PTVCpM9ic_8/edit?usp=sharing



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)