> Лучше бы не хренотень всякую придумывали, а сделали то, о чем ноют
> в интернетике с момента создания InnoDB - вменяемого рекавери. Которое именно
> срекаверит, максимум проигнорирует транзакции с ошибками и восстановит БД, а не
> высрет в лог кучу непонятной срани, а при попытке восстановить скажет
> "Ололо Got error: 1146: Table ‘database.table’ doesn’t exist when using
> бла бла бла" InnoDB модифицирует данные по месту, Если лог транзакций физически повреждён, то на диске могут быть страницы которые ссылаются вникуда (потому что это более свежая версия страницы) и невозможно построить валидное B-tree.
Если лог транзакций не применён (innodb_force_recovery) или если просто есть повреждённые таблички то можно пытаться селектами достать данные.
Если повреждения небольшие то некоторые ошибки могут быть проигнорированы https://www.percona.com/doc/percona-server/LATEST/reliabilit...
Поэтому для таких случаев Алексей Кузьминский сделал свой innodb data recovery tool, который потом форкнул (после ухода из Percona) под названием undrop for innodb. Эта тулза сканирует ibd файл (или даже блочное устройство если файлы были удалены с файловой системы) и ищет строчки по маске (которая делается из словаря innodb или frm файла).
Движки типа дефолтного в postgresql или rocksdb устроены иначе и там можно попытаться проигнорировать ошибки WAL или применить его частично, а т.к. самые последние записи относятся именно к wal, то больше шансов выжить после повреждённых дисков, багов в ядре, багованных кешей на сторадже.
В zheap https://www.opennet.ru/opennews/art.shtml?num=48214 будут те же самые проблемы с аварийным востановлением.
