Details
-
Improvement
-
Status: Closed
-
Major
-
Resolution: Fixed
-
1.5.5, 1.6.2, 1.7.0
Description
Ever since FLINK-3397, upon failure, Flink would restart from the latest checkpoint/savepoint which ever is more recent. With the introduction of local recovery and the knowledge that a RocksDB checkpoint restore would just copy the files, it may be time to re-consider / making this configurable:
In certain situations, it may be faster to restore from the latest checkpoint only (even if there is a more recent savepoint) and reprocess the data between. On the downside, though, that may not be correct because that might break side effects if the savepoint was the latest one, e.g. consider this chain: chk1 -> chk2 -> sp … restore chk2 -> …. Then all side effects between chk2 -> sp would be reproduced.
Making this configurable will allow the user to set whatever he needs / can to get the lowest recovery time in Flink.
Attachments
Issue Links
- causes
-
FLINK-14145 getLatestCheckpoint(true) returns wrong checkpoint
- Resolved
-
FLINK-20427 Remove CheckpointConfig.setPreferCheckpointForRecovery because it can lead to data loss
- Closed
-
FLINK-13692 Make CompletedCheckpointStore backwards compatible?
- Closed
- relates to
-
FLINK-8360 Implement task-local state recovery
- Closed
-
FLINK-3397 Failed streaming jobs should fall back to the most recent checkpoint/savepoint
- Closed
- links to