Hi!
"Kristian" == Kristian Nielsen <knielsen@knielsen-hq.org> writes:
<cut> Kristian> I am not very familiar with timestamps in binlog events. However, all the Kristian> transactions in the group commit are written out one after the other, in a Kristian> single thread holding the lock on the binlog. And the GTID events are Kristian> generated during that loop. So I think that at least the timestamps of the Kristian> GTID events in the group can never walk backwards, nor can they from one group Kristian> to the next. But I am not sure if the time stamps of other events in the Kristian> transaction can be earlier (maybe they were generated when the query was run, Kristian> not when it was committed? Time stamps in a statement is based on when the statement started, not when it committed. This is needed to ensure that all rows has the same value f you do: update big_table set timpestamp=now(); So it's normal that in a group commit, the transactions in the same commit can have totally different timestamps. Longer running transactions will typically have older timestamps. Regards, Monty