maria-developers team mailing list archive
Mailing list archive
Re: set_time() on slave and unversioned -> versioned replication
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
INSERT t1 VALUES (NOW(6));
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
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
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