Uploaded image for project: 'MariaDB MaxScale'
  1. MariaDB MaxScale
  2. MXS-5147

Lightweight GTID monitoring for causal_reads fast modes

    XMLWordPrintable

Details

    • New Feature
    • Status: Closed (View Workflow)
    • Critical
    • Resolution: Fixed
    • None
    • 25.08.0
    • mariadbmon
    • None
    • MXS-SPRINT-227

    Description

      The minimum monitoring interval is 100 ms and this makes sense as some of the monitoring that takes place is relatively heavy, like SHOW ALL SLAVES STATUS.
      When using causal reads, in particular with SNow, we are stuck with the fast global or fast universal (the latter in particular when using more than one MaxScale) and these rely on the moniting picking up the currect GTID on the replica. This in the end meabs that even though replication is lightning fast we have to waut for the monitor to figure this out. The current minimum for the monitoring interval, 100ms, is actually quite a lot for this particular monitoring of the GTID for causal reads. To maximize the usefulness of causal reads we then have to run a bunch of SQL statements much more often than necessary (SELECT from event table, SHOW ALL SLAVES STATUS etc) just to get the GTID position. I suggest that the mariadbmonitor is enhanced with a second optional thread that just monitors the GTID, or possible just a single thread that does "full monitoring" less often. I leave the implementation to you guys.

      Attachments

        Issue Links

          Activity

            People

              markus makela markus makela
              karlsson Anders Karlsson
              Votes:
              0 Vote for this issue
              Watchers:
              2 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.