<p>The error signals that the configured binlog_stmt_cache_size exceeds max_binlog_stmt_cache_size, so MySQL automatically lowers it.</p>
<p>MySQL Error 1745: ER_BINLOG_STMT_CACHE_SIZE_GREATER_THAN_MAX occurs when binlog_stmt_cache_size is set higher than max_binlog_stmt_cache_size. MySQL responds by capping the value, but you should explicitly lower binlog_stmt_cache_size to at or below max_binlog_stmt_cache_size to resolve the warning.</p>
Option binlog_stmt_cache_size (%lu) is greater than
MySQL raises error code 1745 when the session or global variable binlog_stmt_cache_size is configured to a value larger than max_binlog_stmt_cache_size. The server overrides your setting and silently reduces binlog_stmt_cache_size to the maximum allowed size.
This message appears during server startup, SET GLOBAL execution, or replication when the values are evaluated. It is important to correct the configuration because an unintended cache size can impact binary logging performance and memory use.
The error surfaces in error logs at startup, in client sessions executing SET commands, or on replicas inheriting conflicting settings from a primary. It affects MySQL 5.7 and later, as well as Percona and MariaDB derivatives that support statement-based binary log caching controls.
Leaving the mismatch unaddressed hides configuration drift, complicates troubleshooting, and might mask typos in configuration files. Aligning the parameters ensures predictable cache behavior and consistent replication performance across all nodes.
An administrator sets binlog_stmt_cache_size=64M but forgets to update max_binlog_stmt_cache_size, leaving it at 32M.
A DBA issues SET GLOBAL binlog_stmt_cache_size=25600000 without raising max_binlog_stmt_cache_size first.
After upgrading MySQL, new default for max_binlog_stmt_cache_size is lower than the value carried over in my.cnf.
Replication channel forces a replica to use its own smaller max_binlog_stmt_cache_size, triggering the warning during relay log processing.
Same mismatch but for binlog_cache_size against max_binlog_cache_size.
Occurs when trying to change binary log variables while holding a GTID transaction.
Raised when binary logging is disabled yet required by replication configuration.
No. MySQL starts normally but silently reduces binlog_stmt_cache_size to the allowed maximum.
You can, but aligning the parameters keeps configuration transparent and avoids confusion during audits.
Choose a size that balances memory usage with the largest statement you expect to log. 32-64 MB fits most workloads.
Galaxy highlights server warnings in query output and lets you adjust configuration scripts collaboratively, ensuring teams fix mismatches quickly.
.avif)
.avif){kind=logo}
