claudio.nanni, hello.

To
>but paragraph [3] says:
>"Thus, @@gtid_current_pos contains the most recent GTID executed on the server, whether this was done as a master or as a slave."

'the most recent' is defined in terms of the gtid sequence number. As the master and slave share the domain (0) the most recent
was the master's 40 all the way until the slave has generated 41th.
I hope this clarifies away your confusion.

Andrei

PS.

to
> {{MASTER_USE_GTID = slave_pos|current_pos }} (not relevant)
actually when {{ MASTER_USE_GTID = slave_pos }} it really does not matter what slave topped over the mater's replicated gtid. But does matter when the mode is {{ current_pos }}.

To
>but paragraph [3] says:
>"Thus, @@gtid_current_pos contains the most recent GTID executed on the server, whether this was done as a master or as a slave."
'the most recent' is defined in terms of the gtid sequence number. As the master and slave share the domain (0) the most recent
was the master's 40 all the way until the slave has generated 41th.
I hope this clarifies away your confusion.

I still think it's wrong.
Moreover I think this is also due to a flaw in GTID design.
The slaves are aware of the latest sequence number applied by the Master but no one is aware of the latest sequence number applied by any Slave, in a simple setup, the Master doesn't know (doesn't have a feedback mechanism for it) that the Slave generated a sequence number.
The fact that the gtid_current_pos only starts being updated when the local sequence number is higher than the latest sequence number arrived from the Master (gtid_slave_pos) does not make sense to me.

Read again:
"Thus, @@gtid_current_pos contains the most recent GTID executed on the server, whether this was done as a master or as a slave."

That variable must be updated by definition, and it makes no sense that it isn't, what's the logic?
Moreover maybe this Slave won't ever be slave of that Master again.

Wouldn't it be simpler and more logical to just always update gtid_current_pos with local transactions?

gtid_current_pos is updated this way for the reason that it holds 'the most recent' value in the logical time sense.
So it remained 40 until the slave server itself (as a "master") generated 41 and then the clock steps.
Gtid - current_pos and slave_pos are clocks really, so they can't go backward.

To gtid_current_pos specifically KN admitted that Change-Master's MASTER_USE_GTID = current_pos confused many people.
Oth to understand gtid_slave_pos must be comparatively easy.
What practical purpose do you really need gtid_current_pos for?

Andrei,

> Oth to understand gtid_slave_pos must be comparatively easy.
>What practical purpose do you really need gtid_current_pos for?

Yes, gtid_slave_pos would be an easier choice indeed but MaxScale uses gtid_current_pos for it's failover mechanism, maybe there is a valid reason for them to use gtid_slave_pos.

claudio.nanni, salute.

I suggest we sum up what the docs say and how that matches our observations.

1. This report's synopsis states

gtid_current_pos is not updated until a GTID arrived with gtid_seq_no > max(d), where d is a gtid domain present in gtid_current_pos.

Such behavior matches the docs when 'recent' is understood in the logical time sense.

2. Notice that gtid_binlog_state may show changes but only for a reason
that this array collects GTID per server. Union of its GTID:s relating to any domain in gtid_current_pos can produce a value at most matching or less than
one in the latter array.

3. There is unreported observation that despite gtid_strict_mode = ON
the slave is able to update gtid_binlog_state even though those updates
having gtid_seq_no < max(d), max(d) = 41 in your example.
This is benign by gtid_strict_mode definition as the strict mode rules
apply exclusively to binlogged set of GTID:s. So once they are removed (RESET MASTER) less than 41 local GTID:s also gets accepted (over again).

All in all I don't see there is anything that sticks out as questionable though
I admit we may challenge design decisions from perspective of intuitive understanding and easy-doing. For instance, I am unhappy myself to find out
gtid_strict_mode is actually "gtid_binlog_strict_mode". I really thought it should apply generally, including --skip-log-bin or --log-slave-updates=0 slaves, which it does not.

Regardless of our dissatisfaction to this part the current issue is
not a bug in my opinion and should be addressed by extending our documentation
on three referred items:

gtid_current_pos - should be stressed on that it's per domain array
gtid_binlog_state - it's per server-id one
gtid_strict_mode - makes sense only for binlogging slave

Feel free to revert the issue status, should you have more feedback.

Cheers,

Andrei

Reported traces of execution match definitions of the slave GTID state descriptors, as
extensively commented out. Specifically to slave_current_pos it is updated correctly.