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

Tablespaces corrupt, MariaDB does not start

Details

    Description

      It was probably some power outage what caused the issue. I've tried forcing recovery by setting the `innodb_force_recovery` variable incrementally, and none of the recovery modes seemed to magically fix the problem. Using higher modes, at least MariaDB starts, but databases are corrupt and crash MariaDB as soon as I try to interact with them using the client. It's not like I had highly important data in my databases, but I think it's worth trying to fix, in case it happens again when I do have important data stored in it. I attached the systemd logs.

      Attachments

        Issue Links

          relates to

          Bug - A problem which impairs or prevents the functions of the product. MDEV-13542 Crashing on a corrupted page is unhelpful

          • Critical - Crashes, loss of data, severe memory leak.
          • Closed

          Activity

            marko Marko Mäkelä added a comment -

            Unfortunately, the mariadb-stacktrace.log is useless for any analysis, because the addresses were resolved incorrectly. With a correctly resolved stack trace (possibly from a core dump), it would be possible to identify which type of a page was corrupted. With the available information, I cannot know if it was an undo log page or an index page, and therefore I cannot give suggestions how to recover the rest of the data.

            There is no magic fix. The intended purpose of innodb_force_recovery is to allow you to dump the data. The option innodb_force_recovery=6 is the most dangerous one, because it will cause the redo log to be ignored altogether. Starting with 10.5 (thanks to MDEV-19514 removing the special meaning of innodb_force_recovery=4), it should be the only option that can corrupt the data further.

            If you have a copy of the data directory as it was before attempting innodb_force_recovery=6, then I would suggest that you attempt to invoke the server in a debugger. Because it is crashing at startup, this should be fairly easy. See also https://mariadb.com/kb/en/how-to-produce-a-full-stack-trace-for-mysqld/ for some hints.

            marko Marko Mäkelä added a comment - Unfortunately, the mariadb-stacktrace.log is useless for any analysis, because the addresses were resolved incorrectly. With a correctly resolved stack trace (possibly from a core dump), it would be possible to identify which type of a page was corrupted. With the available information, I cannot know if it was an undo log page or an index page, and therefore I cannot give suggestions how to recover the rest of the data. There is no magic fix. The intended purpose of innodb_force_recovery is to allow you to dump the data. The option innodb_force_recovery=6 is the most dangerous one, because it will cause the redo log to be ignored altogether. Starting with 10.5 (thanks to MDEV-19514 removing the special meaning of innodb_force_recovery=4 ), it should be the only option that can corrupt the data further. If you have a copy of the data directory as it was before attempting innodb_force_recovery=6 , then I would suggest that you attempt to invoke the server in a debugger. Because it is crashing at startup, this should be fairly easy. See also https://mariadb.com/kb/en/how-to-produce-a-full-stack-trace-for-mysqld/ for some hints.

            People

              marko Marko Mäkelä
              avalos Iván Ávalos
              Votes:
              0 Vote for this issue
              Watchers:
              2 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.