背景：目前的yarn集群比较少，在数据量大一点，运行资源不足的情况下经常会影响到实时程序（内心os：还不如搭个flink 集群得了跑啥on yarn嘛毕竟穷是原罪。。。，现在整天都要擦屁股。。。。。）
心跳容器超时，也就是在规定的时间内TaskManager 无法为task 向JobManager申请到container 网络，cores，内存都有可能引起
直接查看flink的重启策略是什么：点击dashborad=》Running Job =》Configuration
默认重启策略，没开启checkpoiting就是不重启，开启了就是固定延时重启，不理解策略的看下面👇
这里是on yarn模式，没有开启checkpoint模式所以是不重启直接结束了
如果需要开始checkpoint模式，参考文章：Flink的checkpoint配置详解
StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment();
// start a checkpoint every 1000 ms
env.enableCheckpointing(1000);
// advanced options:
// set mode to exactly-once (this is the default)
env.getCheckpointConfig().setCheckpointingMode(CheckpointingMode.EXACTLY_ONCE);
// checkpoints have to complete within one minute, or are discarded
env.getCheckpointConfig().setCheckpointTimeout(60000);
// make sure 500 ms of progress happen between checkpoints
env.getCheckpointConfig().setMinPauseBetweenCheckpoints(500);
// allow only one checkpoint to be in progress at the same time
env.getCheckpointConfig().setMaxConcurrentCheckpoints(1);
// enable externalized checkpoints which are retained after job cancellation
env.getCheckpointConfig().enableExternalizedCheckpoints(ExternalizedCheckpointCleanup.RETAIN_ON_CANCELLATION);
// This determines if a task will be failed if an error occurs in the execution of the task’s checkpoint procedure.
env.getCheckpointConfig().setFailOnCheckpointingErrors(true);- 使用StreamExecutionEnvironment.enableCheckpointing方法来设置开启checkpoint；具体可以使用enableCheckpointing(long interval)，或者enableCheckpointing(long interval, CheckpointingMode mode)；interval用于指定checkpoint的触发间隔(单位milliseconds)，而CheckpointingMode默认是CheckpointingMode.EXACTLY_ONCE，也可以指定为CheckpointingMode.AT_LEAST_ONCE
- 也可以通过StreamExecutionEnvironment.getCheckpointConfig().setCheckpointingMode来设置CheckpointingMode，一般对于超低延迟的应用(大概几毫秒)可以使用CheckpointingMode.AT_LEAST_ONCE，其他大部分应用使用CheckpointingMode.EXACTLY_ONCE就可以
checkpointTimeout用于指定checkpoint执行的超时时间(单位milliseconds)，超时没完成就会被abort掉
- MinPauseBetweenCheckpoints用于指定checkpoint coordinator上一个checkpoint完成之后最小等多久可以出发另一个checkpoint，当指定这个参数时，maxConcurrentCheckpoints的值为1 单位为ms
- MaxConcurrentCheckpoints用于指定运行中的checkpoint最多同时可以有多少个，用于包装topology不会花太多的时间在checkpoints上面；如果有设置了minPauseBetweenCheckpoints，则maxConcurrentCheckpoints这个参数就不起作用了(大于1的值不起作用)
- EnableExternalizedCheckpoints用于开启checkpoints的外部持久化，但是在job失败的时候不会自动清理，需要自己手工清理state；ExternalizedCheckpointCleanup用于指定当job canceled的时候externalized checkpoint该如何清理，DELETE_ON_CANCELLATION的话，在job canceled的时候会自动删除externalized state，但是如果是FAILED的状态则会保留；RETAIN_ON_CANCELLATION则在job canceled的时候会保留externalized checkpoint state
- FailOnCheckpointingErrors用于指定在checkpoint发生异常的时候，是否应该fail该task，默认为true，如果设置为false，则task会拒绝checkpoint然后继续运行
flink-conf.yaml相关配置
#==============================================================================
# Fault tolerance and checkpointing
#==============================================================================
# The backend that will be used to store operator state checkpoints if
# checkpointing is enabled.
#
# Supported backends are 'jobmanager', 'filesystem', 'rocksdb', or the
# <class-name-of-factory>.
#
# state.backend: filesystem
# Directory for checkpoints filesystem, when using any of the default bundled
# state backends.
#
# state.checkpoints.dir: hdfs://namenode-host:port/flink-checkpoints
# Default target directory for savepoints, optional.
#
# state.savepoints.dir: hdfs://namenode-host:port/flink-checkpoints
# Flag to enable/disable incremental checkpoints for backends that
# support incremental checkpoints (like the RocksDB state backend).
#
# state.backend.incremental: false
- state.backend用于指定checkpoint state存储的backend，默认为none
- state.backend.async用于指定backend是否使用异步snapshot(默认为true)，有些不支持async或者只支持async的state backend可能会忽略这个参数
- state.backend.fs.memory-threshold，默认为1024，用于指定存储于files的state大小阈值，如果小于该值则会存储在root checkpoint metadata file
- state.backend.incremental，默认为false，用于指定是否采用增量checkpoint，有些不支持增量checkpoint的backend会忽略该配置
- state.backend.local-recovery，默认为false
- state.checkpoints.dir，默认为none，用于指定checkpoint的data files和meta data存储的目录，该目录必须对所有参与的TaskManagers及JobManagers可见
- state.checkpoints.num-retained，默认为1，用于指定保留的已完成的checkpoints个数
- state.savepoints.dir，默认为none，用于指定savepoints的默认目录
- taskmanager.state.local.root-dirs，默认为none
遇事不决可问官网，链接我都帮你们你们找好了，你们这群懒人（其实我就很赖，啊哈哈哈哈。。。。）
https://ci.apache.org/projects/flink/flink-docs-release-1.11/dev/task_failure_recovery.html
Flink 作业如果没有定义重启策略，则会遵循集群启动时加载的默认重启策略。 如果提交作业时设置了重启策略，该策略将覆盖掉集群的默认策略。
通过 Flink 的配置文件 flink-conf.yaml 来设置默认的重启策略。配置参数 restart-strategy 定义了采取何种策略。 如果没有启用 checkpoint，就采用“不重启”策略。如果启用了 checkpoint 且没有配置重启策略，那么就采用固定延时重启策略， 此时最大尝试重启次数由 Integer.MAX_VALUE 参数设置。下表列出了可用的重启策略和与其对应的配置值。
每个重启策略都有自己的一组配置参数来控制其行为。 这些参数也在配置文件中设置。 后文的描述中会详细介绍每种重启策略的配置项。
| Key | Default | Type | Description |
|---|---|---|---|
| restart-strategy | (none) | String | Defines the restart strategy to use in case of job failures. Accepted values are:
none. If checkpointing is enabled, the default value is fixed-delay with Integer.MAX_VALUE restart attempts and '1 s' delay. |
除了定义默认的重启策略以外，还可以为每个 Flink 作业单独定义重启策略。 这个重启策略通过在程序中的 ExecutionEnvironment 对象上调用 setRestartStrategy 方法来设置。 当然，对于 StreamExecutionEnvironment 也同样适用。
1、重启策略 Restart Strategies
1.1、固定延时重启策略 Fixed Delay Restart Strategy
固定延时重启策略按照给定的次数尝试重启作业。 如果尝试超过了给定的最大次数，作业将最终失败。 在连续的两次重启尝试之间，重启策略等待一段固定长度的时间。
通过在 flink-conf.yaml 中设置如下配置参数，默认启用此策略。
restart-strategy: fixed-delay如下见词知其意：一个是尝试次数，一个是间隔时间
| Key | Default | Type | Description |
|---|---|---|---|
| restart-strategy.fixed-delay.attempts | 1 | Integer | The number of times that Flink retries the execution before the job is declared as failed if restart-strategy has been set to fixed-delay. |
| restart-strategy.fixed-delay.delay | 1 s | Duration | Delay between two consecutive restart attempts if restart-strategy has been set to fixed-delay. Delaying the retries can be helpful when the program interacts with external systems where for example connections or pending transactions should reach a timeout before re-execution is attempted. It can be specified using notation: "1 min", "20 s" |
例如：
restart-strategy.fixed-delay.attempts: 3
restart-strategy.fixed-delay.delay: 10 s下例展示了如何给我们的作业设置固定延时重启策略。 如果发生故障，系统会重启作业 3 次，每两次连续的重启尝试之间等待 10 秒钟。
- Java
-
ExecutionEnvironment env = ExecutionEnvironment.getExecutionEnvironment(); env.setRestartStrategy(RestartStrategies.fixedDelayRestart( 3, // 尝试重启的次数 Time.of(10, TimeUnit.SECONDS) // 延时 )); - Scala
-
val env = ExecutionEnvironment.getExecutionEnvironment() env.setRestartStrategy(RestartStrategies.fixedDelayRestart( 3, // 尝试重启的次数 Time.of(10, TimeUnit.SECONDS) // 延时 ))
1.2、故障率重启策略 Failure Rate Restart Strategy
故障率重启策略在故障发生之后重启作业，但是当故障率（每个时间间隔发生故障的次数）超过设定的限制时，作业会最终失败。 在连续的两次重启尝试之间，重启策略等待一段固定长度的时间。
通过在 flink-conf.yaml 中设置如下配置参数，默认启用此策略。
restart-strategy: failure-rate如下所示：
1、两次失败中间的延迟时间
2、失败时间间隔
3、每个时间间隔内最大失败次数
| Key | Default | Type | Description |
|---|---|---|---|
| restart-strategy.failure-rate.delay | 1 s | Duration | Delay between two consecutive restart attempts if restart-strategy has been set to failure-rate. It can be specified using notation: "1 min", "20 s" |
| restart-strategy.failure-rate.failure-rate-interval | 1 min | Duration | Time interval for measuring failure rate if restart-strategy has been set to failure-rate. It can be specified using notation: "1 min", "20 s" |
| restart-strategy.failure-rate.max-failures-per-interval | 1 | Integer | Maximum number of restarts in given time interval before failing a job if restart-strategy has been set to failure-rate. |
例如：
restart-strategy.failure-rate.max-failures-per-interval: 3
restart-strategy.failure-rate.failure-rate-interval: 5 min
restart-strategy.failure-rate.delay: 10 s- Java
-
ExecutionEnvironment env = ExecutionEnvironment.getExecutionEnvironment(); env.setRestartStrategy(RestartStrategies.failureRateRestart( 3, // 每个时间间隔的最大故障次数 Time.of(5, TimeUnit.MINUTES), // 测量故障率的时间间隔 Time.of(10, TimeUnit.SECONDS) // 延时 )); - Scala
-
val env = ExecutionEnvironment.getExecutionEnvironment() env.setRestartStrategy(RestartStrategies.failureRateRestart( 3, // 每个时间间隔的最大故障次数 Time.of(5, TimeUnit.MINUTES), // 测量故障率的时间间隔 Time.of(10, TimeUnit.SECONDS) // 延时 ))
1.3、没有重启策略直接结束 No Restart Strategy
作业直接失败，不尝试重启。
restart-strategy: none- Java
-
ExecutionEnvironment env = ExecutionEnvironment.getExecutionEnvironment(); env.setRestartStrategy(RestartStrategies.noRestart()); - Scala
-
val env = ExecutionEnvironment.getExecutionEnvironment() env.setRestartStrategy(RestartStrategies.noRestart())
1.4 Fallback Restart Strategy
使用集群自定义的重启策略。 这对于启用了 checkpoint 的流处理程序很有帮助。 如果没有定义其他重启策略，默认选择固定延时重启策略。
2、故障转移策略 Failover Strategies
Flink 支持多种不同的故障恢复策略，该策略需要通过 Flink 配置文件 flink-conf.yaml 中的 jobmanager.execution.failover-strategy 配置项进行配置。
| 故障恢复策略 | jobmanager.execution.failover-strategy 配置值 |
|---|---|
| 全图重启 | full |
| 基于 Region 的局部重启 | region |
2.1、全图重启 Restart All Failover Strategy
在全图重启故障恢复策略下，Task 发生故障时会重启作业中的所有 Task 进行故障恢复。
2.2、基于Region的局部重启策略 Restart Pipelined Region Failover Strategy
该策略会将作业中的所有 Task 划分为数个 Region。当有 Task 发生故障时，它会尝试找出进行故障恢复需要重启的最小 Region 集合。 相比于全局重启故障恢复策略，这种策略在一些场景下的故障恢复需要重启的 Task 会更少。
此处 Region 指以 Pipelined 形式进行数据交换的 Task 集合。也就是说，Batch 形式的数据交换会构成 Region 的边界。
- DataStream 和 流式 Table/SQL 作业的所有数据交换都是 Pipelined 形式的。
- 批处理式 Table/SQL 作业的所有数据交换默认都是 Batch 形式的。
- DataSet 作业中的数据交换形式会根据 ExecutionConfig 中配置的 ExecutionMode 决定。
需要重启的 Region 的判断逻辑如下：
- 出错 Task 所在 Region 需要重启。
- 如果要重启的 Region 需要消费的数据有部分无法访问（丢失或损坏），产出该部分数据的 Region 也需要重启。
- 需要重启的 Region 的下游 Region 也需要重启。这是出于保障数据一致性的考虑，因为一些非确定性的计算或者分发会导致同一个 Result Partition 每次产生时包含的数据都不相同
最终解决方案：
final StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment();
env.enableCheckpointing(10000, CheckpointingMode.EXACTLY_ONCE);
env.setRestartStrategy(RestartStrategies.failureRateRestart(3, Time.of(5, TimeUnit.MINUTES),Time.of(10, TimeUnit.SECONDS)));
try {
2041
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
