Форум пользователей MySQL

Здравствуйте.
1. Ну, использую виртульный хостинг. Попросил оказать услугу (услуга связана с настройкой сервера). Настроили... Потом дико извинялись, но делу это не помогло. Приходится самому думать. После проведения "услуги" попробовал войти на форум и не вышло. Первым делом полез в phpmyadmin и там не подошел пароль админа. Задал им вопрос в чем дело. По идее они стартанули его с force_recovery и чуда не вышло. Как и с какими параметрами, я не знаю. Дальнейшее - это уже мое углубление в материал и попытка спасти базу. Как бы файлы есть, но ibdata скорее всего поврежден.
2. Насчет файлов согласен. Единственное, в чем не уверен, это бинарные логи. Важны они, не важны? Если их удалить, то при запуске сервиса они создаются заново с тем же размером. Потому, думаю, они не критичны.
3. В логах пишется по крайней мере о 3х поврежденных блоках. Выдается их хекс и всякая брань на буржуйском языке о несоответствии контрольных чисел.
4. Ну и я не знаю как должен вести себя мускул после запуска с восстановлением. Т.е. по идее он запускается в безопасном режиме где не работают половина функций. Но я даже статуса не вижу, т.к. пишет ошибку (111). При попытке сделать дамп также ругается на 111. Поставил себе мускул под винду, подбрасывал туда файлы, но процесс не запускается так же.

Начинаю пить валерьянку и в черновиках писать заявление на отпуск...

Отредактированно BSBAlex (09.10.2016 20:46:35)

Обычный запуск: http://prntscr.com/cryot2
При запуске с --innodb_force_recovery=4 лог почему-то такой же Может я что не так делаю.
Пробовал и в my.cnf прописывать команду и в командной строке - результат тот же. Либо лог может в другом месте хранится а я не то смотрю? лог смотрю в var/log/mysql/error.log

Старые копии есть. Ну по крайней мере те, что стали доступны после вмешательства умельцев из службы поддержки. Насколько они правильные я не скажу... Еще нашел похожую беду в статье http://sqlinfo.ru/forum/viewtopic.php?id=7771 но там ссылки не работают. Логи постараюсь воссоздать в текстовом виде.

Ну то есть с force-recovery завелось?

Странная вещь произошла! Задумал переустановить мускул. Удалил все.
Стер 3 файла: ib_logfile0, ib_logfile1, ibdata1.
Сделал purge mysql, потом install...
Мускул запустился! И что неожиданно - с некоторыми базами и парами таблиц в каждой с данными. MySql база так вообще целая походу... Как это понимать?

Ладно, имеющимися средствами восстановить возможно и не выйдет. Может вы мне подскажете где можно найти структуру самого ibdata файла? Как там чего хранится? Если что, я сам повыдираю нужные блоки...

Отредактированно BSBAlex (11.10.2016 15:09:58)

