MySQL-CDC diagnostic: master status file={}, position={}, ex

Error message

MySQL-CDC diagnostic: master status file={}, position={}, executed_gtid_set={}

What it means

Diagnostic WARN from logMySqlMasterStatus logging the server's current binlog position: current file, position, and Executed_Gtid_Set from SHOW MASTER STATUS. Emitted when binlog/GTID availability checks fail, it lets developers compare the server's current binlog with the binlog filename required by the restored offset.

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

                    variableName,
                    e.getMessage());
        }
    }

    private void logMySqlMasterStatus() {
        try {
            connection.query(
                    "SHOW MASTER STATUS",
                    rs -> {
                        if (!rs.next()) {
                            LOG.warn(
                                    "MySQL-CDC diagnostic: SHOW MASTER STATUS returned empty result");
                            return;
                        }
                        String file = safeGetString(rs, "File");
                        String position = safeGetString(rs, "Position");
                        String gtidSet = safeGetString(rs, "Executed_Gtid_Set");
                        LOG.warn(
                                "MySQL-CDC diagnostic: master status file={}, position={}, executed_gtid_set={}",
                                file,
                                position,
                                gtidSet);
                    });
        } catch (SQLException e) {
            LOG.warn(
                    "MySQL-CDC diagnostic: failed to query SHOW MASTER STATUS: {}", e.getMessage());
        }
    }

    private void logMySqlReplicationStatus() {
        if (logReplicationStatus("SHOW REPLICA STATUS", "replica")) {
            return;
        }
        logReplicationStatus("SHOW SLAVE STATUS", "slave");
    }

View on GitHub (pinned to cf67b549a7)

Solutions

Increase binlog retention (binlog_expire_logs_seconds / expire_logs_days) and re-snapshot the job
Verify the required binlog file is within the server's retained binlog range (SHOW BINARY LOGS)
Use the Executed_Gtid_Set to confirm whether GTID-based resume is feasible

Example fix

// before
SET PERSIST binlog_expire_logs_seconds = 3600; // 1h
// after
SET PERSIST binlog_expire_logs_seconds = 604800; // 7d

Defensive patterns

Strategy: validation

Validate before calling

SHOW MASTER STATUS; -- capture File/Position/Executed_Gtid_Set
SHOW BINARY LOGS; -- confirm checkpoint binlog file still in range
-- required file must be >= oldest retained binlog

Prevention

Compare checkpoint binlog filename against SHOW BINARY LOGS before restarting
Increase binlog retention for long job stoppages
Prefer GTID-based resume so purged binlog files matter less
Re-snapshot the job when required binlogs are known to be purged

When it happens

Trigger: SHOW MASTER STATUS returns a row during a diagnostic run triggered by checkGtidSet or the binlog-availability check finding the restored offset unavailable.

Common situations: Comparing logged 'file' with requiredBinlogFilename from logBinlogRangeAnalysis: if the required file is older than available binlogs, it was purged; if gtid set is empty, GTID mode is off.

Understand the failure class

Background: "invalid response format", "malformed payload", "missing data field": when an API returns 200 but the response shape is wrong — this error's family across 23 libraries.

Related errors

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