<p>MySQL raises warning 1708 (WARN_OPTION_BELOW_LIMIT) when a server option is set to a value lower than the minimum safe or required limit.</p>
<p>MySQL Error 1708 WARN_OPTION_BELOW_LIMIT occurs when you configure a server variable below its required threshold, such as setting slave_pending_jobs_size_max under max_allowed_packet. Increase the option value or reduce the related limit with SET or by editing my.cnf to clear the warning.</p>
The value of '%s' should be no less than the value of
Warning 1708 fires when MySQL detects that a configurable option is set lower than a dependent limit. The server issues the message 'The value of X should be no less than the value of Y' and keeps running, but the unsafe setting may break replication, truncate row events, or impair performance.
The warning emerges most often during SET GLOBAL, SET PERSIST, or at startup when my.cnf overrides defaults. Examples include slave_pending_jobs_size_max being smaller than max_allowed_packet or range_optimizer_max_mem_size under eq_range_index_dive_limit.
Leaving the mismatch untouched can stall replication, cause partial statement logging, or trigger unexpected truncation. Resolving it preserves data integrity, avoids replication lag, and prevents silent data loss in busy production systems.
Typical pairs include slave_pending_jobs_size_max vs max_allowed_packet, range_optimizer_max_mem_size vs read_rnd_buffer_size, and join_buffer_size vs optimizer_search_depth. Always verify both the option you changed and any related upper limit.
Galaxy’s linting engine surfaces MySQL warnings in-line while you edit, flags dangerous SET statements, and suggests safe values based on live server metadata, helping teams correct 1708 before the change hits production.
Setting slave_pending_jobs_size_max below max_allowed_packet during replication tuning immediately triggers the warning.
Reducing range_optimizer_max_mem_size without adjusting read_rnd_buffer_size below the same threshold leads to 1708 at startup.
Deploying generic configuration files that hard-code small buffer limits can violate new default requirements after version upgrades.
Chef, Ansible, or Terraform scripts that enforce absolute values may ignore dynamic limits and push an option under the minimum bound.
Server adjusted an out-of-range option to the closest valid value automatically.
Attempt to set a read-only system variable at runtime.
User lacks SUPER or SYSTEM_VARIABLES_ADMIN privilege to modify the target option.
No, the server continues operating, but the unsafe setting can cause downstream issues like replication lag.
Ignoring it risks data loss or performance degradation. Always fix the underlying mismatch.
Only if startup options satisfy the limits. Otherwise the warning reappears at each boot.
Apply the SET command on a staging replica first, monitor SHOW WARNINGS, and run application workload benchmarks before deploying to production.
.avif)
.avif){kind=logo}
