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

ibdata1 grows when .idb files are moved to another disk

Details

    • Bug
    • Status: Closed (View Workflow)
    • Minor
    • Resolution: Incomplete
    • 10.11.3
    • N/A
    • Storage Engine - InnoDB
    • None
    • Ubuntu 22.04.2 on Linux 5.15.0

    Description

      We have an installation with data directory residing on a disk which is close to being full.

      To make space available, we have moved some huge .ibd files to another disk, with a symlink from the the data directory.

      While this does free up disk space immediately, we have observed that over the course days, the ibdata1 file grows proportionally to the size of the .idb files that were moved, effectively cancelling out the attempt to free up disk space.

      We're wondering if this is expected behavior.

      Attachments

        Issue Links

          relates to

          Bug - A problem which impairs or prevents the functions of the product. MDEV-31234 InnoDB does not free UNDO after the fix of MDEV-30671, thus shared tablespace (ibdata1) may grow indefinitely for no good reason

          • Blocker - Blocks development and/or testing work, production could not run.
          • Closed

          Activity

            Ascending order - Click to sort in descending order
            marko Marko Mäkelä added a comment -

            This could be a duplicate of MDEV-31234.

            marko Marko Mäkelä added a comment - This could be a duplicate of MDEV-31234 .
            crishoj Christian Rishøj added a comment -

            Aha, sounds like it may not be related to symlinking at all.

            Could the workaround you mention on https://jira.mariadb.org/browse/MDEV-31234?focusedCommentId=260198&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-260198 be a possible temporary workaround?

            crishoj Christian Rishøj added a comment - Aha, sounds like it may not be related to symlinking at all. Could the workaround you mention on https://jira.mariadb.org/browse/MDEV-31234?focusedCommentId=260198&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-260198 be a possible temporary workaround?
            crishoj Christian Rishøj added a comment - - edited

            Out of curiosity, I ran `innochecksum` on `ibdata1`, but got the following:

            > sudo innochecksum -S ibdata1
            		 
            Fail: page::13 invalid
            		 
            Exceeded the maximum allowed checksum mismatch count::1 current::0

            crishoj Christian Rishøj added a comment - - edited Out of curiosity, I ran `innochecksum` on `ibdata1`, but got the following: > sudo innochecksum -S ibdata1 Fail: page::13 invalid Exceeded the maximum allowed checksum mismatch count::1 current::0
            marko Marko Mäkelä added a comment -

            The MDEV-31234 debugging that I did with innochecksum and innodb_immediate_scrub_data_uncompressed=ON is not something that I would recommend to normal users. It was my way of creating an execution trace of a minimal run, so that I would find and understand the exact root cause.

            I am sorry, but there is no workaround. I believe that it would trigger more easily when there are more connections writing concurrently to InnoDB tables.

            Unscheduled releases containing a fix should be available soon. They will not allow affected users to reclaim the space that the orphaned undo log pages would occupy in the system tablespace. For now, the only way to reclaim the space will be to export all InnoDB tables and import them into a new server instance. I would recommend setting innodb_undo_tablespaces when initializing a new server. The default was changed to innodb_undo_tablespaces=3 in MDEV-29986 (MariaDB Server 11.0).

            marko Marko Mäkelä added a comment - The MDEV-31234 debugging that I did with innochecksum and innodb_immediate_scrub_data_uncompressed=ON is not something that I would recommend to normal users. It was my way of creating an execution trace of a minimal run, so that I would find and understand the exact root cause. I am sorry, but there is no workaround. I believe that it would trigger more easily when there are more connections writing concurrently to InnoDB tables. Unscheduled releases containing a fix should be available soon. They will not allow affected users to reclaim the space that the orphaned undo log pages would occupy in the system tablespace. For now, the only way to reclaim the space will be to export all InnoDB tables and import them into a new server instance. I would recommend setting innodb_undo_tablespaces when initializing a new server. The default was changed to innodb_undo_tablespaces=3 in MDEV-29986 (MariaDB Server 11.0).
            serg Sergei Golubchik added a comment -

            please, see if the latest release solves the problem for you

            serg Sergei Golubchik added a comment - please, see if the latest release solves the problem for you

            People

              Unassigned Unassigned
              crishoj Christian Rishøj
              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.