[DOC] Add details on the conjunction of innodb_corrupt_table_action and innodb_force_recovery
Affects | Status | Importance | Assigned to | Milestone | ||
---|---|---|---|---|---|---|
Percona Server moved to https://jira.percona.com/projects/PS | Status tracked in 5.7 | |||||
5.1 |
Won't Fix
|
Medium
|
Unassigned | |||
5.5 |
Triaged
|
Medium
|
Borys Belinsky | |||
5.6 |
Triaged
|
Medium
|
Borys Belinsky | |||
5.7 |
Triaged
|
Medium
|
Borys Belinsky |
Bug Description
In case of corruption of an InnoDB table (using files-per-table), there are two variables that are here to try to recover/
- innodb_
- innodb_
The first is the most common one (from upstream InnoDB) while the second one is an XtraDB specific, both variables settings might be overlapping if a corrupted InnoDB table is encountered, the documentation is not clear on which takes precedence.
What should happen if innodb_
- assert (intentionally crash the server when it detects corrupted data in a single-table tablespace) (the default value) : should it crash the server with an assertion or let it try to read from table?
- warn (disable all further I/O (except for deletion) on the table file) : should it be possible to try to read from these table or only to DROP them?
ps: does "salvage" only applies if "innodb_
tags: | added: doc |
summary: |
- [DOC] Add details on the conjonction of innodb_corrupt_table_action and + [DOC] Add details on the conjunction of innodb_corrupt_table_action and innodb_force_recovery |
tags: | added: corrupt-table-action |
Percona now uses JIRA for bug reports so this bug report is migrated to: https:/ /jira.percona. com/browse/ PS-1543