Те таблицы, что остались, действительно myisam. Им повезло )
По поводу лога... большой он! Ну ладно...
161010 16:07:58 [Note] Plugin 'FEDERATED' is disabled.
161010 16:07:58 InnoDB: The InnoDB memory heap is disabled
161010 16:07:58 InnoDB: Mutexes and rw_locks use GCC atomic builtins
161010 16:07:58 InnoDB: Compressed tables use zlib 1.2.3.4
161010 16:07:58 InnoDB: Initializing buffer pool, size = 128.0M
161010 16:07:58 InnoDB: Completed initialization of buffer pool
161010 16:07:58 InnoDB: highest supported file format is Barracuda.
InnoDB: The user has set SRV_FORCE_NO_LOG_REDO on
InnoDB: Skipping log redo
161010 16:07:58  InnoDB: Error: space id and page n stored in the page
InnoDB: read in are 26:39649279, should be 0:604!
InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 604.
InnoDB: You may have to recover from a backup.
...
161010 16:07:59  InnoDB: Page checksum 2689706496, prior-to-4.0.14-form checksum 3250609499
InnoDB: stored checksum 3964862464, prior-to-4.0.14-form stored checksum 1925188315
InnoDB: Page lsn 2779 524502463, low 4 bytes of lsn at page end 524550129
InnoDB: Page number (if stored to page already) 39649279,
InnoDB: space id (if created with >= MySQL-4.1.1 and stored already) 26
InnoDB: Page may be a freshly allocated page
InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 604.
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/ … overy.html
InnoDB: about forcing recovery.
InnoDB: Page directory corruption: infimum not pointed to
...
161010 16:07:59  InnoDB: Page checksum 2689706496, prior-to-4.0.14-form checksum 3250609499
InnoDB: stored checksum 3964862464, prior-to-4.0.14-form stored checksum 1925188315
InnoDB: Page lsn 2779 524502463, low 4 bytes of lsn at page end 524550129
InnoDB: Page number (if stored to page already) 39649279,
InnoDB: space id (if created with >= MySQL-4.1.1 and stored already) 26
InnoDB: Page may be a freshly allocated page
InnoDB: Page directory corruption: supremum not pointed to
...
161010 16:07:59  InnoDB: Page checksum 2689706496, prior-to-4.0.14-form checksum 3250609499
InnoDB: stored checksum 3964862464, prior-to-4.0.14-form stored checksum 1925188315
InnoDB: Page lsn 2779 524502463, low 4 bytes of lsn at page end 524550129
InnoDB: Page number (if stored to page already) 39649279,
InnoDB: space id (if created with >= MySQL-4.1.1 and stored already) 26
InnoDB: Page may be a freshly allocated page
InnoDB: wrong number of columns in SYS_INDEXES record
InnoDB: Page directory corruption: infimum not pointed to
...
161010 16:07:59  InnoDB: Page checksum 2689706496, prior-to-4.0.14-form checksum 3250609499
InnoDB: stored checksum 3964862464, prior-to-4.0.14-form stored checksum 1925188315
InnoDB: Page lsn 2779 524502463, low 4 bytes of lsn at page end 524550129
InnoDB: Page number (if stored to page already) 39649279,
InnoDB: space id (if created with >= MySQL-4.1.1 and stored already) 26
InnoDB: Page may be a freshly allocated page
InnoDB: Page directory corruption: supremum not pointed to
...
161010 16:07:59  InnoDB: Page checksum 2689706496, prior-to-4.0.14-form checksum 3250609499
InnoDB: stored checksum 3964862464, prior-to-4.0.14-form stored checksum 1925188315
InnoDB: Page lsn 2779 524502463, low 4 bytes of lsn at page end 524550129
InnoDB: Page number (if stored to page already) 39649279,
InnoDB: space id (if created with >= MySQL-4.1.1 and stored already) 26
InnoDB: Page may be a freshly allocated page
InnoDB: wrong number of columns in SYS_INDEXES record
InnoDB: Page directory corruption: infimum not pointed to
...
161010 16:07:59  InnoDB: Page checksum 2689706496, prior-to-4.0.14-form checksum 3250609499
InnoDB: stored checksum 3964862464, prior-to-4.0.14-form stored checksum 1925188315
InnoDB: Page lsn 2779 524502463, low 4 bytes of lsn at page end 524550129
InnoDB: Page number (if stored to page already) 39649279,
InnoDB: space id (if created with >= MySQL-4.1.1 and stored already) 26
InnoDB: Page may be a freshly allocated page
InnoDB: Page directory corruption: supremum not pointed to
...
161010 16:07:59  InnoDB: Page checksum 2689706496, prior-to-4.0.14-form checksum 3250609499
InnoDB: stored checksum 3964862464, prior-to-4.0.14-form stored checksum 1925188315
InnoDB: Page lsn 2779 524502463, low 4 bytes of lsn at page end 524550129
InnoDB: Page number (if stored to page already) 39649279,
InnoDB: space id (if created with >= MySQL-4.1.1 and stored already) 26
InnoDB: Page may be a freshly allocated page
InnoDB: wrong number of columns in SYS_INDEXES record
InnoDB: Page directory corruption: infimum not pointed to
...
161010 16:07:59  InnoDB: Page checksum 2689706496, prior-to-4.0.14-form checksum 3250609499
InnoDB: stored checksum 3964862464, prior-to-4.0.14-form stored checksum 1925188315
InnoDB: Page lsn 2779 524502463, low 4 bytes of lsn at page end 524550129
InnoDB: Page number (if stored to page already) 39649279,
InnoDB: space id (if created with >= MySQL-4.1.1 and stored already) 26
InnoDB: Page may be a freshly allocated page
InnoDB: Page directory corruption: supremum not pointed to
...
161010 16:07:59  InnoDB: Page checksum 2689706496, prior-to-4.0.14-form checksum 3250609499
InnoDB: stored checksum 3964862464, prior-to-4.0.14-form stored checksum 1925188315
InnoDB: Page lsn 2779 524502463, low 4 bytes of lsn at page end 524550129
InnoDB: Page number (if stored to page already) 39649279,
InnoDB: space id (if created with >= MySQL-4.1.1 and stored already) 26
InnoDB: Page may be a freshly allocated page
InnoDB: wrong number of columns in SYS_INDEXES record
161010 16:07:59  InnoDB: Error: space id and page n stored in the page
InnoDB: read in are 2:232980480, should be 0:3555!
InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 3555.
InnoDB: You may have to recover from a backup.
...
161010 16:07:59  InnoDB: Page checksum 1662579768, prior-to-4.0.14-form checksum 3025939485
InnoDB: stored checksum 1119682560, prior-to-4.0.14-form stored checksum 2541435643
InnoDB: Page lsn 15099 1919614978, low 4 bytes of lsn at page end 1919661799
InnoDB: Page number (if stored to page already) 232980480,
InnoDB: space id (if created with >= MySQL-4.1.1 and stored already) 2
InnoDB: Page may be a freshly allocated page
InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 3555.
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/ … overy.html
InnoDB: about forcing recovery.
161010 16:07:59  InnoDB: Error: space id and page n stored in the page
InnoDB: read in are 2:193593344, should be 0:2954!
InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 2954.
InnoDB: You may have to recover from a backup.
...
161010 16:07:59  InnoDB: Page checksum 2275578983, prior-to-4.0.14-form checksum 1874468282
InnoDB: stored checksum 2671181824, prior-to-4.0.14-form stored checksum 2434939643
InnoDB: Page lsn 15099 1922170882, low 4 bytes of lsn at page end 1922174220
InnoDB: Page number (if stored to page already) 193593344,
InnoDB: space id (if created with >= MySQL-4.1.1 and stored already) 2
InnoDB: Page may be a freshly allocated page
InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 2954.
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/ … overy.html
InnoDB: about forcing recovery.
161010 16:07:59  InnoDB: Error: space id and page n stored in the page
InnoDB: read in are 2:45940736, should be 0:701!
InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 701.
InnoDB: You may have to recover from a backup.
...
161010 16:07:59  InnoDB: Page checksum 3191491439, prior-to-4.0.14-form checksum 2081512642
InnoDB: stored checksum 1245118464, prior-to-4.0.14-form stored checksum 3678026491
InnoDB: Page lsn 15099 1924726786, low 4 bytes of lsn at page end 1924743489
InnoDB: Page number (if stored to page already) 45940736,
InnoDB: space id (if created with >= MySQL-4.1.1 and stored already) 2
InnoDB: Page may be a freshly allocated page
InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 701.
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/ … overy.html
InnoDB: about forcing recovery.
161010 16:07:59  InnoDB: Error: space id and page n stored in the page
InnoDB: read in are 2:233504768, should be 0:3563!
InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 3563.
InnoDB: You may have to recover from a backup.
...
161010 16:07:59  InnoDB: Page checksum 1503049865, prior-to-4.0.14-form checksum 1345693658
InnoDB: stored checksum 689176576, prior-to-4.0.14-form stored checksum 2452110075
InnoDB: Page lsn 15099 1927282690, low 4 bytes of lsn at page end 1927310167
InnoDB: Page number (if stored to page already) 233504768,
InnoDB: space id (if created with >= MySQL-4.1.1 and stored already) 2
InnoDB: Page may be a freshly allocated page
InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 3563.
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/ … overy.html
InnoDB: about forcing recovery.
161010 16:07:59  InnoDB: Error: space id and page n stored in the page
InnoDB: read in are 2:231276544, should be 0:3529!
InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 3529.
InnoDB: You may have to recover from a backup.
...
161010 16:07:59  InnoDB: Page checksum 205382592, prior-to-4.0.14-form checksum 2048549120
InnoDB: stored checksum 4067360768, prior-to-4.0.14-form stored checksum 1242774267
InnoDB: Page lsn 15099 1929838594, low 4 bytes of lsn at page end 1929874136
InnoDB: Page number (if stored to page already) 231276544,
InnoDB: space id (if created with >= MySQL-4.1.1 and stored already) 2
InnoDB: Page may be a freshly allocated page
InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 3529.
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/ … overy.html
InnoDB: about forcing recovery.
161010 16:07:59  InnoDB: Error: space id and page n stored in the page
InnoDB: read in are 2:233570304, should be 0:3564!
InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 3564.
InnoDB: You may have to recover from a backup.
...
161010 16:07:59  InnoDB: Page checksum 79838741, prior-to-4.0.14-form checksum 2133578430
InnoDB: stored checksum 882180096, prior-to-4.0.14-form stored checksum 2924100347
InnoDB: Page lsn 15099 1932394498, low 4 bytes of lsn at page end 1932459170
InnoDB: Page number (if stored to page already) 233570304,
InnoDB: space id (if created with >= MySQL-4.1.1 and stored already) 2
InnoDB: Page may be a freshly allocated page
InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 3564.
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/ … overy.html
InnoDB: about forcing recovery.
161010 16:07:59  InnoDB: Error: space id and page n stored in the page
InnoDB: read in are 2:195559424, should be 0:2984!
InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 2984.
InnoDB: You may have to recover from a backup.
...
161010 16:07:59  InnoDB: Page checksum 2635952110, prior-to-4.0.14-form checksum 1452663011
InnoDB: stored checksum 938999808, prior-to-4.0.14-form stored checksum 1091844859
InnoDB: Page lsn 15099 1934950402, low 4 bytes of lsn at page end 1934982782
InnoDB: Page number (if stored to page already) 195559424,
InnoDB: space id (if created with >= MySQL-4.1.1 and stored already) 2
InnoDB: Page may be a freshly allocated page
InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 2984.
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/ … overy.html
InnoDB: about forcing recovery.
161010 16:07:59  InnoDB: Error: space id and page n stored in the page
InnoDB: read in are 2:233242624, should be 0:3559!
InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 3559.
InnoDB: You may have to recover from a backup.
...
161010 16:08:00  InnoDB: Page checksum 3765235455, prior-to-4.0.14-form checksum 1489697094
InnoDB: stored checksum 1306329088, prior-to-4.0.14-form stored checksum 474364667
InnoDB: Page lsn 15099 1937506306, low 4 bytes of lsn at page end 1937521694
InnoDB: Page number (if stored to page already) 233242624,
InnoDB: space id (if created with >= MySQL-4.1.1 and stored already) 2
InnoDB: Page may be a freshly allocated page
InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 3559.
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/ … overy.html
InnoDB: about forcing recovery.
161010 16:08:00  InnoDB: Error: space id and page n stored in the page
InnoDB: read in are 2:28049408, should be 0:428!
InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 428.
InnoDB: You may have to recover from a backup.
...
161010 16:08:03  InnoDB: Page checksum 2689706496, prior-to-4.0.14-form checksum 3250609499
InnoDB: stored checksum 3964862464, prior-to-4.0.14-form stored checksum 1925188315
InnoDB: Page lsn 2779 524502463, low 4 bytes of lsn at page end 524550129
InnoDB: Page number (if stored to page already) 39649279,
InnoDB: space id (if created with >= MySQL-4.1.1 and stored already) 26
InnoDB: Page may be a freshly allocated page
161010 16:08:03  InnoDB: Assertion failure in thread 139646221883200 in file page0page.ic line 745
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.5/en/ … overy.html
InnoDB: about forcing recovery.
13:08:03 UTC - mysqld got signal 6 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
We will try our best to scrape up some info that will hopefully help
diagnose the problem, but since we have already crashed,
something is definitely wrong and this may fail.

