当前位置: 首页 > 知识库问答 >
问题:

flink检查点如何帮助故障恢复

蓬新
2023-03-14

1)以上假设是否正确。2)当发生故障时,滚动窗口有状态是否有意义,我们从最后一个kafka分区提交的偏移量开始。3)当滚动窗口有状态时,这个状态什么时候可以被flink使用。4)为什么检查点和保存点的状态大小不同。5)当发生故障时,flink总是从sorce运算符开始。对吗?

共有1个答案

鞠嘉志
2023-03-14

你的假设不正确。

(1)检查点不以任何方式依赖于到达接收器的事件或结果。

(2)Flink做自己的Kafaka偏置管理。当从检查点恢复时,在失败后,使用检查点中的偏移量,而不是那些可能已经提交回Kafka的偏移量。

(4)接收器利用屏障的到达刷新任何排队的输出,并提交挂起的事务。同样,这里有一些复杂性,因为事务接收器使用两阶段提交协议

在应用程序中,如果检查点间隔比窗口持续时间小得多,那么接收器将在从窗口接收任何输出之前完成许多检查点。

(5)当检查点协调器从每个任务中听到检查点已完成时,它就完成检查点元数据。

 类似资料:
  • 我正在检查Flink Sql Table与kafka连接器是否可以在EXACTLY_ONCE模式下执行,我的方法是创建一个表,设置合理的检查点间隔,并在event_time字段上使用简单的翻滚函数,最后重新启动我的程序。 以下是我的详细进度: 1:创建一个Kafka表 2:启动我的 Flink 作业,如下所示配置 3:执行我的sql 如我们所见,翻转窗口间隔为5分钟,检查点间隔为30秒,每个翻转窗

  • 我正在阅读Flink官方文档关于任务失败恢复:https://ci.apache.org/projects/flink/flink-docs-stable/dev/task_failure_recovery.html 据我所知,这个文档告诉我们,如果某个任务由于某种原因失败,Flink可以借助检查点机制来恢复它。 所以现在我还有两个问题: > 如果TaskManager失败怎么办?据我所知,任务分

  • 我有一些必须继续运行的生产关键代码。 将代码视为 我不能相信代码是没有bug的,我需要能够记录问题以便以后调查。 这一次,我知道代码中的某个地方抛出了一个分段错误,我需要至少能够记录该错误,然后重新开始。 阅读这里有几个解决方案,但每一个都是火焰战,声称解决方案实际上弊大于利,没有真正的解释。我也发现了这个我考虑使用的答案,但是我不确定它对我的用例是否有好处。 那么,从C上的分割故障中恢复的最佳方

  • 如果 Flarum 没有按照预期那样安装或工作,您 首先应该检查 服务器环境是否符合 系统要求。如果您缺少一些 Flarum 运行所需的东西,请先补全内容。 然后,请花几分钟时间搜索 支持论坛和 问题跟踪器,有可能该问题已被报告,并且有了解决办法。如果您彻底搜索后,仍然没有找到任何有用的信息,那么就可以开始排查故障了。 在继续前,您应当启用 Flarum 的调试模式。用文本编辑器打开 config

  • 内存限制 eBPF map使用固定的内存(locked memory),但默认非常小,可以通过调用setrlimit(2)来增大RLIMIT_MEMLOCK。如果内存不足,bpf_create_map会返回EPERM (Operation not permitted)错误。 开启BPF JIT 开启方法为 $ sysctl net/core/bpf_jit_enable=1 net.core.bp

  • 不能从其他节点上将raft目录拷贝到mananger节点上,然后重启节点。对于每一个节点ID数据目录是唯一对应的。加入Swarm时每一个节点ID只能被节点使用一次。节点ID控件是全局唯一的。 重新将manager节点加入到集群中,需要如下操作: 将节点降级为worker节点。docker node demote <NODE> 将节点移除。docker node rm <NODE> 将节点重新加入回