Myasuka commented on a change in pull request #19207:
URL: https://github.com/apache/flink/pull/19207#discussion_r833375035
##########
File path: docs/content.zh/docs/ops/state/savepoints.md
##########
@@ -157,10 +157,54 @@ $ bin/flink run -s :savepointPath [:runArgs]
默认情况下，resume 操作将尝试将 Savepoint 的所有状态映射回你要还原的程序。 如果删除了运算符，则可以通过
`--allowNonRestoredState`（short：`-n`）选项跳过无法映射到新程序的状态：
+#### Restore 模式
+
+`Restore 模式` 决定了在 restore 之后谁拥有组成 Savepoint 或者 [externalized checkpoint]({{<
ref "docs/ops/state/checkpoints"
>}}/#resuming-from-a-retained-checkpoint)的文件的所有权。在这种语境下 Savepoint 和
externalized checkpoint 的行为相似。这里我们将它们都称为“快照”，除非另有明确说明。
+
+如前所述，restore 模式决定了谁来接管我们从中恢复的快照文件的所有权。快照可被用户或者 Flink 自身拥有。如果快照归用户所有，Flink
不会删除其中的文件，而且 Flink 不能依赖该快照中文件的存在，因为它可能在 Flink 的控制之外被删除。
+
+每种 restore 模式都有特定的用途。尽管如此，我们仍然认为默认的 *NO_CLAIM*
模式在大多数情况下是一个很好的折中方案，因为它在提供明确的所有权归属的同时只给恢复后第一个 checkpoint 带来较小的代价。
+
+你可以通过如下方式指定 restore 模式：
```shell
-$ bin/flink run -s :savepointPath -n [:runArgs]
+$ bin/flink run -s :savepointPath -restoreMode :mode -n [:runArgs]
```
+**NO_CLAIM （默认的）**
+
+在 *NO_CLAIM* 模式下，Flink
不会接管快照的所有权。它会将快照的文件置于用户的控制之中，并且永远不会删除其中的任何文件。该模式下可以从同一个快照上启动多个作业。
+
+为保证 Flink 不会依赖于该快照的任何文件，它会强制第一个（成功的） checkpoint 为全量 checkpoint
而不是增量的。这仅对`state.backend: rocksdb` 有影响，因为其他 backend 总是制作全量 checkpoint。
+
+一旦第一个全量的 checkpoint 完成后，所有后续的 checkpoint 会照常制作（按照配置）。所以，一旦一个 checkpoint
成功制作，就可以删除原快照。在此之前不能删除原快照，因为没有任何完成的 checkpoint，Flink 会在故障时尝试从初始的快照恢复。
+
+<div style="text-align: center">
+ {{< img src="/fig/restore-mode-no_claim.svg" alt="NO_CLAIM restore mode"
width="70%" >}}
+</div>
+
+**CLAIM**
+
+另一个可选的模式是 *CLAIM* 模式。该模式下 Flink 将声称拥有快照的所有权，并且本质上将其作为 checkpoint
对待：控制其生命周期并且可能会在其永远不会被用于恢复的时候删除它。因此，手动删除快照和从同一个快照上启动两个作业都是不安全的。Flink
会保持[配置数量]({{< ref "docs/dev/datastream/fault-tolerance/checkpointing"
>}}/#state-checkpoints-num-retained)的 checkpoint。
+
+<div style="text-align: center">
+ {{< img src="/fig/restore-mode-claim.svg" alt="CLAIM restore mode"
width="70%" >}}
+</div>
+
+{{< hint info >}}
+**注意：**
+1. Retained checkpoints 被存储在 `<checkpoint_dir>/<job_id>/chk_<x>` 这样的目录中。Flink
不会接管 `<checkpoint_dir>/<job_id>` 目录的所有权，而只会接管 `chk_<x>` 的所有权。Flink 不会删除旧作业的目录。
+
+2. [Native](#savepoint-format) 格式支持增量的 RocksDB savepoints。对于这些
savepoints，Flink 将所有 SST 文件放到 savepoints 目录中。这意味着这些 savepoints 是自包含和可移动的。然而，在
CLAIM 模式下恢复时，后续的 checkpoints 可能会重用一些 SST 文件，这反过来会阻止在 savepoints 被清理时删除
savepoints 目录。稍后 Flink 会删除重用的共享的 SST 文件，但不会重试删除 savepoints 目录。因此，如果在 CLAIM
模式下恢复，Flink 可能会留下一个空的 savepoints 目录。
+{{< /hint >}}
+
+**LEGACY**
+
+Legacy 模式是 Flink 在 1.15 之前的工作方式。该模式下 Flink 永远不会删除初始的
checkpoint。同时，用户也不清楚是否可以删除它。这里的问题是 Flink 可能会立即在恢复的 checkpoint 之上制作一个增量的
checkpoint。因此后续的 checkpoint 会依赖于恢复的 checkpoint。总而言之，恢复的 checkpoint 的所有权没有明确的界定。
Review comment:
```suggestion
Legacy 模式是 Flink 在 1.15 之前的工作方式。该模式下 Flink 永远不会删除初始恢复的
checkpoint。同时，用户也不清楚是否可以删除它。导致该的问题原因是， Flink 会在用来恢复的 checkpoint 之上创建增量的
checkpoint，因此后续的 checkpoint 都有可能会依赖于用于恢复的那个 checkpoint。总而言之，恢复的 checkpoint
的所有权没有明确的界定。
```
##########
File path: docs/content.zh/docs/ops/state/savepoints.md
##########
@@ -157,10 +157,54 @@ $ bin/flink run -s :savepointPath [:runArgs]
默认情况下，resume 操作将尝试将 Savepoint 的所有状态映射回你要还原的程序。 如果删除了运算符，则可以通过
`--allowNonRestoredState`（short：`-n`）选项跳过无法映射到新程序的状态：
+#### Restore 模式
+
+`Restore 模式` 决定了在 restore 之后谁拥有组成 Savepoint 或者 [externalized checkpoint]({{<
ref "docs/ops/state/checkpoints"
>}}/#resuming-from-a-retained-checkpoint)的文件的所有权。在这种语境下 Savepoint 和
externalized checkpoint 的行为相似。这里我们将它们都称为“快照”，除非另有明确说明。
+
+如前所述，restore 模式决定了谁来接管我们从中恢复的快照文件的所有权。快照可被用户或者 Flink 自身拥有。如果快照归用户所有，Flink
不会删除其中的文件，而且 Flink 不能依赖该快照中文件的存在，因为它可能在 Flink 的控制之外被删除。
+
+每种 restore 模式都有特定的用途。尽管如此，我们仍然认为默认的 *NO_CLAIM*
模式在大多数情况下是一个很好的折中方案，因为它在提供明确的所有权归属的同时只给恢复后第一个 checkpoint 带来较小的代价。
+
+你可以通过如下方式指定 restore 模式：
```shell
-$ bin/flink run -s :savepointPath -n [:runArgs]
+$ bin/flink run -s :savepointPath -restoreMode :mode -n [:runArgs]
```
+**NO_CLAIM （默认的）**
+
+在 *NO_CLAIM* 模式下，Flink
不会接管快照的所有权。它会将快照的文件置于用户的控制之中，并且永远不会删除其中的任何文件。该模式下可以从同一个快照上启动多个作业。
+
+为保证 Flink 不会依赖于该快照的任何文件，它会强制第一个（成功的） checkpoint 为全量 checkpoint
而不是增量的。这仅对`state.backend: rocksdb` 有影响，因为其他 backend 总是制作全量 checkpoint。
Review comment:
```suggestion
为保证 Flink 不会依赖于该快照的任何文件，它会强制第一个（成功的） checkpoint 为全量 checkpoint
而不是增量的。这仅对`state.backend: rocksdb` 有影响，因为其他 backend 总是创建全量 checkpoint。
```
--
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: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
