← Back to team overview

maria-developers team mailing list archive

Re: set_time() on slave and unversioned -> versioned replication


Hi, Aleksey!

On Apr 04, Aleksey Midenkov wrote:
> On Thu, Apr 4, 2019 at 2:43 PM Sergei Golubchik <serg@xxxxxxxxxxx> wrote:
> >
> If there is an installation from unversioned 5.3 to versioned 10.3 we
> can warn user about lost microseconds. This is minor issue since such
> setups are rare, I guess. But for what microseconds are sent in 5.3?

When it's needed for replication. Say, in


thd->query_start_sec_part() sets the flag.

> > And I didn't want to force the master to include microseconds in
> > every single event for every single user just in case someone would
> > decide to do unversioned->versioned replication.
> If it's critical, this can be configured. But is it really performance
> issue?

A small performance and storage issue. At least 3 bytes per event.

And it's a general principle - there will be definitely less than 1% of
users, who will use this. Less than 0.1% too. Most probably, less than
0.01%. So, the remaining 99.99% should not pay the price for it.

> > Also, I thought that processing of 1000000 Query_log_event's in a
> > second is not realistic.
> Now it fails just with several events. I guess because
> system_time.sec_part is not reset to 0 initially.

You said yourself that is is reset:

  start_time_sec_part= system_time.sec_part= 0;

Initially it's reset in THD::THD() too:

  system_time.start.val= system_time.sec= system_time.sec_part= 0;

> > But now I see some issues with that. One can freeze the time on the
> > master with 'SET TIMESTAMP' and send an arbitrary number of events
> > with the same timestamp.
> >
> > Or one can generate a query event that includes microseconds, to
> > force the slave to count not from X.0, but from, say, X.999998.
> >
> > So, a wraparound is possible and we need some fix for it.
> Looks like a lots of complications for a minor issue. Other DBMS don't
> use microseconds for System Versioning at all. I guess user should
> cope either with sent microseconds unconditionally (for both SBR and
> RBR) or he should not use microseconds-precise System Versioning on
> slave.

one cannot possibly use microseconds-precise System Versioning on slave,
if the server does not send microseconds. the slave merely tries to
distingush between different statements, it doesn't try being precise.

Chief Architect MariaDB
and security@xxxxxxxxxxx

Follow ups