So I have a test db server that was setup on a replication stream. Over the name an optimize came through that quickly filled up the space on the slaves datadir. Mysql dutifully was just waiting for some more space.

This datadir is a file system used ONLY as mysql's datadir so there wasn't anything else to free up.

I had a 4 gig innodb test table that wasn't part of the replication stream so I figured I'd try something to see if it'd work, and being a test environment I wasn't too worried if things went horribly wrong.

Here's the steps I took

  1. Flushed the table I was about to move
  2. Placed a read lock on it (even though nothing was writing to it and it wasn't in the replication stream)
  3. Copied the .frm and .ibd over to a filesystem w/ some spare room
  4. Unlocked the table
  5. Truncated that table - this freed up enough space for the optimize to finish have replication start chugging along again.
  6. Stop slaving/shutdown mysql
  7. Copy the file out of tmp back to the data dir
  8. Restart mysql

Nothing shows up in the .err log, things look good. I connect and use mydb; and see the table I was messing with in show tables. But, if I try

select * from testtable limit 10;

I get the error

ERROR 1146 (42S02): Table 'mydb.testtable' doesn't exist

From what I can tell so far I can read from all the other tables just fine and replication started back up w/o any complaints.

Is there anything I can do to recover from this point? I can rebuild it from scratch if need be but was curious what others thought about this venture in general. Was there anything about the series of steps I took that would have ended up w/ more flawless results?

What if this wasn't a test server I couldn't just 'do it live' and see what happens? What would have the best way to free up space temporarily on a production slave if I had to like that?

up vote 11 down vote accepted

The biggest thing most people forget about TRUNCATE TABLE is that TRUNCATE TABLE is DDL and not DML. In InnoDB, the metadata within ibdata1 contains a numbered list of InnoDB tables. Using TRUNCATE TABLE causes the internal metadata id of the InnoDB table to shift. This happens because TRUNCATE TABLE effectively does the following:

Example: To truncate an InnoDB Table called mydb.mytb

USE mydb
CREATE TABLE newtb LIKE mytb;
ALTER TABLE mytb RENAME oldtb;
ALTER TABLE newtb RENAME mytb;
DROP TABLE oldtb;

The new mytb would thus have a different internal metadata id.

When you copied the .ibd file to some other place, the .ibd contains within it the original internal metadata id. Simply putting the .ibd file back does not cause a reconciliation of the internal metadata id with that of the one in ibdata1.

What you should have done is this:

Copy the .ibd file of the InnoDB table. Then, run this

ALTER TABLE tablename DISCARD TABLESPACE;

To bring it back later on, copy the .ibd file back into datadir and then run

ALTER TABLE tablename IMPORT TABLESPACE;

This would have preserved the internal metadata id.

Make sure .frm is always present.

I once helped a client restore 30 InnoDB tables he hosed in the same manner. I had to use another DB server and play some games with adding and dropping InnoDB tables to hunt down the correct internal metadata id.

The client found this article : http://www.chriscalender.com/?tag=innodb-error-tablespace-id-in-file . We used it and it helped a great deal. I hope it helps you.

I experienced with my Mac, before selling to a friend simply copy the XAMPP folder only to my hard drive. (NOT SUCCESS) Unfortunately, it was bringing trouble to me, because I tried the following steps: - I install fresh XAMPP and copy the whole \httdocs and var\mysql to my new Mac, those db only with .frm and .ibd, NOT WORKING, I can't still access the tables inside PHPMyAdmin ... - I tried to install the same xampp version and repeat the above steps, still NOT WORKING. - Decided to go to bed.

(SUCCESS) - This morning, I brought my backup disk and try with Windows 7. - Install fresh latest XAMPP for Windows, c:\xampp - I have one of website (folder) from my backup \httdocs and correspond database folder inside \var\mysql are READY in my windows 7, I just want to try with one website then try the rest because I have many projects inside httdocs\ and \var\mysql - I copy the mention httdocs\ folder to windows c:\xampp\httdocs and copy the \var\mysql to c:\xampp\mysql\data

NOT LAST YET I copy the ib_logfile0, ib_logfile1, ibdata1 from my backup file to windows xampp c:\xampp\mysql\data

I refresh the http://localhost/mywebsite

WOW WOW DONE ... it's working...

Your Answer

 
discard

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.