<p>Raised when a single transaction updates more databases than MySQL can list in replication metadata (default cap: 16).</p>
<p>MySQL Error 1754 ER_MTS_UPDATED_DBS_GREATER_MAX appears when one transaction modifies over 16 databases, exceeding replication metadata limits. Reduce the number of affected databases or split the work into smaller commits to resolve the issue.</p>
The number of modified databases exceeds the maximum %d;
MySQL adds the names of all databases changed by a transaction to the binary log header so multithreaded replicas can parallelize safely. The list has a hard limit (16 in most builds). Exceeding that cap triggers error 1754 and strips the names from the event metadata.
The message is generated on the primary server during binary logging or on replicas when relay logs are processed. It typically follows cross-database statements, stored procedures, or automation jobs that touch many schemas in a single commit.
While replication continues, the missing database list forces replicas to serialize events, reducing parallel apply performance. Ignoring the error can slow catch-up, increase lag, and risk data drift in complex topologies.
Administrative scripts that loop through every customer schema and run DDL or DML in one transaction easily breach the 16-database ceiling.
Generic procedures that update tables across many tenant databases before committing also trigger the limit.
Triggers that cascade writes into auxiliary schemas silently increase the database count and hit the cap.
A single INSERT ... SELECT that joins tables from many databases can exceed the metadata limit.
Occurs when MySQL cannot schedule events in parallel due to dependency checks.
Raised when MySQL cannot write an event to the binary log.
Generic replication halt on the replica side due to unrecoverable issues.
No. Replication continues, but parallelism is limited for that event.
The cap is a compile-time constant. You would need to recompile MySQL, which is rarely practical.
No. That variable controls row images, not the database list size.
Galaxy highlights cross-database writes and suggests splitting scripts, preventing excessive database counts before execution.