Redundant DB_TABLESPACE_DELETED handling for crash recovery page reads

[Laurynas Biveinis]

XtraDB and XtraBackup patch buf_read_page_low() and buf_read_recv_pages() to handle DB_TABLESPACE_DELETED error for the data page reads during recovery by looping over the hashed log recs and removing any belonging to this tablespace. This patch has been sent upstream as http://bugs.mysql.com/bug.php?id=43948.

I believe this patch is not required anymore, or never was required in the first place. It is possible that it appeared to be required for XtraBackup before the recent data dictionary handling improvements.

[10 Feb 11:13] Laurynas Biveinis
I don't see how the described situation may ever occur, at least with the current trunks. The patch handles the situation of recovery trying to read a page from a deleted tablespace into the buffer pool. But recovery initializes the fil_space structures by looking at the actual ibds on the disk (fil_load_single_table_tablespaces()) and log records are only stored to the recovery hash table if the tablespace is found to exist at the log parse time (recv_add_to_hash_table() calls fil_tablespace_deleted_or_being_deleted_in_mem()).

Thus a tablespace should somehow disappear between the fil_load_single_table_tablespaces() and some recv_add_to_hash_table() call with a redo log rec for that tablespace. One way for this to happen would be to replay a MLOG_FILE_DELETE, but these aren't replayed during the crash recovery, and even if there is such rec in the redo log, its corresponding ibd is already deleted, meaning that fil_load_single_table_tablespaces() would not load it in the first place.

I'd replace the Yasufumi's patch with something like
ut_ad(!recv_recovery_is_on() || *err != DB_TABLESPACE_DELETED);
to be sure.

[Laurynas Biveinis (laurynas-biveinis)]

5.6 affected too, the original patch is already merged there.

[Alexey Kopytov (akopytov)]

As comment #1 mentions, the code is already in 5.6. So it applies to 5.6 as well?

[Laurynas Biveinis (laurynas-biveinis)]

This is correct, sorry.

[Laurynas Biveinis (laurynas-biveinis)]

This handling is very much non-redundant for XtraBackup, as MLOG_FILE_DELETE is indeed replayed there.

See bug 1079700 fix description at https://code.launchpad.net/~akopytov/percona-xtrabackup/bug1079700-2.0/+merge/162926 [1].

However, it raises the question of why the existing handling of treating recovery updates to deleted tablespaces in buf_read_page_low() was not enough for bug 1079700 purposes. This question is best discussed there.

Marking this bug as invalid for XtraBackup. It is still valid for Percona Server.

[1]
"Another change necessitated by the patch is ignoring deleted tablespaces
on recovery, which has been implemented in XB patches to
recv_apply_hashed_log_recs(). After MLOG_FILE_DELETE is replayed on
recovery and the underlying file is deleted, possible updates to the
same tablespace done before deleting the tablespace are left in the redo
log. They will be ignored by the recovery code. This can never cause any
problems for server, because file creation/removal is done immediately,
so on recovery InnoDB detects missing tablespace files and does not the
corresponding log records to the hash table (see the first lines in
recv_add_to_hash_table). The situation is different with XtraBackup: the
underlying file will be present when recovery starts, but then get
deleted when MLOG_FILE_DELETE is replayed, i.e. after all log records
from the current batch have been added to the hash table. As a result,
log records corresponding to the deleted tablespace are ignore, but are
still left in the hash table, so recv_apply_hashed_log_recs() hangs
forever waiting for recv_sys->n_addrs to become zero. This was also
possible with XtraBackup before this fix, i.e. when a tablespace is
removed after it has been copied by XtraBackup. This fix just makes this
condition more likely to occur, as we always copy all tablespaces rather
than ignore those removed before the copy operation is tarted.

To fix the above case, we also check for deleted tablespaces in
recv_apply_hashed_log_recs(). Those corresponding to previously deleted
tablespaces are marked as processed and recv_sys->n_addrs is decremented
accordingly to not leave spurious unprocessed log records in the hash
table."

[Laurynas Biveinis (laurynas-biveinis)]

https://github.com/percona/percona-server/pull/1805

[Shahriyar Rzayev (rzayev-sehriyar)]

Percona now uses JIRA for bug reports so this bug report is migrated to: https://jira.percona.com/browse/PXB-105

[Shahriyar Rzayev (rzayev-sehriyar)]

Percona now uses JIRA for bug reports so this bug report is migrated to: https://jira.percona.com/browse/PS-2404