key_buffer_size=4194304
read_buffer_size=131072
max_used_connections=0
max_threads=151
thread_count=0
connection_count=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 334412 K  bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x0
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 0 thread_stack 0x30000
/usr/sbin/mysqld(my_print_stacktrace+0x29)[0x7f01ebca6329]
/usr/sbin/mysqld(handle_fatal_signal+0x483)[0x7f01ebb6b013]
/lib/x86_64-linux-gnu/libpthread.so.0(+0xfcb0)[0x7f01ea8b3cb0]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x35)[0x7f01e9f1f0d5]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x17b)[0x7f01e9f2283b]
/usr/sbin/mysqld(+0x599cc9)[0x7f01ebce4cc9]
/usr/sbin/mysqld(+0x6629d9)[0x7f01ebdad9d9]
/usr/sbin/mysqld(+0x5ba911)[0x7f01ebd05911]
/usr/sbin/mysqld(+0x584599)[0x7f01ebccf599]
/usr/sbin/mysqld(_Z24ha_initialize_handlertonP13st_plugin_int+0x41)[0x7f01ebb6d6e1]
/usr/sbin/mysqld(+0x30e6d1)[0x7f01eba596d1]
/usr/sbin/mysqld(_Z11plugin_initPiPPci+0xad4)[0x7f01eba5cdf4]
/usr/sbin/mysqld(+0x285206)[0x7f01eb9d0206]
/usr/sbin/mysqld(_Z11mysqld_mainiPPc+0x624)[0x7f01eb9d3c74]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xed)[0x7f01e9f0a76d]
/usr/sbin/mysqld(+0x27ea85)[0x7f01eb9c9a85]
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.

