Sergei, On Wed, Mar 13, 2019 at 9:01 PM Sergei Golubchik <serg@mariadb.org> wrote:
Hi, Aleksey!
On Mar 13, Aleksey Midenkov wrote:
Query_log_event() can already store microseconds, see Q_HRNOW flag. So better to add them to Rows_log_event, if needed.
But I don't quite understand why it's needed.
In scope of MDEV-16370 slave adds history record. Master sends UPDATE of row (row_start = X.Y; row_end = MAX). Query time is X.(Y + n).
Slave adds history record and gets timestamp: X from master; F from system time fractions. If F < Y this makes bad history record (row_start = X.Y; row_end = X.F).
That's exactly what I wrote below. You can make F=Y, because the event already contains Y, you won't need to extend it.
I don't like it for a couple of reasons. It's a hackish way that is hard to remember and hard to figure out for unenlightened people. It leads to history mismatch between master and slave.
What you see - microseconds from the system time and seconds from the binlog event - is a workaround for replicating non-versioned master to versioned slave, where binlog events don't have microseconds.
In your case versioned-to-versioned RBR, row events should have microsecond-exact timestamps already, you can get them from there.
Only Delete_rows_log_event might not have the actual timestamp(6), but this can be fixed on the master, I suspect.
Regards, Sergei Chief Architect MariaDB and security@mariadb.org
-- All the best, Aleksey Midenkov @midenok