[
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)