mirror of
https://github.com/MariaDB/server.git
synced 2025-07-26 13:15:00 +02:00
42f657cd2f
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. |
||
|---|---|---|
| .. | ||
| log0crypt.cc | ||
| log0log.cc | ||
| log0recv.cc | ||