views:

3172

answers:

4

Is it possible to restore a MySQL database from the physical database files. I have a directory that has the following file types:

client.frm
client.MYD
client.MYI

but for about 20 more tables.

I usually use mysqldump or a similar tool to get everything in 1 SQL file so what is the way to deal with these types of files?

+1  A: 

Yes it is! Just add them to your database-folder ( depending on the OS ) and run a command such as "MySQL Fix Permissions". This re-stored the database. See too it that the correct permissions are set on the files aswell.

Filip Ekberg
A: 

I once copied these files to the database storage folder for a mysql database which was working, started the db and waited for it to "repair" the files, then extracted them with mysqldump.

Spikolynn
+3  A: 

MySQL tables are really three files together:

  • The FRM file is the table definition.
  • The MYD file is the where the actual data is stored.
  • The MYI file is the where the index created on the table are stored.

You should be able to restore by copying them in your database folder.

Vincent
this is true only for MyISAM tables. InnoDB stores its tables and indexes in a single tablespace *, which by default consist of the 3 files ibdata1, ib_logfile0, and ib_logfile1. for restoring a database, you would also need those files.* per-table tablespaces are possible, but not default
ax
He says he have .frm .myi and .myd files. I then assumed it was MyISAM tables.
Vincent
right - point taken :)
ax
@ax is it possible to get data from InnoDB without the ibdata? I have a months old backup, and only the current ib_logfile* and .frm files.
eglasius
A: 

sweet. totally worked here. my Win32 server...got manually deprecated. and i was able to recover my MyISAM tables this way to Ubuntu-64 :) very happy making for me as i really didn't want to have to fix my boot record to get back into windows.

though i am getting the error about "Checking for corrupt, not cleanly closed and upgrade needing tables." that wasn't there before. maybe i'll do a proper SQL dump, DROP, and recover then.

cheers very much.

michael lowden