[
https://issues.apache.org/jira/browse/FLINK-39964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18100553#comment-18100553
]
Sergey Nuyanzin commented on FLINK-39964:
-----------------------------------------
master:
[07bcbd9f1bef8329e68d4837e16a5a963b2818bc|https://github.com/apache/flink/commit/07bcbd9f1bef8329e68d4837e16a5a963b2818bc]
> Checkpoints taken after a CLAIM-mode restore from a native savepoint can be
> unrestorable
> ----------------------------------------------------------------------------------------
>
> Key: FLINK-39964
> URL: https://issues.apache.org/jira/browse/FLINK-39964
> Project: Flink
> Issue Type: Bug
> Components: Runtime / Checkpointing, Runtime / State Backends
> Affects Versions: 1.19.3, 2.2.0, 2.3.0
> Reporter: Aleksandr Savonin
> Assignee: Aleksandr Savonin
> Priority: Critical
> Labels: pull-request-available
> Fix For: 2.2.2, 2.3.1, 2.4.0
>
>
> When a job restores from a NATIVE-format savepoint in CLAIM mode with RocksDB
> incremental checkpoints enabled, the next checkpoint reuses the savepoint's
> SST files instead of re-uploading them. The checkpoint completes
> successfully, but its metadata records the reused files with the relative
> (file-name-only) encoding, which a restore later resolves against the
> checkpoint's own directory. The bytes physically live in the savepoint
> directory, so the resolved paths point at files that do not exist.
> The problem stays silent while the job keeps running, because failover
> restores from the JobManager's completed-checkpoint store and never re-reads
> the metadata file. It surfaces only when a fresh job is started from the
> checkpoint's path: the restore fails with a FileNotFoundException for SST
> files under the checkpoint directory. The first checkpoint after the restore
> is always affected and later ones remain affected until the reused files have
> been compacted away.
> Only filesystem checkpoint storage is affected, setups with entropy injection
> always write absolute paths and are immune.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)