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

[PATCH] feature request MASTER_GTID_WAIT status variables

Details

    Description

      With MASTER_GTID_WAIT I wouldn't mind a global (and optionally session) indication of:

      • total time spent in this wait state in including timeouts
      • total time spent in the function excluding timeouts
      • total number of timeouts occurred in this function

      I'd find this quite useful for general health monitoring of this function, particularly when graphed over time.

      Thanks for your consideration

      Attachments

        Activity

          danblack Daniel Black created issue -
          danblack Daniel Black added a comment -

          attached patch implements three status variables

          master_gtid_wait_count (# of times called)
          master_gtid_wait_timeouts (# of time it was called and timed out)
          master_gtid_wait_time (time in microseconds waiting for results)

          danblack Daniel Black added a comment - attached patch implements three status variables master_gtid_wait_count (# of times called) master_gtid_wait_timeouts (# of time it was called and timed out) master_gtid_wait_time (time in microseconds waiting for results)
          danblack Daniel Black made changes -
          Field Original Value New Value
          Attachment master_gtid_wait_status_vars.patch [ 36214 ]
          danblack Daniel Black added a comment -

          made output more readable by only replacing $wait_time with MASTER_GTID_WAIT_TIME, leaving expression, and using more accurate labels on output.

          danblack Daniel Black added a comment - made output more readable by only replacing $wait_time with MASTER_GTID_WAIT_TIME, leaving expression, and using more accurate labels on output.
          danblack Daniel Black made changes -
          Attachment master_gtid_wait_status_vars.patch [ 36215 ]
          danblack Daniel Black made changes -
          Attachment master_gtid_wait_status_vars.patch [ 36214 ]

          Looks good.
          Only, I think the variables need to be declared ulonglong? Because they are used with SHOW_LONGLONG_STATUS ? (and otherwise timeout counter would wrap after 4000 seconds)

          knielsen Kristian Nielsen added a comment - Looks good. Only, I think the variables need to be declared ulonglong? Because they are used with SHOW_LONGLONG_STATUS ? (and otherwise timeout counter would wrap after 4000 seconds)
          knielsen Kristian Nielsen made changes -
          Assignee Kristian Nielsen [ knielsen ]
          danblack Daniel Black added a comment -

          fixed

          danblack Daniel Black added a comment - fixed
          danblack Daniel Black made changes -
          danblack Daniel Black made changes -
          Summary feature request MASTER_GTID_WAIT status variables [PATCH] feature request MASTER_GTID_WAIT status variables
          danblack Daniel Black made changes -
          Attachment master_gtid_wait_status_vars.patch [ 36215 ]
          knielsen Kristian Nielsen made changes -
          Status Open [ 1 ] In Progress [ 3 ]

          Bummer, I don't know how this has stalled for so long

          I've pushed it to a feature tree for buildbot testing, once that has run I will push it to 10.1.

          knielsen Kristian Nielsen added a comment - Bummer, I don't know how this has stalled for so long I've pushed it to a feature tree for buildbot testing, once that has run I will push it to 10.1.
          knielsen Kristian Nielsen made changes -
          Fix Version/s 10.1.4 [ 18400 ]
          knielsen Kristian Nielsen added a comment - - edited

          Ehm, this really does not work:

          # This one completes immediately ( < 1 ms).
          SELECT master_gtid_wait('1-1-1');
          let $wait_time = query_get_value(SHOW STATUS LIKE 'Master_gtid_wait_time', Value, 1);
          eval SELECT floor($wait_time / 1000) AS Master_gtid_wait_time_milliseconds;
           
          SELECT master_gtid_wait('2-1-2', 0.5);
          # (0.5-0.6 seconds)
          eval SELECT floor($wait_time / 100000) AS Master_gtid_wait_time_tenths_of_a_second;

          Those times will fluctuate a lot depending on load on the test machine (as
          seen in buildbot).

          And did you test that the counters are reset to 0 when the test starts, so
          that they values do not depend on what happened in earlier tests that ran
          before this test?

          Also, main.max_statement_time fails (but that's easy to fix).

          knielsen Kristian Nielsen added a comment - - edited Ehm, this really does not work: # This one completes immediately ( < 1 ms). SELECT master_gtid_wait('1-1-1'); let $wait_time = query_get_value(SHOW STATUS LIKE 'Master_gtid_wait_time', Value, 1); eval SELECT floor($wait_time / 1000) AS Master_gtid_wait_time_milliseconds;   SELECT master_gtid_wait('2-1-2', 0.5); # (0.5-0.6 seconds) eval SELECT floor($wait_time / 100000) AS Master_gtid_wait_time_tenths_of_a_second; Those times will fluctuate a lot depending on load on the test machine (as seen in buildbot). And did you test that the counters are reset to 0 when the test starts, so that they values do not depend on what happened in earlier tests that ran before this test? Also, main.max_statement_time fails (but that's easy to fix).
          knielsen Kristian Nielsen made changes -
          Status In Progress [ 3 ] Stalled [ 10000 ]
          danblack Daniel Black added a comment -

          https://github.com/MariaDB/server/pull/21

          > Those times will fluctuate a lot depending on load on the test machine (as seen in buildbot).

          Increased time windows a lot. The immediate case is a event is pushed to the master before master_gtid_wait is called on the slave. The 0.5 case is the timeout occurs on the slave master_gtid_wait. Is there a way to write these sort of test cases?

          > And did you test that the counters are reset to 0

          I'm only looking at the session status variables on a new connection.

          > Also, main.max_statement_time fails (but that's easy to fix).

          I don't see that in my patch.

          danblack Daniel Black added a comment - https://github.com/MariaDB/server/pull/21 > Those times will fluctuate a lot depending on load on the test machine (as seen in buildbot). Increased time windows a lot. The immediate case is a event is pushed to the master before master_gtid_wait is called on the slave. The 0.5 case is the timeout occurs on the slave master_gtid_wait. Is there a way to write these sort of test cases? > And did you test that the counters are reset to 0 I'm only looking at the session status variables on a new connection. > Also, main.max_statement_time fails (but that's easy to fix). I don't see that in my patch.
          serg Sergei Golubchik made changes -
          Priority Minor [ 4 ] Major [ 3 ]
          knielsen Kristian Nielsen made changes -
          Status Stalled [ 10000 ] In Progress [ 3 ]

          I've merged it into 10.1 and pushed to bb-10.1-knielsen for a buidbot run.
          If everything looks ok, I'll push to main 10.1 tomorrow.

          knielsen Kristian Nielsen added a comment - I've merged it into 10.1 and pushed to bb-10.1-knielsen for a buidbot run. If everything looks ok, I'll push to main 10.1 tomorrow.

          Pushed to 10.1.4, thanks Daniel!

          knielsen Kristian Nielsen added a comment - Pushed to 10.1.4, thanks Daniel!
          knielsen Kristian Nielsen made changes -
          Component/s Replication [ 10100 ]
          Resolution Fixed [ 1 ]
          Status In Progress [ 3 ] Closed [ 6 ]
          ratzpo Rasmus Johansson (Inactive) made changes -
          Workflow MariaDB v2 [ 57200 ] MariaDB v3 [ 65309 ]
          serg Sergei Golubchik made changes -
          Workflow MariaDB v3 [ 65309 ] MariaDB v4 [ 132446 ]

          People

            knielsen Kristian Nielsen
            danblack Daniel Black
            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.