maria-developers team mailing list archive

[Aleksey Midenkov <midenok@xxxxxxxxx>]

Andrei, thanks for explanation!

Agree with you and Sergei on that topic.

Sergei,

On Tue, Mar 12, 2019 at 9:04 PM Sergei Golubchik <serg@xxxxxxxxxxx> wrote:

> Hi, Aleksey!
>
> On Mar 12, Aleksey Midenkov wrote:
> > Hi, Sergei,
> >
> > Thank you for observations! This task is in progress. While doing it I
> > found out that RBR doesn't replicate timestamp fractions. That is: it
> > gets seconds from event timestamp marker and adds fractions from
> > system time.  This causes bugs in System Versioning. More on it in Bug
> > 6 here:
> >
> https://github.com/tempesta-tech/mariadb/issues/578#issuecomment-470533050
> >
> > I propose to fix it by adding timestamp fractions field to Log_event
> > header after FLAGS_OFFSET. To support backwards compatibility it is
> > needed to increment fdle->binlog_version and probably add new flag
> > LOG_EVENT_HAS_SEC_PART_F (for support sending Log_event without
> > fractions).
> > Do you agree?
>
> 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).


>
> 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