paulus написал:

Еще вопрос — не может оказаться, что после старта приходит какой-нибудь mysqlcheck автоматический?

А как это узнать? И где на это установки?
По поводу фак15 не нашел что искал. Может не туда смотрел данные то я вижу, но меня смущает их порядок. Указателей на текстовые строки нет, длин строк нет. Целочисленные данные хранятся как-то не так... Загадка

Это я читал и пробовал. Не прокатило. Я просто хотел структуру файла узнать. Заголовок, тело, указатели начала страниц, деревьев и т.п.
В целом я данные поднял напрямую из базы путем нехитрого анализа расположения данных. Но вытаскивать удается только по страничке.
Да и типа данных типа int все же как-то маскируются Так и не понял в чем фокус. Например, на 1м листе поле id совпадает. На 2м оно
инкрементится, но идет на порядок ниже. Т.е. должно быть 300, 310, 320, к примеру. А идет 10, 20, 30... загадка
А может это и не поле id а некий порядковый номер записей...
Строки вообще идут по порядку без разделителей, но в таком случае где-то должна указываться длина записей...
В любом случае спасибо за содействие, что было критично я вытащил, остальное накопим заново
Ну и надо делать бэкапы нет ничего вечного.
Кстати... у вас есть статейка с описанием как настроить мускул или крон на создание бэкапов. И как их лучше всего делать?

Формат файла ibdata можно узнать из исходников Innodb. К сожалению, простое изложение мне неизвестно. Если найдете, напишите.

Бэкап можно делать разными способами. Главное, чтобы он был. Могу рекомендовать автоматически развертывать бэкап на тестовом сайте, тогда будет просто проверить, что он работает
http://webew.ru/articles/1462.webew