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

provide mechanism to monitor the status of dynamic redo log resize operation

Details

    • New Feature
    • Status: Open (View Workflow)
    • Major
    • Resolution: Unresolved
    • None
    • Server

    Description

      Currently, after changing the value of innodb_log_file_size using SET GLOBAL command, we dont have any mechanism to monitor the status (verified in 10.11.7).

      When we retry the operation when the operation is in progress, we receive below error:
      ERROR 1221 (HY000): innodb_log_file_size change is already in progress

      Provide a mechanism similar to below to monitor the status of the resizing operation available in mysql

      https://dev.mysql.com/doc/refman/8.4/en/server-status-variables.html#statvar_Innodb_redo_log_capacity_resized

      Attachments

        Issue Links

          relates to

          Task - A task that needs to be done. MDEV-27812 Allow innodb_log_file_size to change without server restart

          • Critical - Crashes, loss of data, severe memory leak.
          • Closed

          Bug - A problem which impairs or prevents the functions of the product. MDEV-34750 SET GLOBAL innodb_log_file_size is not crash safe

          • Critical - Crashes, loss of data, severe memory leak.
          • Closed

          Activity

            marko Marko Mäkelä added a comment -

            I was recently thinking about the same while working on MDEV-34750. Note that MDEV-34750 also fixed a bug where the buf_flush_page_cleaner() would fail to be woken up. That is, the log resizing might hang (using 100% of one CPU core) if there were not enough concurrent writes to InnoDB tables.

            I can think of a number of SET GLOBAL that could take a longer time to complete:

            • innodb_log_file_size (MDEV-27812; will wait until the log checkpoint has been advanced enough)
            • innodb_max_purge_lag_wait (MDEV-16952; a dummy assignment, will wait until the history list length is below the specified limit)
            • innodb_max_dirty_pages_pct (it could make sense for it to block until the limit is reached)
            • innodb_buffer_pool_size (in MDEV-29445 I would like it to block until the size has been changed)

            Maybe there should be a variant of the SET GLOBAL statement that would enable the use of the https://mariadb.com/kb/en/progress-reporting/ interface.

            marko Marko Mäkelä added a comment - I was recently thinking about the same while working on MDEV-34750 . Note that MDEV-34750 also fixed a bug where the buf_flush_page_cleaner() would fail to be woken up. That is, the log resizing might hang (using 100% of one CPU core) if there were not enough concurrent writes to InnoDB tables. I can think of a number of SET GLOBAL that could take a longer time to complete: innodb_log_file_size ( MDEV-27812 ; will wait until the log checkpoint has been advanced enough) innodb_max_purge_lag_wait ( MDEV-16952 ; a dummy assignment, will wait until the history list length is below the specified limit) innodb_max_dirty_pages_pct (it could make sense for it to block until the limit is reached) innodb_buffer_pool_size (in MDEV-29445 I would like it to block until the size has been changed) Maybe there should be a variant of the SET GLOBAL statement that would enable the use of the https://mariadb.com/kb/en/progress-reporting/ interface.

            People

              Unassigned Unassigned
              vidyadhar.chelluru vidyadhar
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

                Created:
                Updated:

                Git Integration

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