You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jira@kafka.apache.org by "Ken Huang (Jira)" <ji...@apache.org> on 2026/08/28 23:04:00 UTC

[jira] [Assigned] (KAFKA-21000) Potential data corruption on clean broker restart

     [ https://issues.apache.org/jira/browse/KAFKA-21000?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ken Huang reassigned KAFKA-21000:
---------------------------------

    Assignee: Ken Huang

> Potential data corruption on clean broker restart
> -------------------------------------------------
>
>                 Key: KAFKA-21000
>                 URL: https://issues.apache.org/jira/browse/KAFKA-21000
>             Project: Kafka
>          Issue Type: Improvement
>          Components: core
>            Reporter: Jun Rao
>            Assignee: Ken Huang
>            Priority: Major
>
> A similar issue to https://issues.apache.org/jira/browse/KAFKA-20979 could be exposed in the .log file when preallocation is used.
> When the active segment is closed, FileRecords.close() calls the following.
> {code:java}
> flush();
> trim();{code}
> When preallocation is used, trim() resizes the file length to what's actually being used, but without flushing the length metadata. The broker cleanly shuts down and crashes before the metadata is flushed. When the broker is restarted, the on-disk file length still has the preallocation length but won't go through recovery (since the broker was shutdown cleanly). When the broker tries to calculate the next offset, it will hit the uninitialized bytes and cause an exception.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)