Hello;

I have Mysql server on Fedora 8.
After a miserable electiricity cut, mysql service can not be started
I found out that I can not copy the data file of mysql.
Such:
[root@localhost mysql]# cp ibdata1 ggg
cp: reading `ibdata1': Input/output error

I tried fsck, and fixed 4-5 parts by saying yes whatever asked.
But problem is not fixed.

I checked the mysql log (var/log/mysql.log) and saw the followings :
080611 7:32:20 InnoDB: Error: page 1 log sequence number 6 2853510669
InnoDB: is in the future! Current system log sequence number 0 182043.
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.0/...-recovery.html
InnoDB: for more information.
080611 7:32:20 InnoDB: Error: page 3 log sequence number 3 2008585859
InnoDB: is in the future! Current system log sequence number 0 182043.
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.0/...-recovery.html
InnoDB: for more information.
080611 7:32:20 InnoDB: Error: page 4 log sequence number 6 2877319332
InnoDB: is in the future! Current system log sequence number 0 182043.
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.0/...-recovery.html
InnoDB: for more information.
InnoDB: Error: trying to access page number 1075674354 in space 0,
InnoDB: space name ./ibdata1,
InnoDB: which is outside the tablespace bounds.
InnoDB: Byte offset 0, len 16384, i/o type 10.
InnoDB: If you get this error at mysqld startup, please check that
InnoDB: your my.cnf matches the ibdata files that you have in the
InnoDB: MySQL server.
080611 7:32:20InnoDB: Assertion failure in thread 3086743328 in file fil0fil.c line 3959
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.0/...-recovery.html
InnoDB: about forcing recovery.


What can I do?

Thanks in advance

It sounds to me, that you need to start by looking at your hardware and drives. The I/O error you saw indicates a bad device such as the controller or drive. You might have gotten a very large spike that your surge supressor didn't handle. If the same controller is used for booting as for the drive with the mysql data, then the controller might be OK.

Did you try to execute steps mentioned in http://dev.mysql.com/doc/refman/5.0/...-recovery.html ???
If not, then give a try.

Secondly, Check your harddisk for bad sectors and other concerned hardwares as suggested by jschiwal.

Update us with the outcome.

Yes; I tried the things in ...recovery.html
and server goes up but tables are broken, I can do nothing on database, I can not query, backup, restore etc. It says there are problems in key (index) files. All innodb tables are broken.

As you predict I am new to Linux, so I will be happy if you guide me on "How can I check, detect and repair harddisk for bad sectors and other concerned hardwares". Also I have to add that I remotely control the machine by ssh.

Thanks a lot

I've seen this issue before, especially with InnoDB. We had to recover from backup but before this, had to destroy the ibdata files for InnoDB and allow them to be recreated, then reimported the database from backup.

First make sure you're not dealing with a bad disk so it never occurs again in the future or near future. And secondly, since you can't do anything to export the data, I hope you have a recent backup or your in for a very long haul of either explaining the data is lost or some other type of means to recover the data from the disk.

But the issue with not being able to do anything on the database might relate to the hard disk actually being faulty. With this error, we could however start MySQL and perform a backup (but we didn't use since we didn't trust it due to possible corruption), unlike your situation which tells me it's more than just MySQL but rather hardware. If that's the case, I'll reiterate, I hope you have a recent backup.