![](https://secure.gravatar.com/avatar/359652f5d5394fdc76fea714c0e40c97.jpg?s=120&d=mm&r=g)
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