Details
-
Type:
Bug
-
Status: Closed
-
Priority:
Critical
-
Resolution: Fixed
-
Affects Version/s: N/A
-
Fix Version/s: N/A
-
Component/s: Documentation
-
Labels:None
Description
Your documentation of the new aria engine is not very detailed, but for the option "aria_recover" none of the options are explained.
Today I had an automatic repair issue on the database, found this key which seems the right place, but there is absolutely NO documentation which option might solve my problem and what is the difference between them.
Gliffy Diagrams
Attachments
Issue Links
- relates to
-
-
- Closed
-
Activity
- All
- Comments
- Work Log
- History
- Activity
- Transitions
Ian Gilfillan, it's a valid complaint, there is a description of recovery options for MyISAM, but not for Aria.
Marc, until the documentation is updated, you can use the description for MyISAM, it's close enough.
Regarding the question why the table would get corrupted during normal operation in the first place, the likely reason is disk problems (disk space, inode deficiency, writing errors); if you've already ruled it out, please try running REPAIR or aria_chk on the table manually, maybe it will provide more information.
Also, the MySQL manual entry about repairing a MyISAM table might be helpful.
Hi,
thanks for the information so far.
What I found out was, that during the error first occured a backup was running:
Which means, the tables were locked by "FLUSH TABLES WITH READ LOCK", an lvm-snapshot was created, the lock was released and after the backup finished the snapshot was merged. Plain & simple.
I assume there was a strange situation in the time the snapshot is merged. Since this time I got regular log entries "Table 'X' is marked as crashed and last (automatic?) repair failed".
Just doing a "REPAIR X" has solved the issue; aria_repair was untouched and gave me the value "normal".
Currently I don't understand why the automatic repair didn't work.
had the same issue this night - found this bug report:
http://dba.stackexchange.com/questions/103451/debug-why-mysql-mariadb-table-is-crashing
I had a file named X.TMM too, which has 0 bytes and was created the time the first crash occured.
This file is not removed on restart or after repair. Maybe the problem exists since the file is not deleted and creating the file if it exists fails.
FYI: I'm using version 10.0.19
I have added some documentation about these options
Can you please provide a few reasons why an aria table crashes during normal server operation without any other messages in log than "Table x is marked as crashed and last (automatic?) repair failed"