我是flink的新手,计划在eks上部署flink会话集群,配置1个作业管理器和5个任务管理器(每个任务管理器有4个插槽)。不同的作业将通过ui提交给不同的用例。
假设我已经提交了一个有状态的作业(作业具有使用richflatmapfunction的简单计数器逻辑),由rocksdbstatebindend支持,s3 checkpointdatauri和dbstoragepath指向本地文件路径,这个作业总共使用了8个插槽,分布在两个任务管理器中,一天内运行良好,没有任何问题。下面是我的问题,
1) 我对rocksdbstatebend中的checkpointdatauri和dbstoragepath的理解是,checkpointdatauri将处理后的偏移量信息存储在s3中(因为我用s3前缀配置了checkpointdatauri),dbstoragepath包含richflatmapfunction中使用的所有状态信息。所以所有有状态的信息都存储在checkpointdatauri中,checkpointdatauri只在本地可用。如果错了,请纠正我。
2) 假设我的ec2示例由于某种原因被重新启动(使用了4个插槽的示例),并且它花费了大约30分钟才上线,在这种情况下,eks将使新的ec2示例成为taskmanager以匹配副本,但是flink作业管理器是否会尝试现在将4个插槽重新安排到不同的任务管理器?如果是,如何恢复ec2本地示例中存储的状态?
3) 是否有与flink eks故障恢复相关的文件/视频。我看到了官方文档,其中指定了如何在eks中部署flink会话集群。但我没有发现任何与eks模式下的故障恢复相关的东西。有人能告诉我这个问题的正确方向吗?
1条答案
按热度按时间xsuvu9jc1#
您所关心的所有状态,即已处理的偏移量和
RichFlatMapFunction
(以及flink为您的作业管理的任何其他状态)存储在本地磁盘(dbstoragepath)和s3(checkpointdatauri)中。flink总是将所有状态的工作副本保存在每个任务管理器的本地(用于高吞吐量和低延迟),并在后台将该状态的完整副本保存到分布式文件系统(如s3)以确保可靠性。
换句话说,你在问题的第(1)点所说的是不正确的。第(2)点的答案是,如果s3在本地不可用,那么要恢复的状态总是可以从s3恢复的。至于第(3)点,与任何其他flink部署模型相比,eks上的故障恢复没有什么特别之处。