Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
10.5, 10.6, 10.7(EOL), 10.8(EOL), 10.9(EOL), 10.10(EOL), 10.11, 11.0(EOL), 11.1(EOL)
Description
The initial implementation of MDEV-8139 introduced a condition to prevent violations of the write-ahead-logging protocol:
static void buf_flush_freed_pages(fil_space_t *space) |
{
|
ut_ad(space != NULL);
|
if (!srv_immediate_scrub_data_uncompressed && !space->is_compressed()) |
return; |
lsn_t flush_to_disk_lsn= log_sys.get_flushed_lsn();
|
|
std::unique_lock<std::mutex> freed_lock(space->freed_range_mutex);
|
if (space->freed_ranges.empty() |
|| flush_to_disk_lsn < space->get_last_freed_lsn())
|
{
|
freed_lock.unlock();
|
return; |
}
|
But, there is no logic around log checkpoints that would ensure that all fil_space_t::freed_ranges will be scrubbed before the checkpoint is advanced.
The simplest fix would be to invoke log_write_up_to(flush_to_disk_lsn, true) while not holding any mutex. This should not incur much of a performance regression, given that this code is not enabled by default.
It would be very hard to create a regression test for this, because there is no easy way to control log writes, especially after improvements like MDEV-24341 and MDEV-27774. I found this bug while diagnosing MDEV-31234.
I checked failures of the test innodb.innodb_scrub on the CI system. The majority of them are related to hangs while waiting for all history to be purged. I did not find an example where scrubbing a data page would have been missed.
Attachments
Issue Links
- is caused by
-
MDEV-8139 Fix scrubbing
- Closed
- relates to
-
MDEV-31234 InnoDB does not free UNDO after the fix of MDEV-30671, thus shared tablespace (ibdata1) may grow indefinitely for no good reason
- Closed