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.
My fault, sorry! I should've referred straight to synchronous replication ... where master maintains an "immediate" (without binlog proxy) constant connection to slaves (when it breaks the slave would have to take snapshot, or find a binlog service e.g on some other slave). [In such a case the master connection would still collect transaction statement till prepare or commit to send them to slaves at those points.] So here replicated transactions need identification on the binlog-less master to display its execution status (which would matter when configuration changes and a new master is reelected). I am not dwelling into specifics too deep now, it's just to exemplify such use case.
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?
This one.
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?
True.
I do remember seeing something that relaxed this requirement, but I haven't followed the details.
Like we update `gtid_slave_pos` on slave by the slave applier on the binlog-less server, so they keep updating a general `gtid executed` table by any incl the user connection and slave applier. Cheers, Andrei