Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-8461

option aria-recover not documented

Details

    • Bug
    • Status: Closed (View Workflow)
    • Critical
    • Resolution: Fixed
    • N/A
    • N/A
    • Documentation
    • 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.

      Attachments

        Issue Links

          relates to

          Bug - A problem which impairs or prevents the functions of the product. MDEV-8475 stale .TMM file causes Aria engine to stop serving the table

          • Major - Major loss of function.
          • Closed

          Activity

            Ascending order - Click to sort in descending order
            mokraemer Marc added a comment -

            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"

            mokraemer Marc added a comment - 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"
            elenst Elena Stepanova added a comment - - edited

            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.

            elenst Elena Stepanova added a comment - - edited 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.
            mokraemer Marc added a comment -

            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.

            mokraemer Marc added a comment - 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.
            mokraemer Marc added a comment -

            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

            mokraemer Marc added a comment - 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
            greenman Ian Gilfillan added a comment -

            I have added some documentation about these options

            greenman Ian Gilfillan added a comment - I have added some documentation about these options

            People

              greenman Ian Gilfillan
              mokraemer Marc
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Git Integration

                  Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.