List:General Discussion« Previous MessageNext Message »
From:Heikki Tuuri Date:October 19 2004 9:33am
Subject:Re: corruption after database restore
View as plain text  
Baba,

----- Original Message ----- 
From: "Baba Buehler" <bbuehler@stripped>
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 mysql@stripped
> 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. - <bbuehler@stripped>
>
>
>
> -- 
> MySQL General Mailing List
> For list archives: http://lists.mysql.com/mysql
> To unsubscribe: 
> http://lists.mysql.com/mysql?unsub=1
> 

Thread
corruption after database restoreBaba Buehler6 Oct
Re: corruption after database restoreHeikki Tuuri19 Oct