-
Bug
-
Resolution: Done
-
Major
-
3.1.3.Final, 3.2.0.CR1
-
None
This was originally reported for Oracle, where using a non-recovery snapshot mode where the previous snapshot did not end successfully resulted in a new snapshot being retaken on subsequent starts but using the previous run's offset snapshot details:
2025-07-08 05:42:29,065 INFO Oracle|prd|streaming Offsets: OracleOffsetContext [scn=4946273960199, commit_scn=[], lcr_position=null] [io.debezium.connector.oracle.logminer.LogMinerStreamingChangeEventSource] 2025-07-08 05:42:29,065 INFO Oracle|prd|streaming Finished streaming [io.debezium.pipeline.ChangeEventSourceCoordinator] 2025-07-08 05:42:29,065 INFO Oracle|prd|streaming Connected metrics set to 'false' [io.debezium.pipeline.ChangeEventSourceCoordinator] 2025-07-08 09:44:58,565 INFO Oracle|prd|snapshot Metrics registered [io.debezium.pipeline.ChangeEventSourceCoordinator] 2025-07-08 09:44:58,565 INFO Oracle|prd|snapshot Context created [io.debezium.pipeline.ChangeEventSourceCoordinator] 2025-07-08 09:44:58,565 INFO Oracle|prd|snapshot According to the connector configuration both schema and data will be snapshot. [io.debezium.relational.RelationalSnapshotChangeEventSource] 2025-07-08 09:44:58,566 INFO Oracle|prd|snapshot Snapshot step 1 - Preparing [io.debezium.relational.RelationalSnapshotChangeEventSource] 2025-07-08 09:44:58,566 INFO Oracle|prd|snapshot Previous snapshot was cancelled before completion; a new snapshot will be taken. [io.debezium.relational.RelationalSnapshotChangeEventSource] 2025-07-08 09:44:58,566 INFO Oracle|prd|snapshot Snapshot step 2 - Determining captured tables [io.debezium.relational.RelationalSnapshotChangeEventSource] ... 2025-07-08 09:46:07,566 INFO Oracle|prd|snapshot For table 'WILENQ.ENQUESTACIS.CI911DISTRICT' using select statement: 'SELECT "DISTRICT911", "CREATEDATE", "CREATEOPERATOR", "DESCRIPTION", "UPDATEDATE", "UPDATEOPERATOR" FROM "ENQUESTACIS"."CI911DISTRICT" AS OF SCN 4946273960199' [io.debezium.relational.RelationalSnapshotChangeEventSource]
We can see that on the subsequent snapshot run, the same SCN was used as what was used previously on the earlier run, which is unexpected.
The issue is traced to the fact that inside OracleSnapshotChangeEventSource, the method determineSnapshotOffset will always return the prior offset details when the snapshot mode is not ALWAYS and there are existing offsets. According to the comments, this was done to address the needs for schema_only_recovery.
However inside the Snapshotter API, we already have shouldStreamEventsStartingFromSnapshot which serves preciously this purpose and for our recovery/schema_only_recovery snapshotters, this method should return false, which they currently do not.
So I propose we adjust the snapshotters for recovery/schema_only_recovery so that we do not change the offsets in those use cases, and we rework the snapshot source to use the logic as
if (previousOffset != null && !snapshotterService.getSnapshotter().shouldStreamEventsStartingFromSnapshot()) {
ctx.offset = previousOffset;
tryStartingSnapshot(ctx);
return;
}
This preserves the original intent without tainting the expected behavior for non-recovery snapshot modes, so that the offset details are reset in those cases.
- links to
-
RHEA-2025:154266
Red Hat build of Debezium 3.2.4 release