You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@kudu.apache.org by "Marton Greber (Jira)" <ji...@apache.org> on 2026/03/13 10:48:00 UTC
[jira] [Commented] (KUDU-3752) No auto-recovery when WAL fallback target is also GC'd
[ https://issues.apache.org/jira/browse/KUDU-3752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18065612#comment-18065612 ]
Marton Greber commented on KUDU-3752:
-------------------------------------
The correct recovery action in this state is to trigger a remote bootstrap
(tablet copy) of the follower from the leader, which bypasses WAL replication
entirely. This is not done automatically.
> 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
>
> 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)