1

After restoring from a percona-xtrabackup without a preparation step, ib_logfile0 and ib_logfile1 were not present in the restore data. Therefor during startup the following message is observed:

140223 04:10:24 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended
140223 04:46:51 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
140223  4:46:51  InnoDB: Initializing buffer pool, size = 18.0G
140223  4:46:54  InnoDB: Completed initialization of buffer pool
140223  4:46:54  InnoDB: Log file ./ib_logfile0 did not exist: new to be created
InnoDB: Setting log file ./ib_logfile0 size to 5 MB
InnoDB: Database physically writes the file full: wait...
140223  4:46:54  InnoDB: Log file ./ib_logfile1 did not exist: new to be created
InnoDB: Setting log file ./ib_logfile1 size to 5 MB
InnoDB: Database physically writes the file full: wait...
InnoDB: The log sequence number in ibdata files does not match
InnoDB: the log sequence number in the ib_logfiles!
140223  4:46: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...
140223  4:46:55  InnoDB: Error: page 7 log sequence number 45 3368182252
InnoDB: is in the future! Current system log sequence number 42 975484940.
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.1/en/forcing-innodb-recovery.html

How can I fix this?

  • The last line in the display has http://dev.mysql.com/doc/refman/5.1/en/forcing-innodb-recovery.html. You may have to resort to that. – RolandoMySQLDBA Mar 6 '14 at 18:26
  • 1
    You forgot to --apply-log or ran it with --redo-only. See how a backup copy should be prepared serverfault.com/questions/578448/… – akuzminsky Mar 6 '14 at 19:22
1

You have three(3) options

OPTION #1 : Redo the XtraBackup with the Proper Preparation Steps

The preparation step was meant to carry the logs along for the ride. You must go back and run the backup again.

OPTION #2 : Play with Forced Recovery

Rather that reinvent the wheel, please see my post The InnoDB log sequence number is in the future

OPTION #3 : Run Multiple rsyncs

This is rather risky, but you can run rsync multiple times against the live MySQL instance until two consecutive rsyncs take the same amount of time. Then, shutdown mysql on the source, run one more rsync. Then, after due diligence, startup mysql on the new server.

See my earlier post Any better way out of MySQL InnoDB log "in the future"?

Give it a Try !!!

0

This blog post describes a way to recover the data from the frm and ibd files without ib_logfile0 and ib_logfile1. (Of course, this does not recover data that was only written to the log files.) The guide is a bit rough and needs to be adapted here and there but worked for me.

Your Answer

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.