ailto:do-not-re...@mysql.com]
Sent: Tuesday, July 23, 2013 2:30 PM
Subject: #1341 [Com]: InnoDB ibdata1 never shrinks after data is removed
View this bug at: http://bugs.mysql.com/1341
Updated by: James Day
Reported by: Scott Ellsworth
Category: Server: InnoDB
Severity:
To shrink ibdata1:
1. Dump everything
2. Stop mysql
3. change to innodb_file_per_table = 1
4. change allocation in my.cnf (my.ini) to something smaller, say 50M,AUTOEXTEND
5. remove (rm / delete) ibdata1
6. restart mysql
7. reload data
Step 3: innodb_file_per_table gives you more fine-grained
However, this just popped up on my RSS reader. I haven't even looked at it,
> let alone tried it.
>
> I'm interested in what the experts think...
>
> "Getting rid of huge ibdata file, no dump required: You have been told
> (guilty as charged), that the only
Despite the conventional wisdom, converting to innodb_file_per_table will not
necessarily help you. It depends on your situation. If most of your growth is
in a single table, you will only have transferred the problem from the ibdata1
file to a new file. The ibdata1 file may also continue to
what the experts think...
>
> "Getting rid of huge ibdata file, no dump required: You have been told
> (guilty as charged), that the only way to get rid of the huge InnoDB
> tablespace file (commonly named ibdata1), when moving to
> innodb_file_per_table, is to do a logical
- Original Message -
> From: "Jan Steinman"
>
> That's been the common wisdom for a long time.
>
> However, this just popped up on my RSS reader. I haven't even looked
> at it, let alone tried it.
In brief: convert all your tables to myisam, delete ibdatafile during a
restart, convert
n what the experts think...
"Getting rid of huge ibdata file, no dump required: You have been told (guilty
as charged), that the only way to get rid of the huge InnoDB tablespace file
(commonly named ibdata1), when moving to innodb_file_per_table, is to do a
logical dump of your data, comp
or it could be that your buffer size is too small, as mysql is spending lot
of CPU time for compress and uncompressing
On Tue, May 22, 2012 at 5:45 PM, Ananda Kumar wrote:
> Is you system READ intensive or WRITE intensive.
> If you have enable compression for WRITE intensive data, then CPU cost
Is you system READ intensive or WRITE intensive.
If you have enable compression for WRITE intensive data, then CPU cost will
be more.
On Tue, May 22, 2012 at 5:41 PM, Johan De Meersman wrote:
>
>
> - Original Message -
> > From: "Reindl Harald"
> >
> > interesting because i have here a d
- Original Message -
> From: "Reindl Harald"
>
> interesting because i have here a dbmail-server with no CPU load and
> innodb with compression enabled since 2009 (innodb plugin in the past)
Ah, this is a mixed-use server that also receives data from several Cacti
installs.
> [--] Da
Am 22.05.2012 13:59, schrieb Johan De Meersman:
> - Original Message -
>> From: "Reindl Harald"
>>
>> 95% of mysqld-installations have no problem with
>> innodb_file_per_table so DEFAULTS should not be for 5%
>
> There is "no problem", and there is "better practice"
> and if your syste
- Original Message -
> From: "Reindl Harald"
>
> 95% of mysqld-installations have no problem with
> innodb_file_per_table so DEFAULTS should not be for 5%
There is "no problem", and there is "better practice" - and if your system is
I/O bound it makes sense to minimize on-disk fragmenta
Am 22.05.2012 13:52, schrieb Johan De Meersman:
> - Original Message -
>
>> From: "Ananda Kumar"
>
>> yes, Barracuda is limited to FILE_PER_TABLE.
> Ah, I didn't realise that. Thanks :-)
>
>> Yes, true there is CPU cost, but very less.
>> To gain some you have to loss some.
>
> I've
- Original Message -
> From: "Ananda Kumar"
> yes, Barracuda is limited to FILE_PER_TABLE.
Ah, I didn't realise that. Thanks :-)
> Yes, true there is CPU cost, but very less.
> To gain some you have to loss some.
I've only got it enabled on a single environment, but enabling it added
Am 22.05.2012 13:40, schrieb Johan De Meersman:
> - Original Message -
>> From: "Reindl Harald"
>> Subject: Re: Reducing ibdata1 file size
>>
>> well but for what price?
>> the problem is the DEFAULT
>>
>> users with enough knowl
- Original Message -
> From: "Reindl Harald"
> Subject: Re: Reducing ibdata1 file size
>
> well but for what price?
> the problem is the DEFAULT
>
> users with enough knowledge could easy change the default
> currently what is happening is that mostly
yes, Barracuda is limited to FILE_PER_TABLE.
Yes, true there is CPU cost, but very less.
To gain some you have to loss some.
On Tue, May 22, 2012 at 5:07 PM, Johan De Meersman wrote:
> --
>
> *From: *"Ananda Kumar"
>
>
> yes, there some new features you can use to im
- Original Message -
> From: "Ananda Kumar"
> yes, there some new features you can use to improve performance.
> If you are using mysql 5.5 and above, with files per table, you can
> enable BARACUDA file format, which in turn provides data compression
> and dynamic row format, which will
In regards to why the file grows large, you may wish to read some of
the posts on the MySQL Performance Blog, which has quite a bit of
information on this, such as
http://www.mysqlperformanceblog.com/2010/06/10/reasons-for-run-away-main-innodb-tablespace/
--
MySQL General Mailing List
For list ar
Am 22.05.2012 13:19, schrieb Johan De Meersman:
> - Original Message -
>> From: "Reindl Harald"
>>
>> as multiple said the default of a single table space
>> is idiotic in my opinion, but however this is well
>> known over years
>
> I suppose there's a certain logic to favouring one-sho
yes, there some new features you can use to improve performance.
If you are using mysql 5.5 and above, with files per table, you can enable
BARACUDA file format, which in turn provides data compression
and dynamic row format, which will reduce IO.
For more benefits read the doc
On Tue, May 22, 20
- Original Message -
> From: "Reindl Harald"
>
> as multiple said the default of a single table space
> is idiotic in my opinion, but however this is well
> known over years
I suppose there's a certain logic to favouring one-shot allocation and never
giving up free space, in that it red
- Original Message -
> From: "Pothanaboyina Trimurthy"
>
> hi sir,
Please keep the list in CC, others may benefit from your questions, too.
> can we see any performance related improvements if we use
> "innodb_file_per_table" other than using a single ibdatafile for all
> inn
> >>>> wrote:
> >>>>
> >>>>> Hi,
> >>>>>
> >>>>> I understand that if I set the innodb_file_per_table then once the
> >>> table
> >>>>> is drop the datafile w
is not possible, Innodb datafiles
> *never*
> > >>>> shrink.
> > >>>>
> > >>>> Cheers
> > >>>>
> > >>>> Claudio
> > >>>> On May 22, 2012 10:05 AM, "Kishore Vaishnav" <
> > kish...@railsfactory.org&g
gt; >> I understand that if I set the innodb_file_per_table then once the
>>> table
>>> >> is drop the datafile will also be lost. But is there a way where I
>>> >> truncate
>>> >> the table and the datafile shrinks itself ?
>>> >>
&g
t;Kishore Vaishnav" <
> kish...@railsfactory.org>
> >>>> wrote:
> >>>>
> >>>>> Hi,
> >>>>>
> >>>>> I understand that if I set the innodb_file_per_table then once the
> >>> table
> >
>>>>
>>>>> Hi,
>>>>>
>>>>> I understand that if I set the innodb_file_per_table then once the
>>> table
>>>>> is drop the datafile will also be lost. But is there a way where I
>>>>> truncate
>>
he table and the datafile shrinks itself ?
>>>
>>> *thanks & regards,
>>> ______*
>>> Kishore Kumar Vaishnav
>>> *
>>>
>>> *
>>> On Mon, May 21, 2012 at 6:43 PM, Johan De Meersman >> >wrote:
>>>
>&
t;> >>
>> >> I understand that if I set the innodb_file_per_table then once the
>> table
>> >> is drop the datafile will also be lost. But is there a way where I
>> >> truncate
>> >> the table and the datafile shrinks itself ?
>> >&g
t; >> is drop the datafile will also be lost. But is there a way where I
> >> truncate
> >> the table and the datafile shrinks itself ?
> >>
> >> *thanks & regards,
> >> __*
> >> Kishore Kumar Vaishnav
> >>
; *
>> On Mon, May 21, 2012 at 6:43 PM, Johan De Meersman > >wrote:
>>
>> > - Original Message -
>> > > From: "Manivannan S."
>> > >
>> > > How to reduce the ibdata1 file size in both LINUX and WINDOWS
>> > > mach
e -----
> > > From: "Manivannan S."
> > >
> > > How to reduce the ibdata1 file size in both LINUX and WINDOWS
> > > machine.
> >
> > This is by design - you cannot reduce it, nor can you remove added
> > datafiles.
> >
> >
3 PM, Johan De Meersman wrote:
> - Original Message -
> > From: "Manivannan S."
> >
> > How to reduce the ibdata1 file size in both LINUX and WINDOWS
> > machine.
>
> This is by design - you cannot reduce it, nor can you remove added
> datafile
- Original Message -
> From: "Manivannan S."
>
> How to reduce the ibdata1 file size in both LINUX and WINDOWS
> machine.
This is by design - you cannot reduce it, nor can you remove added datafiles.
If you want to shrink the ibdata files, you must stop all conn
to reduce the ibdata1 data file in MySQL. In
> MySQL data directory the ibdata1 data file is always increasing whenever I
> am creating a new database and inserting some data into database. If I drop
> the existing database, the table structures only dropped from the server
> but da
Hi ,
I am trying to reduce the ibdata1 data file in MySQL. In MySQL
data directory the ibdata1 data file is always increasing whenever I am
creating a new database and inserting some data into database. If I drop the
existing database, the table structures only dropped from the
To: Rozeboom, Kay [DAS]
Cc: mysql@lists.mysql.com
Subject: Re: Reusing "ibdata1" space
- Original Message -
> From: "Kay Rozeboom [DAS]"
>
> I realize that this would not return the unused space to the operating
> system. But would it return it to M
Rozeboom [DAS]"
> To: mysql@lists.mysql.com
> Sent: Friday, 18 November, 2011 5:06:44 PM
> Subject: RE: ibdata1 and undo log
>
> Thanks for the response, Johan.
>
> It would really help if I could determine when the ballooning is
> occurring. Do you know of any way to
: mysql@lists.mysql.com
Subject: Re: ibdata1 and undo log
- Original Message -
> From: "Kay Rozeboom [DAS]"
>
> 1) Can anyone verify that the additional (presently unused)
> space was allocated for the undo log?
> 2) Are the many 1-page segments a leftove
- Original Message -
> From: "Kay Rozeboom [DAS]"
>
> 1) Can anyone verify that the additional (presently unused)
> space was allocated for the undo log?
> 2) Are the many 1-page segments a leftover from a large undo
> log?
I'm not too hot on the InnoDB internals, but yes, the
We are running MySQL 5.0.77, and implemented our first production InnoDB
database a few months ago. The database is on a dedicated server and is
composed of 14 tables. No tables have been added or dropped since creation.
The "ibdata1" file is growing much faster than the database it
- Original Message -
> From: "Prabhat Kumar"
> I wonder, if there could be any method to regain InnoDB space other
> than dump the whole database and reimport.
Very simple answer to that: no.
--
Bier met grenadyn
Is als mosterd by den wyn
Sy die't drinkt, is eene kwezel
Hy die't dr
I wonder, if there could be any method to regain InnoDB space other than
dump the whole database and reimport.
Thanks,
On Thu, Nov 10, 2011 at 12:44 AM, Johan De Meersman wrote:
> - Original Message -
> > From: "Nick Khamis"
> >
> > I should mention that we have deleted the ib_* files i
- Original Message -
> From: "Nick Khamis"
>
> I should mention that we have deleted the ib_* files in the past.
I hope that was an accident, because if you thought that was a good idea I'm
sending someone over with the spiked cluebat.
Luckily for you, the solution to that particular p
Hello Reindl, I just noticed that I misspelled your name. Sorry about that!
Cheers,
Nick.
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/mysql?unsub=arch...@jab.org
M, Reindl Harald wrote:
> Am 01.11.2011 15:02, schrieb Rozeboom, Kay [DAS]:
>> We are running MySQL 5.0.77, and using INNODB in production for the first
>> time. The production database has a lot of inserts and deletes, and the
>> shared "ibdata1" file is continuall
Thanks to everyone who replied to my question.
Kay Rozeboom
Information Technology Enterprise
Iowa Department of Administrative Services
Telephone: 515.281.6139 Fax: 515.281.6137
Email: kay.rozeb...@iowa.gov
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To u
- Original Message -
> From: "Kay Rozeboom [DAS]"
>
> I realize that this would not return the unused space to the
> operating system. But would it return it to MySQL so that it could
> be re-used for subsequent inserts, instead of extending "ibdata1&quo
NNODB in production for the first
> time. The production database has a lot of inserts and deletes, and the
> shared "ibdata1" file is continually growing. I understand that to return
> the unused space to the operating system, we must delete and recreate
> "ibdata1"
Am 01.11.2011 15:02, schrieb Rozeboom, Kay [DAS]:
> We are running MySQL 5.0.77, and using INNODB in production for the first
> time. The production database has a lot of inserts and deletes, and the
> shared "ibdata1" file is continually growing. I understand that to r
We are running MySQL 5.0.77, and using INNODB in production for the first time.
The production database has a lot of inserts and deletes, and the shared
"ibdata1" file is continually growing. I understand that to return the unused
space to the operating system, we must delete an
odb table which was truncated after 150GB in mysql database.
>
>
> Reindl Harald wrote:
>> Am 02.10.2011 22:10, schrieb Dhaval Jaiswal:
>>
>>> Hi All,
>>>
>>> How to shrink the Mysql ibdata1 files.
>>>
>>> The actual size of database i
ibdata1 files.
The actual size of database is only hardly 10G, but ibdata1 is showing 73G
full. I did some googling and found the following procedure.
Do a mysqldump of all databases, procedures, triggers etc
Drop all databases
Stop mysql
Delete ibdata1 and ib_log files
Start
ke for MYISAM
> "ibdata1", "ib_logfile0", "ib_logfile1" will still exists and
> MUST NOT be removed but "ibdata1" will not grow endless
>
> i do not know "other benefits" but they are enough
>
> on the other hand - what are the benefits o
yes and after that you can do "optimize table" like for MYISAM
"ibdata1", "ib_logfile0", "ib_logfile1" will still exists and
MUST NOT be removed but "ibdata1" will not grow endless
i do not know "other benefits" but they are enough
on t
ote:
>
>
> Am 02.10.2011 22:10, schrieb Dhaval Jaiswal:
> > Hi All,
> >
> > How to shrink the Mysql ibdata1 files.
> >
> > The actual size of database is only hardly 10G, but ibdata1 is showing
> 73G
> > full. I did some googling and found the following proc
Am 02.10.2011 22:10, schrieb Dhaval Jaiswal:
> Hi All,
>
> How to shrink the Mysql ibdata1 files.
>
> The actual size of database is only hardly 10G, but ibdata1 is showing 73G
> full. I did some googling and found the following procedure.
>
> Do a mysqldump of a
Hi All,
How to shrink the Mysql ibdata1 files.
The actual size of database is only hardly 10G, but ibdata1 is showing 73G
full. I did some googling and found the following procedure.
Do a mysqldump of all databases, procedures, triggers etc
Drop all databases
Stop mysql
Delete
an out of disk space.
> 'SELECT COUNT(*) FROM general_log' returns 0, yet ibdata1 is still
> 49GB (started at 3GB before the INSERT; the source mysql.general_log,
> a CSV table, was initially 43GB). I tried TRUNCATE then DROP on
> general_log, then restarted mysqld, to no avail.
>
I recently tried to run
INSERT INTO general_log SELECT * FROM mysql.general_log;
but that failed a few hours in because I ran out of disk space.
'SELECT COUNT(*) FROM general_log' returns 0, yet ibdata1 is still
49GB (started at 3GB before the INSERT; the source mysql.general_log,
a
At 04:52 PM 7/16/2009, Todd Lyons wrote:
On Wed, Jul 15, 2009 at 11:58 AM, mos wrote:
>> I have backup all the database files(innodb engine).
>> Now I want to recover it as myisam engine offline.
>> Any suggestions?
>
> Why can't you copy the InnoDb files to another machine and open the
database
On Wed, Jul 15, 2009 at 11:58 AM, mos wrote:
>> I have backup all the database files(innodb engine).
>> Now I want to recover it as myisam engine offline.
>> Any suggestions?
>
> Why can't you copy the InnoDb files to another machine and open the database
> with another MySQL server? (You could do
Re: Any tool convert ibdata1/ib_logfile0/ib_logfile1 files to myisam
data offline
At 07:53 AM 7/15/2009, you wrote:
>hi all,
>
>I have backup all the database files(innodb engine).
>Now I want to recover it as myisam engine offline.
>
>Any suggestions?
Why can't you copy t
At 07:53 AM 7/15/2009, you wrote:
hi all,
I have backup all the database files(innodb engine).
Now I want to recover it as myisam engine offline.
Any suggestions?
Why can't you copy the InnoDb files to another machine and open the
database with another MySQL server? (You could do it on your
hi all,
I have backup all the database files(innodb engine).
Now I want to recover it as myisam engine offline.
Any suggestions?
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/mysql?unsub=arch...@jab.org
system. So long as you
haven't written lots of data to the file system since the loss the
restart shouldn't matter.
Do you know how to do this with Linux Suse ?
I have found how to do this.
The ibdata1 file size was 74G.
Maybe the undelete process will fail for such large f
Sebastien,
On Wed, May 27, 2009 at 11:35 AM, Sebastien MORETTI
wrote:
>>> I think it's too late for this, because the MySQL server has been
>>> restarted.
>>
>>
>> You may be able to recover from the file system. So long as you
>> haven't written lots of data to the file system since the loss th
Sebastien,
On Wed, May 27, 2009 at 11:24 AM, Sebastien MORETTI
wrote:
Hi,
Your data is gone (unless you can undelete it from whatever filesystems
you're using).
I think it's too late for this, because the MySQL server has been restarted.
You may be able to recover from the file system. So
Sebastien,
On Wed, May 27, 2009 at 11:24 AM, Sebastien MORETTI
wrote:
>> Hi,
>>
>> Your data is gone (unless you can undelete it from whatever filesystems
>> you're using).
>
> I think it's too late for this, because the MySQL server has been restarted.
You may be able to recover from the file
mysqld and the tables should be replaced with the old ones but with no
data.
Thanks for the schema.
But the main problem is the data. The generation process was near
completion when we lost ibdata1 file. So, no dump.
Andrew
-Original Message-
From: Sebastien MORETTI [mailto
a.
Andrew
-Original Message-
From: Sebastien MORETTI [mailto:sebastien.more...@unil.ch]
Sent: 27 May 2009 07:41
To: mysql@lists.mysql.com
Subject: ibdata1 lost
Hi,
Is there a way to recover data and/or database schema when ibdata1 file
has been removed (for InnoDB databases) ?
(MySQL 5.0.
* Undelete the file
* Restore from backup
* Apply the infinite monkey theorem
On Wed, May 27, 2009 at 8:41 AM, Sebastien MORETTI <
sebastien.more...@unil.ch> wrote:
> Hi,
>
> Is there a way to recover data and/or database schema when ibdata1 file has
> been removed (fo
Hi,
Is there a way to recover data and/or database schema when ibdata1 file
has been removed (for InnoDB databases) ?
(MySQL 5.0.26)
Thanks
--
Sébastien Moretti
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/mysql
In the last episode (Mar 26), Riccardo Michele Filippone said:
> Hello! First of all sorry for my terrible english.
>
> Well I've a big problem with ibdata1, this damn file increase its size
> constantly.
>
> I tryed to use innodb_file_per_table... but:
>
> - My
forgot the list, sorry :)
Walter Heck
-- Forwarded message --
From: Walter Heck - OlinData.com
Date: Thu, Mar 26, 2009 at 2:09 PM
Subject: Re: A problem relative ibdata1
To:
Cc: Riccardo Michele Filippone
Riccardo,
if you're ibdata1 file is growing fast, it means yo
ee if I am wrong.
Ciao
Claudio
2009/3/26 Riccardo Michele Filippone
> Well, I think it's abnormal because after a few days I can have a ibdata1
> of 7-8 GB!!! I don't think it's normal because, if ibdata1 continue
> is growth... I must be purchase a datacente :P
>
>
s per minute is it growing?
How many inserts do you have on the tables per second/minute/hour?
Ciao!
Claudio
2009/3/26 Riccardo Michele Filippone
> Hello! First of all sorry for my terrible english.
>
> Well I've a big problem with ibdata1, this damn file increase its size
> cons
Hello! First of all sorry for my terrible english.
Well I've a big problem with ibdata1, this damn file increase its size
constantly.
I tryed to use innodb_file_per_table... but:
- MySQL create a lot of ibd files for all DB (correct)
- ibdata1 is however created and increase its
thanks for help.. mas no success..
2007/8/24, Stut <[EMAIL PROTECTED]>:
>
> Adriano Ceccarelli wrote:
> > I removed accidentaly the files :
> > /var/lib/mysql/ibdata1
> > /var/lib/mysql/ib_logfile0
> > /var/lib/mysql/ib_logfile1
> >
> > how
eaning all innodb data in one idata
> file)
> you just deleted your data.
> If you have a recent dump, drop all innodb tables and use the dump to
> restore
>
>
> On 8/24/07 3:20 PM, "Adriano Ceccarelli" <[EMAIL PROTECTED]> wrote:
>
> > Hi,
> >
>
>> restore
>>
>>
>> On 8/24/07 3:20 PM, "Adriano Ceccarelli" <[EMAIL PROTECTED]> wrote:
>>
>>> > Hi,
>>> >
>>> > I removed accidentaly the files :
>>> > /var/lib/mysql/ibdata1
>>> > /var
p to
> restore
>
>
> On 8/24/07 3:20 PM, "Adriano Ceccarelli" <[EMAIL PROTECTED]> wrote:
>
> > Hi,
> >
> > I removed accidentaly the files :
> > /var/lib/mysql/ibdata1
> > /var/lib/mysql/ib_logfile0
> > /var/lib/mysql/ib_logfile1
&
ved accidentaly the files :
> /var/lib/mysql/ibdata1
> /var/lib/mysql/ib_logfile0
> /var/lib/mysql/ib_logfile1
>
> how can I remover them from data files
>
> note
>> show tables
> list all tables OK
>
>> desc wiki_text
> ERROR 1146 (42S02): Table '
Adriano Ceccarelli wrote:
I removed accidentaly the files :
/var/lib/mysql/ibdata1
/var/lib/mysql/ib_logfile0
/var/lib/mysql/ib_logfile1
how can I remover them from data files
note
show tables
list all tables OK
desc wiki_text
ERROR 1146 (42S02): Table 'intranet.wiki_text' doe
Hi,
I removed accidentaly the files :
/var/lib/mysql/ibdata1
/var/lib/mysql/ib_logfile0
/var/lib/mysql/ib_logfile1
how can I remover them from data files
note
> show tables
list all tables OK
> desc wiki_text
ERROR 1146 (42S02): Table 'intranet.wiki_text' doesn't exist
th
Thank you Duncan.
On Thursday 25 May 2006 12:02, balaraju mandala wrote:
> Hello All,
>
> I need some explanations about these files.
>
> 1. ibdata1
> 2. ib_logfile0
> 3. localhost-bin.index
> 4. localhost-relay-bin.01
> 5. master.info
> 6. relay-log.info
http://dev.mysq
Hello All,
I need some explanations about these files.
1. ibdata1
2. ib_logfile0
3. localhost-bin.index
4. localhost-relay-bin.01
5. master.info
6. relay-log.info
is these are standard names. I mean these file names are reserved for mysql?
and can be found, where mysql installed.
regards
which also backs up
MyISAM tables
http://www.innodb.com/order.php
- Original Message - From: "Alex" <[EMAIL PROTECTED]>
Newsgroups: mailing.database.myodbc
Sent: Tuesday, January 03, 2006 6:55 AM
Subject: Re: removing ibdata1 if some/all tables are not InnoDB?
H
Heikki Tuuri wrote:
Carl,
InnoDB does purge deleted rows from the ibdata files. Certain
PostgreSQL advocates have been spreading a claim that InnoDB would not
do that, but the claim is false.
Could You explain more about reusing space previously taken by deleted
rows? Is this concept simil
>
Newsgroups: mailing.database.myodbc
Sent: Tuesday, January 03, 2006 6:55 AM
Subject: Re: removing ibdata1 if some/all tables are not InnoDB?
HI Carl,
The ibdata file growth can be stopped by removing the autoextend
keyword in the my.cnf file.
In your my.cnf file th
HI Carl,
The ibdata file growth can be stopped by removing the autoextend
keyword in the my.cnf file.
In your my.cnf file the entry might be
innodb_data_file_path = ibdata1:256M:autoextend
If you want to stop the growth of that file and add another file then this
is what you want
You can stop the auto-growth of your ibdata1 file, and add additional
ibdata files (as needed) on different disks/partitions. However, you
cannot currently "shrink" the file without some work..
Check out the MySQL documentation for innodb_data_file_path (that is the
config settin
't need to keep logs of for very long.
I have a number of databases, almost all of which are using MyISAM or
HEAP, and one database using InnoDB. As such (or at least, as I
understand it) we have a ibdata1 file that will grow forever and
AFAIK there's no way to stop it growing forever fo
Hello.
>there, in fact, anything important in that ibdata1 file, or can I just
>shut down mySQL, move that file somewhere else, and then re-start mySQL?
Yes, this file contains important information.
>Is this possible, or am I stuck having my database server off-line for
>
Hello!
When I first set up my mySQL 4.1 server, I did not have the
"innodb_file_per_table" option set. I have since set this option, and
re-created all my tables so that they are now in individual innoDB
files. However, the original, 44GB ibdata1 file still exists and I
can't fi
2005 12:24 PM
To: mysql@lists.mysql.com
Subject: [SPAM] - Re: locating ibdata1 and *.ibd files in different
directories. - Bayesian Filter detected spam
Hello.
> symbolic links! Thats a neat solution. Question: when you say
> "symbolic links for databases" do you mean links to ib
Hello.
> symbolic links! Thats a neat solution. Question: when you say
> "symbolic links for databases" do you mean links to ibd files, ibdata1
> file, either, or something else?
I've meant symbolic links for databases. See:
http://dev.mysql.com/doc/refman/5.
ks.
> As far as I know, you can't specify the location of ibd files, they're
> stored in the
> database directory, however, you can use symbolic links for databases to have
> them in another place.
symbolic links! Thats a neat solution. Question: when you say
"sym
1 - 100 of 129 matches
Mail list logo