Details
-
Bug
-
Status: Open (View Workflow)
-
Major
-
Resolution: Unresolved
-
10.6(EOL), 10.11, 11.4, 11.8, 12.3
-
Unexpected results
Description
The following test is for the MDEV-14992 branch:
--source include/have_innodb.inc
|
--source include/innodb_page_size.inc
|
--let $target=$MYSQL_TMP_DIR/backup
|
evalp BACKUP SERVER TO '$target'; |
--exec cat $MYSQLTEST_VARDIR/my.cnf >> $target/backup.cnf
|
--let $restart_noprint=1
|
--let $restart_parameters=--defaults-file=$target/backup.cnf --datadir=$target
|
--source include/restart_mysqld.inc
|
--error ER_OPEN_AS_READONLY
|
DROP TABLE mysql.innodb_table_stats; |
--let $restart_parameters=
|
--source include/restart_mysqld.inc
|
--rmdir $target |
The functions InnoDB_backup::backup() and InnoDB_backup::stream() assume that fil_node_t::size is set correctly to the number of pages.
Adding the following .opt file would make the test fail for innodb_page_size>16k:
--innodb-data-file-path=ibdata1:13M:autoextend |
2026-10-15 9:31:50 0 [ERROR] InnoDB: Tablespace size stored in header is 1232 pages, but the sum of data file sizes is 1216 pages
|
2026-10-15 9:31:50 0 [ERROR] InnoDB: Cannot start InnoDB. The tail of the system tablespace is missing. Have you edited innodb_data_file_path in my.cnf in an inappropriate way, removing data files from there? You can set innodb_force_recovery=1 in my.cnf to force a startup if you are trying to recover a badly corrupt database.
|
The reason is that FSP_EXTENT_SIZE is not 1MiB at larger file sizes. The following patch would seem to fix this. I did not test it with anything else:
diff --git a/storage/innobase/os/os0file.cc b/storage/innobase/os/os0file.cc
|
index 2ed5737eda9..d24a95fc1c1 100644
|
--- a/storage/innobase/os/os0file.cc
|
+++ b/storage/innobase/os/os0file.cc
|
@@ -3743,13 +3743,17 @@ bool fil_node_t::read_page0(const byte *dpage, bool no_lsn) noexcept
|
|
find_metadata();
|
/* Truncate the size to a multiple of extent size. */
|
- ulint mask= psize * FSP_EXTENT_SIZE - 1;
|
+ size_t mask{psize};
|
+ if (srv_page_size_shift <= 14 || !space->id)
|
+ mask<<= 20 - srv_page_size_shift/* 1 MiB in pages */;
|
+ else
|
+ mask<<= 6/* 64 pages */;
|
|
- if (size_bytes <= mask);
|
+ if (size_bytes < mask);
|
/* .ibd files start smaller than an
|
extent size. Do not truncate valid data. */
|
else
|
- size_bytes&= ~os_offset_t(mask);
|
+ size_bytes&= ~os_offset_t(mask - 1);
|
|
this->size= uint32_t(size_bytes / psize);
|
space->set_sizes(this->size); |
Note: I did not test this with a multi-file system tablespace.
One more strange thing is that at innodb_page_size=64k, the system tablespace is being extended unnecessarily, to 0x4d0 pages instead of the requested 0xd0 pages (13 MiB):
|
od -Ax -t x1 ibdata1 |
310080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|
*
|
31fff0 00 00 00 00 00 74 00 65 00 00 a1 f9 71 6f 91 ce
|
320000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|
*
|
4d00000
|
I don’t know if my patch above is the best way to fix this. It could make more sense to add some validation to innodb_data_file_path to ensure that each file covers an entire extent, and to adjust the granularity of innodb_autoextend_increment to 2MiB or 4MiB when innodb_page_size is larger than the default 16k.
We should also test what currently happens with multi-file system tablespaces where some files are not integer multiples of an extent.
Attachments
Issue Links
- relates to
-
MDEV-14992 BACKUP SERVER to mounted file system
-
- In Progress
-
