Kristian Nielsen <knielsen@knielsen-hq.org> writes:
The same problem actually exists in the non-parallel case. In case of a
Just to elaborate on this, here is the binlog from a transaction with some artificial long-running queries (using INSERT(SLEEP())): #151015 9:43:52 server id 1 end_log_pos 1120 GTID 0-1-5 BEGIN #151015 9:43:44 server id 1 end_log_pos 1210 Query thread_id=3 exec_time=0 error_code=0 insert into t1 values (1,0) #151015 9:43:44 server id 1 end_log_pos 1308 Query thread_id=3 exec_time=1 error_code=0 insert into t1 values (2, sleep(1)) #151015 9:43:45 server id 1 end_log_pos 1406 Query thread_id=3 exec_time=5 error_code=0 insert into t1 values (3, sleep(5)) #151015 9:43:50 server id 1 end_log_pos 1504 Query thread_id=3 exec_time=2 error_code=0 insert into t1 values (4, sleep(2)) #151015 9:43:52 server id 1 end_log_pos 1531 Xid = 15 COMMIT/*!*/; Suppose the slave starts executing this transaction at 9:44:00. The value of Seconds_Behind_Master will be set to something like the following as each event is read from the relay log: 8 16 15 11 14 16 Note in particular how the value jumps back and forth during the execution of the transaction. The time used on the slave is the time the event starts executing. The time used on the master is inconsistent with this, it is sometimes the time the transaction ends (BEGIN), sometimes the time the query ends. When these two values are subtracted, the result is somewhat fuzzy if the transaction runs for more than a second. Clearly, I do not have any great desire to jump through hoops and sacrifice performance in parallel replication to try and match a behaviour that seems poorly designed from the start, hence the proposed patch. (I do not have any strong opinion one way or the other on whether to change the existing behaviour of Seconds_Behind_Master in the non-parallel case.) - Kristian.