After last time MySQL crashed, the log file has not been working properly. But it is a silent error so I didn’t notice it until now.
InnoDB: Error: page 570 log sequence number 7289495
InnoDB: is in the future! Current system log sequence number 5574939.
InnoDB: Your database may be corrupt or you may have copied the InnoDB
InnoDB: tablespace but not the InnoDB log files. See
InnoDB: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html
InnoDB: for more information.
The most helpful tips I found is and MySQL InnoDB crash recovery guide for 11.23,11.24 (mysql will not start) and MySQL Forums :: InnoDB :: innodb log sequence error
This one gives answers in a more sophisticated way.
My database is relative small in size so I decided to go with the first two easy recipes. But the “dumpdbs.pl” perl script failed to work because of the mysql root password. I used mysqldump to do the work. Here is what I did:
1) stop mysqld: sudo service mysqld stop
2) backup all the data : mysqldump -u root -p --all-databases > all-databases.sql
3) rename the files in case anything bad happens:
mv ib_logfile0 ib_logfile0.bak
mv ib_logfile1 ib_logfile1.bak
mv ibdata1 ibdata1.bak
4) restart mysqld with “innodb_force_recovery=4” in my.cnf : sudo service mysqld start
Now the “log in the future” problem should be gone with the ibdata1 file reconstructed. But all the data are gone, too.
5) restore the data: mysql -u root -p < all-databases.sql
6) you need to restart the mysqld again with “innodb_force_recovery=4”: sudo service mysqld restart
Otherwise you will get another error in your mysql.log file:
InnoDB: Error: table `xxx`.`xx` does not exist in the InnoDB internal
InnoDB: data dictionary though MySQL is trying to drop it.
InnoDB: Have you copied the .frm file of the table to the
InnoDB: MySQL database directory from another database?
InnoDB: You can look for further help from
InnoDB: http://dev.mysql.com/doc/refman/5.5/en/innodb-troubleshooting.html
Now everything should be back to normal, double check if you lost any data. I got lucky. You can delete the .bak file if you want.
NOTE: if your database is huge, the dump and restore process will take a very long time. So you might want to explore the solutions given by the Any better way out of MySQL InnoDB log “in the future”?
A physicist's thoughts 
In your post
1) stop mysqld: sudo service mysqld stop
2) backup all the data : mysqldump -u root -p –all-databases > all-databases.sql
Are you sure that you can take mysqldump while MySQL service is stopped ?
Yes. I remember that’s what I did.
Thats interesting one to know .. Can you try stopping MySQL service first ( on your test machine ) and try to take a dump of a test database using mysqldump to see if it is working ?
I can not get mysqldump to work as mysql is not running.
Thank you for this. I just rescued a 112gb database that I corrupted by pulling the power at the wrong time.
For clarification, I was not able to do the mysqldump after stopping the SQL service. And also I was not able to import the data in recovery_mode_4. But this was a good framework that pointed me in the direction I needed to recover it.
There is important point was raised by Lin.
Of course there are no possibilities to run any of mysql* commands while the mysqld daemon stopped.