MySQL-CDC diagnostic: requested starting offset sourceInfo={

Error message

MySQL-CDC diagnostic: requested starting offset sourceInfo={}

What it means

A diagnostic warning (not itself a failure) logged by logBinlogNotAvailableDiagnostics() when the connector determines the required binlog file is missing from the server. It prints the requested starting offset's SourceInfo so the operator can see exactly which file/position/GTID the connector tried to resume from before failing.

Source

Thrown at seatunnel-connectors-v2/connector-cdc/connector-cdc-mysql/src/main/java/org/apache/seatunnel/connectors/seatunnel/cdc/mysql/source/reader/fetch/MySqlSourceFetchTaskContext.java:422

                    gtidSetToReplicate,
                    nonPurgedGtidSetToReplicate);
            if (!gtidSetToReplicate.equals(nonPurgedGtidSetToReplicate)) {
                LOG.warn("Some of the GTIDs needed to replicate have been already purged");
                logGtidNotAvailableDiagnostics(offset);
                return false;
            }
            return true;
        }
        LOG.info("Connector last known GTIDs are {}, but MySQL has {}", gtidSet, availableGtidSet);
        logGtidNotAvailableDiagnostics(offset);
        return false;
    }

    private void logBinlogNotAvailableDiagnostics(
            String requiredBinlogFilename,
            List<String> availableBinlogFiles,
            MySqlOffsetContext offset) {
        LOG.warn(
                "MySQL-CDC diagnostic: requested starting offset sourceInfo={}",
                offset.getSourceInfo());
        LOG.warn(
                "MySQL-CDC diagnostic: debezium connection target host={}, port={}",
                getDbzConnectorConfig().hostname(),
                getDbzConnectorConfig().port());

        logMySqlServerIdentity();
        logMySqlBinlogRetentionVariables();
        logMySqlMasterStatus();
        logMySqlReplicationStatus();
        logBinlogRangeAnalysis(requiredBinlogFilename, availableBinlogFiles);
    }

    private void logGtidNotAvailableDiagnostics(MySqlOffsetContext offset) {
        LOG.warn(
                "MySQL-CDC diagnostic: GTID set is not available on server for restored offset. restored_gtid_set={}, sourceInfo={}",
                offset.gtidSet(),

View on GitHub (pinned to cf67b549a7)

Solutions

Read the logged sourceInfo to confirm the expected binlog file/position and compare with SHOW BINARY LOGS on the server.
If the offset is stale (file purged), restart the job with a new snapshot or reset the state.
If the offset points to the wrong server, fix the connection config (host/port) or restore the checkpoint to the correct cluster.
Increase binlog retention to prevent recurrence.

Defensive patterns

Strategy: validation

Validate before calling

-- Cross-check diagnostics against the server:
SHOW BINARY LOGS; -- does the logged file exist here?

Prevention

Read the sourceInfo diagnostic to identify the exact missing file
Compare logged binlog filename with server's SHOW BINARY LOGS
Address retention/purge issues flagged by the diagnostic chain

When it happens

Trigger: checkBinlogFilename() detects the required binlog filename is not among connection.availableBinlogFiles() and calls logBinlogNotAvailableDiagnostics(requiredBinlogFilename, logNames, offset), which logs offset.getSourceInfo().

Common situations: Investigating 'binlog file not available' errors after binlog purging, server replacement, or restoring checkpoints against a different MySQL instance.

Understand the failure class

Background: 'Could not be found', 'does not exist', 'not found in database': the resource-not-found family when an ID, slug, key, or URI lookup comes back empty — this error's family across 20 libraries.

Related errors

AI-assisted analysis of apache/seatunnel@cf67b549a7 (2026-09-10). Data as JSON: /api/errors/b3daf913f713527f. Report an issue: GitHub.