[jira] [Commented] (KUDU-796) New leaders should not allow "up to date" reads until they've committed everything from previous terms

["Todd Lipcon (JIRA)" <ji...@apache.org>]

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

Todd Lipcon commented on KUDU-796:
----------------------------------

[~dralves] is this one on your radar under the aegis of the various consistency issues you're tackling? Not sure if it's "automatically" handled by the safetime advancement work, but maybe worth a specific test for it, at least.

> New leaders should not allow "up to date" reads until they've committed everything from previous terms
> ------------------------------------------------------------------------------------------------------
>
>                 Key: KUDU-796
>                 URL: https://issues.apache.org/jira/browse/KUDU-796
>             Project: Kudu
>          Issue Type: Improvement
>          Components: consensus
>    Affects Versions: M5
>            Reporter: Mike Percy
>            Priority: Critical
>
> This came up in a HipChat discussion based on a consistency problem observed on a testing cluster. Todd suggested the following fix.
> It is possible to lose read-your-writes consistency across a leader failure in the following scenario:
> 1. Write to leader, leader replicates successfully and commits locally, responds to the client, and crashes.
> 2. Client reads back the same data he just wrote, gets routed to the new leader who has not yet finished committing the entries in his log. This leader responds with stale data.
> One solution to this problem is to have the leader stall responding to "up to date" reads until all of the entries in its log from previous terms have been committed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)