[
https://issues.apache.org/jira/browse/KUDU-3752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18089518#comment-18089518
]
Alexey Serbin edited comment on KUDU-3752 at 6/16/26 11:41 PM:
---------------------------------------------------------------
UUIC, this JIRA item is applicable only to Kudu masters. For tablet servers,
the system catalog (i.e. Kudu master) takes care of the situation when a
follower tablet replica falls behind the leader's WAL GC anchor.
As for Kudu masters,
[KUDU-3762|https://issues.apache.org/jira/browse/KUDU-3762] should have
addressed the problem.
I'm resolving this as a duplicate of KUDU-3762. Feel free to re-open if it's a
mistake.
was (Author: aserbin):
UUIC, this JIRA item is applicable only to Kudu masters. For tablet servers,
the system catalog (i.e. Kudu master) takes care of the situation when a
follower tablet replica falls behind the leader's WAL GC anchor.
As for Kudu masters,
[KUDU-3762|https://issues.apache.org/jira/browse/KUDU-3762] should have
addressed the problem.
I'm resolving this as a duplicate for KUDU-3762. Feel free to re-open if it's
a mistake.
> No auto-recovery when WAL fallback target is also GC'd
> ------------------------------------------------------
>
> Key: KUDU-3752
> URL: https://issues.apache.org/jira/browse/KUDU-3752
> Project: Kudu
> Issue Type: Bug
> Reporter: Marton Greber
> Priority: Major
> Fix For: 1.19.0
>
>
> When a leader detects an LMP_MISMATCH with a follower, it attempts to
> reconcile
> by falling back to the follower's last committed index and replaying WAL from
> that point. If the WAL for that fallback index has already been garbage
> collected, Kudu correctly logs "the follower will never be able to catch up" —
> but then takes no corrective action. The LMP_MISMATCH status is retried in an
> infinite loop, and the follower remains permanently stuck.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
