Ecco perché MySQL non può vedere quei file: Il tablespace di sistema (ibdata1) ha un dizionario dati specifico dello Storage-Engine che permette a InnoDB di mappare il potenziale utilizzo delle tabelle:
ALTER TABLE tblname DISCARD TABLESPACE;
ALTER TABLE tblname IMPORT TABLESPACE;
Spostare le tabelle InnoDB da un posto all'altro richiede comandi come
ALTER TABLE mydb.tags DISCARD TABLESPACE;
Qui c'è una parte della MySQL 5.5 Documentation che spiega cosa bisogna considerare
Considerazioni sulla portabilità dei file .ibd
Non si possono spostare liberamente i file .ibd tra le directory del database come si fa con i file delle tabelle MyISAM. La definizione della tabella memorizzata nel tablespace condiviso InnoDB include il nome del database. Anche gli ID delle transazioni e i numeri di sequenza dei log memorizzati nei file del tablespace differiscono tra i database.
Per spostare un file .ibd e la tabella associata da un database a un altro, usare l'istruzione RENAME TABLE:
RENAME TABLE db1.tbl\nometabella a db2.tbl\nometabella; Se hai un backup “pulito” di un file .ibd, puoi ripristinarlo nell'installazione MySQL da cui è partito come segue:
La tabella non deve essere stata eliminata o troncata da quando hai copiato il file .ibd, perché così facendo cambi l'ID della tabella memorizzato all'interno del tablespace.
Emetti questa istruzione ALTER TABLE per cancellare il file .ibd corrente:
ALTER TABLE tbl\nome DISCARD TABLESPACE; Copia il file .ibd di backup nella corretta directory del database.
Emetti questa istruzione ALTER TABLE per dire a InnoDB di usare il nuovo file .ibd per la tabella:
ALTER TABLE tbl\nome IMPORT TABLESPACE; In questo contesto, un backup “pulito” del file .ibd è quello per cui sono soddisfatti i seguenti requisiti:
Non ci sono modifiche non impegnate da transazioni nel file .ibd.
Non ci sono voci di insert buffer unmerged nel file .ibd.
Lo spurgo ha rimosso tutti i record di indice marcati come cancellati dal file .ibd.
mysqld ha lavato tutte le pagine modificate del file .ibd dal buffer pool al file.
Dati questi avvertimenti e protocolli, ecco una linea d'azione suggerita
Per questo esempio, proviamo a ripristinare la tabella tags nel database mydb
STEP #1
Assicurati di avere dei backup di quei file .frm e .ibd in /tmp/innodb_data
STEP #2
Prendi lo statement CREATE TABLE tags ed eseguilo come CREATE TABLE mydb.tags .... Assicurati che sia esattamente la stessa struttura dell'originale tags.frm
STEP #3
Cancella lo tags.ibd vuoto usando MySQL
cd /var/lib/mysql/mydb
cp /tmp/innodb_data.tags.ibd .
chown mysql:mysql tags.ibd
STEP #4
Porta la copia di backup di tags.ibd
ALTER TABLE mydb.tags IMPORT TABLESPACE;
STEP #5
Aggiungi la tabella tags al dizionario dei dati InnoDB
SHOW CREATE TABLE mydb.tags\G
SELECT * FROM mydb.tags LIMIT 10;
STEP 6
Test di accessibilità della tabella
Se ottieni risultati normali, complimenti per aver importato una tabella InnoDB.
STEP 7
In futuro, per favore non cancellare ibdata1 e i suoi log
Provaci!
Ho già discusso cose come questa
CAVEAT
E se non conosci la struttura delle tabelle della tabella tags ?
Ci sono degli strumenti per ottenere l'istruzione CREATE TABLE solo usando il file .frm. Ho scritto un post anche su questo: Come estrarre lo schema della tabella dal solo file .frm? . In quel post, ho copiato un file .frm su una macchina Windows da una scatola Linux, ho eseguito lo strumento Windows e ho ottenuto la dichiarazione CREATE TABLE.