我是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上的故障恢复没有什么特别之处。