Периодически обращаются клиенты с просьбой восстановить базу данных.
Причины прозаичны: у кого резко кончилось место на диске, кто случайно обновился, кто по незнанию скопировал базы не дампом, а файлами, но итог один.
И вот терзает меня множество вопросов.
Ну какого ж хера ваше сраное innodb_file_per_table все равно требует наличия ibdata1 ?
Почему нельзя просто восстановить базы данных и таблицы, если FRM и IBD файлы уже есть ?
Какого черта не вывести в лог просто человеко-понятное объяснение, что нужно сделать ? Ну вот есть у меня в логе запись: InnoDB: Error: checksum mismatch in data file ./ibdata1. Че мне с этим делать ? Редактировать ? Файл удалить ? Забыть ? Забить ?
Или вот. InnoDB: Could not open or create data files. Что за data files ? Почему ? Это права на запись ? Место на диске ? Внутренние настройки ?
Нахера ГАСИТЬ ВЕСЬ СЕРВЕР БД, если какая-то одна-две транзакции не могут быть восстановлены ?
Почему этот гребанный innodb_force_recovery нихрена не рекаверит, а просто срет в лог ненужной инфой, что он не может восстановить?!
InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 5.
InnoDB: You may have to recover from a backup.
190920 14:41:18 InnoDB: Page dump in ascii and hex (16384 bytes):
len 16384; hex 3ef6f18a000000050000000000000000000000517ff9e3dd00070000000000000000000000000000000144f7e300000000000000000200f20000000000000006000000000000002d000000000000002e000000000000002f0000000000000030000000000000003100000000000000320000000000000033000000000000003400000000000000350000000000000036000000000000003700000000000000380000000000000039000000000000003a000000000000003b000000000000003c000000000000003d000000000000003e000000000000003f00000000000000c000000000000000c100000000000000c200000000000000c300000000000000c400000000000000c500000000000000c600000000000000c700000000000000c800000000000000c900000000000000ca00000000000000cb00000000000000cc00000000000000cd00000000000000ce00000000000000cf00000000000000d000000000000000d100000000000000d200000000000000d300000000000000d400000000000000d500000000000000d600000000000000d700000000000000d800000000000000d900000000000000da00000000000000db00000000000000dc00000000000000dd00000000000000de00000000000000df00000000000000e000000000000000e100000000000000e200000000000000e300000000000000e400000000000000e500000000000000e600000000000000e700000000000000e800000000000000e900000000000000ea00000000000000eb00000000000000ec00000000000000ed00000000000000ee00000000000000ef00000000000000f000000000000000f100000000000000f200000000000000f400000000000000f500000000000000f600000000000000f700000000000000f800000000000000f900000000000000fa00000000000000fb00000000000000fc00000000000000fd00000000000000fe00000000000000ff0000000000000100000000000000010100000000000001020000000000000103000000000000010400000000000001050000000000000106000000000000010700000000000001080000000000000109000000000000010a000000000000010b000000000000010c000000000000010d000000000000010e000000000000010f0000000000000110000000000000011100000000000001120000000000000113000000000000011400000000000001150000000000000116000000000000011700000000000001180000000000000119000000000000011a000000000000011b000000000000011c000000000000011d000000000000011e000000000000011f0000000000000120000000000000012100000000000001220000000000000123000000000000012400000000000001250000000000000126000000000000012700000000000001280000000000000129000000000000012a000000000000012b000000000000012cff000a3ac72b5d9505b823ef6f18a7ff9e3dd; asc > Q D - . / 0 1 2 3 4 5 6 7 8 9 : ; < = > ? ! " # $ % & " ( ) * + , _ @ _ @ jPs r P[ > ;
InnoDB: End of page dump
190920 14:41:18 InnoDB: Page checksum 3020044449, prior-to-4.0.14-form checksum 4243072082
InnoDB: stored checksum 1056371082, prior-to-4.0.14-form stored checksum 1056371082
InnoDB: Page lsn 81 2147083229, low 4 bytes of lsn at page end 2147083229
InnoDB: Page number (if stored to page already) 5,
InnoDB: space id (if created with >= MySQL-4.1.1 and stored already) 0
InnoDB: Page may be a transaction system page
InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 5.
InnoDB: You may have to recover from a backup.
InnoDB: It is also possible that your operating
InnoDB: system has corrupted its own file cache
InnoDB: and rebooting your computer removes the
InnoDB: error.
InnoDB: If the corrupt page is an index page
InnoDB: you can also try to fix the corruption
InnoDB: by dumping, dropping, and reimporting
InnoDB: the corrupt table. You can use CHECK
InnoDB: TABLE to scan your table for corruption.
InnoDB: See also http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
190920 14:41:18 InnoDB: highest supported file format is Barracuda.
InnoDB: No valid checkpoint found.
InnoDB: If you are attempting downgrade from MySQL 5.7.9 or later,
InnoDB: please refer to http://dev.mysql.com/doc/refman/5.5/en/upgrading-downgrading.html
InnoDB: If this error appears when you are creating an InnoDB database,
InnoDB: the problem may be that during an earlier attempt you managed
InnoDB: to create the InnoDB data files, but log file creation failed.
InnoDB: If that is the case, please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.5/en/error-creating-innodb.html
190920 14:41:18 [ERROR] Plugin 'InnoDB' init function returned error.
190920 14:41:18 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
InnoDB: You may have to recover from a backup - это шо, такой тонкий стеб от оракла или кто там заведует этой дрянью ? Я сам знаю что можно рекаверить из бэкапа! Но мне надо стартонуть mysql-сервер так, чтобы он не говорил «Error : Unknown storage engine 'InnoDB'»
На кой черт вообще говорить что InnoDB «обеспечивает надежное хранение данных», если после КРАША этого говна, не то что данных нет, но и сам сервер хрен стартонешь?!
</bugurt mode>
Эт не просьба помочь, эт просто вопрос - ДОКОЛЕ :))
