apache/seatunnel · error

Error during binlog processing. Last offset stored = {}, bin

Error message

Error during binlog processing. Last offset stored = {}, binlog reader near position = {}

What it means

A generic error report emitted when binlog processing throws an exception. The connector builds a message containing the last stored offset and the approximate binlog file/position the reader had reached, then logs it at a level chosen by the incident severity (WARN/DEBUG/ERROR as part of the failure-handling policy) and may propagate the error to the error handler.

Source

Thrown at seatunnel-connectors-v2/connector-cdc/connector-cdc-mysql/src/main/java/io/debezium/connector/mysql/MySqlStreamingChangeEventSource.java:1369

    private void logStreamingSourceState() {
        logStreamingSourceState(Level.ERROR);
    }

    protected void logEvent(MySqlOffsetContext offsetContext, Event event) {
        LOGGER.trace("Received event: {}", event);
    }

    private void logStreamingSourceState(Level severity) {
        final Object position =
                client == null
                        ? "N/A"
                        : client.getBinlogFilename() + "/" + client.getBinlogPosition();
        final String message =
                "Error during binlog processing. Last offset stored = {}, binlog reader near position = {}";
        switch (severity) {
            case WARN:
                LOGGER.warn(message, lastOffset, position);
                break;
            case DEBUG:
                LOGGER.debug(message, lastOffset, position);
                break;
            default:
                LOGGER.error(message, lastOffset, position);
        }
    }

    /**
     * Apply the include/exclude GTID source filters to the current {@link #source() GTID set} and
     * merge them onto the currently available GTID set from a MySQL server.
     *
     * <p>The merging behavior of this method might seem a bit strange at first. It's required in
     * order for Debezium to consume a MySQL binlog that has multi-source replication enabled, if a
     * failover has to occur. In such a case, the server that Debezium is failed over to might have
     * a different set of sources, but still include the sources required for Debezium to continue
     * to function. MySQL does not allow downstream replicas to connect if the GTID set does not

View on GitHub (pinned to cf67b549a7)

Solutions

1. Read the underlying exception logged alongside this message to find the root cause (I/O vs deserialization)
2. Check binlog retention: if the last offset's binlog file was purged (SHOW BINARY LOGS / binlog_expire_logs_seconds), take a new snapshot
3. For transient network/server issues, let the connector's restart backoff retry; ensure MySQL connectivity and keepalives are stable
4. Increase binlog retention (binlog_expire_logs_seconds) so offsets remain valid across connector downtime

Example fix

// before
SET GLOBAL binlog_expire_logs_seconds = 86400;
// after (retain >= expected downtime window)
SET GLOBAL binlog_expire_logs_seconds = 604800;

// Preflight source stability checks:
// SHOW STATUS LIKE 'Uptime'; -- server not flapping
// SHOW BINARY LOGS; -- last offset's file still present (not purged)
// SELECT 1; over the same network path used by the connector

try {
    streamBinlogFrom(lastOffset);
} catch (IOException | SQLException e) {
    logLastOffsetAndPosition(lastOffset);
    if (isTransient(e)) {
        retryWithBackoff(lastOffset);
    } else if (isBinlogPurged(e)) {
        triggerReSnapshot();
    } else {
        failConnector(e);
    }
}

When it happens

Trigger: The public handleServerIncident-style path in MySqlStreamingChangeEventSource catches any exception thrown while reading/decoding binlog events — e.g. deserialization failures, I/O errors on the binlog connection, or downstream handler exceptions — and calls this logging/reporting routine.

Common situations: Network interruption between connector and MySQL during streaming; MySQL server restart closing the binlog connection; corrupt or unsupported binlog events; offsets pointing at a purged or rotated binlog file.

Understand the failure class

Background: Database query failed: Internal Server Error 500s wrapping SQL, Prisma, and connection failures — what to check first — this error's family across 16 libraries.

Related errors

• Unexpected error while connecting to MySQL and looking at gt
• Unexpected error while connecting to MySQL and looking for b
• Unexpected error while connecting to MySQL and looking at BI
• Unexpected error while connecting to MySQL and looking at BI
• Cannot read the binlog filename and position via '<showMaste

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