apache/seatunnel · info

MySQL-CDC diagnostic: debezium connection target host={}, po

Error message

MySQL-CDC diagnostic: debezium connection target host={}, port={}

What it means

A companion diagnostic warning in logBinlogNotAvailableDiagnostics() that prints the Debezium connection target hostname and port when the required binlog file was not found on the server. It helps confirm the connector is actually talking to the MySQL instance the operator thinks it is.

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

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

View on GitHub (pinned to cf67b549a7)

Solutions

1. Compare the logged host/port with the intended MySQL server in the job config.
2. Fix the hostname/port in the source config if a replica or wrong instance was targeted.
3. Ensure any load balancer/DNS entry resolves to the primary that holds the binlogs.
4. Then address the underlying missing-binlog problem (retention or re-snapshot).

Example fix

// before
hostname = "mysql-replica.internal"
// after
hostname = "mysql-primary.internal"

-- Confirm which server the connector hit:
SELECT @@hostname, @@server_id, @@server_uuid;
-- Compare with the host/port in the diagnostic log line.

When it happens

Trigger: Same path as 3158: checkBinlogFilename() finds the required binlog unavailable and calls logBinlogNotAvailableDiagnostics(), which logs getDbzConnectorConfig().hostname() and .port().

Common situations: Discovering that the job is pointed at a replica or stale host; misconfigured host/port; DNS round-robin landing on a different server than the checkpoint came from.

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

• Connector used GTIDs previously, but MySQL does not know of
• MySQL-CDC diagnostic: requested starting offset sourceInfo={
• MySQL-CDC diagnostic: variable {}={}
• MySQL-CDC diagnostic: SHOW MASTER STATUS returned empty resu
• MySQL-CDC diagnostic: master status file={}, position={}, ex

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