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
