Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
10.2(EOL), 10.3(EOL), 10.4(EOL), 10.5, 10.6
Description
InnoDB is not checking that the page number in a buffer pool page is correct. The following would implement such a check:
diff --git a/storage/innobase/mtr/mtr0mtr.cc b/storage/innobase/mtr/mtr0mtr.cc
|
--- a/storage/innobase/mtr/mtr0mtr.cc
|
+++ b/storage/innobase/mtr/mtr0mtr.cc
|
@@ -1196,6 +1196,8 @@ void mtr_t::page_lock(buf_block_t *block, ulint rw_latch)
|
#endif /* BTR_CUR_HASH_ADAPT */
|
|
done:
|
+ ut_ad(page_id_t(page_get_space_id(block->page.frame),
|
+ page_get_page_no(block->page.frame)) == block->page.id());
|
memo_push(block, fix_type);
|
}
|
|
This would be tripped in a number of tests that inject corruption to data files. Those tests will have to be adjusted.
Furthermore, operations like DROP TABLE need to be fixed so that they will not attempt to load the table definition at all. This would avoids a crash in a test that corrupts the clustered index root page number of a table. The following fix for that test would be needed in any case:
diff --git a/mysql-test/suite/innodb/t/page_id_innochecksum.test b/mysql-test/suite/innodb/t/page_id_innochecksum.test
|
index 2726b3254da..f5166018dd1 100644
|
--- a/mysql-test/suite/innodb/t/page_id_innochecksum.test
|
+++ b/mysql-test/suite/innodb/t/page_id_innochecksum.test
|
@@ -61,5 +61,9 @@ let SEARCH_PATTERN=page id mismatch;
|
--source include/search_pattern_in_file.inc
|
|
--remove_file $resultlog
|
+# prevent purge from crashing on page ID mismatch
|
+let $restart_parameters=--innodb-force-recovery=2;
|
--source include/start_mysqld.inc
|
drop table t1;
|
+let $restart_parameters=;
|
+--source include/restart_mysqld.inc |
Attachments
Issue Links
- relates to
-
MDEV-12434 Database page corruptions
-
- Closed
-
-
MDEV-26966 The parameter innodb_force_load_corrupted makes no sense
-
- Closed
-
-
MDEV-31347 fil_ibd_create() may hijack the file handle of an old file
-
- Closed
-
I slightly revised this based on a test with a data directory that was archived for
MDEV-25683. That test case would still cause a hang of the DDL log recovery if the server is started up with innodb_force_recovery=4. My aim was to get rid of these useless messages, which would be output because rollback of a recovered DDL transaction was disabled by innodb_force_recovery=4:2021-05-15 1:39:58 0 [ERROR] InnoDB: Trying to load index `PRIMARY` for table `test`.`#sql-alter-27122f-10`, but the index tree has been freed!
2021-05-15 1:39:58 0 [Note] InnoDB: Index is corrupt but forcing load into data dictionary
While cleaning up the code, I realized that the InnoDB DDL rewrite in MariaDB Server 10.6 made obsolete the read-only startup parameter innodb_force_load_corrupted. I think that we should deprecate and ignore that parameter, and remove it in later versions.