XtraBackup thinks 2 TB ibdata file should have wrong number of pages

[Geoff Montee]

A user running MySQL 5.5.27 is using ext3 for their database partition. Since ext3 has a 2 TB limit for maximum file size, they have the following configured:

innodb_data_file_path = ibdata01:2194719883264;ibdata02:50M:autoextend

When trying to back up this database with XtraBackup 2.3.5 and 2.2.13, they see errors like the following:

xtrabackup: open files limit requested 0, set to 100000
xtrabackup: using the following InnoDB configuration:
xtrabackup: innodb_data_home_dir = /datadir/data
xtrabackup: innodb_data_file_path = ibdata01:2194719883264;ibdata02:50M:autoextend
xtrabackup: innodb_log_group_home_dir = /datadir/logs
xtrabackup: innodb_log_files_in_group = 3
xtrabackup: innodb_log_file_size = 268435456
161004 12:25:09 >> log scanned up to (23030000474880)
InnoDB: Data file /datadir/data/ibdata01 is of a different size 133955071 pages (rounded down to MB) than specified
in the .cnf file 133955008 pages!
xtrabackup: Could not open or create data files.

From some simple math, it does look like the file has the proper number of pages:

2194719883264 bytes / 16384 bytes/page = 133955071 pages

I'm not sure why XtraBackup thinks the file should have 133955008 pages instead. Is this related to ext3's maximum file size, or is this a bug in XtraBackup?

[Geoff Montee (geoff-montee)]

To provide additional information, this user says that they were running innobackupex in the following way:

innobackupex --defaults-file=/etc/my.cnf \
--no-timestamp \
--use-memory=2G \
--user=backup_user \
--password=******** \
--databases="db1 db2 db3 mysql" \
--stream=xbstream \
--parallel=4 \
--compress \
--compress-threads=4 \
--history=$(date +%d-%m-%Y) ./ > \
mysqlbackup$(date +%d-%m-%Y).qp.xbc.xbs 2> \
backup-progress.log &

[Geoff Montee (geoff-montee)]

The user reported that reverting to XtraBackup 2.1.9 allowed their backup to work properly. Should XtraBackup 2.2 and 2.3 be fully compatible with MySQL 5.5, or should MySQL 5.5 users need to use XtraBackup 2.1 in some cases?

[Sergei Glushchenko (sergei.glushchenko)]

What is the actual ibdata01 size? InnoDB and xtrabackup expect its size to be multipe of 1M. The size specified in .cnf is not (2194719883264/1024.0/1024.0=2093047.984375)

[Geoff Montee (geoff-montee)]

The size of the ibdata1 file is the exact size size mentioned in the configuration file:

-rw-rw---- 1 mysql mysql 2194719883264 Oct 4 12:42 ibdata01
-rw-rw---- 1 mysql mysql 6629097472 Jun 13 19:03 ibdata02

If this size is unsupported by InnoDB and XtraBackup, do you have any idea why MySQL 5.5 and XtraBackup 2.1 have no problem with the file?

[Sergei Glushchenko (sergei.glushchenko)]

Probably 5.5 did not check the size... Here is from https://dev.mysql.com/doc/refman/5.5/en/innodb-parameters.html#sysvar_innodb_data_file_path:

The file sizes are specified KB, MB or GB (1024MB) by appending K, M or G to the size value. If specifying data file size in kilobytes (KB), do so in multiples of 1024. Otherwise, KB values are rounded off to nearest megabyte (MB) boundary.

and https://dev.mysql.com/doc/refman/5.5/en/innodb-resize-system-tablespace.html:

If the previous last data file is defined with the keyword autoextend, change its definition to use a fixed size, based on how large it has actually grown. Check the size of the data file, round it down to the closest multiple of 1024 × 1024 bytes (= 1MB), and specify this rounded size explicitly in innodb_data_file_path.

So, you can try to round the value as described above

[Shahriyar Rzayev (rzayev-sehriyar)]

Percona now uses JIRA for bug reports so this bug report is migrated to: https://jira.percona.com/browse/PXB-1404