Hi... there is stuff inline there.
>> The logic behind this is probably that without innodb_file_per_table=1
>> and with several large ibdata files, the space IS freed up when one does
>> optimize table or drop table. The space is freed up inside the database
>> files and can be reused.
> well, and if you have this day 2 TB mysql-data and a year later
> get rid of 1 TB of it they allocated space can be REUSED for
> innodb but never for any other application
I did not say it is the right thing to not have an option to shrink the database or do
I tried to explain the logic that is probably put into this product. Another piece of
logic is that it is
not really typical for the databases to lose 50% of its volume. The databases usually
or can grow, or are destroyed. In that regard the product with this feature lacking
probably still covers
the needs of most. By comparison, Oracle did not provide ability to drop the datafiles
until, eh, version 8,
I believe, and it was not made easy until version 10.
>> If we think about it, the database product should only resolve problems of
>> the database space management, not of the OS space management.
> the database producht with default settings is the part starting
> the troubles of os-space-managment and this is idiotic, no other
> words for this!
I would say inconvenient. As I explained above, the OS space allocation problems that
be considered a corner case and thus be considered unimportant by MySQL development.
the problem of reclaiming 1 terabyte out of 2-terabyte database, one could resolve it with
creating a brand
new instance followed by export/import of data. It is not that there is no solution, it
is inconvenient to use.
> MY only luck is that i recognized this years ago after PLAYING
> with innodb and so i started with "innodb_file_per_table=1" from
> the begin with the first production database
Well, I would not base my database design on luck and playing. There should be good
of what the features do and what would be the plan to deal with file allocations should
grow, shrink or somerset.
> but the cases where ibdata1 is growing becasue ONCE bigger
> data was stored and never release the allocated space is a
Not exactly. A design problem is to build a server in such a way as that adding a feature
to remove datafiles
would be impossible (without major rebuild). I think this one can be added. I didn't
bother to check, but I
would be surprised if there isn't already an enhancement request for this