Multiplos tablespaces - colocando cada tabela em seu próprio arquivo .ibd

NOTA IMPORTANTE: se você atualizar para o InnoDB-4.1.1 ou posterior, será difícil retornar a versão 4.0 ou 4.1.0! Isto ocorre porque versões anteriores do InnoDB não permitem vários tablespaces. Se você precisar retornar para a versão 4.0, você deverá fazer um dump das tabelas e recriar todo o tablespace do InnoDB. Se você não tiver criado novas tabelas InnoDB em versões posteriores a 4.1.1, e e precisar retornar a versão anterior rapidamente, você pode fazer um downgrade direto para a versão 4.0.18 do MariaDB, ou outra da série 4.0. Antes de fazer o downgrade diretamente para a versão 4.0.xx, você terá que finalizar todas as conexões a versões >= 4.1.1 e deixar o mysqld to run purge and the insert buffer merge to completion, so that SHOW INNODB STATUS shows the Main thread in the state waiting for server activity. Then you can shut down mysqld and start 4.0.18 or later in the 4.0 series. A direct downgrade is not recommended, however, because it is not extensively tested.

Starting from MySQL-4.1.1, you can now store each InnoDB table and its indexes into its own file. This feature is called multiple tablespaces, because then each table is stored into its own tablespace.

You can enable this feature by putting the line

innodb_file_per_table

in the [mysqld] section of my.cnf. Then InnoDB stores each table into its own file tablename.ibd in the database directory where the table belongs. This is like MyISAM does, but MyISAM divides the table into a data file tablename.MYD and the index file tablename.MYI. For InnoDB, both the data and the indexes are in the .ibd file.

If you remove the line innodb_file_per_table from my.cnf, then InnoDB creates tables inside the ibdata files again. The old tables you had in the ibdata files before an upgrade to >= 4.1.1 remain there, they are not converted into .ibd files.

InnoDB always needs the system tablespace, .ibd files are not enough. The system tablespace consists of the familiar ibdata files. InnoDB puts there its internal data dictionary and undo logs.

You CANNOT FREELY MOVE .ibd files around, like you can MyISAM tables. This is because the table definition is stored in the InnoDB system tablespace, and also because InnoDB must preserve the consistency of transaction id's and log sequence numbers.

You can move an .ibd file and the associated table from a database to another (within the same MySQL/InnoDB installation) with the familiar RENAME command:

RENAME TABLE olddatabasename.tablename TO newdatabasename.tablename;

If you have a clean backup of an .ibd file taken from the SAME MySQL/InnoDB installation, you can restore it to an InnoDB database with the commands:

ALTER TABLE tablename DISCARD TABLESPACE; /* CAUTION: deletes the current .ibd file! */
<put the backup .ibd file to the proper place>
ALTER TABLE tablename IMPORT TABLESPACE;

Clean in this context means:

• There are no uncommitted modifications by transactions in the .ibd file.
• There are no unmerged insert buffer entries to the .ibd file.
• Purge has removed all delete-marked index records from the .ibd file.
• mysqld has flushed all modified pages of the .ibd file from the buffer pool to the file.

You can make such a clean backup .ibd file with the following method.

• Stop all activity from the mysqld server and commit all transactions.
• Wait that SHOW INNODB STATUS\G shows that there are no active transactions in the database, and the main thread of InnoDB is Waiting for server activity. Then you can take a copy of the .ibd file.

Another (non-free) method to make such a clean .ibd file is to

• Use InnoDB Hot Backup to backup the InnoDB installation.
• Start a second mysqld server on the backup and let it clean up the .ibd files in the backup.

It is in the TODO to allow moving clean .ibd files also to another MySQL/InnoDB installation. That requires resetting of trx id's and log sequence numbers in the .ibd file.

Retornar