apache/seatunnel · warning

MySQL-CDC diagnostic: GTID set is not available on server fo

Error message

MySQL-CDC diagnostic: GTID set is not available on server for restored offset. restored_gtid_set={}, sourceInfo={}

What it means

This is a diagnostic WARN log, not a thrown exception. It is emitted by logGtidNotAvailableDiagnostics (called from checkGtidSet) when the GTID set recorded in the restored checkpoint offset cannot be reconciled with GTID information available on the MySQL server, i.e. the server has no GTID data (or GTID mode is off) covering the restored gtidSet. SeaTunnel logs this plus follow-up diagnostics to help explain why a restarted CDC job cannot resume from its saved GTID position.

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

            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(),
                offset.getSourceInfo());
        LOG.warn(
                "MySQL-CDC diagnostic: debezium connection target host={}, port={}",
                getDbzConnectorConfig().hostname(),
                getDbzConnectorConfig().port());
        logMySqlServerIdentity();
        logMySqlBinlogRetentionVariables();
        logMySqlMasterStatus();
        logMySqlReplicationStatus();
    }

    private void logMySqlServerIdentity() {
        final String sql =
                "SELECT @@hostname AS hostname, @@port AS port, @@server_id AS server_id, "
                        + "@@server_uuid AS server_uuid, @@read_only AS read_only, "
                        + "@@super_read_only AS super_read_only, @@version AS version, "

View on GitHub (pinned to cf67b549a7)

Solutions

  1. Enable GTID on the MySQL server (gtid_mode=ON, enforce_gtid_consistency=ON) and restart mysqld if required
  2. Verify the job connects to the same server that produced the offset (compare logged hostname/port/server_uuid)
  3. Check the logged gtid_mode/server identity output; if GTID cannot be enabled, re-run the job from a snapshot (drop the checkpoint and start fresh)
  4. If reading from a replica, ensure it replicates GTIDs (log_slave_updates=ON with GTID enabled)

Example fix

// before (my.cnf)
gtid_mode=OFF
// after (my.cnf, then restart MySQL)
gtid_mode=ON
enforce_gtid_consistency=ON
Defensive patterns

Strategy: validation

Validate before calling

// Run before starting/restoring the CDC job
SELECT @@global.gtid_mode; -- must be ON
SELECT @@global.enforce_gtid_consistency; -- must be ON
SELECT @@global.server_uuid; -- compare with checkpoint sourceInfo server id

Prevention

When it happens

Trigger: A Zeta job is restored from checkpoint/snapshot whose offset contains a GTID set, and checkGtidSet determines the target server does not provide a matching/available GTID set (e.g. gtid_mode=OFF, server without binlogs, or restored offset pointing to a different replica).

Common situations: Restarting a job against a different MySQL instance than originally read from; MySQL upgraded/migrated with GTID disabled; replicas in a topology where GTIDs are not preserved; restores where sourceInfo shows a hostname differing from the configured one.

Understand the failure class

Background: "Invalid state transition" errors: "status must be X, actually Y", "already rejected/charging/uninstalled", "cannot ... while running" — what they mean when a library rejects your call — this error's family across 31 libraries.

Related errors


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