Hi, Aleksey!
On Apr 04, Aleksey Midenkov wrote:
> On Thu, Apr 4, 2019 at 5:08 PM Sergei Golubchik <serg@mariadb.org> 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@mariadb.org