maria-developers team mailing list archive

[Kristian Nielsen <knielsen@xxxxxxxxxxxxxxx>]

Kristian Nielsen <knielsen@xxxxxxxxxxxxxxx> 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.