>>>
Hi... and some more stuff inline.
>>
>> Well, I would not base my database design on luck and playing. There
>> should be good awareness
>> of what the features do and what would be the plan to deal with file
>> allocations should the database
>> grow, shrink or somerset
>
> if you
Am 30.11.2011 01:11, schrieb Karen Abgarian:
>> 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.
On Nov 29, 2011, at 11:50 AM, Claudio Nanni wrote:
>
> This is not to say that MySQL could not have more of the file management
> features. For example, the ability to add or remove datafiles on the fly and
> the
> ability to detach tablespaces as collections of tables.
>
> That's where MySQ
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.
>
>
Am 29.11.2011 20:25, schrieb Karen Abgarian:
>
> On 29.11.2011, at 5:21, Reindl Harald wrote:
>> why is this dumb "innodb_file_per_table=0" default since MOST PEOPLE
>> have only troubles with it because they can not free space with
>> "optimize table" with no real benefits?
>
> The logic behind
>
>
> This is not to say that MySQL could not have more of the file management
> features. For example, the ability to add or remove datafiles on the fly
> and the
> ability to detach tablespaces as collections of tables.
That's where MySQL(read InnoDB) got stuck actually, it never introduced a
On 29.11.2011, at 5:21, Reindl Harald wrote:
>
> ibdata1 does NEVER get smaller, this is normal and a hughe problem
> in your case, only if you are using "innodb_file_per_table" which
> is NOT default would retire the space after drop tables
>
> why is this dumb "innodb_file_per_table=0" defaul
Am 29.11.2011 14:08, schrieb Luis Pugoy:
> Hello. I have the following problem.
>
> I was importing a large database to mysql using mysqldump. Unfortunately this
> filled up the whole disk, and
> mysqldump exited with an error that the table it is currently writing to is
> full. Checking df -h
Hello. I have the following problem.
I was importing a large database to mysql using mysqldump. Unfortunately
this filled up the whole disk, and mysqldump exited with an error that the
table it is currently writing to is full. Checking df -h it shows that the
disk usage is at 100%. I decided to dr
