Flink 解析（六）：Savepoints

目录

Savepoints

分配算子ID

savepoint操作

配置savepoint

触发savepoint

恢复savepoint

删除savepoint

F.A.Q

我应该为我作业中的所有算子分配 ID 吗?

如果我在作业中添加一个需要状态的新算子，会发生什么?

如果从作业中删除有状态的算子会发生什么?

如果我在作业中重新排序有状态算子，会发生什么?

如果我添加、删除或重新排序作业中没有状态的算子，会发生什么?

当我在恢复时改变程序的并行度时会发生什么?

我可以将 savepoint 文件移动到稳定存储上吗?

参考

---

Savepoints

因为Flink的savepoint与checkpoint也有不同之处，跟我之前写的Flink恢复机制有提到过。但是不太详细，所以根据官方文档，详细的说下savepoint。

Savepoint是根据Flink checkpoint机制所创建的流作业执行状态的一致镜像，说白了其实跟checkpoint一样，也是一个快照文件，只不过这个快照是我们手动去触发的。checkpoint主要是为了故障恢复时使用，而我们可以使用savepoint进行Flink作业停止与重启、fork或者更新，例如版本更新或者主动停止Job的时候使用。

Savepoint由两部分组成：稳定存储(例如HDFS,S3等)上存储的二进制文件的目录(通常很大)，以及元数据文件(相对较小)。其中，稳定存储上的文件表示作业执行的状态的数据镜像(即快照)，元数据文件以相对路径的形式包含主要只想作为Savepoint一部分的稳定存储上的文件的指针。

其实savepoint和checkpoint的代码实现基本上是相同的，并且生成的格式也是一致的，然而为什么会有两种名称呢？ 那是因为它们之间存在着概念上的一些差异(还有RocksDB增量checkpoint快照的区别，未来可能还有其他的)。

从概念上来说，savepoint有点像传统数据库当中的备份，而checkpoint有点像是恢复日志的区别。

Checkpoint目的在于为意外失败的作业提供恢复机制，由Flink进行管理(创建、管理、删除)，不需要与人交互，对于使用者是无感的，一般Job结束就会被Flink自动删除checkpoint除非有配置保留。

Savepoint更多的关注于可移植性和对作业的更改支持。savepoint一般是由用户创建、管理、删除。这些用例是计划的，手动备份和恢复的，一般在升级Flink版本，调整用户逻辑，更改并行度或者进行红蓝部署的时候使用。而且Job结束后，savepoint还会存在。

还有一个不同在于，从1.11.0版本开始，Flink可以通过移动拷贝将savepoint目录移动到任意地方，然后再进行恢复，而checkpoint不支持任意移动文件，因为checkpoint中包含一些文件的绝对路径。

不过有两种情况不支持移动savepoint目录的移动

• 如果启用了 entropy injection ：这种情况下，savepoint目录不包含所有的数据文件，因为注入的路径会分散在各个路径中。因为缺少一个公共的根目录，所以savepoint将包含绝对路径，从而导致无法支持savepoint目录的迁移。
• 作业包含了task-owned state， 比如GenericWriteAhreadLog sink。

如果我们使用的是MemoryStateBackend ，可能会在目录下没有数据文件<