I didn't understand the concept of tablespaces utilized,
----- Original Message -----
From: "Heikki Tuuri" <Heikki.Tuuri@stripped>
To: <mysql@stripped>; <win32@stripped>
Sent: Wednesday, October 22, 2003 12:00 PM
Subject: MySQL/InnoDB-4.0.16 is released + sneak peek of 4.1.1
> InnoDB is a MySQL table type which provides transactions, row-level
> non-locking consistent SELECT (multiversioned concurrency control),
> key constraints, and a non-free hot backup tool for backing up InnoDB
> InnoDB is included in all MySQL-4.0 and 4.1 downloads, and also in the
> Pro commercial, non-GPL MySQL license.
> Release 4.0.16 is a bugfix release of the stable 4.0 branch. There are a
> known outstanding bugs in InnoDB-4.0.16, but their fixing has been
> because we are allocating all free resources to preparing the upcoming
> MySQL-4.1.1 release.
> A sneak peek of MySQL-4.1.1:
> NOTE: if you upgrade to InnoDB-4.1.1, you cannot downgrade any more! That
> because earlier versions of InnoDB are not aware of multiple tablespaces.
> The public BitKeeper source tree of 4.1 now supports multiple tablespaces
> for InnoDB. You can enable them with the line
> in the [mysqld] section of my.cnf. Then InnoDB stores each table into its
> own file
> in the database directory where the table belongs. This is like MyISAM
> but MyISAM divides the table to a data file tablename.MYD and the index
> tablename.MYI. For InnoDB, both the data and the indexes are in the .ibd
> If you remove the line, then InnoDB creates tables in the ibdata files
> InnoDB always needs the 'system tablespace', .ibd files are not enough.
> 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 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
> 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:
> 1) There are no uncommitted modifications by transactions in the .ibd
> 2) There are no unmerged insert buffer entries to the .ibd file.
> 3) Purge has removed all delete-marked index records from the .ibd file.
> 4) 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.
> 1) Stop all activity from the mysqld server and commit all transactions.
> 2) 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
> 1) Use InnoDB Hot Backup to backup the InnoDB installation.
> 2) Start a second mysqld server on the backup and let it clean up the .ibd
> 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.
> InnoDB changelog for 4.0.16:
> * Fixed a bug: contrary to what was said in the manual, in a locking read
> InnoDB set two record locks if a unique exact match search condition was
> used on a multi-column unique key. For a single column unique key it
> * Fixed a bug: if one used the rename trick #sql... -> rsql... described
> section 15.1 of http://www.innodb.com/ibman.html to recover a temporary
> table, InnoDB asserted in row_mysql_lock_data_dictionary().
> * There are several outstanding non-critical bugs reported in the MySQL
> database. Their fixing has been delayed, because resources are allocated
> the upcoming 4.1.1 release.
> Best regards,
> Heikki Tuuri
> Innobase Oy
> MySQL General Mailing List
> For list archives: http://lists.mysql.com/mysql
> To unsubscribe: