[
https://issues.apache.org/jira/browse/FLINK-26079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17490532#comment-17490532
]
Roman Khachatryan commented on FLINK-26079:
-------------------------------------------
To implement the validation, we need cluster config (read by TM) to load state
backend; and application settings to read restore mode (and overriding backend
if any).
Reading restore mode should be prone to JM failover; in particular, when
failure happens before creating any new checkpoints.
I don't see any reliable way to access full cluster config on JM ({*}am I
wrong?{*}). So the validation should be done on TM.
I see the following ways to pass Pass RestoreMode to each task:
1. in StreamConfig - set from JobGraph.savepointRestoreSettings in
StreamingJobGraphGenerator
2. in TaskStateSnapshot - set in StateAssignmentOperation
3. in CheckpointProperties - set in CheckpointCoordinator
4. (other options?)
The 1st option is resilient to failures because job graph is generated once.
The main disadvantage is multple places where it has to be checked;
DataSourceTask for example uses TaskConfig instead of StreamConfig IIUC.
2nd and 3rd options need something similar to
completedCheckpoint.props.unclaimed to survive crashes.
Additionally, 3rd has non-clear semantics (we're interested in the initial
checkpoint, not the current one).
WDYT [~pnowojski], [~dwysakowicz], [~ym]?
> Disallow combination of Changelog backend with CLAIM restore mode
> ------------------------------------------------------------------
>
> Key: FLINK-26079
> URL: https://issues.apache.org/jira/browse/FLINK-26079
> Project: Flink
> Issue Type: Bug
> Components: Runtime / Configuration, Runtime / State Backends
> Reporter: Roman Khachatryan
> Priority: Major
> Fix For: 1.15.0
>
>
> Extracted from FLINK-25872.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
