<p>The heartbeat period requested on a replica is below the 1-millisecond minimum, so MySQL resets it to 0 and disables heartbeating.</p>
<p>MySQL Error 1703 ER_SLAVE_HEARTBEAT_VALUE_OUT_OF_RANGE_MIN arises when a replica is told to use a heartbeat interval below 1 millisecond, forcing MySQL to revert the value to 0 and stop heartbeats. Set SOURCE_HEARTBEAT_PERIOD to 0.001 or higher to resolve the issue.</p>
The requested value for the heartbeat period is less than
Error 1703 occurs during replication setup or maintenance when the replica receives a heartbeat interval below the supported minimum of 0.001 seconds. MySQL interprets the request as invalid, logs the error, resets the period to 0, and effectively disables heartbeats.
Heartbeats let the source periodically ping replicas so they can detect lags quickly even when no row events arrive. Disabling heartbeats can delay lag detection and slow failover automation, so correcting the configuration is important for reliable replication.
The message appears in the replica’s error log or SHOW REPLICA STATUS output right after issuing a CHANGE REPLICATION SOURCE TO statement or during START REPLICA if the heartbeat value in replication metadata is out of range.
A disabled heartbeat hides network hiccups and increases recovery time objectives. Production environments with automated failover or tight monitoring SLAs should always run with a valid heartbeat interval.
The most common trigger is a DBA misunderstanding the unit (seconds) and supplying 0.0005 instead of 0.5 milliseconds. Copy-pasting from documentation of other databases that allow microsecond units is another frequent root cause.
In version upgrades, replication metadata can carry an old invalid value forward, resurfacing the error during the first START REPLICA after upgrade.
Set SOURCE_HEARTBEAT_PERIOD to a legal value between 0.001 and 4294967 seconds using CHANGE REPLICATION SOURCE TO, then restart replication threads.
If you need sub-second detection, 0.5 (half a second) is a safe choice. For geographically distant replicas, 1-2 seconds avoids excess network chatter.
In orchestrated clusters, script the fix so every new replica joins with a compliant heartbeat value.
Automate replication setup through trusted templates or tools like Galaxy collections. Validate numeric parameters before issuing CHANGE REPLICATION SOURCE TO commands in CI pipelines.
Monitor replication metadata via scheduled queries and alert if SOURCE_HEARTBEAT_PERIOD is 0.
Errors 1201, 1202, and 1186 relate to replication connection and log reading. Resolving the heartbeat setting often reduces their frequency by keeping the replica connected actively.
The DBA entered 0.0005 believing the unit was seconds but intending microseconds, making the value too small.
Documentation from PostgreSQL or Oracle uses microsecond heartbeat examples that are invalid in MySQL.
An invalid heartbeat value stored in the replica metadata table survived an upgrade and triggers the error on start.
Indicates the replica I/O thread cannot connect to the source. A missing heartbeat can exacerbate detection time.
Signals a failure reading the binary log from the source. Ensuring a valid heartbeat keeps the connection active and lowers risk.
Checksum mismatches while reading events. Correct heartbeat keeps lag low, helping isolate checksum issues quickly.
Yes, setting SOURCE_HEARTBEAT_PERIOD to 0 disables heartbeats, but it is discouraged in production because lag detection slows down.
Between 0.1 and 1 second for intra-data-center replicas, and 1-2 seconds for cross-region setups.
No. You only need to STOP REPLICA, issue CHANGE REPLICATION SOURCE TO with a valid value, and START REPLICA.
Galaxy lets teams store validated replication templates, so new replicas always start with compliant parameters, avoiding this error entirely.
.avif)
.avif){kind=logo}
