Hello,
yesterday my server crashed. The harddisk got corrupted, including some MySQL
table files. So MySQL can't see some of its tables, although the table files
are visible on the filesystem. Is it possible to repair the files? It's a
MySQL 4.1 (Debian Sarge).
From one table I only have the MYD file. The documentation says, that this is
the file with the data in it. I hope it's possible to reconstruct this table,
too?!
Thanks,
Karel W. Dingeldey
PS: I already tried with "myisamchk -r -o *.MY*", but then all datasets are
gone and the table is empty. :-(

>PS: I already tried with "myisamchk -r -o *.MY*", but then all datasets
>are gone and the table is empty. :-(
>
man myisamchk
I tried myisamchk already. But after running the above rescue attempt, the
tables are empty.

At first - do not write anything on the corrupted disk until You have
finished rescuing data. As I understad the crash is connected to HW or
filesystem (FS) failure (HDD). In that case try to use fsck to repair FS
(if it is regular linux FS, like ext2 or ext3, for xfs there were some
other utils), do not use myisamchk at first. If Your data is really
valuable I would recommend bit-by-bit copy of disk content to similar
disk using dd, then try to restore data on that disk (the copy). If You
make some mistakes or something goes wrong (on copy), You will still
have source disk to start over again (with bit by bit copy). After You
have done rescuing FS, use myisamchk on rescued tables.

Martins

Karel W. Dingeldey wrote:
Hello,

yesterday my server crashed. The harddisk got corrupted, including some MySQL
table files. So MySQL can't see some of its tables, although the table files
are visible on the filesystem. Is it possible to repair the files? It's a
MySQL 4.1 (Debian Sarge).
From one table I only have the MYD file. The documentation says, that this is
the file with the data in it. I hope it's possible to reconstruct this table,
too?!

Thanks,
Karel W. Dingeldey

PS: I already tried with "myisamchk -r -o *.MY*", but then all datasets are
gone and the table is empty. :-(

PS: I already tried with "myisamchk -r -o *.MY*", but then all datasets
are gone and the table is empty. :-(
>>
>man myisamchk
>
I tried myisamchk already. But after running the above rescue attempt, the
tables are empty.

Then I hope you made backups You, do keep backups right?

At first - do not write anything on the corrupted disk until You have
finished rescuing data. As I understad the crash is connected to HW or
filesystem (FS) failure (HDD).

, I will do it more clearly. The server has two harddisks, one for the
system, one for the data. The system harddisk breaked, hardware failure. It
seems that this happed while mysqld was writing some data, so that some
tables are corrupted. Most tables are reconstructable, only the one where I
have only the MYD file is very important.

filesystem level I made all rescue trials. My problem is, that only the MYD
file is still available. I tried reconstructing it with "myisamchk -r -o
table_name.MYD", but as I said without the wanted result.

My question is, if there is any solution to get a working table from this MYD
file. Because the data is saved in this file, IMH it should. Am I right?

Then I hope you made backups You, do keep backups right?

Thanks for asking, but I'm that only stupid guy in the world who has no backup
with actual data. ;-) No, that's not really funny. :-( I would bite my ass if
I could!

Karel

filesystem level I made all rescue trials. My problem is, that only the
MYD
file is still available. I tried reconstructing it with "myisamchk -r -o
table_name.MYD", but as I said without the wanted result.

MYD is your data, MYI is your indexes (Indexes are easy to rebuild, you
should not worry about that).

If myisamchk can't read the MYD, then I don't know what else there is. My
guess would be that the data file is damage beyond repair :-(

If you have a complete and working set of binary logs (incase you used
replication which I doubt), you should also be able to get your data back
out of that But otherwise, I'd say you're out of luck.

Karel W. Dingeldey wrote:
, I will do it more clearly. The server has two harddisks, one for the
system, one for the data. The system harddisk breaked, hardware failure. It
seems that this happed while mysqld was writing some data, so that some
tables are corrupted. Most tables are reconstructable, only the one where I
have only the MYD file is very important.

filesystem level I made all rescue trials. My problem is, that only the MYD
file is still available. I tried reconstructing it with "myisamchk -r -o
table_name.MYD", but as I said without the wanted result.

My question is, if there is any solution to get a working table from this MYD
file. Because the data is saved in this file, IMH it should. Am I right?

If you're using MyISAM tables, then you should have an .MYD (data), .MYI
(index) and .frm (table definition?) file for every table. If you don't
have a backup copy (or two) of your MYD file by now, make one. Then try
repeating the CREATE TABLE statement that defines the table. If you can
get a CREATE TABLE that exactly matches the table definition previously
used, the data in the MYD file may be accessible again. You may have to
move the MYD file out of the way while you do the CREATE TABLE.

How you get your CREATE TABLE statement is up to you. Have you got a
mysqldump created since the last time the table definion was changed?
Was it automatically created by some program which uses the database? If
you can't get anywhere with that and the data is valuable, you should
consider paid support.

Pummer