Details
-
Bug
-
Status: In Review (View Workflow)
-
Major
-
Resolution: Unresolved
-
10.11, 11.4, 11.8, 12.3
-
Not for Release Notes
-
Q1/2026 Server Development
Description
While testing MDEV-37949, I encountered this bug that had originally been introduced in MDEV-34062.
While debugging this, I noticed that despite the MDEV-38730 fix, the setting innodb_log_file_mmap=ON probably does not work outside mariadb-backup, because log_t::attach() would refuse to invoke read-only mmap() in a normal server startup.
I reproduced this with a slightly modified test case:
diff --git a/mysql-test/suite/mariabackup/partition_partial.test b/mysql-test/suite/mariabackup/partition_partial.test
|
index 30e31a9d43e..6073e41ec72 100644
|
--- a/mysql-test/suite/mariabackup/partition_partial.test
|
+++ b/mysql-test/suite/mariabackup/partition_partial.test
|
@@ -23,7 +23,7 @@ INSERT INTO t1 VALUES (1), (101), (201), (301);
|
|
echo # xtrabackup prepare;
|
--disable_result_log
|
-exec $XTRABACKUP --defaults-file=$MYSQLTEST_VARDIR/my.cnf --defaults-group-suffix=.1 --prepare --export --target-dir=$targetdir;
|
+exec rr record $XTRABACKUP --defaults-file=$MYSQLTEST_VARDIR/my.cnf --defaults-group-suffix=.1 --prepare --export --target-dir=$targetdir --innodb-log-file-mmap;
|
--enable_result_log
|
|
|
|
mkdir /tmp/var && rm -fr mysql-test/var && ln -s /tmp/var mysql-test/var
|
_RR_TRACE_DIR=/dev/shm/rr mysql-test/mtr mariabackup.partition_partial
|
rr replay /dev/shm/rr/latest-trace
|
break log_t::clear_mmap
|
continue
|
break memcpy_aligned
|
finish
|
print/x buf[(flushed_to_disk_lsn-first_lsn+0x3000)&~(write_size-1)]@write_size
|
print/x log_block@write_size
|
The two commands should show the last block of the memory-mapped log buffer. However, the log_block will contain the log file header:
|
10.11 09657805d04dfe6dfe33fb4b3003e06b29c835bd |
(rr) finish
|
Run till exit from #0 memcpy_aligned<16ul> (dest=dest@entry=0x7ffdec5f0210, src=0x7f4a1389f000, n=n@entry=0x200)
|
at /mariadb/10.6/include/assume_aligned.h:40
|
log_t::clear_mmap (this=0x5624e12898c0 <log_sys>) at /mariadb/10.6/storage/innobase/log/log0log.cc:1260
|
1260 close_file(false);
|
Value returned is $9 = (void *) 0x7ffdec5f0210
|
(rr) print/x buf[(flushed_to_disk_lsn._M_i-first_lsn+0x3000)&~(write_size-1)]@write_size
|
$1 = {0x6, 0x78, 0x0, 0x80, 0x73, 0x0, 0xd5, 0xfb, 0x93, 0x5b, 0x77, 0x0, 0x0, 0x0, 0xae, 0x7, 0x0, 0x6, 0x1, 0x42, 0x62, 0xad, 0xc2, 0x39, 0x0, 0x33, 0x32,
|
0xff, 0xff, 0xff, 0xff, 0x0, 0x0, 0xb7, 0x0, 0xff, 0xff, 0xff, 0xff, 0x0, 0x0, 0x34, 0x0, 0x33, 0x31, 0x0, 0xc3, 0x16, 0x4, 0xff, 0xb3, 0x8f, 0x83, 0x21,
|
0x47, 0x0, 0x80, 0x73, 0xb6, 0xb2, 0x4, 0xff, 0x34, 0x0, 0x0, 0x3d, 0x34, 0x3, 0x0, 0x80, 0xb8, 0x35, 0x0, 0x0, 0x80, 0xdc, 0xeb, 0x48, 0x0, 0x80, 0x73,
|
0xb6, 0x72, 0x80, 0x40, 0x0, 0x77, 0x0, 0x33, 0x0, 0x73, 0xe3, 0x33, 0x7b, 0x78, 0x0, 0x80, 0x73, 0x0, 0x2a, 0x62, 0x27, 0x27, 0x77, 0x0, 0x0, 0x0, 0x1c,
|
0x60, 0xa, 0x43, 0x1, 0x42, 0x76, 0x6a, 0xe7, 0x39, 0x0, 0x34, 0x32, 0xff, 0xff, 0xff, 0xff, 0x0, 0x0, 0xb7, 0x0, 0xff, 0xff, 0xff, 0xff, 0x0, 0x0, 0x34,
|
0x0, 0x34, 0x31, 0x0, 0xc3, 0x16, 0x4, 0xff, 0xb3, 0x8f, 0x83, 0x21, 0x47, 0x0, 0x80, 0x73, 0xb7, 0x72, 0x4, 0xff, 0x34, 0x0, 0x0, 0x3d, 0x33, 0x3, 0x0,
|
0x80, 0xb9, 0x35, 0x0, 0x0, 0x80, 0xdc, 0xef, 0x48, 0x0, 0x80, 0x73, 0xb7, 0x32, 0x80, 0x40, 0x0, 0x77, 0x0, 0x34, 0x0, 0xe3, 0xc6, 0xd9, 0x4a, 0x78, 0x0,
|
0x80, 0x73, 0x0, 0x49, 0x18, 0xa7, 0xd, 0x77, 0x0, 0x0, 0x0...}
|
(rr) print *log_block@write_size
|
$2 = "Phys\000\000\000\000\000\000\000\000\000\000\316\305Backup 10.11.17", '\000' <repeats 477 times>...
|
In this run that I was debugging, we would never actually write anything to the redo log, so no damage was done. That is, neither log_t::append_prepare nor log_t::write_buf would be called.
Come to think of it, the reason is that FLUSH TABLES…FOR EXPORT, which this operation is internally invoking, will not actually change anything; it would only prevent the purge of transactions from running, and ensure that all changes have been written from the buffer pool back to the files. It will also create tablename.cfg files that may be used by a subsequent ALTER TABLE…IMPORT TABLESPACE operation.
Furthermore, if any write-ahead log ib_logfile0 were produced by this mariadb-backup invocation, it would not be supposed to be used for anything. The only intended usable artefact are the InnoDB tablespace files that are being exported.
While there is no sign of actual damage caused by this, I think that we should fix this dormant bug. This fix is necessary in MDEV-37949, where I have implemented innodb_log_file_mmap=ON based recovery for the innodb_log_archive=ON format.
Attachments
Issue Links
- is caused by
-
-
- Closed
-
- relates to
-
MDEV-37949 Implement innodb_log_archive
-
- In Progress
-