[KAFKA-10904] There is a misleading log when the replica fetcher thread handles offsets that are out of range

• Type: Improvement
• Status: Patch Available
• Priority: Minor
• Resolution: Unresolved
• Affects Version/s: 2.7.0
• Component/s: replication
• Assignee: Wenbing Shen
• Reporter: Wenbing Shen
• Created: 05/Jan/21 15:29
• Updated: 05/Jan/21 15:55

Description

There is ambiguity in the replica fetcher thread's log. When the fetcher thread is handling with offset out of range, it needs to try to truncate the log. When the end offset of the follower replica is greater than the log start offset of the leader replica and smaller than the end offset of the leader replica, the follower replica will maintain its own fetch offset.However, such cases are processed together with cases where the follower replica's end offset is smaller than the leader replica's start offset, resulting in ambiguities in the log, where the follower replica's fetch offset is reported to reset to the leader replica's start offset.In fact, it still maintains its own fetch offset, so this WARN log is misleading to the user.

 

[2020-11-12 05:30:54,319] WARN (ReplicaFetcherThread-1-1003 kafka.server.ReplicaFetcherThread 70) [ReplicaFetcher replicaId=1
010, leaderId=1003, fetcherId=1] Reset fetch offset for partition eb_raw_msdns-17 from 1933959108 to current leader's start o
ffset 1883963889
[2020-11-12 05:30:54,320] INFO (ReplicaFetcherThread-1-1003 kafka.server.ReplicaFetcherThread 66) [ReplicaFetcher replicaId=1
010, leaderId=1003, fetcherId=1] Current offset 1933959108 for partition eb_raw_msdns-17 is out of range, which typically imp
lies a leader change. Reset fetch offset to 1933959108

 

I think it is more accurate to print the WARN log only when follower replica really need to truncate the fetch offset to the leader replica's log start offset.

Issue Links

• links to: GitHub Pull Request #9825