apache/seatunnel · error

Connector used GTIDs previously, but MySQL does not know of

Error message

Connector used GTIDs previously, but MySQL does not know of any GTIDs or they are not enabled

What it means

checkGtidSet() (called from isBinlogAvailable) validates GTID-based offsets. If the saved offset contains GTIDs but connection.knownGtidSet() returns null/empty — meaning the connected MySQL server has no known GTIDs or GTID mode is disabled — replication from that GTID position is impossible, so the warning is logged, diagnostics are emitted, and the fetch task cannot start.

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:370

                    summarizeBinlogFiles(logNames));
            logBinlogNotAvailableDiagnostics(binlogFilename, logNames, offset);
        } else {
            LOG.info("MySQL has the binlog file '{}' required by the connector", binlogFilename);
        }
        return found;
    }

    private boolean checkGtidSet(MySqlOffsetContext offset) {
        String gtidStr = offset.gtidSet();

        if (gtidStr.trim().isEmpty()) {
            return true; // start at beginning ...
        }

        String availableGtidStr = connection.knownGtidSet();
        if (availableGtidStr == null || availableGtidStr.trim().isEmpty()) {
            // Last offsets had GTIDs but the server does not use them ...
            LOG.warn(
                    "Connector used GTIDs previously, but MySQL does not know of any GTIDs or they are not enabled");
            logGtidNotAvailableDiagnostics(offset);
            return false;
        }

        // Get the GTID set that is available in the server ...
        GtidSet availableGtidSet = new GtidSet(availableGtidStr);

        // GTIDs are enabled
        LOG.info("Merging server GTID set {} with restored GTID set {}", availableGtidSet, gtidStr);

        // Based on the current server's GTID, the GTID in MySqlOffsetContext is adjusted to ensure
        // the completeness of
        // the GTID. This is done to address the issue of being unable to recover from a checkpoint
        // in certain startup
        // modes.
        GtidSet gtidSet = GtidUtils.fixRestoredGtidSet(availableGtidSet, new GtidSet(gtidStr));
        LOG.info("Merged GTID set is {}", gtidSet);

View on GitHub (pinned to cf67b549a7)

Solutions

1. Enable GTID mode on the server: SET GLOBAL gtid_mode=ON_PERMISSIVE; SET GLOBAL enforce_gtid_consistency=ON; SET GLOBAL gtid_mode=ON;
2. Re-enable gtid_mode permanently in my.cnf (gtid_mode=ON, enforce_gtid_consistency=ON) and restart/resume the job.
3. If GTIDs cannot be enabled, restart the CDC job with a new snapshot instead of the GTID offset.
4. Verify you are restoring against the same server/cluster that produced the offset (execute SELECT @@gtid_mode, @@server_uuid).

Example fix

-- before (my.cnf)
# gtid_mode = ON
-- after
gtid_mode = ON
enforce_gtid_consistency = ON

-- Before restoring a GTID-based checkpoint:
SELECT @@global.gtid_mode, @@global.enforce_gtid_consistency;
-- Must be ON and the server must have executed GTID transactions.

When it happens

Trigger: The connector's last saved offset has GTID fields, but the target server returns an empty knownGtidSet(): gtid_mode is OFF on the (possibly different) server, or the server never executed any GTID transactions (e.g. a fresh replica).

Common situations: Job originally ran against a GTID-enabled MySQL and is being restored against a server with gtid_mode=OFF; failover to a replica without GTIDs; someone disabled GTIDs on the server between checkpoints.

Related errors

• Unexpected error while connecting to MySQL and looking at gt
• Some of the GTIDs needed to replicate have been already purg
• MySQL-CDC diagnostic: debezium connection target host={}, po
• MySQL-CDC diagnostic: master status file={}, position={}, ex
• System or JVM property '<property>' is already defined, but

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