MySQL Reference Manual for version 4.0.18.

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

14.4.5.3 Multiple tablespaces - putting each table into its own .ibd file

IMPORTANT NOTE: if you upgrade to InnoDB-4.1.1 or higher, it is difficult to downgrade back to 4.0 or 4.1.0! That is because earlier versions of InnoDB are not aware of multiple tablespaces. If you need to downgrade to 4.0, you have to take table dumps and re-create the whole InnoDB tablespace. If you have not created new InnoDB tables under >= 4.1.1, and need to downgrade quickly, you can also do a direct downgrade to the MySQL version 4.0.18, or later in the 4.0 series. Before doing the direct downgrade to 4.0.xx, you have to end all connections to >= 4.1.1, and let `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:

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

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

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.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

This document was generated by rdg (Feb 25 2004) using texi2html