Forcing InnoDB Recovery The troubleshooting steps for  InnoDB  I/O problems depend on when the problem occurs: during startup of the MySQL server, or during normal operations when a DML or DDL statement fails due to problems at the file system level. If something goes wrong when  InnoDB  attempts to initialize its tablespace or its log files, delete all files created by  InnoDB : all  ibdata  files and all  ib_logfile  files. If you already created some  InnoDB tables, also delete any  .ibd  files from the MySQL database directories. Then try the  InnoDB  database creation again. For easiest troubleshooting, start the MySQL server from a command prompt so that you see what is happening. If  InnoDB  prints an operating system error during a file operation, usually the problem has one of the following solutions: Initialization Problems Runtime Problems •Make sure the  InnoDB  data file directory and the  InnoDB  log directory exist. •Make sure  mysqld  has access rights to create files in those directories. •Make sure  mysqld  can read the proper  my.cnf  or  my.ini  option file, so that it starts with the options that you specified. •Make sure the disk is not full and you are not exceeding any disk quota. •Make sure that the names you specify for subdirectories and data files do not clash. •Doublecheck the syntax of the  innodb_data_home_dir  and  innodb_data_file_path  values. In particular, any  MAX  value in the  innodb_data_file_path  option is a hard limit, and exceeding that limit causes a fatal error. 15.21.2 Forcing InnoDB Recovery To investigate database page corruption, you might dump your tables from the database with  SELECT ... INTO OUTFILE . Usually, most of the data obtained in this way is intact. Serious corruption might cause  SELECT * FROM  tbl_name  statements or  InnoDB  background operations to unexpectedly exit or assert, or even cause  InnoDB  roll-forward recovery to crash. In such cases, you can use the innodb_force_recovery  option to force the  InnoDB  storage engine to start up while preventing background operations from running, so that you can dump your tables. For example, you can add the following line to the  [mysqld]  section of your option file before restarting the server: [mysqld] innodb_force_recovery = 1 For information about using option files, see Section 4.2.2.2, “Using Option Files” . Only set  innodb_force_recovery  to a value greater than 0 in an emergency situation, so that you can start  InnoDB  and dump your tables. Before doing so, ensure that you have a backup copy of your database in case you need to recreate it. Values of 4 or greater can permanently corrupt data files. Only use an  innodb_force_recovery  setting of 4 or greater on a production server instance after you have successfully tested the setting on a separate physical copy of your database. When forcing  InnoDB  recovery, you should always start with  innodb_force_recovery=1  and only increase the value incrementally, as necessary. Warning 3391