apache/seatunnel · error

Error during binlog processing. Last offset stored =

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.

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

• A deserialization failure event arrived
• Cannot read the binlog filename and position via
• Cannot read the binlog filename and position via
• Cannot read the binlog filename and position via
• Encountered change event

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

Appendix: 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)