[MDEV-31389] ibdata1 grows when .idb files are moved to another disk Created: 2023-06-02  Updated: 2023-07-23  Resolved: 2023-07-23

Status: Closed
Project: MariaDB Server
Component/s: Storage Engine - InnoDB
Affects Version/s: 10.11.3
Fix Version/s: N/A

Type: Bug Priority: Minor
Reporter: Christian Rishøj Assignee: Unassigned
Resolution: Incomplete Votes: 0
Labels: None
Environment:

Ubuntu 22.04.2 on Linux 5.15.0

Issue Links:
Relates
relates to MDEV-31234 InnoDB does not free UNDO after the f... Closed

 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.

 Comments   
Comment by Marko Mäkelä [ 2023-06-02 ]

This could be a duplicate of MDEV-31234.

Comment by Christian Rishøj [ 2023-06-02 ]

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?

Comment by Christian Rishøj [ 2023-06-02 ]

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

Comment by Marko Mäkelä [ 2023-06-02 ]

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).

Comment by Sergei Golubchik [ 2023-06-25 ]

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

Generated at Thu Feb 08 10:23:30 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.