L'architettura di InnoDB richiede l'uso di quattro tipi base di pagine informative
- Pagine dei dati della tabella
- Pagine indice delle tabelle
- Tabella MetaData
- Dati MVCC (per supportare l'isolamento delle transazioni e la conformità ACID )
- Segmenti di rollback
- Annulla spazio
- Double Write Buffer (scrittura in background per impedire la dipendenza dalla cache del sistema operativo)
- Inserisci buffer (gestione delle modifiche agli indici secondari non univoci)
Vedi la rappresentazione pittorica di ibdata1
Per impostazione predefinita, innodb_file_per_table è disabilitato. Questo fa sì che tutti e quattro i tipi di pagina di informazioni eseguano l'archiviazione di un singolo file chiamato ibdata1. Molte persone cercano di diffondere i dati creando più file ibdata. Ciò potrebbe portare alla frammentazione dei dati e delle pagine dell'indice.
Questo è il motivo per cui consiglio spesso di ripulire l'infrastruttura InnoDB, usando il file ibdata1 predefinito e niente di più .
La copia è molto pericolosa a causa dell'infrastruttura in cui funziona InnoDB. Esistono due infrastrutture di base
- innodb_file_per_table disabilitato
- innodb_file_per_table abilitato
Con innodb_file_per_table disabilitato, tutti questi tipi di informazioni di InnoDB vivono all'interno di ibdata1. L'unica manifestazione di qualsiasi tabella InnoDB al di fuori di ibdata1 è il file .frm della tabella InnoDB. La copia di tutti i dati di InnoDB in una sola volta richiede la copia di tutti / var / lib / mysql.
Copiare una singola tabella InnoDB è totalmente impossibile. È necessario eseguire il dump MySQL per estrarre un dump della tabella come rappresentazione logica dei dati e delle definizioni dell'indice corrispondenti. Quindi caricare quel dump su un altro database sullo stesso server o su un altro server.
Con innodb_file_per_table abilitato, i dati della tabella e i relativi indici vivono nella cartella del database accanto al file .frm. Ad esempio, per la tabella db1.mytable, la manifestazione di quella tabella InnoDB al di fuori di ibdata1 sarebbe:
/var/lib/mysql/db1/mytable.frm
/var/lib/mysql/db1/mytable.ibd
Spazio tabelle di sistema ibdata1
Tutti i metadati per db1.mytable risiedono ancora in ibdata1 e non c'è assolutamente alcun modo per aggirare questo . Anche i registri di ripetizione e i dati MVCC vivono ancora con ibdata1.
Quando si tratta di frammentazione della tabella, ecco cosa succede a ibdata1:
- innodb_file_per_table abilitato : puoi ridurre db1.mytables con
ALTER TABLE db1.mytable ENGINE=InnoDB;
oOPTIMIZE TABLE db1.mytable;
. Ciò comporta /var/lib/mysql/db1/mytable.ibd fisicamente più piccolo senza frammentazione.
- innodb_file_per_table disabilitato : non è possibile ridurre db1.mytables con
ALTER TABLE db1.mytable ENGINE=InnoDB;
oOPTIMIZE TABLE db1.mytable;
perché risiede con ibdata1. Eseguendo effettivamente entrambi i comandi, rendere la tabella contigua e più veloce da leggere e scrivere. Sfortunatamente, ciò si verifica alla fine di ibdata1. Questo fa sì che ibdata1 cresca rapidamente. Questo è completamente affrontato nel mio post di pulizia di InnoDB .
Se stai pensando di copiare semplicemente il file .frm e .ibd, sei in linea con il mondo del male. La copia del file .frm e .ibd di una tabella InnoDB è utile solo se e solo se è possibile garantire che l'id del tablespace del file .ibd corrisponda esattamente alla voce dell'ID del tablespace nei metadati del file ibdata1 .
Ho scritto due post in DBA StackExchange su questo concetto di id del tablespace
Ecco un link eccellente su come ricollegare qualsiasi file .ibd a ibdata1 in caso di ID spazio tabella non corrispondenti: http://www.chriscalender.com/?tag=innodb-error-tablespace-id-in-file . Dopo aver letto questo, dovresti capire immediatamente che copiare i file .ibd è semplicemente folle.
Per InnoDB, devi solo fare qualcosa per spostarti
CREATE TABLE db2.mytable LIKE db1.mytable;
INSERT INTO db2.mytable SELECT * FROM db1.mytable;
per fare una copia di una tabella InnoDB.
Se lo stai migrando su un altro server DB, usa mysqldump.
Per quanto riguarda il missaggio di tutte le tabelle InnoDB da tutti i database, posso effettivamente vedere la saggezza nel farlo. Nella società di hosting DB / Web del mio datore di lavoro, ho un client MySQL che ha una tabella in un database i cui vincoli sono associati a un'altra tabella in un altro database all'interno della stessa istanza MySQL. Con un repository di metadati comune, rende possibile il supporto transazionale e l'operatività MVCC su più database.