AFAIK, timestamp for a binlog event is the time when corresponding statement started to execute. The order of statements in the binlog is according to the time when statements were committed, which of course doesn't have anything to do with the time statement started to execute. That's why timestamps in the binlog can jump back and forth randomly. But I'd think that if one looks at timestamps only on GTID events then he should expect to see monotonically increasing time within each domain.

If that’s the case the GTID support is going to be helpful in areas beyond just parallelization and restart. Thank you both for the clarifications. We’ll be adding support for the MariaDB 10.0 binlog format in Tungsten Replicator later this year. Should be a pleasure to work on… :)

Pavel

On Fri, Mar 14, 2014 at 8:54 AM, Robert Hodges <robert.hodges@continuent.com> wrote:
Hi Kristian,

Thanks for the prompt and detailed response!

I’m glad you clarified that GTIDs cannot ever walk backwards. It’s really bad design if they are not monotonically increasing and comparable. This will really help restart logic in a number of places, not just for your own replication.

The timestamp issue is mysterious one. I also don’t fully understand how the timestamp is generated for the event header. All I know is that it sometimes walks backwards, possibly as a result of large transactions or load data infile commands. If I can find a reproducible case I will post it, as it can cause inscrutable problems downstream when loading to other systems. (Ask me how I know…)

Meanwhile, good luck on your replication work. It seems to be proceeding in a good direction.

Cheers, Robert