[
https://issues.apache.org/jira/browse/KAFKA-7897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16761049#comment-16761049
]
Jason Gustafson commented on KAFKA-7897:
----------------------------------------
There is a bit more to this bug than just dealing with message format
downgrades. There was a regression in KAFKA-7415 which caused the leader epoch
cache to be populated upon becoming a leader even if the message format was
older. This could cause unexpected truncation of data following a leader change.
> Invalid use of epoch cache following message format downgrade
> -------------------------------------------------------------
>
> Key: KAFKA-7897
> URL: https://issues.apache.org/jira/browse/KAFKA-7897
> Project: Kafka
> Issue Type: Bug
> Reporter: Jason Gustafson
> Assignee: Jason Gustafson
> Priority: Major
>
> Message format downgrades are not supported, but they generally work as long
> as broker/clients at least can continue to parse both message formats. After
> a downgrade, the truncation logic should revert to using the high watermark,
> but currently we use the existence of any cached epoch as the sole
> prerequisite in order to leverage OffsetsForLeaderEpoch. This has the effect
> of causing a massive truncation after startup which causes re-replication.
> I think our options to fix this are to either 1) clear the cache when we
> notice a downgrade, or 2) forbid downgrades and raise an error.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
