Details
-
Bug
-
Status: Closed (View Workflow)
-
Blocker
-
Resolution: Fixed
-
10.2(EOL), 10.3(EOL), 10.4(EOL), 10.5, 10.6
-
None
Description
InnoDB holds dict_sys mutex while doing file i/o operation during creation of table.
In fil_ibd_create():
if (ulint zip_size = fil_space_t::zip_size(flags)) {
|
page_zip_des_t page_zip;
|
page_zip_set_size(&page_zip, zip_size);
|
page_zip.data = page + srv_page_size;
|
#ifdef UNIV_DEBUG
|
page_zip.m_start = 0;
|
#endif /* UNIV_DEBUG */
|
page_zip.m_end = 0;
|
page_zip.m_nonempty = 0;
|
page_zip.n_blobs = 0;
|
|
|
buf_flush_init_for_writing(NULL, page, &page_zip, false);
|
|
|
*err = os_file_write(IORequestWrite, path, file,
|
page_zip.data, 0, zip_size);
|
} else {
|
buf_flush_init_for_writing(NULL, page, NULL,
|
fil_space_t::full_crc32(flags));
|
|
|
*err = os_file_write(IORequestWrite, path, file,
|
page, 0, srv_page_size);
|
}
|
|
|
if (!os_file_flush(file)) {
|
ib::error() << "File flush of tablespace '"
|
<< path << "' failed";
|
*err = DB_ERROR;
|
goto err_exit;
|
}
|
If we remove the page0 write and flushing the file then InnoDB should handle this scenario during recovery. Right now, InnoDB does the validation of page0 while parsing the FILE redo log records.
InnoDB should defer these tablespace as uninitialized if it encounters zero-filled page 0
and recover page0 of these tablespace before recovering any other pages of these tablespace. This is the idea right now. It could change when we're debuggging encrypted and compressed tablespace.
Attachments
Issue Links
- blocks
-
MDEV-14481 Execute InnoDB crash recovery in the background
-
- Closed
-
-
-
- Closed
-
- causes
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
- relates to
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Open
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
Activity
As far as I understand, there still are some recovery or backup failures that are related to this change.
The test innodb_fts,crash_recovery that was extended in MDEV-18518 revealed that this fix is not only a performance improvement but also a correctness fix, to make all DDL inside InnoDB truly crash-safe. The report MDEV-25646 basically duplicates what I have already seen in innodb_fts,crash_recovery,release. I enhanced Thiru’s work this week, so that it would survive all my mtr tests.
Some more changes are needed in mariabackup.