Details
-
Bug
-
Status: Closed (View Workflow)
-
Critical
-
Resolution: Fixed
-
10.5, 10.6, 10.7, 10.8, 10.9, 10.10, 10.11
-
None
Description
A user is facing this scenario where mariabackup --prepare has been running for 12+ hours, and it's reporting page numbers to recover. Then it goes on to multiple iterations of recovery with no indication of how much work is remaining or how much time remains to complete the process.
It will be great if `--prepare` can report the percentage of pages recovery completed per iteration and a global percentage completion consolidating all iteration batches.
Attachments
Issue Links
- blocks
-
MDEV-32042 Special handling of crash recovery in buf_page_get_gen() may cause overhead
-
- Open
-
- causes
-
MDEV-31386 InnoDB: Failing assertion: page_type == i_s_page_type[page_type].type_value
-
- Closed
-
-
MDEV-31827 InnoDB multi-batch recovery stops prematurely
-
- Closed
-
- is blocked by
-
MDEV-31080 InnoDB: Failing assertion: space->size == check.size in fil_validate() during deferred tablespace recovery
-
- Closed
-
- relates to
-
MDEV-11027 InnoDB log recovery is too noisy
-
- Closed
-
-
MDEV-31350 test innodb.recovery_memory failed on '21 failed attempts to flush a page'
-
- Closed
-
-
MDEV-31353 InnoDB recovery hangs after reporting corruption
-
- Closed
-
-
MDEV-31362 recv_sys_t::apply(bool): Assertion `!last_batch || recovered_lsn == scanned_lsn' failed
-
- Closed
-
-
MDEV-14481 Execute InnoDB crash recovery in the background
-
- Closed
-
-
MDEV-30053 mariabackup should indicate memory needed for prepare
-
- Open
-
-
MDEV-32029 Assertion failures in log_sort_flush_list upon crash recovery
-
- Closed
-