Andrew Carlson wrote:
If you do what Baron suggests, you may want to set Innodb to create a
file-per-table - that way, in the future, you could save space when tables
are dropped, or you could recreate innodb tables individually to save space,
not have to dump all your innodb tables at one time.
I think this is a fantastic idea. So you would
- do your DB dump(horrible with hundreds of Gigs.)
- reset your my.cnf setting to include:
[mysqld]
innodb_file_per_table
- stop the db
- kill off the existing tablespace files
- restart the DB
- recreate the database and import your dump.
http://dev.mysql.com/doc/refman/5.0/en/multiple-tablespaces.html
So the only other question is what is the cost if any? It is a good idea
because often there are just a few tables that get really big and this
is a nice way to deal with them separately like you would with MyISAM.
Eric
On 10/10/07, Baron Schwartz <[EMAIL PROTECTED]> wrote:
Hi,
Tiago Cruz wrote:
Hello guys,
I have one monster database running on MySQL 4.0.17, using InnoDB:
270GB Oct 10 14:35 ibdata1
I've deleted a lot of register of then, and I've expected that the size
can be decreased if 50% (135 GB) but the ibdata was the same value than
before "clean"...
How can I force to save this space?
You must dump your data to files, shut down MySQL, delete your current
InnoDB tablespace and log files, reconfigure the server, restart MySQL
and let InnoDB create new (empty) files. Then reload the data.
You should probably save your current data and tablespace files until
you are sure you complete this successfully.
It's an annoying procedure but there is no other way.
Baron
--
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]
