maria-developers team mailing list archive
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
> 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
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.