y
> is all there is in the logs, Task Manager is spitting some warnings about
> metric name collision, but that should be irrelevant.
>
>
>
> Am I making a false alarm here? Would you need to inspect the _metadata
> file, as well? Or can I do a better job of analyzing it?
>
y
> is all there is in the logs, Task Manager is spitting some warnings about
> metric name collision, but that should be irrelevant.
>
>
>
> Am I making a false alarm here? Would you need to inspect the _metadata
> file, as well? Or can I do a better job of analyzing it?
>
small amount of data?
Nikola.
From: Nikola Milutinovic
Date: Tuesday, June 10, 2025 at 4:01 PM
To:
Cc: Flink Users
Subject: Re: Savepoints and Checkpoints missing files
Hi Gabor.
Thanks for chiming in. I think it is failing but I could be mistaken. There are
no errors in the log, everything looks
ile,
as well? Or can I do a better job of analyzing it?
Nikola.
From: Gabor Somogyi
Date: Tuesday, June 10, 2025 at 10:52 AM
To: Nikola Milutinovic
Cc: Flink Users
Subject: Re: Savepoints and Checkpoints missing files
Hi Nikola,
Fails on how? Some stack trace or error would be beneficial.
G
Hi Nikola,
Fails on how? Some stack trace or error would be beneficial.
G
On Tue, Jun 10, 2025 at 10:48 AM Nikola Milutinovic
wrote:
> Hello.
>
>
>
> We are running Flink 1.20.1 on Kubernetes (AKS). We have observed a
> consistent error situation: both checkpoints and savepoints only save
> “
Hi
First, Checkpoint for Flink is a distributed snapshot of the job.
As Yun said, Kafka consumer will snapshot the topic name and partition to
the checkpoint, then when restoring from the last checkpoint you do not
know about the newly topic name.
Inner the checkpoint, you can think checkpoint as
Hi Min
Since kafka consumer would store KafkaTopicPartition [1] within checkpoint, you
cannot load previous state if you changed the kafka topic name.
If you assign operator-id to previous stateful operator and splits into two
operator but still maintain one new operator as previous operator-id
