alpinegizmo commented on a change in pull request #16448: URL: https://github.com/apache/flink/pull/16448#discussion_r667220263
########## File path: docs/content/release-notes/flink-1.13.md ########## @@ -38,6 +38,22 @@ by default before) and there is no option to configure a synchronous snapshot an The constructors of `FsStateBackend` and `MemoryStateBackend` that take a flag for sync/async snapshots are kept for API compatibility, but the flags are ignored now. +#### Disentangle StateBackends from Checkpointing + +##### [FLINK-19463](https://issues.apache.org/jira/browse/FLINK-19463) + +Flink has always separated local state storage from fault tolerance. +Keyed state is maintained locally in state backends, either on the JVM heap or in embedded RocksDB instances. +Fault tolerance comes from checkpoints and savepoints - periodic snapshots of a job's internal state to some durable file system - such as Amazon S3 or HDFS. + +Historically, Flink's `StateBackend` interface intermixed these concepts in a way that confused many users. +In 1.13, checkpointing configurations have been extracted into their own interface, `CheckpointStorage`. + +This change does not affect the runtime behavior and simply provides a better mental model to users. +Pipelines can be updated to use the new the new abstractions without losing state, consistency, or change in semantics. + +Please follow the [migraiton guide](https://ci.apache.org/projects/flink/flink-docs-release-1.13/docs/ops/state/state_backends/#migrating-from-legacy-backends) or JavaDoc on the deprecated state backend classes - `MemoryStateBackend`, `FsStateBackend` and `RocksDBStateBackend` for migration details. Review comment: ```suggestion Please follow the [migration guide](https://ci.apache.org/projects/flink/flink-docs-release-1.13/docs/ops/state/state_backends/#migrating-from-legacy-backends) or the JavaDoc on the deprecated state backend classes - `MemoryStateBackend`, `FsStateBackend` and `RocksDBStateBackend` for migration details. ``` ########## File path: docs/content.zh/release-notes/flink-1.13.md ########## @@ -38,6 +38,20 @@ by default before) and there is no option to configure a synchronous snapshot an The constructors of `FsStateBackend` and `MemoryStateBackend` that take a flag for sync/async snapshots are kept for API compatibility, but the flags are ignored now. +##### [FLINK-19463](https://issues.apache.org/jira/browse/FLINK-19463) + +Flink has always separated local state storage from fault tolerance. +Keyed state is maintained locally in state backends, either on the JVM heap or in embedded RocksDB instances. +Fault tolerance comes from checkpoints and savepoints - periodic snapshots of a job's internal state to some durable file system - such as Amazon S3 or HDFS. + +Historically, Flink's `StateBackend` interface intermixed these concepts in a way that confused many users. +In 1.13, checkpointing configurations have been extracted into their own interface, `CheckpointStorage`. + +This change does not affect the runtime behavior and simply provides a better mental model to users. +Pipelines can be updated to use the new the new abstractions without losing state, consistency, or change in semantics. + +Please follow the [migraiton guide](https://ci.apache.org/projects/flink/flink-docs-release-1.13/docs/ops/state/state_backends/#migrating-from-legacy-backends) or JavaDoc on the deprecated state backend classes - `MemoryStateBackend`, `FsStateBackend` and `RocksDBStateBackend` for migration details. Review comment: ```suggestion Please follow the [migration guide](https://ci.apache.org/projects/flink/flink-docs-release-1.13/docs/ops/state/state_backends/#migrating-from-legacy-backends) or the JavaDoc on the deprecated state backend classes - `MemoryStateBackend`, `FsStateBackend` and `RocksDBStateBackend` for migration details. ``` -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@flink.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
