...
The checkpoint coordinator has a fixed-size FIFO queue of completed checkpoints that are retained (current default size is 1). Checkpoints are discarded when they are removed from this queue. I propose to store allow persisting these checkpoints as like savepoints. This means that if a job fails permanently the user will have a savepoint checkpoint available to restore from. When a newer checkpoint completes, old savepoints will be automatically discarded These can be subsumed like regular checkpoints..
As an example think of the following scenario: a job runs smoothly until it hits a bad record that it cannot handle. The current behaviour will be that the job will try to recover, but it will hit the bad record again and keep on failing. With the proposed change, some recent checkpoint is stored as a savepoint and the user can update the program to handle bad records and restore from the savepoint.
...
Allow the user to configure periodic triggering of savepoints. The behaviour should be similar to the periodic checkpoints with an extra configuration value for the maximum number of retained periodic savepoints. These savepoints are only discarded when the queue overflowsmanually triggering savepoints periodically. Furthermore, we bound the number of available periodic savepoints. On shut down, they are not removed.never removed.
What's the Difference?
Although persistent checkpoints and periodic savepoints look similar, persistent checkpoints have a major difference: they can only be recovered with the same job and Flink version whereas savepoints allow to modify both the job and Flink version.
Miscellaneous
Always Create CheckpointCoordinator
Currently, the checkpoint coordinator is only created if checkpointing is enabled. This means that it is not possible to trigger a savepoint for stateful jobs that don't have periodic checkpointing enabled.
...