Hello Heikki,
I didn't understand the concept of tablespaces utilized, ----- Original Message ----- From: "Heikki Tuuri" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Wednesday, October 22, 2003 12:00 PM Subject: MySQL/InnoDB-4.0.16 is released + sneak peek of 4.1.1 > Hi! > > InnoDB is a MySQL table type which provides transactions, row-level locking, > non-locking consistent SELECT (multiversioned concurrency control), foreign > key constraints, and a non-free hot backup tool for backing up InnoDB > tables. > > InnoDB is included in all MySQL-4.0 and 4.1 downloads, and also in the MySQL > Pro commercial, non-GPL MySQL license. > > Release 4.0.16 is a bugfix release of the stable 4.0 branch. There are a few > known outstanding bugs in InnoDB-4.0.16, but their fixing has been delayed, > 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 is > 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 > > 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 to 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, then InnoDB creates tables in the ibdata files > again. > > 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 > trick: > > 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: > > 1) There are no uncommitted modifications by transactions in the .ibd file. > 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 > files. > > 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 worked > right. > > * Fixed a bug: if one used the rename trick #sql... -> rsql... described in > 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 bugs > database. Their fixing has been delayed, because resources are allocated to > the upcoming 4.1.1 release. > > Best regards, > > Heikki Tuuri > Innobase Oy > http://www.innodb.com > > > > -- > MySQL General Mailing List > For list archives: http://lists.mysql.com/mysql > To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED] > > -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
