Skip navigation links

MySQL Forums :: Data Recovery :: one row in innodb corrupt


Advanced Search

one row in innodb corrupt
Posted by: Martin Probst ()
Date: July 16, 2011 07:16AM

Hello,
Know I going to make a Database dump. It crash with
mysqldump: Error 2013: Lost connection to MySQL server during query when dumping table `hierarchy` at row: 626022

The row is the same every time.

I found the ID of this row from the log below. A select statment to other id's work. Only a access to this id crash the mysql server.

I use innodb_force_recovery with 1,2 and 4 but the dump crash every time on this line.

mysqld.log
Version: '5.0.26' socket: '/var/lib/mysql/mysql.sock' port: 3306 SUSE MySQL RPM
InnoDB: Error: trying to access update undo rec field 26 in index PRIMARY of table zarafa/hierarchy
InnoDB: but index has only 9 fields
InnoDB: Submit a detailed bug report to http://bugs.mysql.com
InnoDB: Run also CHECK TABLE zarafa/hierarchy
InnoDB: n_fields = 99, i = 2, ptr 0xb79360e7
InnoDB: Error: trying to access update undo rec for table zarafa/hierarchy
InnoDB: but the table id in the undo record is wrong
InnoDB: Submit a detailed bug report to http://bugs.mysql.com
InnoDB: Run also CHECK TABLE zarafa/hierarchy
InnoDB: table zarafa/hierarchy, index PRIMARY, n_uniq 1
InnoDB: undo rec address 0xb7936068, type 0 cmpl_info 0
InnoDB: undo rec table id 0 0, index table id 0 14
InnoDB: dump of 150 bytes in undo rec: len 150; hex <here comes some private data>
InnoDB: index record PHYSICAL RECORD: n_fields 9; compact format; info bits 0
0: len 4; hex 0042252d; asc B%-;; 1: len 6; hex 000080dbf1c9; asc ;; 2: len 7; hex 000006800324f5; asc $ ;; 3: len 4; hex 0042252b; asc B%+;; 4: len 4; hex 4ce513e2; asc L ;; 5: len 4; hex 4ce513e2; asc L ;; 6: len 1; hex 06; asc ;; 7: len 2; hex 0000; asc ;; 8: len 2; hex 0020; asc ;;

InnoDB: record version PHYSICAL RECORD: n_fields 9; compact format; info bits 0
0: len 4; hex 0042252d; asc B%-;; 1: len 6; hex 000080dbf1c9; asc ;; 2: len 7; hex 000006800324f5; asc $ ;; 3: len 4; hex 0042252b; asc B%+;; 4: len 4; hex 4ce513e2; asc L ;; 5: len 4; hex 4ce513e2; asc L ;; 6: len 1; hex 06; asc ;; 7: len 2; hex 0000; asc ;; 8: len 2; hex 0020; asc ;;

InnoDB: Record trx id 0 2161897929, update rec trx id 0 1828743424
InnoDB: Roll ptr in rec 6 2147689717, in update rec 110 2097235
InnoDB: Purge system view:
Read view low limit trx n:o 0 1837752832
Read view up limit trx id 0 1837752832
Read view low limit trx id 0 1837752832
Read view individually stored trx ids:
InnoDB: Purge trx n:o 0 0, undo n_o 0 0
InnoDB: Purge next stored 0, page_no 0, offset 0,
InnoDB: Purge hdr_page_no 0, hdr_offset 0
InnoDB: unknown error code 11
110716 13:22:06InnoDB: Assertion failure in thread 1292860304 in file row0mysql.c line 556
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.0/en/forcing-recovery.html
InnoDB: about forcing recovery.
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=16777216
read_buffer_size=258048
max_used_connections=1
max_connections=500
threads_connected=1
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 398380 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd=0x9b99198
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=0x4d0f5808, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
0x8183617
0x82e4552
0x82f520c
0x824de9b
0x824fc4c
0x823ccfb
0x81e28ea
0x81e2bb7
0x81ef18d
0x81f0fc1
0x81f1803
0x81a0278
0x81a4c41
0x81a528e
0x81a67c3
0x81a727b
0xb7f55112
0xb7d812ee
New value of fp=(nil) failed sanity check, terminating stack trace!
Please read http://dev.mysql.com/doc/mysql/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 0x9bb4620 = SELECT /*!40001 SQL_NO_CACHE */ * FROM `hierarchy`
thd->thread_id=1
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.

Number of processes running now: 0
110716 13:22:07 mysqld restarted

Options: ReplyQuote


Subject Views Written By Posted
one row in innodb corrupt 3235 Martin Probst 07/16/2011 07:16AM
Re: one row in innodb corrupt 1725 addision philip 07/22/2011 12:37AM
Re: one row in innodb corrupt 1705 Oli Sennhauser 08/10/2011 08:11AM


Sorry, you can't reply to this topic. It has been closed.

Content reproduced on this site is the property of the respective copyright holders. It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.