Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
5.5(EOL), 10.0(EOL), 10.1(EOL)
Description
I'm not sure on which operation the file was created (assuming mysqloptimize), but assume you have this temp file.
You restart the server.
You can repair this table by hand, everything looks fine. If you have a cron job that does a mysqloptimize -A at nighty, this operation fails, the table is marked as crashed. You get the message "... is marked as crashed and last (automatic?) repair failed" inside the log.
No automatic repair will work. Doing a repair by hand, will work, but will not remove the temp file, as it is not removed by a full server restart.
Attachments
Issue Links
Activity
@Elena: that's what I was pointing out:
I have a cron job running every night for years the runs mysqloptimize -A
Two things changed recently updated mariadb 5.5.x -> 10.0.x
Upgraded tables from MyIsam to Aria.
Sine Mariadb 10.0 I can see is from time to time when mysqloptimize runs, one of the tables got stuck and runs into state "crashed". Since this doesn't happen every night, I assume some concurrent access to the table during optimize, which is interpreted as "crash".
The result of the next run of mysqloptomize is a stale .TMM file, so only the next run leads to exactly this bug.
I my description is clear enough to understand the problem.
PS: maybe I should open a new bug for this issue, cause this is not exactly this bug, but leads to it.
mokraemer,
My apologies, somehow I did not read from your description that you started getting corrupted tables after 5.5=>10.0 upgrade (as the matter of fact, I still don't, maybe it was in some other report?). I do see philsweeney mention it, but the comment is laconic, we'll need more details.
Anyway, getting corrupted tables is indeed a different story, especially if it looks like a regression from a previous version. So yes, please file a new bug report.
Hi Elena,
we switched from mysql 5.1 to Mariad 10.0 all the DB servers (more 100 servers) in 2 months. Now is 2 months that we are all db serves Mariadb 10.0 and we start to have randomly a stale tmm created when optimize run weekly. Thank you
@all: created a new bug for this problem.
@fustini: please comment / describe your problem there, so we get this fixed - hopefully in one of the 10.0 releases so linux distributors push this as an fix to current versions
Alessandro,
Before I can answer that, I need to understand something. This problem has apparently been around forever, in previous releases, in MySQL, everywhere. How did it happen that it suddenly started bothering you now? Has anything in your procedure changed?