--rebuild-indexes holds on to disk space during --prepare

Reported by Matt on 2013-01-31
14
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Percona XtraBackup
Status tracked in 2.2
2.1
High
Alexey Kopytov
2.2
High
Alexey Kopytov

Bug Description

After doing a --compact backup with xtrabackup I was doing a --prepare --rebuild-indexes, and found that the temporary files that are created (.ibd.tmp) during the expanding phase are deleted but not flushed from disk. This means that in order to do a --prepare of the backup, you need the entire size of the backup free on disk on top of the backup itself (and expanded tables), which may be unmaintainable for very large backups.

As the tables are expanded individually then the temporary file deleted, can these deleted temporary files not be flushed so as to free the disk space they use immediately?

Alexey Kopytov (akopytov) wrote :

Temporary files are renamed to original .ibd files after they are expanded. Which means disk space occupied by original files should be reclaimed. So I'm not sure I understand the problem.

Changed in percona-xtrabackup:
status: New → Incomplete
Matt (whereswardy) wrote :

Basically what I see in lsof is a lot of:

/backup/path/mysql/database/table1.ibd
/backup/path/mysql/database/table1.ibd.tmp (deleted)

These files don't appear on disk, but they do consume space as they're deleted, unflushed files. So what's actually shown in the directory by `ls` is:

/backup/path/mysql/database/table1.ibd 90GB

But what's actually using up disk would be:

/backup/path/mysql/database/table1.ibd 90GB
/backup/path/mysql/database/table1.ibd.tmp 90GB <- (this is a deleted file)

All of these deleted files are shown as being owned and not flushed by the xtrabackup process.

I'll run another backup today so I can get some actual output from the terminal.

Launchpad Janitor (janitor) wrote :

[Expired for Percona XtraBackup because there has been no activity for 60 days.]

Changed in percona-xtrabackup:
status: Incomplete → Expired
Alexey Kopytov (akopytov) wrote :

The same problem has been reported as bug #1214537. I now see where the problem comes from.

Changed in percona-xtrabackup:
status: Expired → Triaged
importance: Undecided → High
assignee: nobody → Alexey Kopytov (akopytov)
milestone: none → future-2.1-releases
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers