GET 24/7 LIVE HELP NOW

Announcement

Announcement Module
Collapse
No announcement yet.

InnoDB table corruption - cannot drop database in recovery mode

Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • InnoDB table corruption - cannot drop database in recovery mode

    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
    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 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.
    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
    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/Us...ack_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 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:a utoextend
    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

  • #2
    I guess its solved, right? )

    Istvan

    Comment

    Working...
    X