【发布时间】：2021-02-24 17:28:52
【问题描述】：
我在 K8 上运行大约 1TB 状态的 flink 集群。
我面临的一个问题是获取保存点并恢复工作。现在，这些更新有时只是简单的代码更新，而不是并行性更改。但是获取保存点然后以旧状态恢复新作业的时间相当长。
有没有办法对作业进行就地更新，以使本地状态和作业标识不改变，从而避免执行保存点+恢复所消耗的时间？
【问题讨论】：
标签： apache-flink flink-streaming
【发布时间】：2021-02-24 17:28:52
【问题描述】：
在许多情况下，您可以使用retained (externalized) checkpoints 代替保存点。这有效，但以下情况除外：
- 使用未对齐的检查点重新缩放（此限制将消失；请参阅 FLINK-17979）
- 涉及状态的作业拓扑发生变化
- 需要状态迁移的类型发生了变化
您可能会发现拓扑更改和状态迁移在某些情况下会起作用，但这不能保证。
对于 RocksDB 上的大型状态，您将需要使用增量检查点。完整的检查点和保存点需要很长时间，但增量检查点要快得多。
如果您确实想重新缩放，增加 RocksDB 可用的线程数是有益的，更像这样：
state.backend.rocksdb.checkpoint.transfer.thread.num: 8
state.backend.rocksdb.thread.num: 8
【讨论】：
-
谢谢大卫，关于保留检查点的一个问题。我们正在使用 s3 类型的检查点存储。使用保留的检查点是否也会保留本地状态检查点？
-
是的，我相信是的。
-
再次感谢。
state.backend.rocksdb.checkpoint.transfer.thread.num的文档说The number of threads (per stateful operator) used to transfer (download and upload) files in RocksDBStateBackend.它是否也适用于 Keyed State？ -
RocksDB 仅用于键控状态。所以是的。