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

Add option for SQL thread to limit maximum execution time per query replicated

Details

    Description

      Currently execution time for the replicated query is not limited in any clear way. On primary node we can use max_statement_time, but this value is neither passed to slave nor enforced for SQL thread when it's set locally. So, there is no way to "control" replication delay and just stop with error when it's too big already.

      I think option to stop with error after specific timeout (that may be different than local max_statement_time or primary's max_statement_time) would be useful for replication setups.

      Attachments

        Activity

          Ascending order - Click to sort in descending order
          Elkin Andrei Elkin added a comment - - edited

          Slave appliers indeed ignore global.max_statement_time which they must be initialized with (as the user connection threads do). Whether that's designed on purpose (doubts) or is actually buggy remains to be seen.
          Should there be no such effect the requested functionally could be provided without any new option.
          To add more, init-slave is around to fine tune slave appliers so @@SESSION level setting
          like this one could be technically done though that.

          Elkin Andrei Elkin added a comment - - edited Slave appliers indeed ignore global.max_statement_time which they must be initialized with (as the user connection threads do). Whether that's designed on purpose (doubts) or is actually buggy remains to be seen. Should there be no such effect the requested functionally could be provided without any new option. To add more, init-slave is around to fine tune slave appliers so @@SESSION level setting like this one could be technically done though that.
          serg Sergei Golubchik added a comment -

          What do you mean "slave appliers indeed ignore global.max_statement_time which they must be initialized with (as the user connection threads do)" ? Every THD gets max_statement_time, slave thread too. It's copied from global in plugin_thdvar_init() which is called from THD::init(). What slave threads don't do — they don't set the query timer to expire after max_statement_time seconds. In THD::set_query_timer() slave threads are explicitly excluded. This looks very much like on purpose, one can hardly write slave_thread || unintentionally.

          serg Sergei Golubchik added a comment - What do you mean "slave appliers indeed ignore global.max_statement_time which they must be initialized with (as the user connection threads do)" ? Every THD gets max_statement_time , slave thread too. It's copied from global in plugin_thdvar_init() which is called from THD::init() . What slave threads don't do — they don't set the query timer to expire after max_statement_time seconds. In THD::set_query_timer() slave threads are explicitly excluded. This looks very much like on purpose, one can hardly write slave_thread || unintentionally.
          serg Sergei Golubchik added a comment -

          I don't think it's a good idea. If the slave thread would always be using global.max_statement_time — that's one thing. But if you're adding an option anyway, better to have an option like --slave-max-statement-time and not --slave-uses-global-max-statement-time

          serg Sergei Golubchik added a comment - I don't think it's a good idea. If the slave thread would always be using global.max_statement_time — that's one thing. But if you're adding an option anyway, better to have an option like --slave-max-statement-time and not --slave-uses-global-max-statement-time
          bnestere Brandon Nesterenko added a comment -

          Hi Andrei!

          This is ready for review.

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

          bnestere Brandon Nesterenko added a comment - Hi Andrei! This is ready for review. https://github.com/MariaDB/server/pull/2182
          Elkin Andrei Elkin added a comment -

          Completed the work. The final review was provided by Sergei (kudos for pretty constructive notes and heads-ups!).

          Elkin Andrei Elkin added a comment - Completed the work. The final review was provided by Sergei (kudos for pretty constructive notes and heads-ups!).
          monty Michael Widenius added a comment -

          The adopted solution was to add a new variable, Slave_max_statement_time, which can be
          used to limit the time that slave is going to wait for a query to be executed.
          The slave will no honor max_statement_time.

          monty Michael Widenius added a comment - The adopted solution was to add a new variable, Slave_max_statement_time, which can be used to limit the time that slave is going to wait for a query to be executed. The slave will no honor max_statement_time.

          People

            bnestere Brandon Nesterenko
            valerii Valerii Kravchuk
            Votes:
            0 Vote for this issue
            Watchers:
            7 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.