I'm not sure why recovery from a savepoint would be different than from a
checkpoint but if you look for a savepoint test case, PTAL at [1].
I rather think you found some edge case in your recovery setup. Changed
degree of parallelism certainly sounds like the most likely option. Or did
you upgrad
One more question: Are you changing the parallelism when resuming from
savepoint?
On Sun, May 8, 2022 at 4:05 PM Thomas Weise wrote:
>
> Hi Kevin,
>
> Unfortunately I did not find a way to test the savepoint scenario with
> the MiniCluster. Savepoints are not supported in the embedded mode.
> The
Hi Kevin,
Unfortunately I did not find a way to test the savepoint scenario with
the MiniCluster. Savepoints are not supported in the embedded mode.
There is a way to hack around that, but then the state of the
enumerator won't be handled.
As for your original issue, is it reproducible consistent
Hi Kevin,
I'm hoping that @Thomas Weise could help with the issue
regarding the recovery from the savepoint.
Best regards,
Martijn
On Wed, 4 May 2022 at 17:05, Kevin Lam wrote:
> Following up on this, is there a good way to debug restoring from
> savepoints locally? We currently have a set-u
Following up on this, is there a good way to debug restoring from
savepoints locally? We currently have a set-up where we use IntelliJ to run
and test our pipelines locally, but would like an API to be able to specify
the savepoint to restore from, without needing to spin up a full cluster.
In int
Hi,
We're encountering an error using a HybridSource that is composed of a
FileSource + KafkaSource, only when recovering from a savepoint [0]. This
HybridSource is used to read from a Kafka topic's archives hosted on GCS
via a bounded FileSource, and then automatically switch over to the data
str
