Bug #81164 slave start time is very high when using milli second heartbeat time period
Submitted: 20 Apr 2016 20:55 Modified: 28 Jun 2019 11:05
Reporter: Santosh Praneeth Banda Email Updates:
Status: Duplicate Impact on me:
None 
Category:MySQL Server: Replication Severity:S2 (Serious)
Version:5.6.24 OS:Any
Assigned to: CPU Architecture:Any

[20 Apr 2016 20:55] Santosh Praneeth Banda 
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
[28 Jun 2019 11:05] MySQL Verification Team 
Closing this as a duplicate of contribution Bug #94356.

regards,
Umesh
[28 Jun 2019 11:06] MySQL Verification Team 
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.