Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-6842

Global variables should only contain configuration settings not state (gtid_current_pos / gtid_slave_pos)

Details

    • Bug
    • Status: Closed (View Workflow)
    • Major
    • Resolution: Not a Bug
    • 10.0.14
    • N/A
    • OTHER

    Description

      On a server I notice:

      root@myserver [(none)]> show global variables like 'gtid%';
      +------------------------+----------------------+
      | Variable_name          | Value                |
      +------------------------+----------------------+
      | gtid_binlog_pos        |                      |
      | gtid_binlog_state      |                      |
      | gtid_current_pos       | 0-187204017-44995072 |
      | gtid_domain_id         | 0                    |
      | gtid_ignore_duplicates | OFF                  |
      | gtid_slave_pos         | 0-187204017-44995072 |
      | gtid_strict_mode       | OFF                  |
      +------------------------+----------------------+
      7 rows in set (0.00 sec)

      The 2 "variables" gtid_current_pos and gtid_slave_pos do not have configuration settings but state. Configuration state should be stored somewhere else. SHOW GLOBAL STATUS has traditionally been used for this.

      See an upstream equivalent ticket I wrote some time ago (not resolved either).

      As stated in the original ticket I care because I collect this configuration information and have to explicitly filter out settings like this which change continually to be able to compare settings from one server to another or one moment in time to another.

      So please remove these variables from global_variables and put the information somewhere else.

      Attachments

        Activity

          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.

          elenst Elena Stepanova added a comment - 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.
          simon.mudd Simon J Mudd added a comment - - edited

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

          simon.mudd Simon J Mudd added a comment - - edited 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)
          simon.mudd Simon J Mudd added a comment -

          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.

          simon.mudd Simon J Mudd added a comment - 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?

          knielsen Kristian Nielsen added a comment - 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?
          simon.mudd Simon J Mudd added a comment -

          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.

          simon.mudd Simon J Mudd added a comment - 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.
          simon.mudd Simon J Mudd added a comment -

          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                                           |

          simon.mudd Simon J Mudd added a comment - 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.

          knielsen Kristian Nielsen added a comment - 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?

          hholzgra Hartmut Holzgraefe added a comment - Will we consider to prevent such VARIABLE / STATUS mixups in the future earlier, preferrably in the design stage already?

          People

            Unassigned Unassigned
            simon.mudd Simon J Mudd
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved:

              Git Integration

                Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.