Details
-
Bug
-
Status: In Review (View Workflow)
-
Critical
-
Resolution: Unresolved
-
10.6, 10.11, 11.4, 11.8, 12.3, 13.0
-
Can result in unexpected behaviour
-
Q3/2026 Server Development
Description
The data directory in data.tar.xz
in the MDEV-37949 (innodb_log_archive=ON) format fails to recover:
tar xJf data.tar.xz
|
sql/mariadbd --innodb-page-size=8192 --datadir="$PWD"/data
|
|
13.0 1a4bb1bbfde5fa17ba148cb62678902f11c66a1a |
2026-08-11 12:50:42 0 [Note] InnoDB: Starting crash recovery from checkpoint LSN=1034042
|
2026-08-11 12:50:42 0 [Note] InnoDB: Ignoring data file './test/#sql-alter-1148a1-13-1f.ibd' with space ID 147. Another data file called ./test/t1.ibd exists with the same space ID.
|
2026-08-11 12:50:42 0 [Note] InnoDB: Ignoring data file './test/#sql-ib181.ibd' with space ID 147. Another data file called ./test/t1.ibd exists with the same space ID.
|
2026-08-11 12:50:42 0 [Note] InnoDB: End of log at LSN=1153119
|
2026-08-11 12:50:42 0 [ERROR] InnoDB: Tablespace 171 was not found at ./test/#sql-alter-1148a1-13-22.ibd.
|
2026-08-11 12:50:42 0 [Note] InnoDB: Set innodb_force_recovery=1 to ignore this and to permanently lose all changes to the tablespace.
|
2026-08-11 12:50:42 0 [ERROR] InnoDB: Plugin initialization aborted at srv0start.cc[1603] with error Tablespace not found
|
2026-08-11 12:50:42 0 [Note] InnoDB: Starting shutdown...
|
2026-08-11 12:50:42 0 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
|
For the tablespace 171, the log file contains a FILE_MODIFY record followed by FILE_CREATE as well as a FILE_RENAME record that is renaming the file to t1.ibd. The file is missing from the data directory, which was created by a development version of MDEV-14992. However, log-based recovery should be possible.
Note: While mariadb-backup currently copies InnoDB files that had been created and renamed by DDL operations during the backup, this should be unnecessary, because all the information for restoring the contents of the files is included in the copied write-ahead-log file. The BACKUP SERVER implementation that is being developed in MDEV-14992 is omitting such data files.
The following patch allows crash recovery to run into completion:
diff --git a/storage/innobase/log/log0recv.cc b/storage/innobase/log/log0recv.cc
|
index 46c2704bc50..ba86d8f1f66 100644
|
--- a/storage/innobase/log/log0recv.cc
|
+++ b/storage/innobase/log/log0recv.cc
|
@@ -1256,7 +1256,7 @@ static void fil_name_process(const char *name, ulint len, uint32_t space_id,
|
}
|
|
ut_ad(f.space == NULL);
|
- goto reset_create;
|
+ f.create_lsn = 0;
|
} else if (p.second // the first FILE_MODIFY or FILE_RENAME
|
|| f.name != fname.name) {
|
reload:
|
@@ -1382,8 +1382,6 @@ static void fil_name_process(const char *name, ulint len, uint32_t space_id,
|
" due to innodb_force_recovery",
|
int(len), name, space_id);
|
}
|
-reset_create:
|
- f.create_lsn = 0;
|
} else if (ftype == FILE_CREATE && !f.space) {
|
f.create_lsn = lsn;
|
} |
This logic was last changed in MDEV-38026. I don’t see any valid reason why we should reset the file_name_t::create_lsn when encountering a FILE_RENAME record. Doing so will cause a failure to recover a backup that could have been recoverable.
The above patch is insufficient; an attempt to access the table would result in an error:
2026-08-11 13:21:35 3 [ERROR] InnoDB: Expected tablespace id 171 but found 147 in the file ./test/t1.ibd
|
Attachments
Issue Links
- blocks
-
MDEV-14992 BACKUP SERVER to mounted file system
-
- In Review
-
- relates to
-
-
- Closed
-
-
-
- In Progress
-
