← Back to team overview

maria-developers team mailing list archive

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

 

Hi Sergei!

On Thu, Apr 4, 2019 at 8:59 PM Sergei Golubchik <serg@xxxxxxxxxxx> wrote:

> Hi, Aleksey!
>
> On Apr 04, Aleksey Midenkov wrote:
> > On Thu, Apr 4, 2019 at 5:08 PM Sergei Golubchik <serg@xxxxxxxxxxx>
> wrote:
> >
> > > > > 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.
> > >
> > But is it really an issue: do you know setups where replication
> > communication is a bottleneck?
>
> It's few percent increase of the binlog size. Not much.
>
> > > 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.
> > >
> > Btw, it would be good to see the stats. We have some feedback plugin
> > that does the job, don't we?
>
> Yes.
>
> > > > > 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;
> > >
> > It is synchronized with hardware clock on each set_start_time().
>
> It must be a bug. Hardware clock shouldn't overwrite
> the counter as it comes from the slave.
>

Yes. And there are more complications: for replication log we can check
thd->slave_thread, because it is replayed, well, in a slave thread. But
executing it from client (which is original MDEV-16370 bug) does not
execute it in a slave thread.


>
> Regards,
> Sergei
> Chief Architect MariaDB
> and security@xxxxxxxxxxx
>


-- 
All the best,

Aleksey Midenkov
@midenok

References