Innodb_force_recovery

If you get this message, you can added innodb_force_recovery = 6 to my.conf.
#The mySQL sever 
[mysqld]
...
...
innodb_log_file_size = 5M
innodb_log_buffer_size = 8M
innodb_flush_log_at_trx_commit = 1
innodb_lock_wait_timeout = 50
innodb_force_recovery = 6

If you use xamp, this file at directory xamp\mysql\bin.

2013-10-14 05:37:43 2508 [Note] Plugin 'FEDERATED' is disabled.
2013-10-14 05:37:43 9d0 InnoDB: Warning: Using innodb_additional_mem_pool_size is DEPRECATED. This option may be removed in future releases, together with the option innodb_use_sys_malloc and with the InnoDB's internal memory allocator.
2013-10-14 05:37:43 2508 [Note] InnoDB: The InnoDB memory heap is disabled
2013-10-14 05:37:43 2508 [Note] InnoDB: Mutexes and rw_locks use Windows interlocked functions
2013-10-14 05:37:43 2508 [Note] InnoDB: Compressed tables use zlib 1.2.3
2013-10-14 05:37:43 2508 [Note] InnoDB: Not using CPU crc32 instructions
2013-10-14 05:37:43 2508 [Note] InnoDB: Initializing buffer pool, size = 16.0M
2013-10-14 05:37:43 2508 [Note] InnoDB: Completed initialization of buffer pool
2013-10-14 05:37:43 2508 [Note] InnoDB: Highest supported file format is Barracuda.
2013-10-14 05:37:43 2508 [Note] InnoDB: The log sequence numbers 0 and 0 in ibdata files do not match the log sequence number 1605539 in the ib_logfiles!
2013-10-14 05:37:43 2508 [Note] InnoDB: Database was not shutdown normally!
2013-10-14 05:37:43 2508 [Note] InnoDB: Starting crash recovery.
2013-10-14 05:37:43 2508 [Note] InnoDB: Reading tablespace information from the .ibd files...
2013-10-14 05:37:43 2508 [ERROR] InnoDB: Attempted to open a previously opened tablespace. Previous tablespace mysql/slave_relay_log_info uses space ID: 3 at filepath: .\mysql\slave_relay_log_info.ibd. Cannot open tablespace namedatabase\nametable which uses space ID: 3 at filepath: .\namedatabase\nametable.ibd
InnoDB: Error: could not open single-table tablespace file .\namedatabase\nametable.ibd
InnoDB: We do not continue the crash recovery, because the table may become
InnoDB: corrupt if we cannot apply the log records in the InnoDB log to it.
InnoDB: To fix the problem and start mysqld:
InnoDB: 1) If there is a permission problem in the file and mysqld cannot
InnoDB: open the file, you should modify the permissions.
InnoDB: 2) If the table is not needed, or you can restore it from a backup,
InnoDB: then you can remove the .ibd file, and InnoDB will do a normal
InnoDB: crash recovery and ignore that table.
InnoDB: 3) If the file system or the disk is broken, and you cannot remove
InnoDB: the .ibd file, you can set innodb_force_recovery > 0 in my.cnf
InnoDB: and force InnoDB to continue crash recovery here.

innodb_force_recovery is 0 by default (normal startup without forced recovery) The permissible nonzero values for innodb_force_recovery follow. A larger number includes all precautions of smaller numbers. If you are able to dump your tables with an option value of at most 4, then you are relatively safe that only some data on corrupt individual pages is lost. A value of 6 is more drastic because database pages are left in an obsolete state, which in turn may introduce more corruption into B-trees and other database structures.

• 1 (SRV_FORCE_IGNORE_CORRUPT)
  Let the server run even if it detects a corrupt page. Try to make SELECT * FROM tbl_name jump over corrupt index records and pages, which helps in dumping tables.
• 2 (SRV_FORCE_NO_BACKGROUND)
  Prevent the main thread from running. If a crash would occur during the purge operation, this recovery value prevents it.
• 3 (SRV_FORCE_NO_TRX_UNDO)
  Do not run transaction rollbacks after recovery.
• 4 (SRV_FORCE_NO_IBUF_MERGE)
  Prevent insert buffer merge operations. If they would cause a crash, do not do them. Do not calculate table statistics.
• 5 (SRV_FORCE_NO_UNDO_LOG_SCAN)
  Do not look at undo logs when starting the database: InnoDB treats even incomplete transactions as committed.
• 6 (SRV_FORCE_NO_LOG_REDO)
  Do not do the log roll-forward in connection with recovery.
  Information further can look at http://dev.mysql.com/doc/refman/5.0/en/forcing-innodb-recovery.html