Baba,
----- Original Message ----- From: "Baba Buehler" <[EMAIL PROTECTED]>
Newsgroups: mailing.database.myodbc
Sent: Thursday, October 07, 2004 12:34 AM
Subject: corruption after database restore
I'm having a corruption problem after doing a backup and then a restore with ibbackup (v1.40).
After restoring from the backup, when mysqld starts I get:
041006 07:46:53 mysqld started InnoDB: Warning: an inconsistent page in the doublewrite buffer InnoDB: space id 0 page number 5877102, 7'th page in dblwr buf. InnoDB: Warning: an inconsistent page in the doublewrite buffer
The sum of data file sizes is 5767168 pages
How is it possible that the doublewrite buffer contains page number 5877102?
InnoDB: space id 0 page number 5877103, 8'th page in dblwr buf. InnoDB: Warning: an inconsistent page in the doublewrite buffer InnoDB: space id 0 page number 5877104, 9'th page in dblwr buf. InnoDB: Warning: an inconsistent page in the doublewrite buffer InnoDB: space id 0 page number 5877105, 10'th page in dblwr buf. InnoDB: Warning: an inconsistent page in the doublewrite buffer InnoDB: space id 0 page number 5877106, 11'th page in dblwr buf. InnoDB: Error: tablespace size stored in header is 6029312 pages, but InnoDB: the sum of data file sizes is 5767168 pages
Are you sure you did not forget some ibdata file from the my.cnf you are using? Looks like the tablespace data files are smaller than they should be.
Please show the my.cnf that you used in taking the backup, as well as in restoring the backup.
041006 7:46:54 InnoDB: Started /usr/sbin/mysqld: ready for connections. Version: '4.0.18-standard' socket: '/tmp/mysql4.sock' port: 3306
Then when queries start hitting the database, I start getting a lot of errors like (full backtrace included below): InnoDB: Assertion failure in thread 36874 in file fil0fil.c line 1204
These assertions happen because the data files are too small.
I've restored from this backup multiple times with the same results, so I'm presuming its the backup itself that is corrupt. Does anyone have any ideas on what might cause ibbackup to corrupt files, as the backup appeared to complete successfully?
Please show the printout of the backup run, as well as the --restore run.
InnoDB: Error: trying to access page number 141623 in space 0 InnoDB: which is outside the tablespace bounds.
Look, it says that page number 142 000 is outside the tablespace data files, though above you had over 5 million pages in data files! You have probably forgotten some data files when you restarted mysqld.
Thanks, baba
Best regards,
Heikki Tuuri
Innobase Oy
Foreign keys, transactions, and row level locking for MySQL
InnoDB Hot Backup - a hot backup tool for InnoDB which also backs up MyISAM tables
http://www.innodb.com/order.php
InnoDB: Error: trying to access page number 141623 in space 0
InnoDB: which is outside the tablespace bounds.
InnoDB: Byte offset 0, len 16384, i/o type 10
041006 7:49:38 InnoDB: Assertion failure in thread 36874 in file
fil0fil.c line 1204
InnoDB: Failing assertion: 0
InnoDB: We intentionally generate a memory trap.
InnoDB: Send a detailed bug report to [EMAIL PROTECTED]
mysqld got signal 11;
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=1048576 read_buffer_size=4190208 max_used_connections=1 max_connections=35 threads_connected=2 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 287603 K bytes of memory Hope that's ok; if not, decrease some variables in the equation.
thd=0x87b2120 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=0xbfe7df28, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x8071f44 handle_segfault + 420 0x82a0e38 pthread_sighandler + 184 0x81edc77 fil_io + 1287 0x81b416b buf_read_page_low + 203 0x81b45c9 buf_read_page + 41 0x81a6fb8 buf_page_get_gen + 888 0x8167771 btr_cur_open_at_rnd_pos + 897 0x8171a4e btr_estimate_number_of_different_key_vals + 670 0x8101c99 dict_update_statistics_low + 89 0x8101d04 dict_update_statistics + 20 0x80f78f8 dict_table_get_and_increment_handle_count + 552 0x80ccc5b open__11ha_innobasePCciUi + 203 0x80c6b54 ha_open__7handlerPCcii + 36 0x8094595 openfrm__FPCcT0UiUiUiP8st_table + 5317 0x8090d27 open_unireg_entry__FP3THDP8st_tablePCcN22 + 87 0x8090178 open_table__FP3THDPCcN21Pb + 888 0x809102b open_tables__FP3THDP13st_table_list + 75 0x8091308 open_and_lock_tables__FP3THDP13st_table_list + 24 0x807ccb3 mysql_execute_command__Fv + 947 0x8080735 mysql_parse__FP3THDPcUi + 149 0x807be13 dispatch_command__F19enum_server_commandP3THDPcUi + 1443 0x807b85e do_command__FP3THD + 158 0x807b088 handle_one_connection + 648 0x829e5ec pthread_start_thread + 220 0x82c7dea thread_start + 4 New value of fp=(nil) failed sanity check, terminating stack trace! Please read http://www.mysql.com/doc/en/Using_stack_trace.html and follow instructions on how to resolve the stack trace. Resolved stack trace is much more helpful in diagnosing the problem, so please do resolve it Trying to get some variables. Some pointers may be invalid and cause the dump to abort... thd->query at 0x87b2af8 = SELECT DISTINCT serial FROM alert WHERE resolve_time IS NULL 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.
-- Baba Buehler - NetBotz, Inc. - <[EMAIL PROTECTED]>
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
-- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
