![](https://secure.gravatar.com/avatar/99fde0c1dfd216326aae0aff30d493f1.jpg?s=120&d=mm&r=g)
Andrei Elkin
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 thread? 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.