maria-developers team mailing list archive

[Aleksey Midenkov <midenok@xxxxxxxxx>]

Sergei,

On Wed, Mar 13, 2019 at 9:01 PM Sergei Golubchik <serg@xxxxxxxxxxx> 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@xxxxxxxxxxx
>


-- 
All the best,

Aleksey Midenkov
@midenok