If a crash occurs in the middle of an ALTER, the files may not get cleaned up.
-Original Message-
From: Reindl Harald [mailto:h.rei...@thelounge.net]
Sent: Thursday, June 20, 2013 12:57 PM
To: mysql@lists.mysql.com
Subject: Re: How can I drop a table that is named “logs/#sql-ib203”
that is what we all know
but how to get rid of them?
but *why* they are not cleaned up?
* the global tablespace knows about them
* nothing is using them really
* so why can mysqld not cleanup this mess?
if you delete them all works fine but each start
the error-log is cluttered
Am 25.06.2013
SHOW GLOBAL STATUS LIKE 'Innodb%';
Then do some math -- usually dividing by Uptime.
That will give you some insight in how hard the I/O is working, and how full
the buffer_pool is.
-Original Message-
From: Rafał Radecki [mailto:radecki.ra...@gmail.com]
Sent: Friday, June 21, 2013 4:59
Yeah, why not flush them to disk on a clean shutdown, and periodically before
that?
-Original Message-
From: Dotan Cohen [mailto:dotanco...@gmail.com]
Sent: Sunday, June 23, 2013 10:39 AM
To: mysql.
Subject: UPDATE_TIME for InnoDB in MySQL 5.7
The MySQL 5.7 changelog mentions:
Switch to InnoDB so you won't have to repair after crashes.
Caution: InnoDB takes 2x-3x the disk space per table. Be sure to use
innodb_file_per_table=1.
Repair by sort. is usually much faster than repair by keycache; you
probably got 'sort' because of this being big enough:
