Job失败后，从检查点恢复

自动恢复机制 和 手动作业恢复机制

作业失败重启策略
定期恢复策略：fixed-delay。 
固定延迟重启策略会尝试一个给定的次数来重启Job，如果超过最大的重启次数，Job最终将失败，在连续两次重启尝试之间，重启策略会等待一个固定时间，默认Integer.MAX_VALUE次

失败比率策略：failure-rate。
失败率重启策略在job失败后重启，但是超过失败率后，Job会最终被认定失败，在两个连续的重启尝试之间，重启策略会等待一个固定的时间。

直接失败策略：None   失败不重启。


手动作业恢复机制
检查点目录分别对应的是JobId，每通过flink run 方式/页面提交方式恢复都会重新生成 jobId，
Flink 提供了在启动之时通过设置 -s 参数指定检查点目录的功能，让新的 job 读取该检查点元文件信息和状态信息 

checkpoint vs savepoint 

触发方式 自动  手动

主要功能
task异常 application异常 恢复  ，保证数据一致性 
按计划备份数据 ， 作业升级备份 ， 代码修改

特点
轻量级 支持增量  作业停止后默认删除 
持久化存储  可人为从savepoint恢复




从checkpoint 恢复
如果Flink程序异常失败，或者最近一段时间内数据处理错误，可以从某一个Checkpoint点，比如chk-860进行回放
bin/flink run -s hdfs://namenode01.td.com/flink-1.5.3/flink-checkpoints/582e17d2cc343e6c56255d111bae0191/chk-860/_metadata flink-app-jobs.jar

所有的Checkpoint文件都在以Job ID为名称的目录里面
当Job停掉后，重新从某个Checkpoint点（chk-860）进行恢复时，重新生成Job ID
Checkpoint编号会从该次运行基于的编号继续连续生成：chk-861、chk-862、chk-863

checkpoint的建议

Checkpoint 间隔不要太短
过短的间对于底层分布式文件系统而言，会带来很大的压力。
Flink 作业处理 record 与执行 checkpoint 存在互斥锁，过于频繁的checkpoint，可能会影响整体的性能。
合理设置超时时间


conf/flink-conf.yaml 配置 Savepoint存储目录

state.savepoints.dir: hdfs://namenode01.td.com/flink/flink-savepoints

手动执行savepoint命令 ，指定Savepoint存储目录
bin/flink savepoint :jobId [:targetDirectory]


使用默认配置
bin/flink savepoint 40dcc6d2ba90f13930abce295de8d038

为正在运行的Flink Job指定一个目录存储Savepoint数据
bin/flink savepoint 40dcc6d2ba90f13930abce295de8d038 hdfs://namenode01.td.com/tmp/flink/savepoints

从Savepoint恢复
bin/flink run -s :savepointPath [:runArgs]

bin/flink run -s hdfs://namenode01.td.com/tmp/flink/savepoints/savepoint-40dcc6-a90008f0f82f flink-app-jobs.jar



checkpoint 和 savepoint 作业快照机制 


checkpoint的侧重点是“容错”，即Flink作业意外失败并重启之后，能够直接从早先打下的checkpoint恢复运行，且不影响作业逻辑的准确性。
savepoint的侧重点是“维护”，即Flink作业需要在人工干预下手动重启、升级、迁移或A/B测试时，先将状态整体写入可靠存储，维护完毕之后再从savepoint恢复现场。

savepoint是 通过checkpoint机制创建的，所以savepoint本质上是特殊的checkpoint

checkpoint面向Flink Runtime本身，由Flink的各个TaskManager定时触发快照并自动清理，一般不需要用户干预
savepoint面向用户，完全根据用户的需要触发与清理。

checkpoint的频率往往比较高（因为需要尽可能保证作业恢复的准确度），所以checkpoint的存储格式非常轻量级，
但作为trade-off牺牲了一切可移植（portable）的东西，比如不保证改变并行度和升级的兼容性。
savepoint则以二进制形式存储所有状态数据和元数据，执行起来比较慢而且“贵”，但是能够保证portability，如并行度改变或代码升级之后，仍然能正常恢复。

checkpoint 支持增量（通过RocksDB），特别是对于超大状态的作业而言可以降低写入成本