Sign up ×
Database Administrators Stack Exchange is a question and answer site for database professionals who wish to improve their database skills and learn from others in the community. It's 100% free, no registration required.

I got a server restart, the mysql server seems crashed. After reboot, mysql database filled of old data for bug tracker.

Do you know how to fix this? mysql error log as below

 131027 15:29:19 [Note] Plugin 'FEDERATED' is disabled.
 131027 15:29:19 InnoDB: The InnoDB memory heap is disabled
 131027 15:29:19 InnoDB: Mutexes and rw_locks use GCC atomic builtins
 131027 15:29:19 InnoDB: Compressed tables use zlib 1.2.7
 131027 15:29:19 InnoDB: Using Linux native AIO
 131027 15:29:19 InnoDB: Initializing buffer pool, size = 128.0M
 131027 15:29:19 InnoDB: Completed initialization of buffer pool
 131027 15:29:19 InnoDB: highest supported file format is Barracuda.
 InnoDB: The log sequence number in ibdata files does not match
 InnoDB: the log sequence number in the ib_logfiles!
 131027 15:29:19  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...
 131027 15:29:24  InnoDB: Waiting for the background threads to start
 131027 15:29:25 InnoDB: 5.5.32 started; log sequence number 320322004
 131027 15:29:25 [Note] Server hostname (bind-address): ''; port: 3306
 131027 15:29:25 [Note]   - '' resolves to '';
 131027 15:29:25 [Note] Server socket created on IP: ''.
 131027 15:29:26 [Note] Event Scheduler: Loaded 0 events
 131027 15:29:26 [Note] /usr/sbin/mysqld: ready for connections.
 Version: '5.5.32-0ubuntu0.13.04.1'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  (Ubuntu)
 131027 15:29:34 [ERROR] /usr/sbin/mysqld: Table './bugtracker/mantis_bug_history_table' is marked as crashed and should be repaired
 131027 15:29:34 [Warning] Checking table:   './bugtracker/mantis_bug_history_table'
 131027 15:29:34 [ERROR] Got an error from unknown thread, /build/buildd/mysql-5.5-5.5.32/storage/myisam/
 131027 15:29:34 [Warning] Recovering table: './bugtracker/mantis_bug_history_table'
share|improve this question

migrated from Oct 27 '13 at 16:11

This question came from our site for professional and enthusiast programmers.

If data is really important for you - hire a real DBA to fix it. – zerkms Oct 27 '13 at 9:35
Do you have binary logging enabled? – Michael - sqlbot Oct 28 '13 at 2:41

1 Answer 1

Do you know how to fix this?

Yes, Apply the latest backup.

If you can not do that because you do not take backups - look please for a job where you are not responsible for managing data. Backups is "professional databases for beginner admins, day 1, hour 1". Fundamental Like not driving a car totally drunk level of fundamental.

That being said, this sounds "crazy". As in - I am sure you overlook something. This is not a behavior I would expect on a crash UNLESS it runs on a VM and was rolling back to a backup or fixed start state.... corruption DOES sometimes make things bad or result in lost data, but rarely in a consistent state some days back. I would investigate whether you have a larger problem. I remember a company loosing money because the (not so smart) admin had set up vm's to roll back to a known state in case of a backup... which wiped access keys that can not be recovered to some serious funds ( I would expect your problem to be something along this line. A rollback without corruption to a state some days ago is very very unlikely.

share|improve this answer
Based on the log, the crashed table looks like it was MyISAM. As a DBA I generally stay far away from MyISAM tables because they are not as resilient as InnoDB, so I am not as familiar with their internal structures, but it seems plausible that a version of the table without the newest inserts could remain after a system crash, with potential interactions between filesystem recovery and MyISAM repair -- there was corruption, but it was repaired. Still, +1 ... the server in its current state likely has nothing left to "fix." – Michael - sqlbot Oct 28 '13 at 2:40
Possibly - I do SqlServer pretty much exclusively and it's file side structure is a lot more controlled, no file per table etc., so it can catch corruption. I would not really use that data at all - this is why backups are fundamental and I am pulling a differential on my core data every couple of minutes. At least on SQL Server log backups are fast and cheap (not a lot has changed in some minutes). – TomTom Oct 28 '13 at 6:20

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.