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

["David Alves (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/KUDU-796?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Alves resolved KUDU-796.
------------------------------
       Resolution: Fixed
    Fix Version/s: 1.2.0

This was resolved as part of KUDU-798, which included a test for this.

> 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
>            Assignee: David Alves
>            Priority: Critical
>             Fix For: 1.2.0
>
>
> 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)