apache/seatunnel · warning

Unable to set innodb_lock_wait_timeout

Error message

Unable to set innodb_lock_wait_timeout

What it means

MySqlSnapshotChangeEventSource attempts to set the MySQL session variable innodb_lock_wait_timeout to the configured snapshot lock timeout before taking global read locks for the snapshot. If the SET SESSION statement throws a SQLException, the source logs a warning and continues; the snapshot lock acquisition itself is not aborted, but the timeout guard is not applied.

Source

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

        // With REPEATABLE READ, all SELECT queries within the scope of a transaction (which we
        // don't yet have) will read
        // from the same MVCC snapshot. Thus each plain (non-locking) SELECT statements within the
        // same transaction are
        // consistent also with respect to each other.
        //
        // See: https://dev.mysql.com/doc/refman/5.7/en/set-transaction.html
        // See: https://dev.mysql.com/doc/refman/5.7/en/innodb-transaction-isolation-levels.html
        // See: https://dev.mysql.com/doc/refman/5.7/en/innodb-consistent-read.html
        connection.connection().setTransactionIsolation(Connection.TRANSACTION_REPEATABLE_READ);
        connection.executeWithoutCommitting(
                "SET SESSION lock_wait_timeout="
                        + connectorConfig.snapshotLockTimeout().getSeconds());
        try {
            connection.executeWithoutCommitting(
                    "SET SESSION innodb_lock_wait_timeout="
                            + connectorConfig.snapshotLockTimeout().getSeconds());
        } catch (SQLException e) {
            LOGGER.warn("Unable to set innodb_lock_wait_timeout", e);
        }

        // ------------------------------------
        // LOCK TABLES
        // ------------------------------------
        // Obtain read lock on all tables. This statement closes all open tables and locks all
        // tables
        // for all databases with a global read lock, and it prevents ALL updates while we have this
        // lock.
        // It also ensures that everything we do while we have this lock will be consistent.
        if (connectorConfig.getSnapshotLockingMode().usesLocking()
                && connectorConfig.useGlobalLock()) {
            try {
                globalLock();
                metrics.globalLockAcquired();
            } catch (SQLException e) {
                LOGGER.info(
                        "Unable to flush and acquire global read lock, will use table read locks after reading table names");

View on GitHub (pinned to cf67b549a7)

Solutions

1. Verify snapshot.lock.timeout is within the server's allowed innodb_lock_wait_timeout range (1-1073741824) and adjust it
2. Grant the CDC user privileges to set session variables, or use an account that can on your managed MySQL
3. Check the SQLException in the log for the real cause (privilege vs connection) and fix connectivity/permissions accordingly
4. If timeouts persist, lower the lock timeout or run the snapshot during low-traffic windows

Example fix

// before
connectorConfig.snapshotLockTimeout(Duration.ofSeconds(0))
// after (a valid, positive seconds value within server range)
connectorConfig.snapshotLockTimeout(Duration.ofSeconds(30))

// Before starting the CDC job, verify the account can set the variable:
// SHOW VARIABLES LIKE 'innodb_lock_wait_timeout';
// SET SESSION innodb_lock_wait_timeout = <snapshotLockTimeoutSeconds>;
// SELECT @@innodb_lock_wait_timeout; -- must equal requested value

When it happens

Trigger: Executing 'SET SESSION innodb_lock_wait_timeout=<seconds>' during lockTablesForSchemaSnapshot fails with a SQLException — e.g. the connected account lacks privileges for the variable value, the server rejects the value (out of range / innodb disabled), or the connection is broken.

Common situations: MySQL users without SUPER or variable-set privileges on managed services (RDS, Aurora, Cloud SQL) where session variable ranges are restricted; snapshot.lock.timeout configured to a value outside server bounds; stale connections to a restarted MySQL.

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.

• Timeouts: ETIMEDOUT, deadlines, and hung requests — what actually expires when a request times out.

Related errors

• Snapshotting of table ${table.id()} failed
• Unable to set innodb_lock_wait_timeout
• Error reading MySQL variables:
• Unexpected error while connecting to MySQL and looking at GT
• Unexpected error while connecting to MySQL and looking at pr

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