MDEV-13267 At startup with crash recovery: mtr_t::commit_checkpoint(lsn_t,...
MDEV-13267 At startup with crash recovery: mtr_t::commit_checkpoint(lsn_t, bool): Assertion `!recv_no_log_write' failed This is a bogus debug assertion failure that should be possible starting with MariaDB 10.2.2 (which merged WL#7142 via MySQL 5.7.9). While generating page-change redo log records is strictly out of the question during tat certain parts of crash recovery, the fil_names_clear() is only emitting informational MLOG_FILE_NAME and MLOG_CHECKPOINT records to guarantee that if the server is killed during or soon after the crash recovery, subsequent crash recovery will be possible. The metadata buffer that fil_names_clear() is flushing to the redo log is being filled by recv_init_crash_recovery_spaces(), right before starting to apply redo log, by invoking fil_names_dirty() on every discovered tablespace for which there are changes to apply. When it comes to Mariabackup (xtrabackup --prepare), it is strictly out of the question to generate any redo log whatsoever, because that could break the restore of incremental backups by causing LSN deviation. So, the fil_names_dirty() call must be skipped when restoring backups. recv_recovery_from_checkpoint_start(): Do not invoke fil_names_clear() when restoring a backup. mtr_t::commit_checkpoint(): Remove the failing assertion. The only caller is fil_names_clear(), and it must be called by recv_recovery_from_checkpoint_start() for normal server startup to be crash-safe. The debug assertion in mtr_t::commit() will still catch rogue redo log writes.
Showing
Please register or sign in to comment