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

Non-blocking "set read_only"

Details

    • Task
    • Status: Closed (View Workflow)
    • Major
    • Resolution: Fixed
    • 5.3.8
    • None

    Description

      It can be dangerous to run "set read_only" on a production server because it can block in close_cached_tables. More details about the pain this caused previously are at:
      http://mysqlha.blogspot.com/2008/07/what-exactly-does-flush-tables-with.html

      Per the code in set_var.cc:

       /*
      		 
          Perform a 'FLUSH TABLES WITH READ LOCK'.
      		 
          This is a 3 step process:
      		 
          - [1] lock_global_read_lock()
      		 
          - [2] close_cached_tables()
      		 
          - [3] make_global_read_lock_block_commit()
      		 
          [1] prevents new connections from obtaining tables locked for write.
      		 
          [2] waits until all existing connections close their tables.
      		 
          [3] prevents transactions from being committed.
      		 
        */

      Can there be a variant that doesn't do #2? My workload doesn't use MyISAM and I don't know if #2 is done because of MyISAM. Calling close_cached_tables seems like a heavy way to force LOCK TABLEs to be unlocked. Any long running queries will cause #2 to block.

      See also http://lists.mysql.com/commits/142825

      Attachments

        Issue Links

          relates to

          Task - A task that needs to be done. MDEV-309 reimplement FLUSH ... CHECKPOINT

          • Minor - Minor loss of function, or other problem where easy workaround is present.
          • Open

          Activity

            Ascending order - Click to sort in descending order
            View 5 older comments
            mdcallag Mark Callaghan added a comment -

            Will "refresh_version" still be incremented in this case? And if yes, then doesn't that create a significant performance impact by forcing all InnoDB table instances to be reopened?

            mdcallag Mark Callaghan added a comment - Will "refresh_version" still be incremented in this case? And if yes, then doesn't that create a significant performance impact by forcing all InnoDB table instances to be reopened?
            monty Michael Widenius added a comment -

            We can skip incrementing refresh_version for the case of
            set readonly=1

            The reason we increment refresh_version is to ensure that we will close any old instances of the table and read the possible new table definition (that may have changed during FLUSH TABLES).
            This is not needed when setting readonly.

            monty Michael Widenius added a comment - We can skip incrementing refresh_version for the case of set readonly=1 The reason we increment refresh_version is to ensure that we will close any old instances of the table and read the possible new table definition (that may have changed during FLUSH TABLES). This is not needed when setting readonly.
            holyfoot Alexey Botchkov added a comment -

            Patch committed
            http://lists.askmonty.org/pipermail/commits/2012-May/003284.html

            holyfoot Alexey Botchkov added a comment - Patch committed http://lists.askmonty.org/pipermail/commits/2012-May/003284.html
            ratzpo Rasmus Johansson (Inactive) added a comment -

            As agreed with Monty, please review this

            ratzpo Rasmus Johansson (Inactive) added a comment - As agreed with Monty, please review this
            holyfoot Alexey Botchkov added a comment -

            New patch committed:
            http://lists.askmonty.org/pipermail/commits/2012-May/003324.html

            holyfoot Alexey Botchkov added a comment - New patch committed: http://lists.askmonty.org/pipermail/commits/2012-May/003324.html

            People

              holyfoot Alexey Botchkov
              ratzpo Rasmus Johansson (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              5 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.