MySQL Forums
Forum List  »  InnoDB

Re: Different ibdata files for every database
Posted by: Rick James
Date: July 05, 2010 12:06PM

1. stop mysql
2. find the exact size, in bytes, of ibdata1
3. divide by 1048576 (1MB)
4. edit my.cnf (my.ini); use that number in ibdata1:#####M,ibdata2:10M:autoextend
5. start mysql

But why?

There is virtually no need for ibdata2 (etc) these days.

As for ibdata1:10M;ibdata2:10M;ibdata3:10M -- that tells InnoDB how to lay out 30MB of space on disk. InnoDB then sees one uniform tablespace of 30MB. It will scatter a 12MB table throughout the 30MB in whatever way it feels like. You cannot predict which 10M chunk(s) it will be in.

Look at it this way... That notation was quite useful in the "old days" when operating systems could not handle a single file bigger than 2GB (or maybe 4GB). InnoDB had grander plans -- tables bigger than 2GB. So, the solution was to hide the OS's inadequacies behind this notation.

For the last decade, the rational approach has been simply:
ibdata1:10M:autoextend
and let the file grow as needed.

Recently, a better approach came about -- innodb_file_per_table. This allows has each table owning its own tablespace, and the setting is not needed. However, InnoDB needs some space in the common tablespace (ibdata1), so the 10M:autoextend is still useful.

For those who are transitioning from the older methods to file_per_table, alas, there is no easy migration strategy. One has to dump the tables (mysqldump), drop ibdata*, change my.cnf, restart, and reload.

Note: No tablespace can ever be shrunken. ibdata1 can be restarted, as above. file_per_table can be restarted, but only by DROPping the table (possibly as part of an ALTER...ENGINE=).

Options: ReplyQuote


Subject
Views
Written By
Posted
Re: Different ibdata files for every database
2484
July 05, 2010 12:06PM


Sorry, you can't reply to this topic. It has been closed.

Content reproduced on this site is the property of the respective copyright holders. It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.