[MDEV-8461] option aria-recover not documented Created: 2015-07-14  Updated: 2015-07-16  Resolved: 2015-07-16

Status: Closed
Project: MariaDB Server
Component/s: Documentation
Affects Version/s: N/A
Fix Version/s: N/A

Type: Bug Priority: Critical
Reporter: Marc Assignee: Ian Gilfillan
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
Relates
relates to MDEV-8475 stale .TMM file causes Aria engine to... Closed

 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.



 Comments   
Comment by Marc [ 2015-07-14 ]

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"

Comment by Elena Stepanova [ 2015-07-14 ]

greenman, it's a valid complaint, there is a description of recovery options for MyISAM, but not for Aria.

mokraemer, 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.

Comment by Marc [ 2015-07-14 ]

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.

Comment by Marc [ 2015-07-15 ]

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

Comment by Ian Gilfillan [ 2015-07-16 ]

I have added some documentation about these options

Generated at Thu Feb 08 07:27:20 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.