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)