diff options
| author | Srinidhi Kaushik <shrinidhi.kaushik@gmail.com> | 2021-04-01 15:03:59 +0530 |
|---|---|---|
| committer | Marko Mäkelä <marko.makela@mariadb.com> | 2021-04-01 13:34:40 +0300 |
| commit | 5bc5ecce081d235ac6faed0e22885b3a22e6edee (patch) | |
| tree | 10b7fc94665651c29939ef7124fe816660032298 /storage | |
| parent | f93e087d745a0c24e30aa144c0f9d34fa042e21b (diff) | |
| download | mariadb-git-5bc5ecce081d235ac6faed0e22885b3a22e6edee.tar.gz | |
MDEV-24197: Add "innodb_force_recovery" for "mariabackup --prepare"
During the prepare phase of restoring backups, "mariabackup" does
not seem to allow (or recognize) the option "innodb_force_recovery"
for the embedded InnoDB server instance that it starts.
If page corruption observed during page recovery, the prepare step
fails. While this is indeed the correct behavior ideally, allowing
this option to be set in case of emergencies might be useful when
the current backup is the only copy available. Some error messages
during "--prepare" suggest to set "innodb_force_recovery" to 1:
[ERROR] InnoDB: Set innodb_force_recovery=1 to ignore corruption.
For backwards compatibility, "mariabackup --innobackupex --apply-log"
should also have this option.
Signed-off-by: Srinidhi Kaushik <shrinidhi.kaushik@gmail.com>
Diffstat (limited to 'storage')
| -rw-r--r-- | storage/innobase/srv/srv0start.cc | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/storage/innobase/srv/srv0start.cc b/storage/innobase/srv/srv0start.cc index a7be1cdbf21..9548730b359 100644 --- a/storage/innobase/srv/srv0start.cc +++ b/storage/innobase/srv/srv0start.cc @@ -2322,7 +2322,7 @@ files_checked: to the data files and truncate or delete the log. Unless --export is specified, no further change to InnoDB files is needed. */ - ut_ad(!srv_force_recovery); + ut_ad(srv_force_recovery <= SRV_FORCE_IGNORE_CORRUPT); ut_ad(srv_n_log_files_found <= 1); ut_ad(recv_no_log_write); buf_flush_sync_all_buf_pools(); |