apache/seatunnel · warning

MySQL-CDC diagnostic: required binlog sequence {}{} is newer

Error message

MySQL-CDC diagnostic: required binlog sequence {}{} is newer than the latest available {}{}; possible connection to an out-of-date replica, proxy routing to different instance, or RESET MASTER

What it means

Diagnostic WARN emitted when the required binlog sequence number is HIGHER than the newest file present on the server — the connector holds a position ahead of what this MySQL instance knows, typically meaning it is now talking to a different/out-of-date server rather than the original one.

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

            min = Math.min(min, parsed.number);
            max = Math.max(max, parsed.number);
        }
        if (!any) {
            LOG.warn(
                    "MySQL-CDC diagnostic: cannot compare binlog sequence because available binlog filenames don't match required prefix '{}'",
                    required.prefix);
            return;
        }

        if (required.number < min) {
            LOG.warn(
                    "MySQL-CDC diagnostic: required binlog sequence {}{} is older than the earliest available {}{}; likely purged/expired binlog on server",
                    required.prefix,
                    required.number,
                    required.prefix,
                    min);
        } else if (required.number > max) {
            LOG.warn(
                    "MySQL-CDC diagnostic: required binlog sequence {}{} is newer than the latest available {}{}; possible connection to an out-of-date replica, proxy routing to different instance, or RESET MASTER",
                    required.prefix,
                    required.number,
                    required.prefix,
                    max);
        } else {
            LOG.warn(
                    "MySQL-CDC diagnostic: required binlog sequence {}{} is within available range {}{}..{}{} but missing; possible manual binlog deletion, binlog.index corruption, or connecting to a different MySQL instance intermittently",
                    required.prefix,
                    required.number,
                    required.prefix,
                    min,
                    required.prefix,
                    max);
        }
    }

    private static String summarizeBinlogFiles(List<String> files) {

View on GitHub (pinned to cf67b549a7)

Solutions

  1. Confirm the connector's endpoint resolves to the ORIGINAL primary (check @@server_uuid / @@hostname against the one in the saved offset).
  2. If connecting via proxy/LB, pin CDC traffic to the primary node.
  3. If the server was rebuilt with RESET MASTER, restart the CDC job from a fresh snapshot — old offsets are meaningless.
  4. On a legit failover, re-point the job using GTID-based offsets or re-snapshot from the new primary.

Example fix

// before: LB round-robins replicas
cdc.url = jdbc:mysql://mysql-lb.internal:3306
// after: pin to primary
cdc.url = jdbc:mysql://mysql-primary.internal:3306
Defensive patterns

Strategy: validation

Validate before calling

SELECT @@hostname, @@server_uuid; SHOW BINARY LOGS; -- must match the server that produced the job's saved offsets

Prevention

When it happens

Trigger: logBinlogRangeAnalysis (via logBinlogNotAvailableDiagnostics) finds required.number > max of available sequences — e.g. required mysql-bin.000200 while the server's latest is mysql-bin.000150.

Common situations: DNS/LB switching the client to a lagging replica or a rebuilt instance; failover to a server whose binlogs were RESET MASTER / re-initialized; restoring the database from an old snapshot while the job keeps its old offsets; containerized MySQL recreated from an older image/volume.

Related errors


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