It might be true for gtid_current_pos, but gtid_slave_pos can (and in some cases might need to) be set, so it cannot go to status.

Assigning to knielsen to decide what can be done about this.

Note: upstream issue reported here (2 years ago):

• http://bugs.mysql.com/bug.php?id=65189 (Don't pollute status settings in SHOW [GLOBAL] VARIABLES)

Well setting of gtid_slave_pos, like gtid_executed in MySQL 5.6+ has the same issue.

However, I'd still argue that it's not a configuration setting, so it does not belong here.

My frustration with this sort of thing is that I have to add exceptions when collecting "configuration information" from my servers and then comparing these settings to determine if one server is configured the same as another one. So any sort of "setting like this" is a major nuisance. It also means that I have to go and back-fix information that's already been collected in order to have a consistent set of data.

Anyway, this ticket is marked as priority: Major. That's probably not true so maybe it should be adjusted accordingly.

I don't know what I'm supposed to do with this?

A suggestion to "remove" something isn't too useful without also suggesting
what to replace it with? And how to do it without breaking backward
compatibility?

Kristian with all respect, put it in another (system/gtid/performance_schema) table.
Or put it in the SHOW SLAVE STATUS output (which is where most people might expect to see it.

The point I'm trying to make is that it should have never been put here in the first place.

If you have GTID information which you need to keep track of, then a gtid table would seem like a good place. You already have a table mysql.gtid_slave_pos, so mysql.gtid_current_pos might be appropriate?

My point here is that mixing configuration and status information in the same place is really unfortunate.
I try to keep track of the configuration settings and changes of a number of servers so the output of SHOW GLOBAL VARIABLES is tracked. Except for these settings, unless I've missed others which are doing the same thing, all the other settings are stable unless an explicit configuration change happens.

Regarding backward compatibility, well yes, I'd agree that it would not be good to change this in the 10.0 current version.

I also notice on another server (a master) that gtid_binlog_pos and gtid_binlog_state also contain state information. It was not apparent to me on the first server I was looking at.

+------------------------+--------------------------------------------------------------------------------+

| Variable_name          | Value                                                                          |

+------------------------+--------------------------------------------------------------------------------+

| gtid_binlog_pos        | 0-nnnnnnn24-94405423,999-nnnnnnn24-2                                           |

| gtid_binlog_state      | 0-nnnnnnn58-94405296,0-nnnnnnn03-32195206,0-nnnnnnn24-94405423,999-nnnnnnn24-2 |

| gtid_current_pos       | 0-nnnnnnn24-94405423,999-nnnnnnn24-2                                           |

Serg asked me to close this as "not a bug".

It is not a bug, because this is how it was designed and is documented.

It is a valid feature request to ask for things to be designed differently, I suppose. But I don't see how to change this now after a GA release, as it would break backwards compatibility.

Will we consider to prevent such VARIABLE / STATUS mixups in the future earlier, preferrably in the design stage already?