Nayan Gondaliya
04/22/2026, 8:50 AM-- java --
'debezium.signal.enabled.channels' = 'source',
'debezium.signal.data.collection' = 'public.debezium_signal'
and created the signal table in Postgres:
--- signal table ---
CREATE TABLE public.debezium_signal (
id VARCHAR(42) PRIMARY KEY,
type VARCHAR(32) NOT NULL,
data VARCHAR(2048)
);
Then I insert signals like:
--- trigger adhoc snapshot ---
INSERT INTO public.debezium_signal (id, type, data)
VALUES (
'1',
'execute-snapshot',
'{"data-collections": ["public.my_table"], "type": "incremental"}'
);
My understanding is that Flink CDC embeds Debezium and passes debezium.* properties through, but Flink CDC 3.x also has its own incremental snapshot framework (split enumerator / chunk snapshotting / checkpoint-aware recovery).
So I’m unsure whether Flink CDC 3.4.0 actually supports Debezium signaling semantics for triggering snapshots, or whether these configs are simply ignored / only partially honored.
Has anyone successfully used Debezium signaling with Flink CDC PostgreSQL source in 3.4.x?
Specifically:
1. Does Flink CDC read/process the signal table?
2. Can execute-snapshot trigger Flink CDC incremental snapshots?
3. Are there recommended alternatives for ad-hoc table re-snapshotting without restarting the job?
Any guidance would be greatly appreciated.sap1ens
04/22/2026, 4:11 PMwhether Flink CDC 3.4.0 actually supports Debezium signaling semanticsIt doesn’t. Flink CDC has a completely separate implementation for snapshotting. It only uses Debezium for the live CDC phase.
sap1ens
04/22/2026, 4:12 PMAre there recommended alternatives for ad-hoc table re-snapshotting without restarting the job?Not really, the decision to snapshot is fully controlled by the source splits: once the snapshot is done, the information is stored in Flink state.