The ibdata1 file usually grows up to a very large size. The bad new is that the
ibdata1
file can´t actually be shrunk unless you delete all databases, remove the files and reload a dump.But you can configure MySQL so that each table, including its indexes, is stored as a separate file. In that way
ibdata1
will not grow as large. It was a while ago I did this. However, to setup your server to use separate files for each table you need to change
my.cnf
in order to enable this:[mysqld]
innodb_file_per_table
In this regard I found the following excerpt from the Mysql documents very enlightening:"You can store each
InnoDB
table and its
indexes in its own file. This feature is called “multiple
tablespaces” because in effect each table has its own
tablespace.
Using multiple tablespaces can be beneficial to users who want to move specific tables to separate physical disks or who wish to restore backups of single tables quickly without interrupting the use of other
InnoDB
tables.To enable multiple tablespaces, start the server with the
--innodb_file_per_table
option.
For example, add a line to the [mysqld]
section of my.cnf
:
[mysqld] innodb_file_per_table
With multiple tablespaces enabled,
InnoDB
stores each newly created table into its own
tbl_name
.ibd
file in the database directory where the table belongs. This is
similar to what the MyISAM
storage engine
does, but MyISAM
divides the table into a
tbl_name
.MYD
data file and an
tbl_name
.MYI
index file. For InnoDB
, the data and the
indexes are stored together in the .ibd
file. The
tbl_name
.frm
file is still created as usual.You cannot freely move
.ibd
files between
database directories as you can with MyISAM
table files. This is because the table definition that is stored
in the InnoDB
shared tablespace includes the
database name, and because InnoDB
must
preserve the consistency of transaction IDs and log sequence
numbers.
If you remove the
innodb_file_per_table
line from
my.cnf
and restart the server,
InnoDB
creates tables inside the shared
tablespace files again.The
--innodb_file_per_table
option affects only table creation, not access to existing
tables. If you start the server with this option, new tables are
created using .ibd
files, but you can still
access tables that exist in the shared tablespace. If you start
the server without this option, new tables are created in the
shared tablespace, but you can still access any tables that were
created using multiple tablespaces.
Note
InnoDB
always needs the shared tablespace
because it puts its internal data dictionary and undo logs
there. The .ibd
files are not sufficient
for InnoDB
to operate..ibd
file and the associated
table from one database to another, use a
RENAME TABLE
statement:
RENAME TABLEdb1.tbl_name
TOdb2.tbl_name
;
If you have a “clean” backup of an
.ibd
file, you can restore it to the MySQL
installation from which it originated as follows:
-
Issue this
ALTER TABLE
statement to delete the current.ibd
file:
ALTER TABLE
tbl_name
DISCARD TABLESPACE; -
Copy the backup
.ibd
file to the proper database directory. -
Issue this
ALTER TABLE
statement to tellInnoDB
to use the new.ibd
file for the table:
ALTER TABLE
tbl_name
IMPORT TABLESPACE;
.ibd
file backup is one for which the
following requirements are satisfied:
-
There are no uncommitted modifications by transactions in
the
.ibd
file. -
There are no unmerged insert buffer entries in 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.
.ibd
file using
the following method:
- Stop all activity from the mysqld server and commit all transactions.
-
Wait until
SHOW ENGINE INNODB STATUS
shows that there are no active transactions in the database, and the main thread status ofInnoDB
isWaiting for server activity
. Then you can make a copy of the.ibd
file.
.ibd
file is to use the commercial
InnoDB Hot Backup tool:
-
Use InnoDB Hot Backup to back up the
InnoDB
installation. -
Start a second mysqld server on the
backup and let it clean up the
.ibd
files in the backup.
No comments:
Post a Comment
Hi, Leave a comment here and one of the binary piper's will reply soon :)