# InnoDB table corruption - cannot drop database in recovery mode **URL:** \ **Category:** Other MySQL® Questions\ **Created:** [September 11, 2008, 12:39pm UTC](https://forums.percona.com/t/innodb-table-corruption-cannot-drop-database-in-recovery-mode/922 "2008-09-11T12:39:03Z")\ **Posts on this page:** 2\ **Page:** 1
**Author:** ![hbarto](https://avatars.discourse-cdn.com/v4/letter/h/d6d6ee/32.png) [@hbarto](https://forums.percona.com/u/hbarto)\ **Post date:** [September 11, 2008, 12:39pm UTC](https://forums.percona.com/t/innodb-table-corruption-cannot-drop-database-in-recovery-mode/922/1 "2008-09-11T12:39:03Z")
Using mysql 5.0.18. We have a corrupted InnoDB table in our wordpressmu database (verified through logs). Right now we have the server running in recovery mode (tried levels 2-6) and dumped the database successfully but cannot drop the database. Basically anytime I try to do anything with the corrupted table (or drop the database), mysql crashes and restarts. Any ideas on how to drop this database so I can import my dump file and get back up and running? Thanks! Henry Below are a portion of the log showing the corruption and our /etc/my.cnf file. Please let me know if I need to post any other information. what we are seeing in the log: 080910 17:00:15 mysqld started 080910 17:00:16 [Warning] No argument was provided to --log-bin, and --log-bin-index was not used; so replication may break when this MySQL server acts as a master and has his hostname changed!! Please use ‘–log-bin=mysqldev-bin’ to avoid this problem. 080910 17:00:25 InnoDB: Started; log sequence number 294 2697819285 080910 17:00:26InnoDB: Error: Insert buffer insert fails; page free 32, dtuple size 36 InnoDB: Cannot insert index record DATA TUPLE: 2 fields; 0: len 8; hex 0000000000445696; asc DV ;; 1: len 20; hex 574f524450524553534d552f6372656174696f6e; asc WORDPRESSMU/creation;; InnoDB: The table where where this index record belongs InnoDB: is now probably corrupt. Please run CHECK TABLE on InnoDB: that table. Bitmap bits 0 InnoDB: Submit a detailed bug report to [http://bugs.mysql.com](http://bugs.mysql.com) InnoDB: Dump of the child page: 080910 17:00:26 InnoDB: Page dump in ascii and hex (16384 bytes): len 16384; hex ;InnoDB: End of page dump 080910 17:00:26 InnoDB: Page checksum 1484120561, prior-to-4.0.14-form checksum 1004440779 InnoDB: stored checksum 974160416, prior-to-4.0.14-form stored checksum 1004440779 InnoDB: Page lsn 294 2355518105, low 4 bytes of lsn at page end 2355518105 InnoDB: Page number (if stored to page already) 84888, InnoDB: space id (if created with \>= MySQL-4.1.1 and stored already) 0 InnoDB: Page may be an index page where index id is 4294967295 0 InnoDB: (index CLUST\_IND of table SYS\_IBUF\_TABLE\_0) InnoDB: Dump of the parent page: 080910 17:00:26 InnoDB: Page dump in ascii and hex (16384 bytes): len 16384; hex ;InnoDB: End of page dump 080910 17:00:26 InnoDB: Page checksum 3195563833, prior-to-4.0.14-form checksum 3166042183 InnoDB: stored checksum 3195563833, prior-to-4.0.14-form stored checksum 3166042183 InnoDB: Page lsn 294 2350375591, low 4 bytes of lsn at page end 2350375591 InnoDB: Page number (if stored to page already) 4, InnoDB: space id (if created with \>= MySQL-4.1.1 and stored already) 0 InnoDB: Page may be an update undo log page InnoDB: Page may be an index page where index id is 4294967295 0 InnoDB: (index CLUST\_IND of table SYS\_IBUF\_TABLE\_0) InnoDB: Corruption of an index tree: table SYS\_IBUF\_TABLE\_0, index CLUST\_IND, InnoDB: father ptr page no 45860, child page no 84888 PHYSICAL RECORD: n\_fields 6; 1-byte offsets; info bits 0 0: len 4; hex 00000000; asc ;; 1: len 1; hex 00; asc ;; 2: len 4; hex 00000e73; asc s;; 3: len 13; hex 00860300048000860800088000; asc ;; 4: len 4; hex d44204f7; asc B ;; 5: len 8; hex 8000011b524b0a1c; asc RK ;; n\_owned: 0; heap\_no: 2; next rec: 183 PHYSICAL RECORD: n\_fields 7; 1-byte offsets; info bits 16 0: len 4; hex 00000000; asc ;; 1: len 1; hex 00; asc ;; 2: len 4; hex 000020ec; asc ;; 3: len 13; hex 00860300048000860800088000; asc ;; 4: len 4; hex db3f487b; asc ?H{;; 5: len 8; hex 8000011bcb51eae4; asc Q ;; 6: len 4; hex 0000b324; asc $;; n\_owned: 0; heap\_no: 2; next rec: 189 InnoDB: You should dump + drop + reimport the table to fix the InnoDB: corruption. If the crash happens at the database startup, see InnoDB: [http://dev.mysql.com/doc/mysql/en/Forcing\_recovery.html](http://dev.mysql.com/doc/mysql/en/Forcing_recovery.html) about InnoDB: forcing recovery. Then dump + drop + reimport. 080910 17:00:26InnoDB: Assertion failure in thread 2358115248 in file btr0btr.c line 624 InnoDB: Failing assertion: btr\_node\_ptr\_get\_child\_page\_no(node\_ptr, offsets) == buf\_frame\_get\_page\_no(page) InnoDB: We intentionally generate a memory trap. InnoDB: Submit a detailed bug report to [http://bugs.mysql.com.](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/mysql/en/Forcing\_recovery.html](http://dev.mysql.com/doc/mysql/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=268435456 read\_buffer\_size=1044480 max\_used\_connections=0 max\_connections=1000 threads\_connected=0 It is possible that mysqld could use up to key\_buffer\_size + (read\_buffer\_size + sort\_buffer\_size)\*max\_connections = 2306136 K bytes of memory Hope that’s ok; if not, decrease some variables in the equation. thd=(nil) 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=0x8c8de24c, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x815bbb0 0xb75bcd28 0x82b9be4 0x82b9be4 0x82c4ab7 0x82c5266 0x828a9c1 0x828b181 0x82ec760 0x82f27bd 0x82f2c3e 0x82ea23c 0x82bf1c8 0x82bff34 0x829cdd7 0x829a9b2 0x829b93b 0x829ae89 0x829b776 0x829b79b 0x8282e67 0x8282bfb 0x82d4632 0x826a232 0xb75b6dec 0xb74ede8a New value of fp=(nil) failed sanity check, terminating stack trace! Please read [http://dev.mysql.com/doc/mysql/en/Using\_stack\_trace.html](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 The manual page at [http://www.mysql.com/doc/en/Crashing.html](http://www.mysql.com/doc/en/Crashing.html) contains information that should help you find out what is causing the crash. 080910 17:00:27 mysqld ended /etc/my.cnf [mysqld] datadir=/mysqldata/datadir socket=/var/lib/mysql/mysql.sock user=mysql pid-file=/mysqldata/datadir/mysqld.pid log-error=/home/mysql/errorlog/mysqld.log default-table-type=innodb innodb\_data\_home\_dir=/mysqldata/datadir innodb\_data\_file\_path=ibdata1:1200M;ibdata2:100M:autoextend innodb\_log\_file\_size=128MB innodb\_buffer\_pool\_size=512MB innodb\_force\_recovery=6 max\_connections=1000 skip-locking key\_buffer = 256M max\_allowed\_packet = 64M table\_cache = 256 sort\_buffer\_size = 1M read\_buffer\_size = 1M thread\_cache = 8 query\_cache\_size= 64M myisam\_sort\_buffer\_size = 64M thread\_concurrency = 8 open\_files\_limit=1024 # Look for slow queries and other query problems log\_slow\_queries=/home/mysql/errorlog/mysql\_slow\_query.log long\_query\_time=2 # Option for locking out users from the network #skip-networking # Next, replication items: log-bin server-id=1 [client] socket=/var/lib/mysql/mysql.sock ---
**Author:** ![istvan.podor](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/istvan.podor/32/16879_2.png) [@istvan.podor](https://forums.percona.com/u/istvan.podor)\ **Post date:** [May 8, 2010, 9:59am UTC](https://forums.percona.com/t/innodb-table-corruption-cannot-drop-database-in-recovery-mode/922/2 "2010-05-08T09:59:18Z")
I guess its solved, right? ) Istvan