[
https://issues.apache.org/jira/browse/FLINK-12836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16864343#comment-16864343
]
Andrew Duffy commented on FLINK-12836:
--------------------------------------
Hey, yea the intention is to allow checkpoints to be reused after a successful
completion of a job. The scenarios where this comes up for us:
* Recurring bounded stream processing job, which can be re-run multiple times
and pick up from where the previous one left off with state/offsets intact.
* Hybrid storage: bootstrapping state by running over the complete set of
historical data, then restoring that state to start reading realtime data.
For both of these, it's considerably easier for an outside service (or human)
to orchestrate around job completions than trying to properly time a
cancellation, particularly when you're already trying to read one source to
completion.
> Allow retained checkpoints to be persisted on success
> -----------------------------------------------------
>
> Key: FLINK-12836
> URL: https://issues.apache.org/jira/browse/FLINK-12836
> Project: Flink
> Issue Type: Improvement
> Components: Runtime / Checkpointing
> Reporter: Andrew Duffy
> Assignee: vinoyang
> Priority: Major
>
> Currently, retained checkpoints are persisted with one of 3 strategies:
> * {color:#333333}CHECKPOINT_NEVER_RETAINED:{color} Retained checkpoints are
> never persisted
> * {color:#333333}CHECKPOINT_RETAINED_ON_FAILURE:{color}{color:#333333}
> Latest retained checkpoint{color} is persisted in the face of job failures
> * {color:#333333}CHECKPOINT_RETAINED_ON_CANCELLATION{color}: Latest retained
> checkpoint is persisted when job is canceled externally (e.g. via the REST
> API)
>
> I'm proposing a third persistence mode: _CHECKPOINT_RETAINED_ALWAYS_. This
> mode would ensure that retained checkpoints are retained on successful
> completion of the job, and can be resumed from later.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
