Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
11.8
-
None
-
Unexpected results
Description
The InnoDB system tablespace (ibdata1) fails to autoshrink even
though it is almost entirely free. The error log shows the
defragmentation/shrink attempt running and reporting success, but no
space is reclaimed:
InnoDB: System tablespace defragmentation process starts
|
InnoDB: Moving the data from extent <N> to extent <M>
|
InnoDB: Defragmentation of system tablespace is successful
|
InnoDB: Cannot shrink the system tablespace; there is not much space
|
to reclaim (last used extent=<N+64>, fixed size=..., header size=<N+64>
|
Root cause:
=========
fsp_traverse_extents() (find-last-used mode) determines the
high-water mark by descending from the end of the file, treating an
extent as "above the high-water mark" only if it is XDES_FREE, or
the descriptor-page extent (XDES_FREE_FRAG with n_used == 2). Any
other XDES_FREE_FRAG extent makes it stop.
An XDES_FREE_FRAG extent with zero used pages can legitimately exist
on disk e.g. as a leftover from MDEV-31333 (fsp_free_page() fails to move
the extent from FSP_FREE_FRAG to FSP_FREE list). Such an
empty fragment extent at the tail is mistaken for a used extent, so
the high-water mark is pinned at the end of the file and the shrink
reclaims nothing, even though the extent holds no data pages)
Attachments
Issue Links
- relates to
-
MDEV-31333 fsp_free_page() fails to move the extent from FSP_FREE_FRAG to FSP_FREE list
-
- Closed
-