maria-developers team mailing list archive

[andrei.elkin@xxxxxxxxxx]

>> 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