Skip to content

[Bug] Fix Flink Dedicated Streaming Compact Job stuck when checkpointed snapshot expired - #9535

Open
zhang-arvin wants to merge 1 commit into
apache:masterfrom
zhang-arvin:fix/flink-compact-stuck-snapshot-expired-9533
Open

[Bug] Fix Flink Dedicated Streaming Compact Job stuck when checkpointed snapshot expired#9535
zhang-arvin wants to merge 1 commit into
apache:masterfrom
zhang-arvin:fix/flink-compact-stuck-snapshot-expired-9533

Conversation

@zhang-arvin

Copy link
Copy Markdown
Contributor

Fixes #9533: When Flink Dedicated Streaming Compact Job restores from a checkpoint whose snapshot has been expired, the job gets stuck in a loop because nextPlan() keeps returning SnapshotNotExistPlan without incrementing nextSnapshotId.

Fix

In restore(), when nextSnapshotId is less than earliestSnapshotId (snapshot expired), set nextSnapshotId to null so plan() falls back to tryFirstPlan() which uses ContinuousCompactorStartingScanner to find the latest compact snapshot.

@JingsongLi

Copy link
Copy Markdown
Contributor

Spark test failed.

@lilei1128

Copy link
Copy Markdown
Contributor

The proposed fix addresses the expired nextSnapshotId case. Please verify whether pending splits and sink writer state can also reference the expired snapshot. If they cannot, this source-only fix may be sufficient for the current bug scope. If they can, additional cleanup or writer reinitialization is required for end-to-end recovery.

@@ -315,6 +315,19 @@ public Long watermark() {

@Override
public void restore(@Nullable Long nextSnapshotId) {

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Similar possible situations need to be taken into consideration, for example:

A previous asynchronous compaction may expire and delete the snapshot files that the source is about to read.

Possible sequence:
The source selects snapshot N for reading
-> a previous asynchronous compaction commits a newer snapshot
-> snapshot N or its manifest files are deleted
-> the source continues reading snapshot N
-> the read fails with OutOfRangeException or FileNotFoundException

This is a read-time race and can happen even without a Flink failover.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we can treat it as a source-and-sink recovery problem, follows:
detect expired snapshot(include normal read or checkpoint restore)
-> discard expired pending splits
-> build a baseline from the latest valid snapshot
-> notify all compaction writers
-> rebuild writer state
-> ignore in-flight splits covered by the new baseline
-> continue from the next snapshot

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Bug] Flink Dedicated Streaming Compact Job Is Stuck When Its Checkpointed Snapshot Has Expired

3 participants