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