You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@flink.apache.org by GitBox <gi...@apache.org> on 2021/09/02 14:38:41 UTC
[GitHub] [flink] pnowojski commented on a change in pull request #17126: [FLINK-24090][docs] Added Troubleshooting section with ignoring in-fl…
pnowojski commented on a change in pull request #17126:
URL: https://github.com/apache/flink/pull/17126#discussion_r701144836
##########
File path: docs/content/docs/ops/state/unaligned_checkpoints.md
##########
@@ -118,3 +118,15 @@ operators. Flink implements the broadcast state by checkpointing only a single c
from subtask 0 of the stateful operator. Upon restore, we send that copy to all of the
operators. Therefore it might happen that an operator will get the state with changes applied for a
record that it will soon consume from its checkpointed channels.
+
+## Troubleshooting
+
+### Corrupted in-flight data
+{{< hint warning >}}
+Actions described below are a last resort due to they lead to data loss. Which means they should be applied only at extreme scenarios.
Review comment:
```suggestion
Actions described below are a last resort as they will lead to data loss.
```
##########
File path: docs/content/docs/ops/state/unaligned_checkpoints.md
##########
@@ -118,3 +118,15 @@ operators. Flink implements the broadcast state by checkpointing only a single c
from subtask 0 of the stateful operator. Upon restore, we send that copy to all of the
operators. Therefore it might happen that an operator will get the state with changes applied for a
record that it will soon consume from its checkpointed channels.
+
+## Troubleshooting
+
+### Corrupted in-flight data
+{{< hint warning >}}
+Actions described below are a last resort due to they lead to data loss. Which means they should be applied only at extreme scenarios.
+{{< /hint >}}
+In case of the in-flight data corrupted or by another reason when the job should be restored without in-flight data,
Review comment:
```suggestion
In case of the in-flight data corrupted or by another reason when the job should be restored without the in-flight data,
```
##########
File path: docs/content/docs/ops/state/unaligned_checkpoints.md
##########
@@ -118,3 +118,15 @@ operators. Flink implements the broadcast state by checkpointing only a single c
from subtask 0 of the stateful operator. Upon restore, we send that copy to all of the
operators. Therefore it might happen that an operator will get the state with changes applied for a
record that it will soon consume from its checkpointed channels.
+
+## Troubleshooting
+
+### Corrupted in-flight data
+{{< hint warning >}}
+Actions described below are a last resort due to they lead to data loss. Which means they should be applied only at extreme scenarios.
+{{< /hint >}}
+In case of the in-flight data corrupted or by another reason when the job should be restored without in-flight data,
+it is possible to use [recover-without-channel-state.checkpoint-id]({{< ref "docs/deployment/config" >}}#execution-checkpointing-recover-without-channel-state-checkpoint) property.
+This property requires the checkpoint id of the checkpoint for which in-flight data should be ignored.
+Extremely important to keep this property with default value in order to avoid accidental triggering of ignoring in-flight data.
Review comment:
```suggestion
Do not set this property, unless a corruption inside the persisted in-flight data has lead to an otherwise unrecoverable situation.
```
##########
File path: docs/content/docs/ops/state/unaligned_checkpoints.md
##########
@@ -118,3 +118,15 @@ operators. Flink implements the broadcast state by checkpointing only a single c
from subtask 0 of the stateful operator. Upon restore, we send that copy to all of the
operators. Therefore it might happen that an operator will get the state with changes applied for a
record that it will soon consume from its checkpointed channels.
+
+## Troubleshooting
+
+### Corrupted in-flight data
+{{< hint warning >}}
+Actions described below are a last resort due to they lead to data loss. Which means they should be applied only at extreme scenarios.
+{{< /hint >}}
+In case of the in-flight data corrupted or by another reason when the job should be restored without in-flight data,
+it is possible to use [recover-without-channel-state.checkpoint-id]({{< ref "docs/deployment/config" >}}#execution-checkpointing-recover-without-channel-state-checkpoint) property.
+This property requires the checkpoint id of the checkpoint for which in-flight data should be ignored.
Review comment:
```suggestion
This property requires to specify a checkpoint id for which in-flight data will be ignored.
```
--
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-unsubscribe@flink.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org