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

Jason Gustafson resolved KAFKA-12619.
-------------------------------------
    Fix Version/s: 2.8.1
                   3.0.0
       Resolution: Fixed

> Ensure LeaderChange message is committed before initializing high watermark
> ---------------------------------------------------------------------------
>
>                 Key: KAFKA-12619
>                 URL: https://issues.apache.org/jira/browse/KAFKA-12619
>             Project: Kafka
>          Issue Type: Bug
>            Reporter: Jason Gustafson
>            Assignee: Jason Gustafson
>            Priority: Major
>             Fix For: 3.0.0, 2.8.1
>
>
> KIP-595 describes an extra condition on commitment here: 
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-595%3A+A+Raft+Protocol+for+the+Metadata+Quorum#KIP595:ARaftProtocolfortheMetadataQuorum-Fetch.
>  In order to ensure that a newly elected leader's committed entries cannot 
> get lost, it must commit one record from its own epoch. This guarantees that 
> its latest entry is larger (in terms of epoch/offset) than any previously 
> written record which ensures that any future leader must also include it. 
> This is the purpose of the LeaderChange record which is written to the log as 
> soon as the leader gets elected.
> We have this check implemented here: 
> https://github.com/apache/kafka/blob/trunk/raft/src/main/java/org/apache/kafka/raft/LeaderState.java#L122.
>  However, the check needs to be a strict inequality since the epoch start 
> offset does not reflect the LeaderChange record itself. In other words, the 
> check is off by one.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Reply via email to