I'm having a problem with MySQL when testing my production data. Whenever I started MySQL (mysqld), it always crash. My suspect is on my InnoDB data file (ibdata1) since the size is already bigger than 4GB. I'm using Windows XP 32-bit, memory 3GB.

How can I start my server normally? I already tried to search on the Internet, and found out that we can actually make more than one ibdata by changing the config file (my.ini), but when I change the config file, I got "Error 1067: The process terminated unexpectedly"

How can I fix this problem? Thank you.


Error log:

Log file:

130630 13:33:53 [Note] Plugin 'FEDERATED' is disabled.
130630 13:33:53 InnoDB: The InnoDB memory heap is disabled
130630 13:33:53 InnoDB: Mutexes and rw_locks use Windows interlocked functions
130630 13:33:53 InnoDB: Compressed tables use zlib 1.2.3
130630 13:33:53 InnoDB: Initializing buffer pool, size = 47.0M
130630 13:33:53 InnoDB: Completed initialization of buffer pool
130630 13:33:54 InnoDB: highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 30597818328
130630 13:33:54  InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
InnoDB: Doing recovery: scanned up to log sequence number 30601590452
130630 13:33:56  InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 
InnoDB: Apply batch completed
130630 13:33:58  InnoDB: Waiting for the background threads to start
130630 13:33:59 InnoDB: 1.1.8 started; log sequence number 30601590452
130630 13:33:59 [Note] Event Scheduler: Loaded 0 events
130630 13:33:59 [Note] C:\Program Files\MySQL\MySQL Server 5.5\bin\mysqld: ready for connections.
Version: '5.5.17'  socket: ''  port: 3306  MySQL Community Server (GPL)
InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 134995.
InnoDB: You may have to recover from a backup.
130630 13:34:00  InnoDB: Page dump in ascii and hex (16384 bytes):
len 16384; hex **deleted, too long**
InnoDB: End of page dump
130630 13:34:01  InnoDB: Page checksum 580897364, prior-to-4.0.14-form checksum 4142776698
InnoDB: stored checksum 1320496436, prior-to-4.0.14-form stored checksum 4142776698
InnoDB: Page lsn 7 512426390, low 4 bytes of lsn at page end 512426390
InnoDB: Page number (if stored to page already) 134995,
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 3938
InnoDB: (index "xxxx" of table "xxxx"."xxxx")
InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 134995.
InnoDB: You may have to recover from a backup.
InnoDB: It is also possible that your operating
InnoDB: system has corrupted its own file cache
InnoDB: and rebooting your computer removes the
InnoDB: error.
InnoDB: If the corrupt page is an index page
InnoDB: you can also try to fix the corruption
InnoDB: by dumping, dropping, and reimporting
InnoDB: the corrupt table. You can use CHECK
InnoDB: TABLE to scan your table for corruption.
InnoDB: See also http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
InnoDB: Ending processing because of a corrupt database page.
130630 13:34:01  InnoDB: Assertion failure in thread 3212 in file buf0buf.c line 3660
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.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
130630 13:34:01 - mysqld got exception 0xc0000005 ;
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.
  • The size of ibdata1 file is not a problem. You can worry about it when it's 4TB. However, please paste the entire error log output, beginning with the "start service" time. – Shlomi Noach Jun 30 '13 at 5:30
  • Hi, so it's not related to OS file capacity? And how can I get the error log? Is it the one with .err extension? Thanks before :) – Ruly Jun 30 '13 at 5:36
  • Oh, it absolutely could be related to disk/file system capacity. Please check with your file explorer or disk manager on your disk capacity. But it is not related to some "MySQL-capacity". – Shlomi Noach Jun 30 '13 at 5:39
  • 1
    The name of the error log should be spscified in your my.ini file: "log-error" parameter. I would assume "yes" - the one that ends with ".err" – Shlomi Noach Jun 30 '13 at 5:40
  • 1
    Ruly: if you are able to SELECT the data, my immediate advice to you is to make a full backup via mysqldump. Looking at the log there is apparently a corruption in one of the InnoDB files. This could be a disk failure; you may want to test your disk after taking the backup. I otherwise have no advice on how to resume operation in existing setup: if backup goes well, I would just drop everything (under the data directory), make a clean install, import backup back. – Shlomi Noach Jun 30 '13 at 17:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.