MDEV-34156 InnoDB fails to apply the redo log for compressed tablespace #3254
Conversation
|
|
storage/innobase/log/log0recv.cc
Outdated
| /* Add the freed page ranges in the respective | ||
| tablespace */ | ||
| if (!rs.second.freed_ranges.empty() | ||
| tablespace only if InnoDB doesn't need to | ||
| rescan the redo logs */ | ||
| if (!rescan | ||
| && !rs.second.freed_ranges.empty() | ||
| && (srv_immediate_scrub_data_uncompressed | ||
| || rs.second.space->is_compressed())) { |
There was a problem hiding this comment.
Based on this code change, this has something to do with page_compressed=1 tables, and possibly also with innodb_immediate_scrub_data_uncompressed=ON.
Problem: ======= During recovery, InnoDB fails to apply the redo log for compressed tablespace. The reason is that InnoDB assumes that pages has been freed while applying the redo log for it. InnoDB does multiple scan due to small buffer pool size. Problematic page has been freed and reinitialize multiple times. InnoDB stores the freed page information before it ran out of memory. But InnoDB assigns the freed page ranges to tablespace in recv_init_crash_recovery_spaces() even though InnoDB doesn't have complete freed range information. Solution: ======== Store the freed page information irrespective of the InnoDB redo log memory.
Thirunarayanan
force-pushed
the
10.5-MDEV-34156
branch
from
af5be3d
to
51e0192
Compare
There was a problem hiding this comment.
Thank you! This is tricky to review, because I was not able to reproduce this on my own system, no matter what I tried. On the shared environment where this was reproduced in the first place, I debugged the recovery of the data directory whose copy is attached to MDEV-34156, with and without the fix. The problem was that store_freed_or_init_rec was not being called on the BLOB page 0x2c:5 in the function with the template parameter store=false.
Unfortunately, this patch turns out to be an exact reversion of 941af1f (MDEV-31803). We need to understand this scenario better and revise the fix accordingly.
A possible answer is that the previous fix was incorrect, and something needs to be adjusted for the immediate_scrub_data_uncompressed=ON case elsewhere.
Description
Problem:
InnoDB assumes that pages has been freed while applying the redo log for it. InnoDB does multiple scan due to small buffer pool size. Problematic page has been freed and reinitialize multiple times. InnoDB stores the freed page information before it ran out of memory.
But InnoDB assigns the freed page ranges to tablespace in recv_init_crash_recovery_spaces() even though
InnoDB doesn't have complete freed range information.
Solution:
Store the freed page information irrespective of the InnoDB redo log memory.
Basing the PR against the correct MariaDB version
PR quality check