| Bug #81164 | slave start time is very high when using milli second heartbeat time period | ||
|---|---|---|---|
| Submitted: | 20 Apr 2016 20:55 | Modified: | 28 Jun 11:05 |
| Reporter: | Santosh Praneeth Banda | Email Updates: | |
| Status: | Duplicate | Impact on me: | |
| Category: | MySQL Server: Replication | Severity: | S2 (Serious) |
| Version: | 5.6.24 | OS: | Any |
| Assigned to: | CPU Architecture: | Any | |
[28 Jun 11:05]
Umesh Shastry
Closing this as a duplicate of contribution Bug #94356. regards, Umesh
[28 Jun 11:06]
Umesh Shastry
Bug #94356 closed with the below changelog: [17 Apr 11:53] Margaret Fisher Posted by developer: Changelog entry added for MySQL 8.0.18: The heartbeat interval for a replication slave, which is controlled by the MASTER_HEARTBEAT_PERIOD option of the CHANGE MASTER TO statement, can be specified with a resolution in milliseconds. Previously, the master's binary log dump thread used a granularity of seconds to calculate whether a heartbeat signal should be sent to the slave, causing excessive heartbeat activity in the case of multiple skipped events. To remove this issue, all heartbeat-related calculations by the master and slave are now carried out using a granularity of nanoseconds for precision. Thanks to Facebook for the contribution.
Description: Use auto-positioning with GTIDs. Start slave with milli second heartbeat period. mysql> stop slave; change master to master_heartbeat_period=0.25, master_auto_position=1; mysql> start slave; Verify slave receives heartbeats for every skipped event. If auto-positioning causes sender thread to skip lots of events, then slave start time is very high. The problematic line of code is time_for_hb_event= ((ulonglong)(now - last_event_sent_ts) >= (ulonglong)(heartbeat_period/1000000000UL)); If heartbeat_period is < 1 sec then time_for_hb_event is always true !! How to repeat: see description Suggested fix: Fix time granularity bug in sender thread