THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
| Page properties | |||||
|---|---|---|---|---|---|
|
Status
Current state: Under Discussion
Discussion thread: -
...
|
...
|
Please keep the discussion on the mailing list rather than commenting on the wiki (wiki discussions get unwieldy fast).
| Table of Contents |
|---|
This is a follow up on https://cwiki.apache.org/confluence/display/FLINK/FLIP-193%3A+Snapshots+ownership which this is heavily relying on and as such please check FLIP-193 before for the require context
...
Yes | Yes (unofficially)/Maybe (untested) | No (but could be done) | Very difficult/impossible |
Canonical Savepoint | Aligned Checkpoint | Unaligned Checkpoint | |
Statebackend change | |||
| Self-contained and relocatable | |||
State Processor API(reading) | (|||
| State Processor API(writing) | |||
Schema evolution | untested? | untested? | |
Flink minor (1.x → 1.y) version upgrade | (???) | ||
Flink bug/patch (1.14.x → 1.14.y) version upgrade | (???) | (???) | |
Arbitrary job upgrade (changed graph shape/record types) | |||
Job upgrade w/o changing graph shape and record types | |||
Rescaling |
...
What about RocksDB upgrades? If we bump RocksDB version between Flink versions, do we support recovering from a native format snapshot (incremental checkpoint)?
Proposal
...
Canonical Savepoint | Native Savepoint | Aligned Checkpoint | Unaligned Checkpoint | |||||||||||
Statebackend change | ||||||||||||||
| Self-contained and relocatable | ||||||||||||||
State Processor API( | ???reading) | (???) | Schema evolution | (??? | )(???) | (???) | Flink minor (1.x → 1.y) version upgrade | Flink bug/patch (1.14.x → 1.14.y) version upgrade | (change) | (change) | Arbitrary job upgrade (changed graph shape/record types) | Job upgrade w/o changing graph shape and record types | Rescaling
Main aim of the first proposal is to unify guarantees between two types of savepoints and two types of checkpoints. The only difference between native and canonical savepoint should be the ability to change statebackend, and officially there would be no difference between aligned and unaligned checkpoints. Hence we would simplify the documentation, as we could avoid documenting the distinction between unaligned and aligned checkpoints.
Proposal 2
Canonical Savepoint | Native Savepoint | Aligned Checkpoint | Unaligned Checkpoint | Statebackend change | State Processor API | (???writing) | ||||
(???) | Schema evolution | (???) | (???) | (???) | ||||||
Flink minor (1.x → 1.y) version upgrade | (change) | |||||||||
Flink bug/patch (1.14.x → 1.14.y) version upgrade | (change) | (change) | ||||||||
Arbitrary job upgrade (changed graph shape/record types) | (change) | |||||||||
Job upgrade w/o changing graph shape and record types | (change) | (change) | ||||||||
Rescaling |
...
Support of the incremental savepoint is subject to configured statebackend providing such feature. For example, without FLIP-151, HashMapStatebackend would not be able to provide incremental savepoints.the default configuration
This FLIP-203 does not intend to define guarantees for usage of State Processor API and Schema evolution with native format checkpoints or savepoints. This is intended as a follow up work in the future.
Compatibility, Deprecation, and Migration Plan
...
- In Flink 1.15 `--native` savepoint mode is added, but `--canonical` is kept the default.
- In Flink 1.16 `--native` will become the new default.
Rejected Alternatives
Rejected proposal for checkpoint guarantees
Canonical Savepoint | Native Savepoint | Aligned Checkpoint | Unaligned Checkpoint | |
Statebackend change | ||||
| Self-contained and relocatable | ||||
State Processor API | (???) | (???) | ||
Schema evolution | (???) | (???) | (???) | |
Flink minor (1.x → 1.y) version upgrade | ||||
Flink bug/patch (1.14.x → 1.14.y) version upgrade | (change) | (change) | ||
Arbitrary job upgrade (changed graph shape/record types) | ||||
Job upgrade w/o changing graph shape and record types | ||||
Rescaling |
Main aim of the first proposal was to unify guarantees between two types of savepoints and two types of checkpoints. The only difference between native and canonical savepoint should be the ability to change statebackend, and officially there would be no difference between aligned and unaligned checkpoints. Hence we would simplify the documentation, as we could avoid documenting the distinction between unaligned and aligned checkpoints.
It was rejected because native savepoints and checkpoints are basically the same thing, so there is not much sense in artificially decreasing aligned checkpoint guarantees.