← Back to team overview

maria-discuss team mailing list archive

Re: WHY are TMM files never removed in 10.0.x

 



Am 22.08.2015 um 15:02 schrieb Elena Stepanova:
Hi Reindl,

On 22.08.2015 15:42, Reindl Harald wrote:

Am 22.08.2015 um 14:37 schrieb Elena Stepanova:
Hi Reindl,

On 22.08.2015 13:20, Reindl Harald wrote:
i was flooded once again with mcron-mails "ERROR 144 (HY000) at line 1:
Table './asterisk/cdr' is marked as crashed and last (automatic?)
repair
failed"

well, because mariadb creates such temp files and don't remove them
which makes myisam-recover-options = "FORCE" useless

Please check https://mariadb.atlassian.net/browse/MDEV-8475, it's
probably the same problem that you are experiencing. If so, it's fixed
in 10.1.6.

sounds similar

this really needs to be fixed in 10.0.x and was introduced with 10.0.x

There are two parts of the problem: that these stale files appear at
all, and that they are not removed.

MDEV-8475 describes and fixes the second part, and it exists at least in
5.5 as well, both MySQL and MariaDB, so it was not introduced in 10.0.x.
I suppose Monty had good reasons to fix it only in 10.1; but since there
seems to be a strong interest in this bugfix for 10.0, maybe he will
want to reconsider.

There is, however, still the first part, why these files appear. We have
a separate JIRA issue for it,
https://mariadb.atlassian.net/browse/MDEV-8571 -- still open with no
good way to reproduce. It is quite possible that *this* was indeed
introduced with 10.0.x, at least that's when people started observing
it. If you have any information on it, especially if you know how to
reproduce it reliably, please comment on the bug report (or here, if you
so prefer)

at least i faced this the first time after upgrade from 5.5.x to 10.0.x

given that we have around 30 MariaDB instances it's a strong indicator that with 10.0.x it got much worser and more likely to happen

each time on production machines with the same errors in the logfile and each time the "repair table" seems to have worked and a followed "optimize table" failed until i found out that this file exists

well, we have scripts checking the overhead of tables nightly and optimize them if it's larger than 100 KB and try to do this on random selected number of tables to not impact caches too much, likely because of that it gets more visible, but these scripts existing for many years starting with MySQL 5.0 in 2006 or so

Attachment: signature.asc
Description: OpenPGP digital signature


Follow ups

References