Hi
你好，这个需求看上去是一个通用的需求（可以是任何的文件进行灾备，刚好这里是 checkpoint 文件），对 hdfs distcp
的限制不太了解，不过如果你要是想做这件事情，能否尝试定时的把文件先 copy 到本集群，然后 copy 后的文件通过 distcp 拷贝到其他集群。
另外改造 flink 代码支持 checkpoint 异步双写这从理论上来说是可以的，不过做的事情可能也不简单，粗略想了下需要：1）tm
端能够双写，可以参考现在开启 localrecovery 的双写（本地和远程）的实现[1] -- 另外需要考虑异常情况；2）jm 端需要考虑
checkpoint m
据说是6月下旬
| |
Sun.Zhu
|
|
17626017...@163.com
|
签名由网易邮箱大师定制
在2020年06月9日 11:13，zhipengchen 写道：
+1
发送自 Windows 10 版邮件应用
发件人: a773807...@gmail.com
发送时间: 2020年6月9日 10:53
收件人: user-zh
主题: 回复: Flink 1.11 什么时候正式发布呢
+1
a773807...@gmail.com
发件人： hyangvv
发送时间： 2020-06-09 10:52
收件人： user-zh
主题： Flink
1: Flink??
--try
catch??checkpoint??
2??checkpoint??savepointsavepoint??
??
3
Hi Xingxing
由于作业仍在运行，所以checkpoint目录下的文件是不断新增以及删除的，其实在使用distcp的时候加上 “-i” [1]
来忽略失败的拷贝（例如FileNotFoundException)
文件即可。因为作业的原始checkpoint目录最终一定可以做到正常restore，所以即使部分文件因为在拷贝时被原作业不需要而删除时，只要最终目录结构一致，是可以做到在另外一个HDFS上实现容灾备份的。
[1]
https://hadoop.apache.org/docs/current/hadoop-distcp/DistCp.html#Command_Line
Hi
我想你的问题是数据源中存在之前代码中没有很好处理的corner
case，导致在处理某一条“脏数据”时，作业进入FAILED状态。此时即使从之前的checkpoint恢复，由于作业代码逻辑未变，之前的corner
case依然无法处理，作业只能无限进去失败状态。
这种场景可以一开始时候将checkpoint的保留策略设置成RETAIN_ON_CANCELLATION
[1]，这样cancel作业之后，更改业务代码逻辑，从而可以处理之前的问题，再降作业上线从之前的checkpoint恢复 [2]，这样做的话，数据是不会丢失的。
[1]
https://ci.apache.o
