[
https://issues.apache.org/jira/browse/FLINK-17808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17112652#comment-17112652
]
Stephan Ewen commented on FLINK-17808:
--------------------------------------
I think this pattern (atomically visible file) may be quite common. We can add
a method to {{FileSystem}} or add a flag to {{create(Path)}} to create a stream
for a file that is only visible once the writing is complete.
That should be easy to implement
- file:// will to that via rename
- hdfs:// will do that via rename
- s3:// does not need to do anything, it always behaves like that.
- oss:// ? (not sure, but I would assume also does not need anything, object
stores tend to publish at the end)
This avoids cases where components manually implement a rename-based solution
(which breaks S3 and probably other object store visibility consistency)
> Rename checkpoint meta file to "_metadata" until it has completed writing
> -------------------------------------------------------------------------
>
> Key: FLINK-17808
> URL: https://issues.apache.org/jira/browse/FLINK-17808
> Project: Flink
> Issue Type: Improvement
> Components: Runtime / Checkpointing
> Affects Versions: 1.10.0
> Reporter: Yun Tang
> Assignee: Yun Tang
> Priority: Major
> Fix For: 1.12.0
>
>
> In practice, some developers or customers would use some strategy to find the
> recent _metadata as the checkpoint to recover (e.g as many proposals in
> FLINK-9043 suggest). However, there existed a "_meatadata" file does not mean
> the checkpoint have been completed as the writing to create the "_meatadata"
> file could break as some force quit (e.g. yarn application -kill).
> We could create the checkpoint meta stream to write data to file named as
> "_metadata.inprogress" and renamed it to "_metadata" once completed writing.
> By doing so, we could ensure the "_metadata" is not broken.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
