RENAME/DROP crashes with innodb_track_changed_pages
|Percona Server||Status tracked in 5.6|
The redo log reading code has been chaned in 5.5.30 with
Part of the change is that on MLOG_FILE_RENAME events the
also applys the rename operation.
This can lead to InnoDB assertion failures if:
* a table is renamed
* and is dropped shortly after
The assertion messages are:
InnoDB: Error: cannot find space id ### in the tablespace memory cache
InnoDB: though the table '(name not specified)' in a rename operation should have that id
InnoDB: Assertion failure in thread ### in file fil0fil.c line 2248
The related backtrace looks like this:
The important part of the InnoDB change is:
+ case MLOG_FILE_RENAME:
+ ptr = fil_op_
+ space_id, 0);
- case MLOG_FILE_RENAME:
ptr = fil_op_
which causes MLOG_FILE_RENAME events to be replayed when
the page change cache parses the logs. Now what can happen is
that a table gets renamed and then dropped shortly afterwards.
As the page change tracking thread reads the redo log with a
slight delay it may only end up reaching the RENAME event at
about the time when the DROP happens.
Now if this happens at just the "right" time then
exists, then check for fil_get_
right after it has been dropped, and comes to the wrong
conclusion that the rename has not happened yet and
needs to be recovered/redone. Then next it tries
table no longer exists and eventually the
cannot find space id ### in the tablespace memory cache
assertion is raised.
So actually a bug introduced by Oracle, but I'm reporting it
here only for now as it only affects the Percona page change
feature but has probably no negative effect on upstream
MySQL itself as the log parsing code is only used for crash
recovery or ibbackup postprocessing and never has to deal
with other DB activity going on in parallel ...
- RENAME/DROP crashes 5.5.30+ with innodb_track_changed_pages
+ RENAME/DROP crashes with innodb_track_changed_pages