maria-developers team mailing list archive
Mailing list archive
Re: set_time() on slave and unversioned -> versioned replication
On Thu, Apr 4, 2019 at 2:43 PM Sergei Golubchik <serg@xxxxxxxxxxx> wrote:
> Hi, Aleksey!
> On Apr 04, Aleksey Midenkov wrote:
> > Hello, Sergei!
> > In unversioned -> versioned scenario in the code below it first gets to
> > time 4, creates some records (on slave) and then seconds on slave
> > (X+1) while on master seconds are not yet increased (X). Then we get to
> > time 3 and reset time on slave to X.0 therefore we get back in time and
> > stored records with timestamp X.n will be in future. 'n' came from
> > ++system_time.sec_part in Set time 4.
> That's not how it is supposed to work.
> As long as the master sends events with seconds=X,
> the slave will generate microsecons, X.0, X.1, X.2, etc.
> When the master sends an event with a new timestamp, Y,
> the slave goes back to Y.0, and continues with Y.1, etc.
> > Why did you decided to use such logic of getting seconds from master
> > and microseconds from slave? Since microseconds sooner or later reset
> > to 0 it's not better than just assigning some random number. What
> > sending microseconds from master conditionally only is good for?
> Because the master was sending microseconds conditionally, since 5.3.
> The slave had to cope with that somehow anyway.
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?
> 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
> 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.
> 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.
> Chief Architect MariaDB
> and security@xxxxxxxxxxx
All the best,