был сервер на mysql 4.1.18, в нем была база A, сервера нестало, сохранилиь только все содержимое $mysql_data_dir/A/ и файлы $mysql_data_dir/(ib_logfile0 ib_logfile1 ibdata1), сервер mysql 4.1.21, формирую в нем новые сист таблицы, затем копирую все выше указанные файлы в datadir данного сервера, сервер запускается и просто так и с innodb_force_recovery = 4, при запуске получаю мат в логи типа === 070510 18:49:00 InnoDB error: Cannot find table A/sc_domain from the internal data dictionary of InnoDB though the .frm file for the table exists. Maybe you have deleted and recreated InnoDB data files but have forgotten to delete the corresponding .frm files of InnoDB tables, or you have moved .frm files to another database? Look from section 15.1 of http://www.innodb.com/ibman.html how you can resolve the problem. === либо в случае с innodb_force_recovery = 4 === InnoDB: Page checksum 791801283, prior-to-4.0.14-form checksum 1894285615 InnoDB: stored checksum 3735928559, prior-to-4.0.14-form stored checksum 3735928559 InnoDB: Page lsn 0 393348209, low 4 bytes of lsn at page end 393348209 InnoDB: Page number (if stored to page already) 7, InnoDB: space id (if created with >= MySQL-4.1.1 and stored already) 0 InnoDB: Database page corruption on disk or a failed InnoDB: file read of page 7. 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/mysql/en/Forcing_recovery.html InnoDB: about forcing recovery. InnoDB: Ending processing because of a corrupt database page. 070510 21:48:25 mysqld ended === в случае обрашение к базе (use A) mysql падает в корку при попытке создать тред я так понял. 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=67108864 read_buffer_size=1044480 max_used_connections=1 max_connections=300 threads_connected=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 1600333 K bytes of memory Hope that's ok; if not, decrease some variables in the equation.
thd=0x8a56838 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... Cannot determine thread, fp=0xb, backtrace may not be correct. Bogus stack limit or frame pointer, fp=0xb, stack_bottom=0x9f060000, thread_stack=196608, aborting backtrace. Trying to get some variables. Some pointers may be invalid and cause the dump to abort... thd->query at 0x8a58250 = thd->thread_id=3 The manual page at http://www.mysql.com/doc/en/Crashing.html contains information that should help you find out what is causing the crash.
теперь вопрос - как понять данные из базы?
