← Back to team overview

maria-developers team mailing list archive

Re: Interaction between rpl_slave_state and rpl_binlog_state


Andrei Elkin <andrei.elkin@xxxxxxxxxxx> writes:

> I would also raise another but relevant topic of maintaining
>    gtid_"executed"_pos
> which is an union of all GTID executed regardless of their arrival
> method. E.g some of foreign (to the recipient server) domains gtid:s may

> The master potentially could be (made) interested in such table
> should create a replication mode without necessary binlogging on the
> server.

Sorry, I don't follow.

Do you mean to create a new table of GTID positions, which will be updated
by all transactions, whether originating locally or replicated by a slave

Or do you mean to have the mysql.gtid_slave_pos table updated also by
locally originated transactions?

Or do you mean to have a new system variable @@gtid_executed_pos which is
constructed from the existing binlog and mysql.gtid_slave_pos_table, similar
to @@gtid_current_pos, but maybe including more GTIDs somehow?

> This is not really something new as it's exactly how mysql implemented
> gtid bookkeeping.

I think MySQL originally kept track of GTIDs only in the binlog, right? And
binlog was required to be enabled for GTID to work? I do remember seeing
something that relaxed this requirement, but I haven't followed the details.

 - Kristian.

Follow ups