Hi Devs,
Currently there is a number of efforts around checkpoints/savepoints, as
reflected by the number of FLIPs. From a quick look FLIP-34, FLIP-41,
FLIP-43, and FLIP-45 are all directly related to these topics. This
reflects the importance of these two notions/features to the users of the
fram
Hi Kostas,
It makes a lot of sense to just have one underlying mechanism (snapshot) to
save the state of a Flink job. And we can use that mechanism in different
scenarios, including checkpoint and user-triggered savepoint.
To facilitate the discussion, maybe it is useful to clarify a few design
g
Hi Kostas
Thanks for bringing this up. Currently, there are indeed some overlaps
between checkpoint and savepoint that will make user confused. I think the
FLIP's proposal can give users a clearer description.
About the FLIP, I have a question about “Deleting or moving a snapshot
must be done by
Hi all,
Please allow me to throw some points in combination of FLIP-45 [1] for
discussing, and please don't be confused if some of them are inconsistent
or even opposite to current proposals in FLIP-47 (with me as a co-author),
because as Kostas pointed out, the discussion is still in progress and
Hi,
Sorry for the quite late response!
I initially understood FLIP-45 [0] more as a “allow user to
stop-with-checkpoint”, that’s why I didn’t think too much about the other
things it mentions like semantics of savepoints and checkpoints. I thought that
the “stop-with-checkpoint” would work ver
